Home Creators Posts Import Register Favorites Logout

Downloads

Content

🎥 Watch this workflow in action: timestamped to where I use Checkpoint Tester in the full video. If you want a visual walkthrough alongside this breakdown, that link jumps straight to it.

When you train a character LoRA, the training process saves multiple checkpoints along the way rather than producing just one final file. A run might save a checkpoint every 250 steps, meaning a 3000-step training run could leave you with over a dozen separate LoRA files to choose from. The instinct most people have is to just grab whichever one has the highest step count and assume that's the best result. That instinct is wrong more often than people expect. This workflow exists to actually prove which checkpoint is best by comparing them side by side instead of guessing based on step count alone.

This is the last step in the character LoRA pipeline, after a Face Creator identity photo has been used to generate a full dataset and that dataset has been used to train a run. This workflow is what tells you which of the resulting saved checkpoints to actually use.

One shared base model for every comparison

The base diffusion model, text encoder, and VAE only get loaded once in this workflow. A Diffusion Model loader pulls in krea2_turbo_fp8_scaled.safetensors, a Text Encoder loads qwen3vl_4b_fp8_scaled.safetensors set to the krea2 type, and a VAE Loader pulls qwen_image_vae.safetensors. All three feed into a single broadcast node that pushes the model, CLIP, VAE, and latent out to every branch in the workflow simultaneously.

Loading the base model once and broadcasting it guarantees every checkpoint gets tested against the exact same foundation. There's no risk of four separate loader chains accidentally drifting out of sync with each other and quietly invalidating the comparison.

Four checkpoints loaded side by side

From that shared base, four separate loader nodes each pull in a different saved checkpoint from the same training run.

Same character, same training run, four different points along the training curve, all loaded into the workflow at once so they can be generated and compared directly instead of testing them one at a time and trying to remember what the last one looked like.

Why fixing the seed and prompt is the whole point

Each of the four checkpoint branches runs through its own KSampler, and every setting across all four samplers is identical on purpose. Seed locked at 42, control after generate set to fixed, 8 steps, cfg 1.0, sampler euler, scheduler simple, full denoise at 1.00. All four branches also share the exact same positive prompt, a candid full body kitchen scene, and the exact same negative prompt.

This is the actual mechanism that makes the comparison meaningful. When the seed and the prompt are both fixed and the only variable changing between the four branches is which checkpoint got loaded, any visible difference you see in the four outputs is coming directly from the checkpoint itself. Not random noise, not prompt variation, not a different roll of the dice on the seed. If you tested each checkpoint separately using random seeds instead, you'd have no way of knowing whether a difference in output was the checkpoint actually improving or just a different seed producing a different result.

Assembling the comparison grid

Each of the four decoded outputs gets labeled directly on the image, "Checkpoint 1" through "Checkpoint 4," using an Add Label node. From there, three chained Batch Images nodes combine all four labeled outputs into a single batch, which feeds into a Side by Side Grid node set to four columns at 720 by 1280 per cell with 8 pixels of padding between them.

The end result is a single image: all four checkpoints laid out left to right, clearly labeled, same pose, same lighting, same everything except the actual training step behind each one. No flipping between separate saved files trying to remember which one was which.

What you're actually looking for

Early checkpoints usually show weaker identity lock, the face reads as close but not fully settled into the character yet. Later checkpoints can go the other direction, overtrained skin texture that starts looking a little waxy or plastic, or the model starting to lose some of the natural variety it had earlier in training. The checkpoint you actually want is usually somewhere in the middle of that range, not automatically the first one and not automatically the last one either.

For my Alyssa character, the training config saved a checkpoint every 250 steps. Rather than eyeball a handful of separate sample images generated during training, running the actual saved checkpoint files through this comparison grid afterward is what confirmed which specific step had the best identity lock without tipping over into overtrained.

Takeaway

Don't finish a training run and just grab whatever file has the highest step count in its filename. Run this comparison instead, fixed seed, fixed prompt, four checkpoints side by side, and let the actual output tell you which one to use. The extra few minutes this takes is what keeps you from shipping a character LoRA that's either undertrained or overbaked simply because you never actually looked.

Files

Comments

Mick B

Hey Mike, I am trying to deploy the Runpod But as you have already alluded to in another video Called how to get a runpod GPU when everything says unavailable I have searched for the script inside of the Discord and here in Patreon And I was trying to deploy the A40 48GB As it was half the price, as the L40S But I keep getting unavailable I wonder if there is a chance you could put the script in the ComfyUI hub please

LoRAtech - ComfyUI Hub

Yes I can post it in the masterclass tier for you for free, do you have a network volume?

Mick B

Currently I have Container disk Temporary storage that will be erased when the Pod is stopped 100GB Persistent storage: States it is under 1TB at 0.07 per month Is this correct? Sorry, I forgot to mention I changed it to Network volume

LoRAtech - ComfyUI Hub

yeah just make sure you make a network volume with like 50-100 GB to start out, and then youll be able to use the GPU deployer.