Nodes/Krea 2 SVDQuant/Krea2 SVDQuant W4A4 Loader
ComfyUI Node

Krea2 SVDQuant W4A4 Loader

The loader that makes Krea 2's 4-bit weights actually fast

By alperktt·Created 2 months ago·Updated 25 days ago· 13
Krea2 SVDQuant W4A4 Loader
    • model
    • status
    model_name
    vram_managementauto

    The short version

    This is the loader you use when you've downloaded one of the SVDQuant Krea 2 diffusion models (the files with rank64 or rank256 in the name) and want the 4-bit thing to be worth your download. It loads a single self-contained .safetensors from models/diffusion_models/ and attaches the low-rank correction branch on top of ComfyUI's native 4-bit kernel. The README's numbers on an RTX 3090: about 2.4–2.9x faster than BF16, at a third of the size.

    Why it exists at all is the part worth understanding. FP8 only pays off on GPUs with FP8 tensor cores - Ada, Hopper, Blackwell. On a 30-series card there are none, so FP8 weights get cast back to bf16 before the matmul and you've saved VRAM without gaining speed (on a 3090, FP8 measured slower than plain bf16). The trick here is quantizing activations too - W4A4. INT8/W4A4 tensor cores go back to Turing, so a 3090 or even a 20-series card can run the math genuinely fast. That's SVDQuant's trick from the MIT Han Lab paper, reimplemented from scratch on top of kernels ComfyUI already ships (convrot_w4a4 in comfy_kitchen) instead of the paper's own Nunchaku engine.

    The inputs that matter

    • model_name - picks from your models/diffusion_models/ folder. Only the svdq checkpoints belong here (they carry *.svdq_l1 / *.svdq_l2 tensors - the low-rank branch). The branchless w4a4 / int8 / fp8 files should go through the stock UNETLoader instead; this loader will tell you as much if you point it at one.
    • vram_management - leave it on auto. auto lets ComfyUI use its dynamic VRAM streaming patcher, which is what keeps iteration time flat once the model stops fitting in VRAM. classic pins the old patcher, where a model that no longer fits falls back to streaming weights per module per step - and your ~1s iteration becomes 30–100s. Only flip it if you have a specific reason.

    Outputs: model (wire to a KSampler) and status (a string telling you the rank, variant, size, which kernel the quantized layers actually dispatch to, and which patcher you got). Read the status line if generation is slow - that's where the loader will shout that the fast kernel isn't in play.

    How to install

    Grab the pack once, then pick a checkpoint:

    cd ComfyUI/custom_nodes && git clone https://github.com/alperktt/Krea-2-SVDQuant-ComfyUI krea-2-svdquant
    

    Restart ComfyUI (or install via Manager by searching "Krea-2-SVDQuant-ComfyUI"). The pack has zero Python dependencies - it builds on comfy_kitchen, which ComfyUI already ships. Then download a standalone DiT from AlperKTS/Krea-2-SVDQuant-ComfyUI on Hugging Face into models/diffusion_models/. Krea2-Turbo-SVDQuant-W4A4-rank256-actaware.safetensors (9.10 GB) is the one the author recommends if you use LoRAs; rank64 (7.90 GB) is statistically identical without them.

    The trap that gets everyone

    If generation comes out slower than your FP8 build, you're almost certainly on a pre-cu130 PyTorch. The kernels live behind a CUDA-13 gate: on older torch builds ComfyUI disables comfy_kitchen's CUDA backend and every quantized layer silently falls to a pure-Python fallback that is slower than bf16 - and the ordering inverts, w4a4 slowest instead of fastest. Check with:

    python -c "import torch; print(torch.__version__, torch.version.cuda)"
    

    Below 13.0, install a cu130+ torch build before you chase anything else. The status output tells you the truth here, and the Krea2 SVDQuant Diagnostics node will confirm it without you guessing. One more honest caveat: if you're comparing against an INT8 build, the speed win is real but modest (~1.2x); the decisive win is VRAM, about 8.5 GiB resident against 12.8 GiB for INT8.

    CategoryKrea2/SVDQuant

    Inputs (2)

    NameTypeDefaultDescription
    model_nameCOMBOA checkpoint from quantize_krea2.py --format svdq (it carries *.svdq_l1/*.svdq_l2 tensors). The --format w4a4 / int8 / fp8 checkpoints have no branch and load with the stock UNETLoader instead.
    vram_managementoptCOMBOautoLeave on "auto" unless something is wrong. "auto" lets ComfyUI manage this model the way it manages any other, which on an ordinary launch means the dynamic-VRAM streaming patcher -- that is what keeps iteration time flat once the model stops fitting in VRAM. "classic" pins it to the older patcher, where a model that no longer fits falls back to streaming weights per module per step and an iteration goes from ~1 s to 30-100 s. KREA2_DISABLE_DYNAMIC=1 forces classic for a whole server run.

    Outputs (2)

    NameTypeDescription
    modelMODELWire this to a KSampler.
    statusSTRINGRank, variant, size and which kernel the quantized layers will actually dispatch to. Read this if generation is slow.