Krea 2 Turbo — Activation-Aware SVDQuant W4A4 for ComfyUI
Activation-aware INT4 quantization + SVDQuant low-rank correction for Krea 2 Turbo — ~2.4x faster than BF16, about a third the file size of the usual FP8 setup, no calibration dataset needed. Built for GPUs without FP8 tensor cores (Turing/Ampere, RTX 20/30-series), where the standard FP8 advice actually runs slower than plain BF16.
Speed (RTX 3090, 1024x1024, 8 steps, warm):
BF16 (reference): 18.80 s — 1.00x
W4A4, no low-rank branch: 6.49 s — 2.90x
SVDQuant rank 64: 7.16 s — 2.63x
SVDQuant rank 256 / rank 256 actaware: 7.77 s — 2.42x
The low-rank branch (the accuracy correction) costs ~9-10% of step time and barely varies with rank — going from rank 16 to rank 256 is only ~4% slower.
Fidelity, measured, not guessed: LPIPS against a BF16 reference, 16 prompts x 2 seeds, paired stats. The activation-aware objective (branch fit against real per-channel activation energy instead of assuming it's uniform) is the biggest single accuracy win in the whole project and costs nothing at inference — same shapes, same kernels, only different numbers inside the branch.
Links: 🔧 Custom nodes (GitHub): https://github.com/alperktt/Krea-2-SVDQuant-ComfyUI 📦 Checkpoints + full benchmarks + example images (Hugging Face): https://huggingface.co/AlperKTS/Krea-2-SVDQuant-ComfyUI
Setup:
Clone the custom nodes: git clone https://github.com/alperktt/Krea-2-SVDQuant-ComfyUI custom_nodes/krea2-svdquant Restart ComfyUI.
Download a checkpoint from Hugging Face into ComfyUI/models/diffusion_models/. Start with rank256-actaware — closest to BF16 of anything in the sweep, same speed as plain rank 256. rank64 if you want the smaller file and never load a LoRA. W4A4-noLowRank for max speed/min size with no branch at all.
Grab the text encoder (qwen3vl_4b_fp8_scaled.safetensors) and VAE (qwen_image_vae.safetensors) — standard for any Krea 2 Turbo workflow.
Load this workflow, select your checkpoint in the loader node, generate.
Loader node by checkpoint:
W4A4-noLowRank → stock UNETLoader
SVDQuant-W4A4-rank* (16/64/128/256/actaware) → Krea2 SVDQuant W4A4 Loader (this repo)
Using LoRAs? Use Krea2 SVDQuant LoRA Loader. On a quantized checkpoint the stock loader would have to dequantize the weight, add the LoRA, and requantize it — losing the 4-bit format and requantizing the LoRA delta along with it. This repo's node applies the LoRA as a parallel branch instead, so the quantized weight is never touched. If you load LoRAs, use rank 256 — rank 64 loses most of its accuracy advantage under one.
Tested on: RTX 3090 (Ampere) — works on any GPU with INT8/W4A4 tensor cores (Turing and up). Experimental, from-scratch project on ComfyUI's native comfy_kitchen backend. Benchmark reports from other GPUs welcome — open a discussion on the repo.
Description
https://civitai.red/models/2762538/fineporn-v4-int8-or-nvfp4-or-bf16-or-fp8?modelVersionId=3197873
Rank16
Original models belongs to:
simonishere
FAQ
Comments (7)
Tested a bit. Model fine for simple tasks, but its incompatible with dynamic VRAM feature - ones using this model Comfy hits 12 Gb VRAM - there huge spike of generation time to 30 and sometimes over 100 seconds per iteration.
Its a trouble of this quant, FP8 and INT8 models are fine with using more than 12 Gb VRAM without this massive slowdown.
This model faster than INT8 in simple generations but without Dynamic VRAM its very limited.
I've found the cause and it's a deliberate line in my loader: it passes disable_dynamic=True, which pins the model to ComfyUI's classic ModelPatcher and opts it out of dynamic VRAM management. The stock UNETLoader doesn't do that, which is exactly why FP8, INT8 and the noLowRank build behave differently from the svdq ones at the same size. Past the point where the model no longer fits, the pinned path streams weights per module per step and a ~1 s iteration becomes 30-100 s.
Two things make an svdq file hit that line earlier: the low-rank branch is real memory on top of the checkpoint (~645 MB at rank 256), and rank 256 is 9.10 GB against 7.50 GB for noLowRank.
The pin isn't an oversight — the dynamic patcher takes ownership of the weights, and that path has never been validated against the branch buffers. Two things have to hold before I can lift it: the branch buffers have to survive the streaming assignment on the right device, and module_size() has to keep counting them, or ~645 MB goes uncounted and the VRAM budget makes decisions on a number that's wrong. It's now item 1 on the roadmap with both conditions written down.
Until it's done, on 12 GB: Krea2-Turbo-W4A4-noLowRank (7.50 GB, stock UNETLoader so it gets dynamic VRAM, and ~9% faster per step), or the rank-64 build (7.90 GB, statistically identical to rank 256 unless you load a LoRA). Written up in TROUBLESHOOTING.md now instead of leaving people to find it the hard way.
@MaliaTate Krea2-Turbo-W4A4-noLowRank censored and uncensoring ways ineffective. =( But fast, 8 seconds, fastest krea2 model for now.
@velanteg Dynamic VRAM fixed give it a try... Choose auto.
Please add workflow to generate model_act_stats.safetensors with many LoRAs.
I have converted most of my models (18 models) but I'm not quite sure if the act_stats generation is correct because it lacks a proper documentation on the GitBub page.
The workflow you're asking for just shipped — workflows/krea2_quantize_calibrated.json, plus a written procedure in workflows/README.md. You were right that the docs were the missing piece.
One correction that will save you a lot of work across 18 models, though: you don't calibrate with LoRAs. The statistics are a property of the model's weights, not of any adapter you later run on top. Capture from the BF16 weights you're about to quantize, with nothing loaded, and use that one file for every LoRA you use afterwards. This isn't a shortcut — it was tested directly: calibrating with an adapter loaded measured marginally worse than calibrating without one, even when scored on the arm it was calibrated for (Test 5 in BENCHMARKS.md). The capture from that experiment is published as krea2_act_stats_turbo_lora_bloomgirls.safetensors so it's reproducible, not as a recommendation.
So: one capture per model, no adapters. For stock Turbo and base you don't need to capture at all — calibration/krea2_act_stats_turbo.safetensors and ..._base.safetensors are published, 6.67 MB each.
How to know your capture is correct: the Capture Save node prints a token count per layer. A clean run has all 224 layers on the same number (ours was 264200/264200). A spread means the hooks stayed live through something other than your calibration run — usually a graph that errored between Start and Save — and you should re-run with reset = true. Also make sure Capture Save is downstream of the KSampler; if it isn't, ComfyUI is free to run it first and you capture nothing.
Thank you very much now everything is clear.I forked and added W4A8.