FLUX on Blackwell: Why sm_120 PyTorch Segfaults and GGUF Bypasses It

The Blackwell sm_120 native crash and port migration loop

Deploying cutting-edge diffusion architectures onto next-generation GPU hardware frequently exposes hidden driver and kernel incompatibilities. When our studio provisioned NVIDIA Blackwell sm_120 silicon running embedded PyTorch 2.7.1 compiled for CUDA cu128, submitting standard FLUX safetensors workflows immediately triggered fatal system instability on 2026-06-21. ComfyUI terminated abruptly without returning a standard Python traceback.

Inspecting low-level operating system telemetry revealed a catastrophic fault: `Windows fatal exception: access violation`. The failure occurred directly inside native CUDA memory during the execution of `FluxClipModel_`. Because the underlying C++ process suffered a hard memory segmentation violation, the parent execution layer received no structured error object, making the failure appear as an unprompted application crash.

A repeated port-migration loop in local web backends indicates a native segmentation violation, not a network failure. SwarmUI's process supervisor detected that port 7821 had closed unexpectedly. Operating under the assumption of a temporary socket conflict, the supervisor automatically attempted to relaunch ComfyUI on the next available port: 7822, followed by 7823. Each subsequent generation attempt crashed instantly upon hitting the text encoder, locking the workstation into an endless restart loop that consumed system resources without rendering a single pixel for production delivery or client review.

Isolating the fp8 T5 encoder kernel incompatibility

Diagnosing a Python-traceback-free crash requires methodical isolation of candidate subsystems. In initial troubleshooting passes, developers hypothesized that the downloaded safetensors model weights were corrupted on disk. Re-hashing the files confirmed exact byte-level integrity across all storage volumes. Companion architectures like Z-Image executed cleanly on the identical backend, proving that the hardware, operating system, and base CUDA runtime were fundamentally functional.

The failure persisted even when running under the `--fp16-text-enc` startup flag and default UNET dtypes. Tracing the ComfyUI 0.21.1 startup logs exposed the architectural culprit: the internal `comfy_kitchen` accelerated quantization backend logged a distinct warning: `WARNING: You need pytorch with cu130 or higher`. Blackwell's sm_120 instruction set introduced novel floating-point execution units that require updated CUDA compilation paths.

Under PyTorch cu128, loading the massive fp8 T5 language model invoked a low-level tensor kernel compiled exclusively for CUDA cu130 toolchains. When the sm_120 hardware attempted to execute instructions unsupported by the cu128 binary, the driver threw an immediate memory access violation. The diffusion transformer UNET was entirely blameless; the crash occurred exclusively within the text encoder's fp8 memory loader during initial weight unflattening.

Bypassing native crashes via GGUF dequantization

Because upgrading the entire embedded Python runtime to unreleased CUDA cu130 toolchains risked destabilizing established studio production stacks, engineering required an in-place software workaround. The solution lay in fundamentally altering how weights are ingested into memory. Rather than relying on ComfyUI's native fp8 safetensors loader, our pipeline migrated to the GGUF quantization format.

The revised workflow pairs `flux1-dev-Q6_K.gguf` with `t5-v1_1-xxl-encoder-Q5_K_M.gguf`, ingested via `UnetLoaderGGUF` and `DualCLIPLoaderGGUF`. The GGUF loader executes dequantization through its own self-contained C++ runtime routines. By translating quantized weights into standard floating-point tensors on the fly, the GGUF pathway completely sidesteps the broken `comfy_kitchen` fp8 kernel.

Upon implementing the GGUF graph, local inference executed with complete stability. Visual generation proceeded without a single memory exception, delivering pristine editorial fidelity while operating well within consumer hardware limits. Both image generation latency and output clarity matched unquantized reference renders without kernel panics.

The immunity of bf16 weights during LoRA training

An essential discovery that emerged during subsequent character LoRA development was that the sm_120 segmentation violation does not affect training pipelines that avoid fp8 quantization. When preparing for Phase 2C adapter training, engineers feared that fine-tuning FLUX on Blackwell silicon would hit the same fatal kernel error during gradient backpropagation.

In training workflows, however, the uncompressed 23.8 GB UNET is ingested in native bf16 safetensors format via standard `UNETLoader`. Paired with a GGUF text encoder loaded through `DualCLIPLoaderGGUF`, the training pipeline initialized cleanly. The system successfully executed real forward passes, calculated autograd graphs, and performed backward optimization passes without triggering an access violation.

Because native bf16 tensor operations utilize mature, long-established CUDA execution units, they never touch the experimental fp8 kernels responsible for the inference crash. This empirical verification proved that Blackwell hardware is entirely capable of executing complex diffusion training under PyTorch cu128, provided quantization pathways are properly isolated from faulty compilation routines. Fine-tuning runs proceeded with predictable gradient convergence across extended epochs.

Production routing rules for Blackwell developer workstations

The lessons learned from the sm_120 access violation established a permanent architectural rule across our local workstation fleet. Until system distributions transition to full CUDA cu130 environments, all local FLUX text-to-image and image-to-image workflows must route exclusively through GGUF loader nodes.

Automated job submission scripts enforce this routing programmatically. When a pipeline requests a local FLUX generation on sm_120 silicon, the runner automatically substitutes the GGUF workflow template for legacy safetensors scripts. This defensive abstraction shields studio artists from cryptic system crashes while maintaining continuous local generation.

Furthermore, system health monitors now track ComfyUI port initialization across local daemons. If an unexpected port migration beyond 7821 is observed during startup, monitoring agents halt the supervision loop immediately, preventing cascading worker launches and alerting engineers to potential CUDA library incompatibilities. By treating the segmentation violation as a specific kernel-level compilation gap rather than general hardware incompatibility, our studio unlocked reliable local generation on state-of-the-art silicon without waiting for upstream toolchain updates.