This article was originally published on runaihome.com
A black image out of ComfyUI is one of the most frustrating failures because nothing crashes. The workflow turns green, the progress bar fills, the preview is solid black, and the terminal usually shows a single quiet line:
RuntimeWarning: invalid value encountered in cast
That line is the whole story. Your KSampler produced NaN (not-a-number) values in the latent, and when ComfyUI cast those to an 8-bit image, every pixel collapsed to zero — black. Sometimes it's gray or a green wash instead, but the root cause is the same family of problems, and almost all of them are precision-related.
There are only about five real causes, and each has a specific fix. This walks through them in the order you should check, fastest first.
What you'll be able to do after this:
- Read the one terminal warning that proves it's a NaN problem (not a bad prompt or model)
- Apply the right precision flag (
--fp32-vae,--cpu-vae,--force-fp32) for your exact card and model - Know when the fix is a 200MB VAE download versus a one-word launch flag
If your problem is ComfyUI failing to start, a red node, or "Torch not compiled with CUDA enabled," that's a different class of bug — see ComfyUI "Torch not compiled with CUDA enabled" and ComfyUI custom node "IMPORT FAILED". This article is only for the case where generation runs but the output is black, gray, or green.
Step 0: Confirm it's actually a NaN problem
Before changing anything, look at the terminal (the console window ComfyUI runs in, not the browser). You're looking for one of these:
RuntimeWarning: invalid value encountered in cast- A message mentioning
NaNin the latent or "tensor contains NaN/Inf" - No error at all, just a silent black PNG saved to
output/
If you see invalid value encountered in cast, the KSampler output was already corrupt before the VAE decoded it — the latent itself is full of NaNs. That points the finger at precision in the diffusion model or VAE, which is exactly what the fixes below address. ComfyUI's own VAE flag help text says the quiet part out loud: --fp16-vae is documented as "Run the VAE in fp16, might cause black images." Half precision is the usual culprit.
If instead you see a real Python traceback or a red node, stop here — that's a different problem (out of memory, a bad model file, a broken custom node).
Fix 1: The SDXL fp16 VAE NaN bug (the classic one)
This is the single most common cause for anyone running SDXL or SDXL-based checkpoints. The original SDXL VAE that Stability shipped numerically overflows in fp16: certain activations exceed the fp16 range, become Inf, then NaN, and you get a black image. It's not your GPU — the VAE itself is broken in half precision.
Three ways to fix it, in order of preference:
Option A — swap in the fp16-safe VAE (best). Download sdxl-vae-fp16-fix, a version of the SDXL VAE retrained to stay inside fp16 range without producing NaNs. Drop sdxl_vae_fp16_fix.safetensors into ComfyUI/models/vae/, add a Load VAE node, point it at that file, and wire it into your VAE Decode. This keeps the speed and low VRAM of fp16 while killing the black images. It's built on the SDXL 0.9 VAE and works with SDXL 0.9 and 1.0 checkpoints.
Option B — force the VAE to fp32. Launch with:
python main.py --fp32-vae
This runs the VAE in full precision. No NaNs, slightly more VRAM and a little slower on decode, but it always works. On a 24GB card the cost is negligible.
Option C — run the VAE on CPU. If you're VRAM-starved and fp32 VAE tips you into an out-of-memory error:
python main.py --cpu-vae
Community reports are consistent that running the VAE on CPU reliably eliminates the SDXL black-image issue. It's slow — decode can take several seconds instead of a fraction of one — but it's bulletproof when nothing else fits. If --cpu-vae then throws an OOM on system RAM, see CUDA out of memory fixes.
For most SDXL users, Option A is the right answer: it's a one-time download and you never think about it again.
Fix 2: Wrong VAE for the model
If there's no Load VAE node in your workflow, ComfyUI uses whatever VAE is baked into the checkpoint — and if that's missing or mismatched, you get black or garbage output. The mismatch that bites people most: using an SD 1.5 VAE with an SDXL model (or vice versa). They are not interchangeable. An SD 1.5 VAE on SDXL produces black or noise-filled images every time.
Fix: add an explicit Load VAE node and point it at the correct file:
- SDXL / SDXL checkpoints →
sdxl_vae.safetensors(or the fp16-fix version from Fix 1) - SD 1.5 checkpoints → the SD 1.5 VAE (
vae-ft-mse-840000-ema-pruned.safetensors) - FLUX → the FLUX VAE (
ae.safetensors)
Make sure the file actually exists in ComfyUI/models/vae/. An empty or zero-byte download will also decode to black.
Fix 3: The GTX 16-series fp16 trap
This one is hardware, not software. The GTX 1650 / 1660 / 1660 Ti / 1660 Super have a known defect in fp16 support — they'll produce an all-black or all-green image in half precision unless you force full precision. ComfyUI maintainers and a long-running issue thread (#884) confirm the behavior: on a 16-series card, fp16 is unreliable.
The fix is a single flag:
python main.py --force-fp32
One user reported this "eliminated 99% of black images and crashes" on a GTX 16-series setup. It sets the UNet, VAE, and text encoder all to fp32 — the most accurate and slowest path — but on these cards it's the only stable option. Expect generation to be noticeably slower; the 16-series was never a fast inference card to begin with.
If you're hitting this, it's worth being honest about the hardware: a card with broken fp16 in 2026 is a hard floor on your local AI experience. A used RTX 3090 (24GB, ~936 GB/s, proper fp16/bf16) or a new RTX 5060 Ti 16GB sidesteps every fp16 precision bug in this article and runs FLUX and SDXL at sane speeds. See the GPU buying guide if you're weighing an upgrade.
Fix 4: Extreme CFG and bad sampler settings
NaNs don't only come from precision. Pushing the CFG scale far outside its sane range can blow up the math too. CFG above ~15 (and sometimes below ~2) can drive values out of range and produce NaN latents, especially on models tuned for low CFG.
Check your KSampler:
- Standard SDXL / SD 1.5: CFG around 6–8 is the safe zone. If you've cranked it to 20 chasing "more prompt adherence," pull it back to 7 and test.
- Turbo / Lightning / distilled models: these want CFG 1–2. Running a Turbo model at CFG 7 can give you fried or NaN output.
- FLUX: uses its own guidance node, not classic CFG — leave the KSampler CFG at 1.0 and use the FluxGuidance node instead. See FLUX.1 Kontext Dev local setup for the correct FLUX graph.
Also sanity-check that you didn't accidentally set steps to 1 or pick a sampler/scheduler combo the model wasn't trained for. A mismatched scheduler can produce noise that looks like a "failed" black-ish image.
Fix 5: The new-model NaN bug (Z-Image and friends, 2026)
Newer architectures sometimes ship before their fp16/bf16 paths are stable in ComfyUI. The clearest 2026 example: Z-Image Base (Tongyi-MAI). Multiple reports — including ComfyUI issue #13123 (filed March 2026) and the upstream Z-Image issue #14 — show that Z-Image Base outputs silent black images regardless of precision, throwing the same invalid value encountered in cast warning, while Z-Image Turbo works perfectly in the identical workflow. Running the model in torch.float16 produces pure black (N
