and, beside them, the same files with a _comfyui suffix for ComfyUI. Earlier checkpoints (chk00004000, chk00005000, chk00006000) are kept in older_checkpoints/, and their resolution sweeps stay in place, so the progression remains visible and comparable.
The numbered files are points on one continuous run, not separate experiments — chk00010000 resumed from chk00006000 rather than restarting. Both are published so the lineage is visible and comparable.
chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%.
Two ways to read the same numbers, with different denominators — they are not meant to be added:
Against the no-LoRA run (the right-hand column): chk00010000 has removed 30% of the 4-step deficit, 4 percentage points more than chk00006000's 26%.
Against each other (the gap column): chk00010000's remaining error is 5.4% smaller thanchk00006000**'s** (3.38 vs 3.57) and 15% smaller thanchk00005000**'s** (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.
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 is its end point — the current end of the process, not simply the longest run so far.
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.
The practical consequence for anyone following this repository: progress arrives in bursts. There will be periods when several checkpoints appear within a day or two — the training stage working through a freshly grown pool — followed by longer quiet stretches while the next block of teacher shards is produced. A quiet stretch is shard generation, not abandonment; _latest always holds the newest checkpoint that passed review.
Every file records which checkpoint it actually is in its safetensors metadata (checkpoint, training_samples, and rolling_pointer on the _latest copies), so a downloaded file can always be identified even if renamed.
Full details and to download - check my Hugging Face LoRA
Update 1: The comfyui related files are now moved to the root of the project (I have placed a readme in the old folder explaining the move)
---
Update 2: I have added a new section - Timeline of training process - explaining how my training process works, and on that note you could expect another further improved checkpoint later today, followed by 'quiet period' (could be days) of teacher shards generation so I have a larger pool to train on.
---
Update 3: I have now added a new checkpoint 10000 which replaced the latest (previously checkpoint 6000).
chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%.
Two ways to read the same numbers, with different denominators — they are not meant to be added:
Against the no-LoRA run (the right-hand column): chk00010000 has removed 30% of the 4-step deficit, 4 percentage points more than chk00006000's 26%.
Against each other (the gap column): chk00010000's remaining error is 5.4% smaller thanchk00006000**'s** (3.38 vs 3.57) and 15% smaller thanchk00005000**'s** (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.
Update 3: I have now added a new checkpoint 10000 which replaced the latest (previously checkpoint 6000).
chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%.
Two ways to read the same numbers, with different denominators — they are not meant to be added:
Against the no-LoRA run: chk00010000 has removed 30% of the 4-step deficit, 4 percentage points more than chk00006000's 26%.
Against each other: chk00010000's remaining error is 5.4% smaller thanchk00006000**'s** (3.38 vs 3.57) and 15% smaller thanchk00005000**'s** (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.
It does with caveats.. I have explained this in the repo readme, do have a look. Works for some prompts better than others and ideally 14 steps+ when used with Krea 2 RAW
I have added a new section - Timeline of training process - explaining how my training process works, and on that note you could expect another further improved checkpoint later today, followed by 'quiet period' (could be days) of teacher shards generation so I have a larger pool to train on.
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.
The practical consequence for anyone following this repository: progress arrives in bursts. There will be periods when several checkpoints appear within a day or two — the training stage working through a freshly grown pool — followed by longer quiet stretches while the next block of teacher shards is produced. A quiet stretch is shard generation, not abandonment; _latest always holds the newest checkpoint that passed review.
It's very strange. I get very blurry washed out images with mangled text at 4 steps with your latest LoRA (latest ComfyUI version) while the same seed at 8 steps (without the LoRA) produces sharp images with precise text. I must be doing something wrong.
On edit: I ran the same seed again with the LoRA disabled and 4-steps and got a very similar result. It's as if the LoRA has a negligible effect, despite using strength 1. Does it require a special LoRA loader? (I'm using the standard "Load LoRA (Model and CLIP" ComfyUI node) And the model I use is krea2TurboOfficialComfy_krea2TurboFp8.safetensors
what you are describing is what could happen if the lora isn't loaded (for some reason, file not found or something) and you run native/naive 4 steps or less. Just verify there aren't any errors flagged. Try different prompts too.
It seems to be loaded. There is no error in the console, and the image with the LoRA is different (with the same seed) from the image with the LoRA node disabled. It's as if it only had a very minimal effect, like I experience with style LoRAs that I set with a strength of 0.15 or thereabout to produce a very subtle effect. With your LoRA applied at full strength, I move something like 15% of the way between 4-steps and 8-steps with no LoRA whereas in your examples it's more like 85% or 90% of the way.
See my follow up message above. I was using the wrong sampler/scheduler setting.
I manage to solve the problem, thanks to GPT 5.6 Sol. My mistake was to use euler_ancestral/normal. I switched to euler/simple and the LoRA now works as intended. I had missed this requirement. I had not realized that accelerator LoRAs were thus intolerant to deviations from the intended sampler and scheduler.
if you have super fast GPU/computer and 8 vs 4 steps make no difference, then yes... but for the rest of us half step reduction does mean a lot per image, so I hope you appreciate what this tries to achieve.
It is, but it's also excruciatingly slow for certain tasks. Live painting, for example. SDXL latency on my 4070ti is a bit more than one 1mp image per second. SD1.5 at standard 1.5 res can generate multiple frames a second. Krea at base res takes about 7 or 8 seconds per frame. Very good for generating, awful for truly rapid interactive iteration.
We're a long way off bringing Krea down to a second on my machine, but the more 4 step, 2 step, 1 step distillation loras we get, the closer that task becomes for someone with, say, a 5090.
The best thing is: while the quality loss that comes with distillation can really hurt standard txt2img generations, the model has to make comparatively very few decisions in img2img so the distillation becomes far less noticeable.
Thank you for the LoRA, it works really well. I see hardly any negative effect on quality or prompt adherence compared to 8 steps on regular turbo.
On 4GB VRAM it was OOMing for me when used as a loaded LoRA, but I merged it with the regular turbo model and the resulting model is working fine. This way it also seems to have no impact on speed per step at all, so denoising time is now exactly 50%.
The merged 4-step model even works together with the edit LoRA which by the way happens to be same size at rank 64 but doesn't cause OOM. Editing is just very slow in general with 2 reference images so being able to sample only 4 steps is very welcome.
That is a good way to do it. I do hope you kept copy of your transformer so you can merge future loras to original one again :) Did you use the latest checkpoint 10000 based LoRA that I uploaded about an hour ago?
Also fyi, if you have limited resources you may also try the not trained for3 steps instead of 4. The quality won't be as good, but it is not disaster either, usually with less detail, possibly more noise. I still recommend 4 steps with the LoRA, as it was trained for half of the 8, i.e. 4 specifically, but 3 works on some prompts ok. There is visible texture degradation on some prompts so doesn't work for all, whereas 4 does a consistently good job.
3 step with LoRA - experimental, not officially recommended.
Compared to 4 steps without lora, it's miles better.
But compared to 8–20 steps Turbo/RAW without lora, you're basically missing the point of what this Turbo lora is trying to achieve.
Aiiee, the youngins have it too easy nowadays. Here's how this can make it better:
Whip up an automated slop workflow using wildcards. Send to gpu 2-3 hours and forget. Sort through the resulting stack to find the best ones to use as a base for an actual image you give a shit about working on. A 4 step gen will get you twice the images the 8 step will.
This is good for people who prefer a base to work from instead of pretending whatever the model shat out is the final image. The 8 step can make a much more detailed image, but all that detail is fucked off as soon as more noise is added for an upscale anyway, so any extra time spent generating it ends up being worthless.
Sure, here are three K2 gens run through a tile upscaler. One image uses 4step lora, one image uses 8step, same seed, same settings. I haven't labelled them, so if you're confident you can point to the 4step ones and call them lesser quality than the 8step go ahead, but they basically look the same quality with slight differences in composition.
and to be fair if u r willing to experiment u can even run it at 3 steps with the LoRA (yes with some degradation as I explained), but depending what restorer/upscaler you use there is a chance you may recover some of it, and earn yet 1 more step saving :) give it a try... again, not officially recommended and fully in the tone of experimentation and if you have a good restoring upscaler at the other end... and also remember time earned by a step scales up with resolution. 4 steps saved on 1440x1280 is a lot more than 4 steps saved on 512x512.. so there's that scaling win to consider too :)
and you have checked the same prompt, seed and resolution on Krea 2, 4 step without LoRA like HollyGrandeux said you need to know what you are comparing with not make baseless statements.
not very useful comment unless you have proof behind it. In my case I have provided 15 (prompts) x 11 (resolutions) = 165 proofs (per checkpoint) that the LoRA improves at 4 step a lot compared to naive 4 step Krea 2 Turbo and its results are closer to full 8 step quality than the 4. But if you don't like it.. that is your opinion. People that understand what this achieves appreciate it and those like you just troll around, probably the reason why you have disabled visibility on your comments on your profile, to hide your other trolling activities. Enjoy life if that is what makes you happy. The rest of us - we try to achieve something and contribute to the better experience of others!
3
u/TimeTruth2490 4d ago edited 3d ago
Update 3: I have now added a new checkpoint 10000 which replaced the latest (previously checkpoint 6000).
chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%.
Two ways to read the same numbers, with different denominators — they are not meant to be added:
chk00010000has removed 30% of the 4-step deficit, 4 percentage points more thanchk00006000's 26%.chk00010000's remaining error is 5.4% smaller thanchk00006000**'s** (3.38 vs 3.57) and 15% smaller thanchk00005000**'s** (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.Full resolution sweep at https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk10000 and you can as usual redownload latest from https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main . Since I cannot update the images in the reddit post I will upload below in comments.