lvladikov/Krea2-Turbo-Distill-4step-LoRA

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.

• ⚡ Half the steps — 8 → 4, on Turbo's own deployment sigmas.
• ⏱️ ~1.6× faster end to end — 54.5 s against the 8-step bar's 88.7 s at 1024×1024, and 1.8× on denoise alone.
• 🎯 Detail, not just speed — it restores the high-frequency texture a halved schedule drops.
• 🔌 Drop-in — plain LoRA weights for diffusers and ComfyUI. No custom nodes, no patched sampler, no code.

Load it on top of Krea 2 Turbo, run 4 steps instead of 8, keep guidance at 0.0. Everything else about the model stays as it is.

Left: Turbo as shipped, 8 steps. Middle: 4 steps on its own — the detail a halved schedule loses. Right: 4 steps with this LoRA. Same seed throughout; click for full size. More comparisons in Examples.

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_chk00026000.safetensors	pin this exact checkpoint

and, beside them, the same files with a _comfyui suffix for ComfyUI. Earlier checkpoints (chk00004000, chk00005000, chk00006000, chk00010000, chk00014000, chk00019000) 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 — chk00026000 resumed from chk00014000, which resumed from chk00010000, rather than restarting.

chk00026000 removes 46% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00014000 removed 44% and chk00010000 40% — 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 4% smaller than chk00014000's and 10% smaller than chk00010000's — and unlike a purely teacher-forced score, the gain also shows up free-running: a full 4-call rollout from the teacher's noise ends 1.6% nearer the teacher's final latent than chk00014000's does. What the headline number is — and what it is not — is in chk00026000 vs chk00014000.

📌 _latest currently points to chk00026000 — 26,000 training samples. This line is updated whenever a newer checkpoint is published.

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.

Two earlier releases set the terms this project publishes on. chk00010000's first attempt — same data, optimiser left as it was — got steadily worse for 4,000 samples and none of it was published; retrained with cosine learning-rate decay and weight decay, every checkpoint improved on the one before it, and its end point shipped. chk00014000 added the other half of the lesson: the final, texture-deciding call of the schedule weighted more heavily in the loss, and a running average of the weights kept beside the live ones and scored at every evaluation — the averaged weights measured better than any checkpoint before them, so the average is what shipped. Left running past that point, the adapter's magnitude grew again and every later checkpoint measured worse. The number is chosen by measurement, not by how far a run went.

chk00026000 — the current checkpoint — is that discipline paying off. It resumes from chk00014000's averaged weights with the same recipe: same loss weighting, same running average, a conservative constant learning rate, over a much larger pool of teacher trajectories. This time the continuation held. The averaged weights' held-out gap fell throughout the run, and every free-running rollout measured of them improved on the one before — so unlike the first continuation, this one produced a checkpoint worth shipping. Every published number improves on chk00014000: the held-out gap (44% → 46% of the deficit closed), the full 4-call rollout from the teacher's noise (1.6% nearer the teacher's final latent), and the fixed-seed render distance to the 8-step images. chk00019000, an intermediate point of the same continuation, is kept in older_checkpoints/ with the rest of the lineage.

Timeline of training process

Each checkpoint is the product of three stages with very different costs:

1. Text-encoder embeddings. Every training prompt is encoded once and cached. This is the fast part — thousands of prompts take minutes.
2. 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.
3. 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.

The current checkpoint, chk00026000, runs the recipe the earlier releases arrived at — the final, texture-deciding call weighted more heavily in the loss, the shipped weights a running average of the trained ones — carried further over a larger pool of teacher trajectories, and published because it measured better on every evaluation. Each published checkpoint has measured a smaller gap to the teacher than the one it replaced; the earlier files stay in older_checkpoints/ for comparison only.

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.

Checkpoint numbering

krea2_turbo_4step_rank_64_lora_chk00026000.safetensors
                                   ^^^^^^^^

The number is the count of training samples consumed — chk00026000 has seen 26,000. It is not an epoch count, a step count, or a quality score. Higher-numbered checkpoints are further along the same continuous run, resuming from the previous checkpoint rather than restarting.

chk00026000 vs chk00014000

The measure. Every checkpoint is scored the same way. On a fixed set of held-out prompts that never receive a gradient step, the 4-step student's predicted velocity is compared with the 8-step teacher's recorded two-step chord at each of the four sigmas the student actually deploys on (see Method). The result is a relative error — the gap to the teacher — and it is deterministic: the same weights always score the same number. The set behind the figures below is the enlarged one: one hundred held-out prompts across all eleven trained resolutions (800 teacher states). Every earlier checkpoint has been re-scored on it, so all rows are comparable; the earlier, smaller set (eight prompts at four resolutions) gave different absolute values and is no longer used. Krea 2 Turbo run at 4 steps with no LoRA scores 4.69e-02 on this set; that is the deficit this LoRA exists to close.

	gap to the 8-step teacher	of the 4-step deficit closed
Krea 2 Turbo — 4 steps, no LoRA	4.69e-02	0%
chk00005000	3.26e-02	30%
chk00006000	3.45e-02	27%
chk00010000	2.81e-02	40%
chk00014000	2.64e-02	44%
chk00019000	2.62e-02	44%
chk00026000	2.53e-02	46%

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): chk00026000 has removed 46% of the 4-step deficit, about 2 percentage points more than chk00014000's 44%.
• 📈 Against each other (the gap column): chk00026000's remaining error is 4.2% smaller than chk00014000's (2.53 vs 2.64) and 10% smaller than chk00010000's (2.53 vs 2.81). 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.

(The larger set also reordered two early neighbours — chk00005000 edges chk00006000 on it — which is exactly why it replaced the original eight-prompt set.)

Read these as error figures, not as quality fractions. A plain 4-step run already produces a complete, coherent image; what it loses against 8 steps is fine detail and texture, and that loss shows up as its predictions sitting about 4.7% away from the teacher's. The LoRA brings that to about 2.5%. "46% of the deficit closed" therefore does not mean "46% of the teacher's quality" — it means 46% of that 4.7% error is gone. A gap of zero would be the student reproducing the teacher's two-step chords exactly, i.e. perfect 8-step equivalence in 4 steps, which no low-rank adapter on a frozen base reaches and which the images do not need in order to match.

Why it is better, not just later. chk00026000 continues the same run from chk00014000's averaged weights — recipe unchanged — and measures better everywhere the project measures. The averaged weights at 26,000 samples are what ships: 2.53e-02 against chk00014000's 2.64e-02 on the held-out gap. The improvement is not an artifact of teacher-forced scoring — a full 4-call free-running rollout from the teacher's noise ends 1.6% nearer the teacher's final latent, and every intermediate averaged checkpoint of the run (19,000, 22,000, 24,000) improved that rollout on the one before it. In fixed-seed renders of the fifteen published prompts at 1280×1280 it lands nearer the 8-step images than chk00014000 does (relative pixel distance 0.308 against 0.316), with texture energy at 0.88 of the teacher's against 0.87 (1.0 is teacher-like), without crossing it. chk00014000 earned its place against chk00010000 the same way — every one of the four calls improved, not just the weighted one — and that history stays with its files in older_checkpoints/.

What the number does not say. It is a training-space measure and does not rank images pixel for pixel. With a fixed seed the student's trajectory drifts away from the teacher's, so side-by-side renders differ in composition whatever their quality, and same-seed pixel distance cannot rank checkpoints. The visual evidence is the resolution sweeps and the Examples below — every published checkpoint is rendered at all 165 prompt/resolution combinations, so the metric and the images can be checked against each other.

This is not a Raw→Turbo diff

Other Krea 2 LoRAs in circulation are extractions: a low-rank projection of the weight difference between Krea 2 Raw and Krea 2 Turbo. Applied to Raw, they reproduce Turbo. They are a delivery mechanism for a model that already exists, and they stop at Turbo's 8 steps.

This one is different in both base and origin:

	Raw→Turbo extraction LoRAs	this LoRA
apply to	Krea 2 Raw	Krea 2 Turbo
produces	Turbo behaviour (8 steps)	4-step Turbo
origin	SVD of an existing weight delta	trained by distillation

It is trained, not extracted, and it assumes Turbo's weights underneath it — it shortens Turbo's own schedule rather than reproducing it.

Using it on Raw

This LoRA is trained on Krea 2 Turbo, against Turbo as its own teacher, and for Turbo. Every layer it targets also exists in Krea 2 Raw, so it will load there without complaint — but that is a side effect of the shared architecture, not a supported mode.

Results on Raw are mixed and subject-dependent. It does not give Raw a 4-step schedule: at very low step counts the adapter sharpens texture while composition is still unresolved, and subjects come out malformed — duplicated heads, fused limbs, faces that do not close. Expect to need 14 steps or more, keeping Raw's normal CFG on, before output is coherent. Even then some prompts come through well and others degrade into over-processed or blown-out images — and that degradation happens with or without the adapter, because it comes from shortening Raw's schedule rather than from the LoRA.

If you want the behaviour this was built for, run it on Turbo at 4 steps. If you are starting from Raw, move to Turbo first — with a Raw→Turbo LoRA or the Turbo weights directly — and apply this on top.

Usage

setting	value
base model	Krea 2 Turbo
LoRA scale	1.0
steps	4
guidance / CFG	0.0 (Turbo is CFG-free; do not enable it)
timestep shift	mu = 1.15, fixed (Turbo's deployment shift)

The 4 sampling sigmas are Turbo's own deployment grid: [1.0, 0.90453, 0.75951, 0.51284].

Performance — does it save time, or only steps?

It saves time. Measured at 1024×1024 on Apple Silicon (MLX, bf16), two prompts each, run strictly one at a time:

	load	denoise	total
Turbo 8 steps (the quality bar)	8.2 s	77.5 s	88.7 s
Turbo 4 steps, no LoRA	7.8 s	38.8 s	49.7 s
Turbo 4 steps + this LoRA	7.3 s	44.0 s	54.5 s

4 steps with the LoRA is ~1.6× faster than the 8-step bar — 54.5 s against 88.7 s, saving about 39% of the wall-clock. Counting denoise alone, where the step reduction actually applies, it is 1.8× (44.0 s against 77.5 s).

The adapter is not free, and its cost is in denoising rather than loading. Per step: 9.7 s without it, 11.0 s with it — about 13% slower per step, plus roughly 1.3 GB more peak memory (28.4 GB vs 27.1 GB). Loading the LoRA costs nothing measurable; the overhead scales with the number of steps you run, because the adapter's low-rank product is computed on every forward pass.

So the arithmetic is: each step costs 13% more, but you run half as many. Halving wins comfortably.

LoRA strength

Use 1.0. That is the value the adapter was trained at, and where its output sits closest to the 8-step reference.

Strength is worth understanding rather than tuning blindly, because what it scales is specific: this LoRA's job is to restore the high-frequency detail that a 4-step schedule loses — fine texture, edge definition, surface micro-contrast. The strength dial scales exactly that correction, so it does not make the image "more" or "less" of anything semantic; it decides how hard the texture recovery is applied.

strength	what happens
below 1.0	the correction is only partly applied — output lands between an unassisted 4-step render and a full one: softer, flatter, less recovered detail; you can use this with more steps if you want to experiment
1.0	the trained point, and the recommended setting
above 1.0	extrapolation past anything seen in training. The image does not break or fall apart — it becomes over-textured: surface detail grows denser than the subject warrants, fine structures turn wiry, and micro-contrast hardens until the result reads as stylised rather than photographic; you can try this with fewer steps, but quality is not guaranteed

The useful takeaway is that the failure mode above 1.0 is not noise or artifacts, which is what over-driving a LoRA usually looks like. It is the adapter doing its one job too enthusiastically, and it arrives gradually — 1.5 is heavy-handed but still coherent, 2.0 is clearly overcooked.

As a rule, reach for steps before strength: 1.0 at more steps is the dependable way to get more out of it. But strength and step count trade against each other, and the combinations in the table above are worth experimenting with if the defaults are not giving you what you want.

File format and compatibility

A plain .safetensors file — not tied to any framework or backend. It is weights plus a naming convention, so it loads under PyTorch (CUDA, MPS or CPU), MLX on Apple Silicon, or anything else that can read safetensors and do a matrix multiply.

container	safetensors
adapter weights	bf16 (lora_A, lora_B)
alpha	fp32 scalar per module, 64.0
rank	64 → effective scale alpha / rank = 1.0

Keys are diffusers module paths with PEFT-style suffixes:

transformer_blocks.0.attn.to_gate.lora_A.weight   (64, 6144)
transformer_blocks.0.attn.to_gate.lora_B.weight   (6144, 64)
transformer_blocks.0.attn.to_gate.alpha           scalar
time_embed.linear_2.lora_A.weight                 ...

applied the standard way:

W' = W + (alpha / rank) · (B @ A)

The one thing to watch when porting is naming, not framework. Runtimes that use their own layer names — ComfyUI, for instance, calls these diffusion_model.blocks.N.attn.gate with lora_down/lora_up — need a key remap first. The tensors themselves need no conversion.

ComfyUI

A pre-converted file (..._comfyui.safetensors) and a ready workflow sit in the repo root. No custom nodes — stock ComfyUI only.

file	put it in
krea2_turbo_4step_rank_64_lora_latest_comfyui.safetensors	ComfyUI/models/loras/
krea2_turbo_bf16.safetensors — Comfy-Org/Krea-2	ComfyUI/models/diffusion_models/
qwen3vl_4b_bf16.safetensors — same repo	ComfyUI/models/text_encoders/
qwen_image_vae.safetensors — same repo	ComfyUI/models/vae/

Then load krea2_turbo_4step_lora_t2i.json.

The workflow is full bf16, with no quantisation anywhere. bf16 needs no backend-specific kernel, so it runs unchanged on CUDA, Apple Silicon and CPU — one workflow, no platform caveats, nothing that depends on which device a component happens to land on.

Smaller builds work too; both loaders accept any variant, just set the matching filename:

diffusion model	size	NVIDIA	Apple Silicon
krea2_turbo_bf16 (workflow default)	26.3 GB	✅	✅
krea2_turbo_int8_convrot	13.5 GB	✅	✅
krea2_turbo_fp8_scaled	13.1 GB	✅	❌

The text encoder ships as bf16 (8.9 GB) or fp8 (5.2 GB) only — there is no int8 text encoder, so a fully matched int8 pair is not possible.

The LoRA is independent of the base build. It is applied on top of the diffusion model by ComfyUI's own loader, which handles any dequantisation, so a quantised or otherwise optimised build of Krea 2 Turbo behaves just as bf16 does. Please use whichever variant suits your hardware — set it in the Load Diffusion Model node and leave the rest of the workflow untouched. The workflow ships bf16 simply because it is the one build guaranteed to run everywhere.

🍎 fp8_scaled does not work on Apple Silicon. MPS has no Float8_e4m3fn support, so the run dies at the sampler with "Trying to convert Float8_e4m3fn to the MPS backend but it does not have support for that dtype". That failure is the weight dtype, not the workflow or the LoRA — the graph executes fine right up to the sampler. The fp8 text encoder does run on MPS, but only because ComfyUI places it on CPU; the published workflow does not rely on that.

📌 _latest_comfyui currently points to chk00026000 — 26,000 training samples.

The workflow references the _latest LoRA filename deliberately: as training continues and newer checkpoints are published, replacing that one file is enough — the workflow itself never needs editing. A numbered copy (..._chk00026000_comfyui.safetensors) sits beside it if you would rather pin a specific checkpoint in the node.

Why a separate file. ComfyUI addresses the transformer by its own layer names, so the adapter needs a key remap: transformer_blocks.0.attn.to_q.lora_A becomes diffusion_model.blocks.0.attn.wq.lora_down. The tensors are bit-identical — nothing is requantised or rescaled, only renamed. The mapping is verified against Comfy-Org's own Krea 2 LoRA: all 456 tensors land on keys that file also uses, with matching shapes.

alpha keys are omitted, as in Comfy's own file. ComfyUI defaults alpha to the rank when absent, giving scale = alpha/rank = 1.0 — exactly what alpha 64 at rank 64 encodes.

Settings

steps	4
cfg	1.0
sampler / scheduler	euler / simple
LoRA strength	1.0

⚙️ cfg 1.0, not 0.0. ComfyUI expresses "no classifier-free guidance" as cfg 1.0, whereas diffusers expresses the same thing as guidance 0.0. They mean the same: one forward pass per step, no negative branch. Setting 0.0 in ComfyUI is not the same thing and will not give you Turbo's intended behaviour. That is also why the workflow's negative input is a ConditioningZeroOut — at cfg 1.0 it is never evaluated, so there is nothing to write in it.

To compare against stock Turbo, set steps back to 8 and bypass the LoRA node with Ctrl+B.

Resolution sweeps

The Examples above are all 1024×1024. A single resolution is not enough to judge a checkpoint of this kind: the shard pool a checkpoint trains on is never evenly spread across buckets, and adapters carry recency bias, so a checkpoint can improve the resolution it saw most while quietly regressing the ones it barely saw. Only rendering every bucket shows that.

checkpoint_resolution_sweeps/ holds the full evidence: each published checkpoint rendered at all 11 trained resolutions, for all 15 test prompts — 165 images per checkpoint, same prompts, same seed, 4 steps, LoRA strength 1.0. Nothing is cherry-picked; a sweep is the complete set or it is not published.

The same folder also carries the measuring stick: _teacher-8step/ — the official Krea 2 Turbo 8-step reference renders: the stock model, no LoRA, at its native recommended settings (8 steps, guidance 0.0), for the same 15 prompts, the same seed and the same 11 resolutions. Those images are the teacher this LoRA is distilled from and the fixed quality bar every checkpoint is measured against — any sweep image can be compared 1:1 with the teacher's <WxH>/<prompt>.jpg.

checkpoint_resolution_sweeps/
├── _teacher-8step/         the official 8-step stock-Turbo reference renders (no LoRA)
├── chk4000/  chk5000/  chk6000/  chk10000/  chk14000/  chk19000/
└── chk26000/               one folder per checkpoint, named for the checkpoint it renders
    ├── 512x512/            one folder per resolution
    │   ├── portrait.jpg
    │   ├── kingfisher.jpg
    │   ├── … 13 more, one per published prompt
    │   └── snowleopard.jpg
    ├── 768x512/
    ├── 1024x1024/
    ├── 1280x1280/
    └── 1440x1280/          …and the remaining buckets

Three ways to read them, all useful:

• 🔍 down a checkpoint — does this checkpoint hold together across every resolution, or is it strong at one size and soft at others?
• 🔀 across checkpoints at one resolution — open the same <WxH>/<prompt>.jpg under two checkpoint folders to see what changed between them, with everything else held constant
• 🎯 against the teacher — open the same image under _teacher-8step/ to see how close 4 steps with the LoRA gets to the full 8-step render it is distilled from

The resolutions are exactly the training buckets listed under Resolutions. Sweeps are not generated for every checkpoint — only for those worth comparing, and a sweep is published only for a checkpoint that is itself published.

Method

Progressive distillation (PD), with Krea 2 Turbo as its own teacher.

The teacher runs its normal 8-step schedule at mu = 1.15 and guidance 0.0, and its full trajectory is recorded — the latent x and the predicted velocity v at every one of the 8 steps. The student is then trained to cover two teacher steps in one: at teacher state x_i it must predict the chord that lands where the teacher arrives two steps later,

v_target = (x_{i+2} − x_i) / (σ_{i+2} − σ_i)

The two schedules line up exactly rather than approximately. On the mu = 1.15 grid, the even indices of the 8-step schedule are precisely the four sigmas the 4-step student deploys on, so every training target is anchored on a point the student will actually visit at inference. No interpolation, no schedule mismatch.

Teacher trajectories are precomputed into shards, so training reads recorded states rather than re-running the teacher.

What the LoRA touches

Rank 64, alpha = rank (scale 1.0), bf16. 228 modules:

• 🧱 224 block linears — across all 28 transformer blocks: attn.to_q, attn.to_k, attn.to_v, attn.to_gate, attn.to_out.0, ff.gate, ff.up, ff.down
• 🌐 4 global (non-block) linears — time_embed.linear_1, time_embed.linear_2, time_mod_proj, final_layer.linear

Those four are included deliberately. Measuring Krea's own Raw→Turbo delta — a completed step distillation by the model's authors — shows the change is not concentrated in the blocks:

layer	relative ‖ΔW‖/‖W‖
time_embed.linear_2	0.0777 ← largest change in the whole network
time_embed.linear_1	0.0429
final_layer.linear	0.0265
typical block linear	~0.014

time_embed.linear_2 moves about 5.5× more than any block linear. Changing a model's step count is in large part a change to how it reads the timestep, so a LoRA that freezes the timestep path is withholding exactly the weights the task most needs.

Training data

Prompts are drawn from Lakonik/t2i-prompts-3m — sampled without replacement, deduplicated, and filtered for degenerate lengths. A held-out tail is reserved for validation and never receives a gradient step; it measures the student→teacher velocity gap on unseen prompts.

Resolutions

Training is multi-aspect across 11 buckets, so the adapter is not shaped by a single resolution or a single aspect ratio:

512×512	512×768	768×512
768×768	768×1024	1024×768
1024×1024	960×1280	1280×960
1280×1280	1440×1280

Buckets are interleaved in proportion to their remaining samples rather than run as a small-to-large curriculum, so every checkpoint along the way has recently seen all of them.

Hardware

Trained on a single RTX 3090 (24 GB VRAM), and the recipe is shaped by that ceiling.

The frozen base is quantized weight-only to int8 (blockwise-64) so the 28-block transformer, its gradients and the optimizer state fit alongside the activations. Since the frozen base sits under every gradient the adapter receives, its quantization error is training noise — the trade that makes a 24 GB card viable at all.

int8 was chosen over NF4 on measurement: on Krea 2's own weights it introduces ~0.007 relative error against NF4's ~0.096 — roughly 13× less — for about a 3% cost in step time. The teacher trajectories are rolled at the same precision, which matters more than it sounds: the targets are permanent, so the teacher's error is baked into every trajectory forever.

chk00006000 and every checkpoint after it are trained this way. Everything up to and including chk00005000 used an NF4 teacher and an NF4 base. On the same held-out set the cleaner targets were worth a 13% smaller gap to the teacher at chk00006000; the optimiser changes that followed took it further (see chk00026000 vs chk00014000).

There is a second, subtler effect worth stating plainly. Re-scoring the older chk00005000 against int8 targets instead of NF4 ones drops its measured gap-recovery from 28.9% to 17.9% — the weights did not change, the ruler did. Part of what looked like the adapter improving the model was it fitting the teacher's own quantization noise. Cleaner targets make the remaining gap honest.

NF4 survives in exactly one role. At or above ~1.5 MP (1280×1280 and 1440×1280) a full int8 step does not fit in 24 GB, so for those two buckets the attention weights drop to NF4 while the feed-forward weights stay int8. Feed-forward keeps the higher precision because that is where the learned deltas concentrate — ff.down was the single largest mover in Krea's own Raw→Turbo delta. Every other bucket trains under full int8.

Any of this affects training only. The released LoRA is bf16 and is applied to the unquantized base.

Examples

Every sheet below is three renders at the same seed: the base model as shipped, the base model at the reduced step count without the LoRA, and the same reduced step count with it. Each panel is captioned with its own steps, CFG and NFE. Click any image for the full-size version.

NFE = number of function evaluations: how many times the model itself is run, and the honest unit of cost — steps are not, because a step with CFG runs the model twice (once conditional, once unconditional). Turbo is CFG-free, so here NFE equals steps: the 8-step reference costs 8, and this LoRA's 4 steps cost 4. Wall-clock tracks NFE.

How to read these sheets. Compare the second and third panels — they run the same step count and differ only by the adapter, so that pair isolates what the LoRA does. The first panel is the quality bar, not a pixel-level target: changing the step count moves the sampling trajectory by itself, so the full-step render often differs in pose and framing from both reduced-step panels regardless of whether the LoRA is loaded. Same seed throughout; the seed fixes the starting noise, not the destination.

Krea 2 Turbo — 8 steps → 4 steps

One section per prompt: the three-panel comparison first, then the individual renders — click any image for full size.

Portrait of a young woman with freckles and windswept auburn hair, soft window light, shallow depth of field, photograph, sharp detail

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A kingfisher bird bursting out of water with spread wings, water droplets frozen mid-air, iridescent blue and orange feathers, high-speed photography

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

Rainy night city street with glowing neon shop signs and readable text, wet asphalt reflections, pedestrians with umbrellas, cinematic

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

Busy outdoor street market crowded with many people browsing colorful fruit and vegetable stalls, awnings, midday sun, wide shot, photorealistic

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

Overhead shot of a rustic wood-fired pizza with bubbling melted cheese, basil leaves, charred crust, on a dark wooden table, food photography

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A young swordsman leaping through falling cherry blossoms, dynamic action pose, anime key visual, crisp linework, vivid colors

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A giant mecha standing in a rain-soaked city plaza, anime style, panel lining, glowing cockpit, dramatic low angle

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A fox in a red scarf reading a book under a mushroom, children's storybook illustration, watercolour texture, soft edges

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A curious young inventor girl with oversized goggles, 3D animated film style, subsurface skin, soft studio lighting, shallow depth of field

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A claymation chef holding a tiny cake, visible fingerprints in the clay, miniature set, tilt-shift

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A gleaming white colony ship in orbit above a turquoise ocean planet, smooth curved hull, glowing cyan engine rings, brilliant sunlight, clean sci-fi concept art, bold simple shapes, vivid colors

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A sleek winged drone gliding between glowing futuristic skyscrapers at night, bright lit avenue far below, deep blue sky above, digital matte painting, bold clean forms, vivid colors

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A storm sorceress channelling lightning, video-game splash art, bold rim lighting, energetic brush strokes, high contrast

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A formula 1 futuristic looking racing car beefed up with a lot of technology mid-corner on a wet track, motion blur background, photorealistic motorsport photography

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

A snow leopard walking along a rocky ridge in falling snow, telephoto wildlife photograph, natural light

3-way comparison — one image, all three renders side by side

Individual frames — click any panel to open that render full size

Turbo — 8 steps	Turbo — 4 steps, no LoRA	Turbo — 4 steps + this LoRA
as shipped · 8 NFE	the deficit this closes	_latest · 4 NFE

---

Why these prompts

The first five stress classic photographic failure modes — skin and hair, frozen motion and fine droplets, legible text and reflections, many small faces and repeated objects, and close-range texture. The ten that follow were added after community requests for broader style coverage: anime and cel animation, storybook and claymation, 3D animated film, video-game splash art and concept painting, plus photorealistic subjects (motorsport, wildlife, night cityscape) that lean on motion, weather and low light. Flat-colour styles are deliberately included: large uniform regions with hard edges expose step-reduction artifacts (banding, mushy line weight) that photographic texture hides.

The individual renders behind each sheet are in assets/ too. LoRA renders are named ..._4step_lora_latest.jpg and are regenerated whenever _latest moves to a newer checkpoint, so the images always show what the current file actually produces. Each sheet's caption states the checkpoint it was rendered with. Base-model references (..._4step.jpg, ..._8step.jpg) carry no checkpoint in their name because they do not depend on one.

Status

Work in progress, published as an ongoing lineage. A checkpoint is published only when it improves the held-out gap to the teacher on the fixed evaluation set and its full resolution sweep is rendered and checked for regressions. Both are required: the metric is the ranking, the sweep is the guard against a checkpoint that scores well while rendering worse.

Training is continuing on a growing pool of teacher trajectories, so expect the set to grow. Each checkpoint is a self-contained LoRA; take whichever one you prefer.

Notes and limitations

• 🎯 Krea 2 Turbo only. It is trained against Turbo's weights and Turbo's schedule.
• 🚫 Keep guidance at 0.0 — in ComfyUI that is cfg 1.0, not 0.0 (see ComfyUI). Turbo is CFG-free and this LoRA does not change that.
• 📐 Keep mu = 1.15. The training targets are anchored to that grid; a different shift moves the student off the sigmas it was trained on.
• 🔬 Training quantizes the frozen base (see Hardware). That affects training only — the released LoRA is bf16 and is applied to the unquantized base.