Following up from my 2 Step and 4 Step Krea 2 Turbo LoRAs, an even easier way to create Krea 2 Turbo content fast with the LoRAs, with best in class performance and ease of use from both local ComfyUI Desktop use (including not only the usual Torch support, but also optimised Apple Silicon MLX / MFLUX super fast processing and performance) as well as ComfyUI Cloud (for those of you with subscriptions), so I have prepared 3 Workflows/Apps and a bunch of supporting Custom Nodes (LVNodes) to allow me to achieve that - Torch, MLX and Cloud. I have also added support for both Raw and Turbo Krea 2 models, and now added as well Z-Image Base and Turbo in the workflows and apps.

Highlights:

• 🖼️ Two apps, three editions each — Krea 2 and Z-Image, each for Comfy Cloud, local ComfyUI (PyTorch) and Apple MLX: one App view with about 20 inputs, the full graph behind it, and Notes inside that explain every input
• 🌀 Turbo and Raw / Base in one app — a Model switch at the top, and only the chosen model loads: Krea 2 Turbo (4 steps) or Krea 2 Raw, the undistilled base (28+ steps at CFG 4.5; Krea's own: 52 at 3.5); Z-Image Turbo (8 steps) or Z-Image (Base) (28–50 steps at CFG 3–5). Raw and Base get a Negative prompt, always used exactly as typed (never through prompt enhancement), and CFG; 1, the default, suits Turbo and every step-LoRA run
• 🎛️ Settings follow the model (local) — pick a model and Steps, Enable step LoRAs and CFG switch to its recommendations on the spot: Krea 2 Raw to 28 steps, step LoRAs off, CFG 4.5, and back to 4 steps, on, CFG 1 for Turbo (Z-Image Base: 28 steps, CFG 4; Turbo: 8 steps, CFG 1). What the fields show is what runs, and you can change any of them afterwards. It's a page add-on in LVNodes, and Comfy Cloud only runs the node packs it has installed itself, so it can't load it; on Cloud you set those fields by hand, and their hints give the same values
• ⚡ Steps pick the step LoRA — switched inside the graph, with one Step LoRA strength. Krea 2, with the 2-step and 4-step distill LoRAs: 2–3 steps the 2-step, 4+ the 4-step, the native model from 7 on Turbo (from 28 on Raw). Z-Image, with alibaba-pai's Z-Image-Fun-Lora-Distill: 1–3 steps the 2-step, 4–7 the 4-step, 8–10 the 8-step, none from 11
• 🎚️ Enable step LoRAs — off runs the native model at any step count. On by default for Krea 2, whose LoRAs are trained for Turbo (Raw is best with them off); off by default for Z-Image, whose LoRAs are made for Base (Turbo is best without)
• 🎯 Each model's own sampling — Krea 2 Raw gets its own resolution-dependent shift (Turbo, and Raw with a step LoRA, Turbo's fixed 1.15); Z-Image gets Tongyi's shift (3 for Turbo, 6 for Base without a step LoRA) and res_multistep, on every edition, MLX included. Z-Image also offers a choice of VAE: FLUX.1's own, UltraFlux for sharper detail, or locally TAEF1 for speed
• 📊 Live progress and previews (local) — stage, step, s/it and time left right above Run, then "Done in m:ss", and the picture forming as it samples (on MLX through LVNodes, sharp with a tiny decoder in models/vae_approx); it comes from LVNodes, which Comfy Cloud can't load
• 🍏 Both models on Apple MLX — they run on Apple's MLX inside ComfyUI, from ComfyUI's own bf16 files: Krea 2 Turbo in about a minute per 1 MP image (about 41 s for each later image of a batch), Z-Image Turbo in about 78 s at 8 steps; Raw and Base too, slower as undistilled models are (all in its own sub-environment, not touching ComfyUI's main Torch one)
• 🔥 Local PyTorch, on any GPU — runs on NVIDIA (CUDA) and other GPUs exactly as ComfyUI normally does; on Apple Silicon, through PyTorch's MPS backend, it runs the step LoRA alongside the model instead of keeping a second copy of its weights, which halves Krea 2's memory (48 → 24 GB) for the same picture
• ☁️ Comfy Cloud, nothing to install — download the Krea 2 or Z-Image Cloud workflow, drag it onto Comfy Cloud, import its step LoRAs once (everything else is already on Cloud), and run: 3.5 MP by default, with upscaling at any factor
• 🎲 Random prompts with real variety — seeded scene lists and about 14,000 dictionary words, or real prompts from 3M+ Hugging Face dataset rows read live; the Prompt LLM turns them into photorealistic prompts, and refusals are retried
• 🗣️ Prompt enhancement with any LLM — by default the same file as the model's text encoder (Qwen3-VL 4B for Krea 2, Qwen3 4B for Z-Image), so nothing extra to download; falls back to your own prompt if the LLM refuses or returns nothing
• 🎨 Extra LoRAs and upscaling — style LoRAs on top, with their own strength and trigger words; SeedVR2 7B or classic upscalers at any factor (a 3.5 MP image at 4× comes out at 8864×6624)
• 🧠 Memory on demand (local) — models load stage by stage, and Keep models loaded holds them between runs only when you want, whatever ComfyUI's startup flags
• 🧩 LVNodes, one light pack — the MLX nodes for both models, loaders that need only the files a run uses, keep-loaded loaders, seeded random prompts, live dataset rows, Wait For gates, and in the app the status line, the keep checkbox, settings that follow the model and a fresh first seed. It needs nothing beyond Python's standard library, except the MLX nodes: on their first run they make a one-off install of mflux, MLX and transformers 5 (about 1.3 GB, a few minutes, automatic) into LVNodes' own environment, so ComfyUI's packages stay untouched. Besides LVNodes, the local workflows need only KJNodes (for the Set/Get pills); Comfy Cloud needs nothing
• 🧹 No spaghetti — every workflow starts from a Fields → Set column and wires its groups with Set/Get pills, aligned with even gaps
• 📥 Models download themselves — every file carries its link for ComfyUI's missing-models dialog
• 🆓 Apache-2.0 — workflows, nodes and docs

Getting the project: the simplest way is Hugging Face's hf command, which ComfyUI Desktop's Python includes ("$COMFY/.venv/bin/hf", with COMFY your ComfyUI folder; other installs: the hf of the Python that runs ComfyUI, or pip install huggingface_hub):

hf download lvladikov/ComfyUI-Nodes-and-Workflows --local-dir ComfyUI-Nodes-and-Workflows

Or download the files you need from the repository's file browser. To check which version you have, see version in meta.yaml.

Local ComfyUI setup

Every local workflow here needs the following. Comfy Cloud needs none of it; each model's README covers Cloud.

LVNodes

1. Copy the whole LVNodes folder into ComfyUI/custom_nodes/. For ComfyUI Desktop, ComfyUI is the folder you chose during setup.
2. Restart ComfyUI.

There's nothing to run by hand, and ComfyUI's own Python packages aren't changed. The Apple MLX nodes set up their own environment the first time they run.

Optional: a Hugging Face token

LVNodes' Random Prompt (HF Dataset) node reads Hugging Face datasets without an account. If you set the HF_TOKEN environment variable before starting ComfyUI, its requests are sent as your account, so rate limiting is less likely, and gated datasets you can access also work. Any free read token from huggingface.co/settings/tokens will do.

• macOS or Linux: export HF_TOKEN=hf_... in the shell that starts ComfyUI.
• Windows: run setx HF_TOKEN hf_... once, then restart ComfyUI.
• ComfyUI Desktop on macOS: run launchctl setenv HF_TOKEN hf_..., then restart the app. This lasts until the Mac restarts.

Full setup (KJNodes, models, and updating from the previous version, incl. the renamed MLX node folder) is on the model card.

Project Repo: https://huggingface.co/lvladikov/ComfyUI-Nodes-and-Workflows

Krea 2 (Raw/Turbo) Workflow/Apps and More Info: https://huggingface.co/lvladikov/ComfyUI-Nodes-and-Workflows/blob/main/Krea-2/README.md

Z-Image (Base/Turbo) Workflow/Apps and More Info: https://huggingface.co/lvladikov/ComfyUI-Nodes-and-Workflows/blob/main/Z-Image/README.md

Happy Creating!

Krea 2 Turbo — 2-Step Distillation LoRA (work in progress)

Previous posts/releases - here, here and here.

🧪 A fast-preview adapter, from a project still in training. When the subject is close and fills a good part of the frame — a portrait, a single figure, an object seen up close — two steps already hold up well, and you can rely on this adapter for those images. Small subjects are where it still falls short, people and objects alike: faces in a crowd, figures in a wide scene, the machines at the back of a gym — anything that takes up little of the frame can come out ghosted or smeared. For those, and whenever quality matters more than speed, use the 4-step LoRA. Every figure on the model card measures the adapter honestly against 4-step and 8-step renders. Training continues one recipe change at a time, and a later checkpoint replaces this one only when the sweeps and I visually agree it is better. Known issues.

📐 The saved steps can also go into resolution. A small subject is simply one that covers few pixels, so a larger render makes the same subject bigger — and at a quarter of the teacher's steps, renders up to 2048×2048, Krea's published maximum recommended resolution and beyond the largest size this adapter was trained at (1440×1440), come within easy reach. That makes the adapter a stepping stone to high-resolution renders as well as a fast preview. Past 2048×2048, stock Krea 2 itself begins to duplicate subjects — a property of the base model, with or without this adapter.

chk00041320 (2 Oct 2026) is 9,720 training samples later than chk00031600 (25 Sep 2026), and those samples went to what matters first in a picture — subjects drawn twice, or two poses blended into one, at the large sizes — and to faces in busy scenes. It is also the first checkpoint measured on the full 22-prompt sweep: the original 15, plus seven scenes of people, animals and action added on 29 Sep 2026 because structure is what they test — five friends on a beach, a family at a table seen from above, three kittens in a basket, two dogs in a tug of war, a show jumper, a pianist's hands, a flock of flamingos. Details on the changes since previously released last checkpoint here.

LoRA highlights:

• ⚡ A quarter of the steps — 8 → 2, on Turbo's own deployment sigmas [1.0, 0.7595]
• ⏱️ 4× faster denoising — 76.4 s → 19.3 s at 1024×1024; the adapter's own cost per call is within measurement noise
• 🎯 Fine detail at the teacher's level — 0.97–1.09× the teacher's fine-texture energy at every trained resolution (stock Turbo at 2 steps: 0.40–0.65×); from 1 megapixel up, closer to the teacher than the 4-step adapter
• 📊 Distribution matching, not imitation — matches what the teacher would plausibly produce rather than its exact trajectory, so the student commits instead of averaging into blur and doubled edges
• 🗣️ Prompt-conditioned throughout — teacher and fake scores both read each prompt's conditioning; a blind rubric finds 2 points missing of 352 (objects, counts, attributes, relations), and a judge prefers the 8-step teacher on 12 of 66 (4-step adapter: 6 of 45, on the original 15 prompts), mostly on style
• 📐 12 trained resolutions — multi-aspect from 512×512 up to 1440×1440
• 🔌 Drop-in, no exceptions — plain LoRA, stock Euler, diffusers / ComfyUI / MLX. No custom nodes, no custom sampler
• 🧬 Same shape as the 4-step adapter — rank 64 on the same 228 modules
• 🎲 13,750 recorded teacher trajectories from the 4-step project, reused — not one new teacher run
• 🔢 41,320 training samples in the 2-step stages, on top of the 4-step LoRA's 78,000
• 📅 25 days from the first 2-step launch to this checkpoint, on a single RTX 3090 — training continues
• 🔁 More than forty recipe adjustments across two methods — each kept only when the renders did not get worse

If you have already used my previous version, please redownload/replace krea2_turbo_2step_rank_64_lora.safetensors / krea2_turbo_2step_rank_64_lora_comfyui.safetensors from the latest in the project repo.

Full details on model card - https://huggingface.co/lvladikov/Krea2-Turbo-Distill-2step-LoRA

Not my video, but found someone on YouTube has covered the 2 & 4 step LoRAs including identify preserving edits, have a look: https://www.youtube.com/watch?v=V_qgoV0iPDM (copyright goes to author)

Also if you are using ComfyUI Cloud and have subscription, I have released a new ComfyUI Cloud Workflow / App for Krea 2 Turbo using my 2 & 4 step LoRAs, includes User Prompt, two Random Prompt modes, Prompt Enhancement, Steps, Resolution choices, as well as Upscaling - you can find details here.

For those of you with ComfyUI Cloud subscription I have created a Krea 2 Turbo Workflow/App which uses my 2 and 4 steps LoRAs (4 steps being the high quality one, and 2 steps also being good enough quality for running a fast just 2 steps flow), so getting you quicker outputs. It also supports three ways to enter/use a prompt, including two random modes (more on that below), it also offers Prompt Enhancement (and LLM models to use for it), predefined list of / and custom Resolutions, number of Steps - and here it dynamically uses my 2 Step Krea 2 Turbo LoRA for up to 3 steps and the higher quality 4 steps LoRA for 4+ steps, it also supports Upscaling which a choice between 4x-UltraSharp, RealESRGAN x4 and SeedVR2 7B sharp) - it basically is my personal All In One Krea 2 Turbo workflow/app that I am sharing with you all to play with, especially if you have been following my 2/4 step Krea 2 Turbo LoRAs this is a nice all in one place workflow / app for ComfyUI Cloud.

The workflow and app allow either user prompt - I think that is clear, you type in your prompt and you use or not Enhance Prompt and you get the result.

Or you use what I call Fully Random - each run it draws a random subject, art style and lighting mood from built-in lists (108,000 possible combinations - 80 subjects, e.g. "a lighthouse keeper feeding seagulls" or "a tiny dragon asleep in a teacup", 45 styles, e.g. "35mm film photograph" or "cinematic still, anamorphic lens", 30 moods / lighting, e.g. "soft morning light" or "neon-soaked night"), then has an AI (LLM) "art director" turn that combination into one original, detailed image description, which Krea 2 Turbo renders. The lists keep the ideas varied but sensible, and the AI adds the creativity, so every run gives a different picture. Your Prompt box is ignored in this mode.

Or you use the Random from Dataset - takes a real, human-written prompt from a built-in prompt collection and renders it. No LLM invents the idea. It picks a real prompt that someone already wrote, from one of five public prompt collections built into the workflow, and renders it. You choose the collection; each run draws a different prompt at random. With Prompt enhancement on, the AI polishes it first; with it off, the prompt is used exactly as written. Comfy Cloud workflows can't download data from the internet while they run, and can't read uploaded text files, so the prompt collections have to travel inside the workflow itself. The full datasets are far too big for that (the main one is about 770 MB), so the workflow carries a cleaned random sample of each, about 5,200 prompts in total. Running locally with a custom node could use the complete datasets. Your Prompt box is ignored in this mode.

If you go with Random from Dataset, you choose a collection in Dataset. Each one is a sample from a public Hugging Face dataset, stored in the workflow one prompt per line:

Dataset	Prompts in the workflow	Typical style
t2i-prompts-3m (Lakonik), the default	2,000 of ~3 million	Broad general prompts: "Sedona sunset over red rock formations. Serene and awe-inspiring."
Open Image Preferences	600 of ~8,700	Quality-focused prompts with style keywords
Midjourney detailed prompts	400 of ~3,000	Long, richly descriptive scenes
PartiPrompts (Google benchmark)	1,630, essentially the whole set	Short test prompts: "a motorcycle", "two wine bottles and three beer cans"
Stable Diffusion prompts (Lexica)	600 of ~82,000	Classic SD style with artist names and keywords

Before you start using it, you will need to import (once) the two Krea 2 Turbo step LoRAs:

- 4-step LoRA (used when Steps is 4+): best quality: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/resolve/main/krea2_turbo_4step_rank_64_lora_comfyui.safetensors

- 2-step LoRA (used when Steps is 1-3): reasonably good quality but faster, in just two steps: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-2step-LoRA/resolve/main/krea2_turbo_2step_rank_64_lora_comfyui.safetensors

- In Comfy Cloud: import both links as LoRAs (Import in the model library, paste the link). Cloud names them `lvladikov__Krea2-Turbo-Distill-4step-LoRA__…` and `lvladikov__Krea2-Turbo-Distill-2step-LoRA__…`, the names this workflow expects. Every other model used here is already on Comfy Cloud.

- If your LoRA files have other names, select them in LoRA 4-step (steps 4+) and LoRA 2-step (steps 1-3) inside the Krea 2 Turbo subgraph.

What the app outputs is the image (Preview, not saved, you download as you wish) and Prompt used (a small .txt in your outputs, shown as text in the app)

Here's the link to the workflow/app: https://huggingface.co/lvladikov/ComfyUI-Nodes-and-Workflows

Krea 2 Turbo — 2-Step Distillation LoRA (work in progress)

Previous posts/releases - here and here.

🧪 A fast-preview adapter, from a project still in training. When the subject is close and fills a good part of the frame — a portrait, a single figure, an object seen up close — two steps already hold up well, and you can rely on this adapter for those images. Small subjects are where it still falls short, people and objects alike: faces in a crowd, figures in a wide scene, the machines at the back of a gym — anything that takes up little of the frame can come out ghosted or smeared. For those, and whenever quality matters more than speed, use the 4-step LoRA. Every figure on the model card measures the adapter honestly against 4-step and 8-step renders. Training continues one recipe change at a time, and a later checkpoint replaces this one only when the sweeps and I visually agree it is better. Known issues.

📐 The saved steps can also go into resolution. A small subject is simply one that covers few pixels, so a larger render makes the same subject bigger — and at a quarter of the teacher's steps, renders up to 2048×2048, Krea's published maximum recommended resolution and beyond the largest size this adapter was trained at (1440×1440), come within easy reach. That makes the adapter a stepping stone to high-resolution renders as well as a fast preview. Past 2048×2048, stock Krea 2 itself begins to duplicate subjects — a property of the base model, with or without this adapter.

chk00031600 (25 Sep 2026) replaces chk00017464 (14 Sep 2026). It is 14,136 training samples later, aimed at what the previous checkpoint still got wrong — grain and excess texture at the largest sizes, colour under the teacher's there, small faces, stylised prompts — through a colour band at the teacher's level, nine critics taking turns, detail held to the teacher region by region, more training at the large sizes and a guarded running average.

• ⚡ A quarter of the steps — 8 → 2, on Turbo's own deployment sigmas [1.0, 0.7595]
• ⏱️ 4.2× faster denoising — 81.4 s → 19.5 s at 1024×1024; the adapter's own cost per call is within measurement noise
• 🎯 Fine detail at the teacher's level — 0.95–1.08× the teacher's fine-texture energy at every trained resolution (stock Turbo at 2 steps: 0.39–0.57×); from 1 megapixel up, closer to the teacher than the 4-step adapter
• 📊 Distribution matching, not imitation — matches what the teacher would plausibly produce rather than its exact trajectory, so the student commits instead of averaging into blur and doubled edges
• 🗣️ Prompt-conditioned throughout — teacher and fake scores both read each prompt's conditioning; a blind rubric finds 1 point missing of 240 (objects, counts, attributes, relations), and a judge prefers the 8-step teacher on 11 of 45 (4-step adapter: 6), mostly on style
• 📐 12 trained resolutions — multi-aspect from 512×512 up to 1440×1440
• 🔌 Drop-in, no exceptions — plain LoRA, stock Euler, diffusers / ComfyUI / MLX. No custom nodes, no custom sampler
• 🧬 Same shape as the 4-step adapter — rank 64 on the same 228 modules
• 🎲 13,750 recorded teacher trajectories from the 4-step project, reused — not one new teacher run
• 🔢 31,600 training samples in the 2-step stages, on top of the 4-step LoRA's 78,000
• 📅 18 days from the first 2-step launch to this checkpoint, on a single RTX 3090 — training continues
• 🔁 More than forty recipe adjustments across two methods — each kept only when the renders did not get worse

If you have already used my previous version, please redownload/replace krea2_turbo_2step_rank_64_lora.safetensors / krea2_turbo_2step_rank_64_lora_comfyui.safetensors from the latest in the project repo.

Full details on model card - https://huggingface.co/lvladikov/Krea2-Turbo-Distill-2step-LoRA

Not my video, but found someone on YouTube has covered the 2 & 4 step LoRAs including identify preserving edits, have a look: https://www.youtube.com/watch?v=V_qgoV0iPDM (copyright goes to author)

Update 03 Oct 2026 - New checkpoint chk41320 released, details here.

Krea 2 Turbo — 2-Step Distillation LoRA (work in progress, early days, only for the curious)

Initial release post here.

🧪 A fast-preview adapter, from a project still in training. When the subject is close and fills a good part of the frame — a portrait, a single figure, an object seen up close — two steps already hold up well, and you can rely on this adapter for those images. Small subjects are where it still falls short, people and objects alike: faces in a crowd, figures in a wide scene, the machines at the back of a gym — anything that takes up little of the frame can come out ghosted or smeared. For those, and whenever quality matters more than speed, use the 4-step LoRA. Every figure on the model card measures the adapter honestly against 4-step and 8-step renders. Training continues one recipe change at a time, and a later checkpoint replaces this one only when the sweeps and I visually agree it is better. Known issues.

📐 The saved steps can also go into resolution. A small subject is simply one that covers few pixels, so a larger render makes the same subject bigger — and at a quarter of the teacher's steps, renders up to 2048×2048, Krea's published maximum recommended resolution and beyond the largest size this adapter was trained at (1440×1440), come within easy reach. That makes the adapter a stepping stone to high-resolution renders as well as a fast preview. Past 2048×2048, stock Krea 2 itself begins to duplicate subjects — a property of the base model, with or without this adapter.

🔀 Also compatible with Krea 2 Raw. With some prompts it works very well on Krea 2 Raw too, at 7 steps+ — see Using it on Raw and the dedicated experiment. Krea 2 Raw needs 28 steps by default so this allows a run at quarter of the official steps (and works for some but not all prompts). The LoRA was trained for and on Turbo so this side effect is both a bonus and an experiment but not intended trained use.

If you have already used my previous version, please redownload/replace krea2_turbo_2step_rank_64_lora.safetensors / krea2_turbo_2step_rank_64_lora_comfyui.safetensors from the latest in the project repo.

chk17464 vs chk13663 (the initial published version) - see details here.

Full details on model card - https://huggingface.co/lvladikov/Krea2-Turbo-Distill-2step-LoRA

Update - 25 Sep 2026 - Checkpoint 31600 released - details here

Krea 2 Turbo — 4-Step Distillation LoRA

Full details and to download - HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA

https://preview.redd.it/9p2rjwh3y3oh1.jpg?width=3072&format=pjpg&auto=webp&s=f7f8896210c72328f2257cf1337a2be6e69d41b6

A LoRA for Krea 2 Turbo that reduces the minimum usable step count from 8 to 4 — Turbo's own model and sigmas, half the denoising passes, and the fine texture that 4-step Turbo loses put back.

• ⚡ 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.
• 🎯 Texture as good as the teacher or better — 1.03× the teacher's fine-texture energy at 1280×1280 and 1440×1440, every frequency band within 10% of the teacher's; verified clean: saturation 0.96–0.97× the teacher's, fewer clipped highlights and shadows, skin texture 0.97–0.99×.
• 📏 45% of the 4-step gap closed — the held-out velocity error to the 8-step teacher fell from 4.70e-02 (stock Turbo at 4 steps) to 2.59e-02 with the LoRA; a vision-language judge shown the teacher's and the LoRA's renders side by side preferred the teacher on only 6 of 45 (37 ties, 2 wins for the LoRA).
• 🗣️ Prompt-aware training — the critic scores images against their prompts during training, so adherence is pressured directly, not inherited.
• 📐 12 trained resolutions — multi-aspect from 512×512 up to 1440×1440, each with its sweep.
• 🔌 Drop-in — plain LoRA weights for diffusers and ComfyUI. No custom nodes, no patched sampler, no code.
• 🎲 13,750 prompts drawn at random from Lakonik's 3-million-prompt dataset, each recorded by the teacher as a full 8-step trajectory at one of the 12 resolutions — 13,750 teacher shards.
• 📷 43,044 real-photo crops — 25,560 from LSDIR and 17,484 from Flickr2K — cut at native resolution and captioned, in the critic's real set: texture anchored to reality as well as to the teacher.
• 🔢 78,000 training samples in the shipped weights.
• 📅 21 days from the first training launch to the final file, on a single RTX 3090.
• 🔁 16 recipe adjustments

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.

💡 Too strong on a prompt? Turn it down. The LoRA restores fine texture, and on some subjects — stylised art, high-contrast splash pieces, very large renders — that can read as too much at strength 1.0. The effect scales smoothly with strength, so 0.75 is a good second setting, and anything from 0.6 to 0.9 is fair game; you lose nothing but the extra bite.

Files

file	what it is
krea2_turbo_4step_rank_64_lora.safetensors	the LoRA in diffusers key format — see Inference with diffusers; also for MLX or anything that reads safetensors
krea2_turbo_4step_rank_64_lora_comfyui.safetensors	the same weights under ComfyUI's key names — see ComfyUI
krea2_turbo_4step_lora_t2i.json	a ready ComfyUI workflow, stock nodes only
LICENSE.pdf	the Krea 2 Community License Agreement, which covers this adapter — see License
NOTICE.txt	the attribution notice the license requires of a derivative

The two weight files are one adapter — only the key names differ. Both carry the training details in their safetensors metadata: base model, method, sample count and the inference settings.

If you want to bypass the Reddit image compression and check the quality of the LoRA produced images directly, here are some of the Hugging Face 1440x1280 links: portrait, sorceress, snowleopard, colonyship, inventor, kingfisher, claychef, ... the rest you can see in the 1440x1280 folder. And full sweep at: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/assets/resolution_sweeps/4step-LoRA

How I got here

This was not a "train for longer and ship whatever comes out last" project. More samples do not reliably mean a better adapter — measured here, they can make it worse, and a higher sample count on its own means nothing.

The loop was train → assess → adjust the recipe → carry on → assess again — carrying on from the weights in hand when they were worth keeping, and from an earlier point when they were not. What ships is the point of the run that measurably advanced the release axes as a whole — teacher faithfulness, prompt adherence, and texture/detail, on the same held-out set and the same fixed-seed renders — with a full resolution sweep showing no regression. Stretches that came out flat or worse were kept as information about the recipe and never shipped; there were several.

The recipe therefore grew over the run rather than being fixed at the start. In broad strokes: the early stretch settled the optimiser schedule (cosine decay with weight decay) after a first attempt that got steadily worse; the next added the final-call loss weighting and the running average of the weights that the shipped adapter is, and established that a run left going past its peak measures worse — so the shipping point is chosen by measurement, not by distance run. A much larger trajectory pool then pushed the single number the project optimised at the time — the velocity gap to the teacher — to its best value, and exposed that number's limit: past a point, chasing it further trades away exactly the texture a step-distillation exists to restore. The recipe from then on judged all three axes at once and added a measured dose of real-image texture pressure and a prompt-aware critic (the discriminator saw images with their prompts and punished mismatches). The long final stretch of the run continued on that recipe, with the critic's weight tuned once texture had settled where it was wanted.

The sixteen recipe adjustments, in order — each one made on the measurement of the one before:

1. progressive distillation replaced the policy-head objective the project started with
2. cosine learning-rate decay with weight decay
3. the shipped weights became a running (EMA) average instead of the live state
4. the final chord — the call that decides fine texture — weighted 3× in the loss
5. resumable state, warmup and a plateau rule, so a run could pause and continue without a cold restart
6. the LADD-style critic on the frozen model's own block-14 features, teacher finals as its real class
7. real photographs entered the critic's real set, half the draws
8. the critic's weight rebalanced against the distillation term
9. the prompt-aware critic head with its mismatch term, on a fresh pool of teacher trajectories
10. 1440×1440 joined the training mix
11. the real photographs got captions, so they took part in the prompt-aware term too
12. a low-frequency anchor to the teacher's chord on the large buckets, restarting from the averaged weights
13. the critic's weight lowered once texture had settled
14. a paired critic: the teacher's final for the same prompt as the real
15. the paired critic plus a hard low-frequency floor on every bucket
16. back to the recipe before 14 and 15, once both were measured as unnecessary

Timeline of training process

The adapter was the product of several stages with very different costs:

1. Text-encoder embeddings. Every training prompt was encoded once and cached. This was the fast part — thousands of prompts took minutes.
2. Teacher shards. For each cached prompt, the unmodified Krea 2 Turbo ran its full 8-step schedule and the whole trajectory was recorded, each prompt at one of the supported resolutions so that every resolution was covered. This was by far the most time-consuming stage — it was the teacher doing real inference, thousands of times, and a batch of several thousand shards was measured in days of GPU time, not hours.
3. Real-photo crops. Bucket-sized crops were cut at native resolution from quality-gated real photo sources (public high-res datasets), VAE-encoded into the training latent space, and captioned per crop for the prompt-aware side of training. Cutting, encoding and captioning a pool refresh was a matter of hours.
4. Student training. The LoRA trained against the recorded trajectories (progressive distillation), with a latent-space GAN critic running alongside — real crops and teacher finals as its real class, the student's outputs as fake — plus a prompt-aware head that scored images against their prompts. Relative to the shard stage this was quick: each block of a thousand training samples was a matter of hours, not days. Of course the longer the training, the better and more diverse the results, so hours did turn into days.

Because these stages competed for the same GPU, they were interleaved rather than run to completion one after another: generate a block of embeddings, produce teacher shards for them, refresh the crop pool when measurement said it was worth it, train on what existed, assess, then go back to producing shards while the results were reviewed. A larger and more varied shard pool was what made further training worthwhile, so shard production was always the gate; the run took several such cycles.

Archive

Earlier checkpoints of the run and their resolution sweeps are kept under _archive/ — checkpoints/ and resolution_sweeps/ — for anyone who wants to look back. They are superseded by the final release files and not maintained.

What's next

A 2-step LoRA is the natural follow-on, and it is the next project. It will be a separate release rather than a competitor to this one: at two steps a distilled model gives up more than at four, so the goal is a usable 2-step Turbo — fast previews and drafts at half this adapter's cost, a quarter of the teacher's — not the quality bar this adapter holds. I may or may not get there. I will try anyway, and if it works it will appear as its own project alongside this one.

Full details and to download - check my Hugging Face LoRA

HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA

Important NOTE: The repo has been fully restructured folder and files wise for the final release (focus is no longer on checkpoint numbers). So for those of you who have been part of the journey over the last few weeks - first of all, Big Thank You for all the feedback - and do check the repo's fully rewritten README and the new files/folders structure.

Previous posts on Reddit: Initial, Previous: here, here, here, here,  and here

Enjoy!

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.
• 🎯 Texture at teacher parity — fine-detail energy 1.00× the 8-step teacher's at 1280×1280 and 1.02× at 1440×1440, matched band-for-band across the frequency spectrum, not grain.
• 🗣️ Prompt-aware training — the critic scores images against their prompts during training, so adherence is pressured directly, not inherited.
• 📐 12 trained resolutions — multi-aspect from 512×512 up to 1440×1440, each with its published sweep.
• 🔌 Drop-in — plain LoRA weights for diffusers and ComfyUI. No custom nodes, no patched sampler, no code.

This is an update release, following up from my previous posts where you can find full details:

Initial, Previous: here, here,  and here

Headline for this update: chk00042000 closes the texture gap: total fine-detail energy against the 8-step teacher reaches 1.00× at 1280×1280 and 1.02× at 1440×1440 (1.0 = teacher-like), where chk00026000 measured 0.88× and 0.82×. And the distribution is right, not just the total — split the spectrum into frequency bands and every band individually lands within ~10% of the teacher's (0.9–1.1×), where 26K ran 0.79–0.92, starved in every band. Total at parity and bands at parity means the detail lives in the same frequencies as the teacher's — real structure, not grain piled into one band. (How can it exceed the teacher? Because the teacher isn't ground truth — training also shows the critic real photographs, so the adapter learns detail density from reality, not only from an 8-step model that itself slightly under-renders fine texture. The teacher anchors structure; reality anchors texture. Values just above 1.0 are that pressure paying off.) In fixed-seed renders it matches chk26K's distance to the 8-step images at 1440×1440 outright.

The recipe grew up since 26K, in four ways: a measured dose of real-image texture pressure — what carried detail to parity; a prompt-aware critic that scores images against their own prompts during training, so effect-heavy prompts now get the energy they ask for; NF4 fully retired — the big resolutions used to squeeze into 24 GB by dropping their attention weights to 4-bit, and after re-engineering the training step to fit full int8, those buckets measure 3.96% closer to the teacher (exactly the buckets texture lives in: 1280², 1440×1280, 1440²); and 1440×1440 promoted to a trained bucket with its own sweep column.

One metric paid for the texture leap — the teacher-velocity score sits a step behind 26K's — a deliberate trade already being won back checkpoint by checkpoint (2.93 → 2.90 → 2.85 and falling) while texture holds parity. _latest now points to chk00042000.

The improvement reaches even the out-of-spec 2-step extreme test. I had a separate dedicated post on that here - since the initial post was done on an earlier to 42K checkpoint, I have since re-rendered the whole native-vs-LoRA 2 step strength-2 set on this checkpoint (42K being released now), and the FFT is the diagnostic: the old 2-step had the classic collapse signature — hollow mid-bands (0.52/0.55) plus a fake-grain overshoot at the very top (b6 = 1.05). This checkpoint lifts every structural band (0.64/0.65/0.76/0.80) and settles the top band to 0.82 — more real structure, less noise dressed as detail. Fresh strips: 2-step extreme test. And that's the preview mode (at quick 2 steps, unofficial, untrained for, still useful for previews, and getting better and better with every new checkpoint release).

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_chk00042000.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, chk00026000) are kept in older_checkpoints/, and their resolution sweeps stay in place, so the progression remains visible and comparable.

For the full 42K Checkpoint resolution sweep go here: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk42000

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.

Timeline of training process

Each checkpoint is the product of several 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. Real-photo crops. Bucket-sized crops are cut at native resolution from quality-gated real photo sources (public high res datasets), VAE-encoded into the training latent space, and captioned per crop for the prompt-aware side of training. Cutting, encoding and captioning a pool refresh is a matter of hours.
4. Student training. The LoRA trains against the recorded trajectories (progressive distillation), with a latent-space GAN critic running alongside — real crops and teacher finals as its real class, the student's outputs as fake — plus a prompt-aware head that scores images against their prompts. Relative to the shard stage this is quick: each +1,000 checkpoint is a matter of hours, not days. Of course the longer the training the better and more diverse results, so hours do turn into days eventually.

Full details and to download - check my Hugging Face LoRA

HF Repo: https://huggingface.co/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.

This is an update release, following up from my initial post where you can find full details - https://www.reddit.com/r/StableDiffusion/comments/1vtf1b7/krea2_turbo_distill_4_step_lora_trained_for_turbo/

Update (22 Aug 2026): I have published a new checkpoint, improved further from the previous one and the latest (both main and comfyi) have been repointed to the new improved checkpoint. For details and to download new version go to - https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA. Readme has been updated too as well as all images in readme regenerated on the basis of new checkpoint as well as full resolution sweep at https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk10000 if you want to check for yourselves.

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

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 than chk00006000**'s** (3.38 vs 3.57) and 15% smaller than chk00005000**'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:

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.

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

HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-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 than chk00006000's (3.38 vs 3.57) and 15% smaller than chk00005000'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.

Over the last few weeks, I have been training and fine tuning a 1.44 B-parameter, 6-layer one-step diffusion image upscaler distilled from ByteDance-Seed/SeedVR2-7B (the sharp EMA variant, which is 36 layers, converted to safetensors). It targets the case where the 7B teacher is too large or too slow to be practical: 5.7× smaller on disk, and it runs in ≈4.6 GB where the teacher needs ≈14–16 GB.

The speed advantage grows with the job. At 4× it is ≈1.6× faster; at 8× it is 4.7–5.6× faster (55 s vs 257–307 s).

teacher	advantage
transformer layers	6
parameters	1,442,608,252
weights on disk (fp16)	2.69 GB
512→2048 (4×)	20.2–22.5 s
512→2048 peak RAM	4.6 GB
512→4096 (8×)	54.4–55.2 s

Measured on an Apple M2 Ultra (64 GB) via MLX, model load included. 

Who this is for

The teacher is an excellent upscaler that many people cannot actually run. At 36 layers and 15.35 GB of weights it wants a workstation; on a 64 GB machine it already thrashes at 8×, and it is simply out of reach on consumer laptops, integrated GPUs and phones.

This model exists to move that line. Six layers instead of thirty-six, 2.69 GB instead of 15.35, and a 4.6 GB peak instead of 14–16 GB — which is the difference between "runs on a 16 GB machine" and "does not run at all". The layer count is what drives it: attention and MLP cost scale with depth, so cutting 36 → 6 cuts both the resident weights and the activation working set, not just the file size.

Quality vs the teacher

Teacher-relative FFT band energy, 15 scenes, identical inputs for both models. The teacher is the reference, so 1.000 means indistinguishable from the teacher in that band; below 1.0 means the student under-produces detail, above 1.0 means it over-produces (ringing / over-sharpening).

512 → 2048 (4×) — the recommended operating point

band	student / teacher	per-scene range
mid (0.15–0.40 Nyq)	0.852	0.664 – 1.039
fine (0.40–0.70 Nyq)	0.696	0.406 – 0.871
edges (0.70–1.0 Nyq)	1.125	0.471 – 1.705
MAE vs teacher (8-bit levels)	5.70	2.80 – 9.10

2048 → 8192 (4×) — upscaling an already-large image

band	student / teacher	per-scene range
mid (0.15–0.40 Nyq)	0.833	0.684 – 0.930
fine (0.40–0.70 Nyq)	0.803	0.550 – 1.020
edges (0.70–1.0 Nyq)	1.213	0.791 – 1.665
MAE vs teacher (8-bit levels)	4.35	2.37 – 8.21

This is the line where the model is closest to the teacher in absolute fidelity. 

512 → 4096 (8×) — works, but degrades

band	student / teacher	per-scene range
mid	0.443	0.349 – 0.595
fine	0.345	0.195 – 0.467
edges	0.475	0.217 – 0.725
MAE vs teacher	5.43	2.64 – 9.33

8× is this model's stretch goal rather than its home ground: it retains under half the teacher's detail energy per band, and produces a clean, usable 4096×4096 image in ≈55 seconds at 7.5 GB — a job the teacher needs 4–5 minutes for, and only by pushing a 64 GB machine into swapping.

Recommendation: use this as a 2×–4× upscaler, where it is genuinely close to the teacher.

Model here: https://huggingface.co/lvladikov/SeedVR2-1.4B

Added ComfyUI version of the model, custom node and workflow: https://huggingface.co/lvladikov/SeedVR2-1.4B/tree/main/comfyui (details on how to use in main Readme)

Update (30/07/2026):

Since I keep getting asked the same question, over and over - how does it compare to 3B (official model) - I have spent time and have done full analysis and comparison with 3B, and it is honest very detailed one - 3B being bigger on size and has 2x many params and 6x more layers does win in fidelity, I won't hide, but my model has its place too, as it was created to be the smallest descent quality version of the amazing SeedVR2, and I am personally very happy with it.

For full detailed comparison with 3B including same testing images (same prompt, seed, resolutions) on both my model and the 3B one: https://huggingface.co/lvladikov/SeedVR2-1.4B#compared-to-the-official-seedvr2-3b

Also feel free to compare same prompt/seeds with both. Don't just look at them at 100% crop zoom :) look at them as a whole. my 1.4B does a good job, but if you are after fidelity only and the size and speed and memory requirements don't bother you, then go with the official 3b/7b models.

Images generated by same prompt, seed, resolutions with the official 7B, 3B and my 1.4B:

https://huggingface.co/lvladikov/SeedVR2-1.4B/tree/main/assets/teacher-7B

https://huggingface.co/lvladikov/SeedVR2-1.4B/tree/main/assets/official-3B

https://huggingface.co/lvladikov/SeedVR2-1.4B/tree/main/assets/student-1.4B

I do hope people appreciate my effort, and the time and resources I have spent to make a small in size and quite capable still SeedVR2 model that can run literally everywhere, including on phones and tablets.

And if you have been on my HF link, you'll know I am also working on a 2.8B 12L version - still lower than both 7B and 3B official models by design (actually I started with 12L first and that is what helped make the 6L 1.4B, as I wanted to see what is the smallest I can go where it still produces nice results. 12L is still being improved and fine tuned... but keep an eye on my HF and watch the space....)