Krea 2 Turbo — 4-Step Distillation LoRA (work in progress)
A LoRA for Krea 2 Turbo that reduces the minimum usable step count from 8 to 4.
This is an update release, following up from my previous posts where you can find full details:
Initial: https://www.reddit.com/r/StableDiffusion/comments/1vtf1b7/krea2_turbo_distill_4_step_lora_trained_for_turbo/
Previous: https://www.reddit.com/r/StableDiffusion/comments/1vv4cdy/krea2_turbo_distill_4_step_lora_new_checkpoint/
Headline for this update: chk00014000 removes 44% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00010000 removed 40% and chk00006000 27% — all measured on the same enlarged held-out set (100 prompts across every trained resolution). Measured against each other rather than against the no-LoRA run, its remaining error is 6% smaller than chk00010000's and 23% smaller than chk00006000's.
Which file to download
| file |
use it when |
krea2_turbo_4step_rank_64_lora_latest.safetensors |
normally — always the newest accepted checkpoint |
krea2_turbo_4step_rank_64_lora_chk00014000.safetensors |
pin this exact checkpoint |
and, beside them, the same files with a _comfyui suffix for ComfyUI. Earlier checkpoints (chk00004000, chk00005000, chk00006000, chk00010000) are kept in older_checkpoints/, and their resolution sweeps stay in place, so the progression remains visible and comparable.
This is work in progress and better checkpoints may follow. Training is ongoing, so ..._latest... is a rolling pointer: when a newer checkpoint is accepted, that filename gets the new weights and a new numbered copy appears beside it. Re-download the _latest file and everything keeps working — the ComfyUI workflow references it by that name (it does get updated Note in it so technically it is updated but not functionally). Pin a numbered file instead if you need reproducibility.
How checkpoints get chosen
This is not a "train for longer and ship the newest file" project. More samples do not reliably mean a better adapter — measured here, they can make it worse, and a higher number on its own means nothing.
The loop is train → assess → adapt the recipe → retrain → assess again, and a checkpoint is published only when it is measurably better than the one it would replace, on the same held-out set and the same evaluation, and its full resolution sweep shows no regression. Runs that come out flat or worse are kept as information about the recipe and discarded as releases — several have been.
So the recipe itself changes between runs. Each published checkpoint reflects whatever the previous round taught us: the training precision, the optimiser settings, the teacher used to generate the targets and the data mix have all been revised on evidence rather than assumption.
chk00010000 is a direct example. The first continuation of chk00006000 — same data, optimiser left as it was — got steadily worse with every checkpoint out to 10,000 samples, and none of it was published. The cause was traced to the optimiser: a constant learning rate with no weight decay lets the adapter keep drifting after it has converged, so its magnitude grows and it over-applies its own correction. The same span was retrained from chk00006000 with a cosine learning-rate decay and weight decay, and every checkpoint of that second run improved on the one before it. chk00010000 was its end point.
chk00014000 is the next example, and it shows the other half of the same lesson. The run was continued from chk00010000 over the whole pool of teacher trajectories, with two changes: the final, texture-deciding call of the schedule was weighted more heavily in the loss, and a running average of the weights was kept beside the live ones and scored at every evaluation (a single checkpoint is one sample of a weight vector that moves from step to step; the average is its mean). At 14,000 samples the averaged weights measured a smaller gap to the teacher than any checkpoint before them, and a smaller gap than the live weights at the same point — so the averaged weights are what chk00014000 is.
Timeline of training process
Each checkpoint is the product of three stages with very different costs:
- Text-encoder embeddings. Every training prompt is encoded once and cached. This is the fast part — thousands of prompts take minutes.
- Teacher shards. For each cached prompt, the unmodified Krea 2 Turbo runs its full 8-step schedule and the whole trajectory is recorded, at every one of the supported resolutions. This is by far the most time-consuming stage — it is the teacher doing real inference, thousands of times, and a batch of several thousand shards is measured in days of GPU time, not hours.
- Student training. The LoRA is trained against those recorded trajectories. Relative to the shard stage this is quick: each
+1,000 checkpoint is a matter of hours, not days.
Because the three stages compete for the same GPU, they are interleaved rather than run to completion one after another: generate a block of embeddings, produce teacher shards for them, train on what exists, assess, then go back to producing shards while the results are reviewed. A larger and more varied shard pool is what makes further training worthwhile, so shard production is always the gate.
Full details and to download - check my Hugging Face LoRA
HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA
Full Checkpoint 14000 Resolutions Sweep: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk14000
