Krea 2 Turbo — SVDQuant 2.42x Faster

Native W4A4 (activation-aware INT4) quantization + SVDQuant low-rank correction for Krea 2 Turbo, built from scratch on ComfyUI's own comfy_kitchen backend (not Nunchaku — no Krea 2 support there).

Why activation-aware INT4: Weight-only 4-bit quantization (W4A16) doesn't actually speed anything up — if activations stay 16-bit, the matmul still runs on bf16 tensor cores at bf16 speed. The real gain comes from quantizing activations too , down to 4-bit, onto hardware that has native INT8/W4A4 tensor cores (Turing/RTX 20-series and up — much wider support than FP8, which only helps on Ada/Hopper/Blackwell). The convrot (Hadamard rotation) step handles the outliers that 4-bit activations create, and the SVDQuant low-rank branch claws back additional accuracy on top of that — no calibration dataset needed for any of it.

What's included:

4 checkpoints : W4A4-noLowRank (7.50 GB, fastest) and 3 activation-aware SVDQuant-W4A4 variants at rank 16/64/128 (7.60–8.30 GB) — higher rank = larger correction branch = generally closer to BF16, though not strictly monotonic at a single seed.

2 custom nodes : Krea2 SVDQuant W4A4 Loader (reads the extra low-rank tensors the stock UNETLoader can't) and Krea2 SVDQuant LoRA Loader (stock LoRA loader silently skips all 224 quantized transformer layers on these models — matches only ~32/256 with no warning; this one patches correctly via a parallel low-rank branch).

quantize_krea2.py : reproducible script, regenerates any of these from a BF16 source in under two minutes, plus lets you produce ranks not included here (32, 256) or the INT8 (non-activation-aware-4-bit) variant if you want the higher-accuracy/lower-compression tradeoff instead.

Speed (RTX 3090, 1024x1024, 8-step Euler, warm run):

formatwarm runvs. BF16BF1621.3s1.0xFP8 (emulated on Ampere)19.2s1.1x Activation-aware W4A4 (no low-rank) 10.1s 2.1xActivation-aware SVDQuant W4A4 (any rank) 10.1–10.2s 2.1x

Accuracy notes: Rank 128 was the closest SVDQuant variant to BF16 in my qualitative text-rendering tests, which is why it's included alongside rank 16 (smallest) and rank 64 (middle ground). If your use case is dense small text (menus, labels, documents), the low-rank branch narrows the gap but doesn't fully close it — large text and general composition hold up fine across every checkpoint here, including the no-low-rank file.