Before dim, alpha, or repeats mean anything, this pile of photos has to exist.
Before dim, alpha, or repeats mean anything, this pile of photos has to exist.
Past prompting, past face-locking tools, into building the model itself
A face embedding tool locked the jawline. The character sheet held the wardrobe and the eye color steady across sixty renders. And there's still one thing missing that neither trick can supply: a specific, repeatable look for scenes the reference photo never covered, three-quarter angles, different outfits, different lighting, all recognizably the same person. That gap is what a trained LoRA closes, and it closes it by baking the character into the model's weights instead of asking the model to infer her fresh every single time.
Two earlier entries on this site covered the runtime side of consistency: a structured prompt sheet for the words, and IPAdapter FaceID, InstantID, and PuLID for feeding the model a reference photo at generation time. Training goes a step further and produces a small file, a LoRA, that the checkpoint loads permanently. No reference image needed at render time. No face-analysis node in the workflow. The character is just part of the model now.
Everything starts with the dataset, and it decides more of the outcome than any setting after it. A folder of reference photos of the subject, captioned, is the entire input. Coverage matters more than volume: different angles, different expressions, different lighting, ideally a few different outfits so the model learns the face and not the shirt. There is no single magic image count that every guide agrees on, coverage and caption quality matter more than hitting a specific number, but a common working configuration for a character LoRA is around 20 training images.
Kohya-ss's sd-scripts, the training engine behind the popular kohya_ss GUI, reads how many times each image repeats per epoch from the training folder's own name. A folder named 3_subjectname tells the script to show every image in it three times before moving to the next epoch, no separate config field required. Get that number wrong and the dataset silently trains too fast or too slow relative to everything else in the run.
Epoch and repeat math is straightforward once it's spelled out: 20 images at 3 repeats is 60 images seen per epoch, and a typical character LoRA run in this range trains for roughly 25 to 40 epochs, landing around 1,500 to 2,400 total training steps. That range is a starting point to watch and adjust, not a number to set once and trust blindly.
For Flux-based checkpoints, the tool most people reach for now is ai-toolkit by Ostris, describing itself as a toolkit for finetuning diffusion models and shipping a browser UI, flux_train_ui.py, that handles the upload, captioning, training, and publishing steps from one screen instead of a folder of config files. It's also the primary training path for FLUX.2, Z-Image, and Qwen Image, not just the original FLUX.1. The hardware floor is real: the project documents a minimum of 24GB of VRAM to run it.
One caveat worth knowing before picking a base model: FLUX.1-schnell doesn't train the same way FLUX.1-dev does. It needs a separate adapter, ostris/FLUX.1-schnell-training-adapter, bolted on to train against it at all, and for overall output quality, training against FLUX.1-dev is the better default. Grabbing schnell because it's the faster inference model and expecting training to behave the same way is the kind of assumption that costs an afternoon.
Civitai's on-site LoRA trainer removes the hardware question entirely, since it runs the whole process on Civitai's own servers. Upload the dataset, and the captioning step offers a real choice: tag-based captions or natural-language captions, plus a setting for whether to ignore existing captions, append to them, or overwrite them outright. Pick a base model and the trainer selects its own training engine to match, SD 1.5 and SDXL run through the familiar path, while newer architectures including Qwen, Z-Image, Flux2 Klein, and LTX2 route through the same AI-Toolkit engine covered above, and video models are handled by a separate engine called Musubi. It's the least technical route to a working LoRA, at the cost of the fine control a local sd-scripts run gives.
Here's the part a training guide should say plainly: for a character who appears in three images and never again, none of this pays for itself. Dataset collection, captioning, and a training run measured in dozens of minutes to a couple of hours is a real cost, and IPAdapter FaceID at a solid weight gets close enough for a one-off. Training earns its place for a recurring character, a persona that's going to show up across dozens of scenes, outfits, and styles over months, where loading one small file beats reloading a reference photo and a face-analysis node into every single workflow forever.
Those reference photos on the table at the top of this piece aren't a metaphor for the process, they're the actual first step. Everything after that, the folder name, the dim and alpha pair, the engine that runs the job, is just the machinery for turning that stack of photos into a face the model already knows.