ModelComputeDtype

ModelComputeDtype is the node you reach for when a model runs but the output is wrong - NaN splotches, black frames, or output that looks subtly corrupted for no obvious reason. It forces the whole model to compute in a different precision, and it lives in the advanced/debug category for exactly that reason: it's a "try this and see if the garbage goes away" knob, not a daily driver.

One MODEL in, one MODEL out, sitting between your loader and your sampler like any other model patch. It's been in ComfyUI core for a long time (it lives in comfy_extras/nodes_model_advanced.py), so there's nothing to install.

How it works

Under the hood it calls set_model_compute_dtype() on the model, which does two things: it sets a manual_cast_dtype patch on the model, and it flags the weights to be force-cast into that dtype for the forward pass. So the model still loads in its original file precision, but the math runs in whatever dtype you picked.

The dtype dropdown is the whole interface, and there are only four options:

• default - no forced cast. The model runs in its natural dtype. This is the "undo" option.
• fp32 - full float32 compute. Most precise, roughly double the memory pressure of fp16, and the classic fix for precision-related garbage.
• fp16 - half precision, the memory-light option if a model is somehow running in fp32 and you want it to fit.
• bf16 - brain float16. Similar size to fp16 but with the same exponent range as fp32, so it drifts less on value range even if it keeps less precision overall.

That's it. The search aliases on the node are literally "model precision" and "change dtype," which tells you everything about how the developers expect you to think about it.

When you'd actually use it

The textbook case is NaN corruption. As the troubleshooting lore from the A1111/Forge days puts it, some GPUs and some model paths don't handle half-precision math well, and the result is black images or NaN splotches. Forcing fp32 compute is the standard counter-move - it costs VRAM, but it produces valid numbers. ModelComputeDtype gives you that fix mid-graph instead of via launch flags.

The same logic extends to quantized models. An fp8 or bf16-quantized model that comes out unstable on your hardware sometimes stabilizes if you force fp32 (or even just bf16) compute for the parts that are exploding. It's a broad hammer - it applies to the whole model at once - but broad is often what you want when you're debugging and don't know which block is the problem.

Gotchas

• It forces a full model reload when you change it. The source even has a TODO noting the reload should be optimized. So treat it as a set-once-and-test knob, not something to toggle per generation.
• fp32 is heavy. On a big 12B model that's a lot of extra VRAM for the math pass. If fp32 fixes your artifact but you can't afford it, try bf16 next - it often clears precision bugs at a fraction of the cost.
• It's coarser than the pack-specific controls. Dedicated quant loaders (GGUF and friends) expose per-layer or compute-dtype options that give you precision surgery. ModelComputeDtype is the whole-body approach; use it to confirm precision is the culprit, then decide whether you need finer tools.
• default restores, it doesn't "optimize." Coming back to default returns the model to whatever it loaded as, not to some ideal setting.

If your workflow produces fine images, don't add this node. But when a model comes out corrupted and you suspect the math, it's the fastest way to test the precision hypothesis before you go down a rabbit hole of launch flags.