ComfyUI NVFP4 on RTX 50-Series: Why Your ‘2x Faster’ Model Is Running Slower Than FP8

You bought an RTX 5090 (or 5070 Ti / 5060 Ti), read that NVFP4 quantization delivers a “~2x performance boost” over fp8 and bf16, downloaded an NVFP4 model like LTX-2 19B, and then watched it generate slower than the fp8 version you already had. If that sounds familiar, you are not doing anything wrong — you are almost certainly falling into a silent fallback that ComfyUI documents but that is easy to miss.

The failure here is subtle: the model works. It doesn’t crash, doesn’t throw an error, doesn’t print a red warning. It just runs slower. And because the whole point of NVFP4 is speed, a slow NVFP4 run is a symptom that the acceleration path was never actually engaged. This article walks through how to confirm that, why it happens, and how to fix it, using only commands you can run on your own machine.

What NVFP4 Actually Requires (the part everyone misses)

NVFP4 is a 4-bit floating-point quantization format that targets the dedicated FP4 hardware in NVIDIA’s Blackwell architecture — the chips inside every RTX 50-series card and the Blackwell Pro workstation parts. When the path works, ComfyUI reports up to a ~2x speedup compared to fp8 or bf16/fp16 on the same model.

But there is a hard dependency buried in the official announcement. Quoting the ComfyUI blog post directly: ComfyUI “only supports NVFP4 acceleration if you are running PyTorch built with CUDA 13.0 (cu130).” The critical sentence that follows is the one that causes the confusion:

Otherwise, while the model will still function, your sampling may actually be up to 2x slower than fp8.

Read that again carefully. If your PyTorch is a cu128 build (the current stable PyTorch at the time of writing), an NVFP4 model will load, will produce output, and will be slower than fp8 — with no obvious error telling you why. This is the silent-fallback trap, and it is the single most common reason people report “NVFP4 made my card slower.”

This is also consistent with the official NVIDIA Blackwell setup guidance for ComfyUI, which directs RTX 50-series users to PyTorch nightly (cu130) rather than the stable cu128 build while Blackwell support matures. If you installed ComfyUI through a stable channel and never touched your PyTorch, you are likely on cu128 right now.

Diagnosing the Fallback: Check Your CUDA Runtime First

Before you tweak a single flag, confirm which PyTorch build you actually have. This command is the whole diagnosis in one line:

python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"

Run it from the same Python environment ComfyUI uses (activate the venv or use ComfyUI’s embedded Python first, depending on your install). What you are looking for is the middle value — torch.version.cuda:

• 13.0 or 13.1 (cu130/cu131): NVFP4 acceleration is available. Any slowness you see is not a build mismatch — move on to the next section.
• 12.8 (cu128) or lower: You are on the stable build. NVFP4 models will run, but without hardware acceleration — and can be up to 2x slower than fp8. This is your problem.
• None: PyTorch has no CUDA at all. You have a bigger issue; NVFP4 is irrelevant until you fix the base CUDA install.

There is also a useful second check if you want to see which CUDA architectures your build was compiled for — this tells you whether sm_120 (Blackwell) is even present in the binary:

python -c "import torch; print(torch.cuda.get_arch_list())"

If sm_120 is missing from that list while you are on cu128, that is the smoking gun: your PyTorch build was never compiled with native Blackwell kernels, and NVFP4 cannot be hardware-accelerated on it.

The Fix: Moving to a cu130 PyTorch Build

The repair is a PyTorch reinstall, not a ComfyUI change. The official guidance for Blackwell cards is to use a cu130 build, which at present means the PyTorch nightly channel — the stable release still ships cu128.

The exact install command depends on your OS and how you installed ComfyUI, and PyTorch’s install matrix changes over time, so the safest move is to generate the correct command from the official selector rather than copy a stale one from a forum. In the same environment where you confirmed torch.version.cuda == 12.8, run the cu130 nightly install, then verify with the same one-liner from the previous section:

python -c "import torch; print(torch.__version__, torch.version.cuda)"

You want that middle value to now read 13.x. Only after it does should you re-run an NVFP4 model and benchmark it against fp8. A few practical cautions from real-world reports:

• Nightly is not stable. Community reports on Blackwell note occasional crashes with cu130 nightly builds. Treat it as a trade — native NVFP4 speed versus the stability of the cu128 release. Some people keep two environments for this reason.
• Windows portable users should prefer the official standalone Blackwell package (the cu128 50-series build) if they are not chasing NVFP4 specifically, rather than hand-mixing PyTorch into a portable install where the embedded Python can fight you during updates.
• Reinstalling PyTorch does not touch your models or workflows. Your checkpoints, custom nodes, and saved workflows survive a PyTorch swap. Worst case you reinstall a compatible PyTorch back to cu128 and you are exactly where you started.

When You Are Already on cu130 But Still Not Seeing the Speed

If your torch.version.cuda already reads 13.x and an NVFP4 model is still slower than expected, the build is no longer the culprit. There is a real-world case of exactly this: a GitHub issue on the ComfyUI-LTXVideo repository reported LTX-2 19B NVFP4 (143 frames at 720p) taking ~66 seconds on an RTX 5090 32GB, versus the ~40–45 second range shown in NVIDIA’s own video guide — with CUDA 13.1 already installed and the GPU otherwise idle.

That gap is not a build mismatch; it is the gap between a freshly-released model path and a vendor reference number. When you hit this situation, work through these instead:

• Confirm your ComfyUI and custom nodes are genuinely current. NVFP4 support and Blackwell kernels are landing in rapid succession. An uptime-old checkout can silently lack a performance patch that matters.
• Verify async offloading and pinned memory are active. These are now enabled by default for all NVIDIA cards, and they primarily help when weights don’t fit in VRAM. On a 32GB card running a 19B model, they matter less; but if they were disabled, you’d lose that headroom.
• Check your PCIe link, not just your GPU. ComfyUI explicitly notes that async-offload gains scale with PCIe generation and lane count. A card in an x8 slot (or an older PCIe 3.0/4.0 motherboard) will see measurably worse offload gains than the x16 PCIe 5.0 reference numbers.
• Measure with the same prompt and seed. “Slower than expected” only means something against a controlled baseline. Time fp8 vs NVFP4 on the identical workload before you conclude anything.

Experiment Flags Worth Knowing (But Not Your First Move)

ComfyUI ships experiment optimization flags under --fast, including fp8_matrix_mult and fp16_accumulation. These can unlock further speed but are documented as experimental and may affect quality or stability. The correct order of operations is: fix the PyTorch build first, confirm the baseline speed, and only then experiment with flags — one at a time, re-measuring each change. Enabling experimental flags on top of a cu128 fallback just adds noise to a problem you haven’t actually isolated.

One more thing worth stating plainly: if a model fits entirely in VRAM and you never offload weights, async offloading and pinned memory are not going to give you a meaningful speedup. Those optimizations target the offload path. NVFP4, by contrast, is a math optimization — it changes how fast the kernels run, not just how weights are loaded. That is why getting the correct cu130 build matters more than any flag.

Conclusion

The overwhelming majority of “NVFP4 is slower than fp8 on my RTX 50-series card” reports come down to one thing: a cu128 PyTorch build silently falling back to non-accelerated execution. The fix is not a ComfyUI setting — it is verifying your runtime with print(torch.version.cuda) and, if it reads 12.8, moving to a cu130 build. Confirm the version change, re-benchmark against fp8 on an identical prompt, and only then chase experiment flags or PCIe topology if the gap remains.

For the authoritative details on NVFP4 acceleration, async offloading, and pinned memory, see the official ComfyUI optimization announcement and NVIDIA’s TensorRT FP4 on Blackwell technical blog. For the RTX 50-series setup specifics and the cu130 nightly guidance, see the ComfyUI Blackwell support discussion. If you are still running into VRAM pressure while you are at it, our earlier write-up on why Dynamic VRAM breaks some workflows and the attention backend tradeoffs cover the two settings people most often crank at the same time.