Load Diffusion Model (BNB 4-bit)
BNB NF4/FP4 UNETs without the bitsandbytes pain
- MODEL
Most of the loaders in silveroxides' QuantOps pack teach ComfyUI a new quant format. This one is the odd one out: it loads BNB 4-bit (NF4/FP4) UNETs - the most aggressive compression the pack touches - and it does the whole job in pure PyTorch, so you never install bitsandbytes. If fp8 is the "just use it" tier of the quantization ladder and GGUF Q4 is the "genuinely desperate" tier, NF4 is the one you don't bring up at parties. You reach for it when nothing 8-bit fits your card and you've got a Flux, Chroma, or Radiance model that was quantized with silveroxides' convert_to_quant tool using its --bnb-4bit flag.
The KB puts NF4 in perspective: it's called out as the lowest-quality common quantization method - a noticeable step past Q4 for the same or worse space savings. That's the trade you're signing up for, and it's the honest reason this node exists for a narrow crowd rather than everyone.
How it works
BNB 4-bit storage is a neat trick. A weight doesn't get a simple 4-bit cast; instead the file stores:
- packed 4-bit indices as
uint8tensors (two values per byte, shape[numel/2, 1]), - per-block
absmaxscales in fp32, - a 16-entry codebook - the NF4 values straight out of the QLoRA paper, or the normalized E2M1 table for FP4,
- a JSON metadata block (
quant_state.bitsandbytes__nf4) recording the original shape, block size, and quant type.
On the forward pass the node looks up indices in the codebook and rescales by the block scales, effectively reconstructing bf16 weights on the fly. That's the "pure PyTorch dequantization" in the description. The file's own metadata hands back the original tensor shapes, which matters because packed weights look like [N*K/2, 1] - wrong shapes that break ComfyUI's normal architecture detection. So the node auto-detects Flux vs Flux2 vs the Chroma/Radiance family from state-dict key patterns instead (double_stream_modulation_img means Flux2, distilled_guidance_layer plus nerf_blocks plus __x0__ picks the Radiance X0 variant, and so on).
The inputs that matter
There are only two, which is refreshing.
- unet_name - pick from your
diffusion_modelsfolder. This is the file you downloaded, quantized with--bnb-4bit. - model_type_override -
autois almost always right; the explicit values (flux,flux2,chroma,chroma_radiance,chroma_radiance_x0) exist for when auto-detection guesses wrong, which is rare but not unheard of.
Output is a single MODEL - wire it straight into your KSampler. No CLIP or VAE here; this node only handles the diffusion transformer.
Installing it
Same story as the whole pack: ComfyUI Manager → search "ComfyUI-QuantOps", or:
cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-QuantOps
Then restart ComfyUI. The pack pulls unifiedefficientloader>=0.5.2 from its requirements.txt automatically. Get the models from silveroxides' HuggingFace.
The uncomfortable part
Read the README before you get attached. The pack is deprecated - int8 ConvRot quantization landed natively in ComfyUI (v0.27.0+), which is what QuantOps was really angling toward, so the author closed up shop and explicitly asks that you take complaints to Comfy Org rather than filing low-effort issues here. The model_type_override values for Chroma/Radiance and the BNB path are also only useful for files made by the convert_to_quant toolchain. If auto-detection picks the wrong architecture, set the override by hand; if you get an "unknown quantization format" style error, the file probably wasn't made with --bnb-4bit in the first place. For everything else - recent ComfyUI, native formats - the stock loaders now do the job better than this pack ever could.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| unet_name | COMBO | 0 options: | |
| model_type_overrideopt | COMBO | 6 options: auto, flux2, flux, chroma, chroma_radiance, chroma_radiance_x0 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |