Load Diffusion Model

If you've ever seen a workflow that loads a "diffusion model" separately from its text encoder and its VAE, this is the node doing that loading. Load Diffusion Model (class name UNETLoader) reads a single model file - the denoiser, the thing that actually removes noise from your latents - from ComfyUI/models/unet or ComfyUI/models/diffusion_models, and hands you one MODEL wire. That's it. But it represents a genuine shift in how modern ComfyUI workflows are built, and it's worth understanding why it exists.

Why it exists

Older checkpoints bundled everything - denoiser, text encoder, VAE - into one multi-gigabyte file, and Load Checkpoint unwrapped it all at once. Flux and friends changed the math. BFL ships the transformer, the T5 encoder, and the autoencoder as separate downloads, because 12B parameters is too much to keep re-downloading as one blob and because you'll want different precisions for each piece. So the modern modular workflow loads the model here, the CLIP through Load CLIP / DualCLIP Loader, and the VAE through Load VAE - three nodes where there used to be one. The name is a half-lie that survived history: "UNet" describes the SD 1.5-era denoiser, but the dropdown happily lists the Diffusion-Transformer files that replaced it, from Flux to SD3.5 to the video models.

The one setting that matters

weight_dtype is where most people touch this node, and it's worth a moment because fp8 is the default answer for a reason:

• default - whatever precision the file was saved in (usually fp16/bf16).
• fp8_e4m3fn - the 8-bit float format that became the default way to run Flux-class models. Half the VRAM of fp16 at near-invisible quality loss.
• fp8_e4m3fn_fast - same dtype plus fp8_optimizations, a speed bump on GPUs that can take it.
• fp8_e5m2 - the looser of the two fp8 variants, slightly worse quality, occasionally the only option for a given file.

The honest rule from the community: fp8 is basically fp16 at half the size, so if it fits, just use it. Below about 12GB VRAM fp8 stops fitting and people reach for GGUF quantized files instead - which load through the GGUF custom-node pack, not this node. And one thing to know before you switch dtypes mid-project: don't flip a LoRA-trained workflow to a different weight dtype expecting identical output. Precision changes the numbers, and finetuned stacks can respond badly.

Wiring and gotchas

The single MODEL output goes straight into your sampler - KSampler, KSampler Advanced, or a guider if you're running distilled models. Around it you'll wire the conditioning from your CLIP and the latent from your VAE encoder.

The usual traps, in order of frequency:

• Wrong model for the sampler. A distilled 8-step checkpoint through a 30-step KSampler at CFG 7 is a guaranteed mess. Match steps and CFG to what the model page says.
• fp8 on old GPUs. RTX 30-series and older can't always run fp8 natively well; default or GGUF is the fallback.
• The "why is my workflow slow" question. Offloading a 12B model to system RAM works but is brutal on speed - the PCIe bottleneck makes it usually not worth it. If you're swapping, quantize instead.

It ships with ComfyUI core; nothing to install. The mindset shift is the real deliverable: on modern architectures, the model is a component you size and quantize on its own, and this node is the dial.