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.

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_chk00005000.safetensors	pin this exact checkpoint
krea2_turbo_4step_rank_64_lora_chk00004000.safetensors	the previous one, kept to show the progression

and under comfyui/, the same three with a _comfyui suffix.

The numbered files are points on one continuous run, not separate experiments — chk00005000 resumed from chk00004000 rather than restarting. Both are published so the lineage is visible and comparable; in side-by-side renders the two are close enough that picking a winner by eye is hard, which is itself worth knowing before assuming a higher number is automatically better.

_latest currently points to chk00005000 — 5,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, so it needs no edit. Pin a numbered file instead if you need reproducibility.

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_chk00005000.safetensors
                                   ^^^^^^^^

The number is the count of training samples consumed — chk00005000 has seen 5,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.

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 and a ready workflow are in comfyui/. 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 comfyui/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 chk00005000 — 5,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 (..._chk00005000_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 5 test prompts — 55 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.

checkpoint_resolution_sweeps/
└── chk5000/                one folder per checkpoint, named for the checkpoint it renders
    ├── 512x512/            one folder per resolution
    │   ├── portrait.jpg
    │   ├── kingfisher.jpg
    │   ├── neonstreet.jpg
    │   ├── market.jpg
    │   └── pizza.jpg
    ├── 768x512/
    ├── 1024x1024/
    ├── 1280x1280/
    └── 1440x1280/          …and the remaining buckets

Two ways to read them, both 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

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 NF4 (bitsandbytes) so the 28-block transformer, its gradients and the optimizer state fit alongside the activations. The teacher trajectories these checkpoints were distilled from were likewise rolled with an NF4-quantized teacher. 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.

The precision is uniform across resolution buckets: every bucket trains under the same NF4 base.

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

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

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

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

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

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

Chosen to stress different 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 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 after its renders have been reviewed and approved visually — automated loss metrics are used to catch catastrophes, never to decide that a checkpoint is good. A model that improves on every metric while looking worse is a real outcome, and metrics do not notice.

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.