Load FP4 or NF4 Quantized Checkpoint Model

This node loads one of those all-in-one bnb-nf4 Flux checkpoints - the kind that bundle the UNET, CLIP, and VAE into a single quantized .safetensors file so a 12-billion-parameter model can squeeze onto a 6-16GB card. It's the ComfyUI equivalent of what Forge users have been doing with NF4 checkpoints since Flux launched, and it's a straight drop-in for the stock Load Checkpoint node when your file happens to be one of these bitsandbytes-quantized ones.

One thing worth knowing up front, because it colors everything else: the pack's own README opens with a strikethrough sentence calling itself "very likely deprecated in favor of GGUF which seems to give better results." That's the author being unusually honest about their own tool, and it's not wrong - NF4 is generally regarded as the roughest of the mainstream Flux quantization options, behind fp8 and behind GGUF's Q5-and-up tiers. But it still gets used, because it's genuinely the smallest, most convenient package going: one file, no separate encoder or VAE to hunt down, and it runs on hardware that laughs at fp16. People have reported it running on a GTX 970 at a few minutes per image. That's the trade you're making - convenience and low VRAM over the last bit of quality.

How it works

Bitsandbytes NF4 (4-bit NormalFloat) packs each weight into 4 bits using a distribution tuned for how neural network weights actually look, rather than a flat linear scale. The checkpoint on disk is already quantized this way - this node's job is just to read that packed format back out into a working MODEL, CLIP, and VAE, the same objects a normal checkpoint loader would hand you. The code here is adapted from lllyasviel's implementation in Forge, so if you've used NF4 checkpoints there before, the behavior should feel familiar.

The inputs and outputs that matter

Two required inputs, both simple:

• ckpt_name - a dropdown of checkpoints in your models/checkpoints folder. Point it at an NF4 (or FP4) quantized .safetensors file.
• bnb_dtype - default, nf4, or fp4. There's no tooltip spelling out the internals, but in practice: leave it on default unless you specifically know your file needs to be read as the other format. Everything linked from this pack's own README - the dev and schnell checkpoints - is NF4, so default is the right call almost every time.

Outputs are MODEL, CLIP, and VAE - exactly what you'd get from the stock Load Checkpoint node. Wire MODEL into your sampler, CLIP into your text encode nodes, VAE into your VAE Decode. Nothing about the rest of your graph needs to change.

Installing it

It's on ComfyUI Manager, but with a catch: switch the Manager's channel to dev first, or it won't show up in the default search. Alternatively, install by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI_bnb_nf4_fp4_Loaders

Restart ComfyUI after either method. You also need bitsandbytes installed (pip install bitsandbytes into your ComfyUI environment), and the README flags that your ComfyUI itself needs to be reasonably current - this isn't a node that tolerates a stale install.

For models: the README points at lllyasviel's flux1-dev-bnb-nf4 and silveroxides' flux1-schnell-bnb-nf4, or you can search CivitAI for "NF4" against the Flux base models. Drop the file into models/checkpoints like any other checkpoint.

Common issues

The single most common failure isn't this node at all - it's not using this node. If you grab an NF4 checkpoint and load it through the regular Load Checkpoint node, you'll get a wall of size mismatch errors on nearly every layer, because the quantized weights are packed at a different shape than the full-precision loader expects. If you see that error, the fix is almost always "you need CheckpointLoaderNF4, not the stock loader" - which is exactly the trap that sends people searching for this node in the first place.

Beyond that: if you're pushing a large CLIP (T5-XXL in particular) alongside this on a single GPU, VRAM can still get tight even though the checkpoint itself is small - the encoder, not the quantized UNET, is often what tips you into an out-of-memory error. And given the deprecation note, it's worth checking whether a GGUF version of the same model exists before committing to NF4 for a new project - quality-conscious users increasingly reach for Q5/Q8 GGUF or fp8 instead, and only fall back to NF4 when VRAM is the hard constraint GGUF can't solve either.