The Blackwell Gauntlet: Deploying GLM-5-NVFP4 Across 8 GPUs Through Iterative Debugging

Introduction

In the rapidly evolving landscape of large language model deployment, the intersection of cutting-edge model architectures and brand-new GPU hardware creates a debugging frontier where established practices break down and every assumption must be verified. This article synthesizes a sprawling coding session—spanning over 120 messages—in which an AI assistant attempted to deploy the GLM-5-NVFP4 model, a 4-bit quantized Mixture-of-Experts (MoE) language model with DeepSeek Sparse Attention (DSA), across eight NVIDIA RTX PRO 6000 Blackwell GPUs using the SGLang inference serving framework.

What began as a straightforward deployment task evolved into a multi-layered debugging odyssey that tested the limits of systematic problem-solving. The assistant encountered and resolved a cascade of failures: a missing model architecture in Transformers, a GPU architecture incompatibility requiring a source-code fix, an out-of-memory crash during CUDA graph capture, and—most persistently—a numerical stability failure that produced NaN (Not a Number) values in the probability tensor during decode. Each failure narrowed the search space, and each resolution revealed deeper layers of complexity in the intersection of Blackwell hardware, FP4 quantization, sparse attention mechanisms, and rapidly evolving serving framework code.

This article traces that journey, examining the key decisions, assumptions, and discoveries that shaped the deployment effort, and extracting lessons for anyone working at the frontier of AI infrastructure.

From Environment Setup to Deployment Planning

The session's first segment (messages 0–84) had established a stable ML environment on an Ubuntu 24.04 machine with CUDA 12.8 and 13.1, PyTorch 2.9.1, flash-attn 2.8.3, and vLLM 0.15.1. The user then delivered a pivotal instruction at [msg 85]: "Added 8 GPUs; Deploy glm-5 nvfp4." This single sentence transformed the session's trajectory from environment setup to production deployment.

The assistant's response at [msg 86] was a masterclass in structured planning. It created a prioritized todo list: verify the 8 GPUs, install SGLang from the main branch, download the model, deploy with tensor parallelism, and tune parameters. This planning phase established a framework that would guide the next hundred messages, with each subsequent action traceable back to this initial decomposition of the user's request.

The first verification step at [msg 87] confirmed that all eight RTX PRO 6000 Blackwell GPUs (96 GB each, compute capability SM120) were visible and operational. This was not a trivial check—the user had physically added six GPUs mid-session, and the assistant needed to confirm that the NVIDIA driver, PCIe topology, and NCCL communication stack could handle the expanded configuration. The nvidia-smi output showed all eight GPUs with their full 96 GB of memory, confirming the hardware was ready.

The First Launch and Its Immediate Failures

With the hardware verified, the assistant proceeded to install SGLang. The initial installation used version 0.5.8.post1 from PyPI, along with flashinfer 0.6.1 for attention kernels. The first launch command at [msg 109] was carefully constructed, drawing on the HuggingFace model card's recommended parameters: tensor parallelism 8, FP4 quantization via modelopt_fp4, flashinfer attention backends, and aggressive memory reservation (--mem-fraction-static 0.95).

The launch failed immediately—but not with a GPU error. Instead, the server crashed with a KeyError: 'glm_moe_dsa' ([msg 110]). The installed Transformers library (version 4.57.1) did not recognize the model architecture used by GLM-5. This was the first critical discovery: the GLM-5-NVFP4 model uses a custom architecture (glm_moe_dsa) that was only added to Transformers in version 5.2.0. The assistant upgraded Transformers to 5.2.0 ([msg 113]), verified the architecture was now recognized ([msg 114]), and prepared for a second launch.

The SM120 Correction: Why Main Branch Mattered

Before the second launch could proceed, the user interjected with a crucial observation at [msg 117]: the installed SGLang version lacked support for the SM120 compute capability of Blackwell GPUs. A specific pull request, #14311, had been merged into SGLang's main branch to fix shared memory block sizes for the RTX PRO 6000's architecture. Without this fix, attention kernels would use Hopper-sized block sizes that exceeded the Blackwell GPU's smaller shared memory capacity (100 KB versus 160+ KB on Hopper), causing crashes or silent correctness issues.

The assistant verified this by inspecting the source code of the installed SGLang ([msg 120]), confirming that the SM120 fix was absent. The solution required cloning the SGLang repository and building from the main branch (<msg id=123-125>). After installation, the assistant verified the fix by re-inspecting the source code for the CUDA_CAPABILITY[0] == 12 branch ([msg 127]). This episode highlighted a fundamental challenge of deploying on new hardware: stable releases of serving frameworks often lack critical patches for the latest GPU architectures, and operators must be prepared to build from source.

The Second Launch: Warnings Before the Storm

The second launch at [msg 130] used the freshly built main-branch SGLang with Transformers 5.2.0. The server began loading the model—a process that would consume the next several messages as the assistant monitored the download of approximately 250 GB of checkpoint shards across all eight GPUs (<msg id=133-145>).

But the launch log contained two warnings that would prove prophetic. The first warned: "DeepGemm is enabled but the scale_fmt of checkpoint is not ue8m0. This might cause accuracy degradation on Blackwell." The second warned: "Transformers version 5.2.0 is used for model type glm_moe_dsa. If you experience issues related to RoPE parameters, they may be due to incompatibilities." The assistant noted both warnings but could not act on them at this stage—the server was still loading, and the warnings were classified as advisory rather than critical.

The model eventually loaded successfully across all eight GPUs, consuming approximately 63 GB per GPU for weights. KV cache was allocated with 425,664 tokens across 24.37 GB per GPU. CUDA graphs were captured for batch sizes up to 64. The server reported itself as running. Everything looked ready.

The Moment of Truth: First Inference Crash

The assistant sent a simple test query at [msg 159]: "Hello! What model are you?" with 100 max tokens. The server returned nothing. A health check at [msg 162] showed "Connection refused"—the server had crashed.

The crash log at [msg 163] revealed a device-side assert triggered error—a CUDA runtime assertion failure. The assistant's initial grep for error patterns returned cryptic output: a corrupted traceback and a reference to the CUDA documentation. The actual error message was fragmented across multiple log lines, garbled by concurrent GPU threads writing to the same error buffer.

It took several rounds of forensic log analysis to extract the critical clue. At [msg 185], the assistant grepped for "Scheduler hit an exception" and found the assertion message: "probability tensor contains either inf, nan or element < 0." The model was producing garbage values during decode. This was not a kernel compatibility issue—it was a numerical stability failure.

The Debugging Spiral: Attention Backends and GEMM Paths

The discovery of NaN values in the probability tensor launched an intensive debugging phase spanning messages 163 through 210. The assistant pursued multiple hypotheses in parallel, each grounded in the warnings from the server logs.

Hypothesis 1: Attention backend incompatibility. The assistant tried switching from flashinfer to triton attention backends ([msg 170]), but the triton backend crashed with a different assertion about NSA KV cache FP8 incompatibility ([msg 174]). It then tried flashmla_sparse as the NSA decode backend ([msg 178]), which appeared to work during warmup but crashed on the first real query (<msg id=182-184>).

Hypothesis 2: DeepGemm scale format mismatch. The warning about DeepGemm being enabled with a non-ue8m0 scale format pointed to a potential numerical corruption in the GEMM (General Matrix Multiply) operations. The assistant forced --fp8-gemm-backend cutlass to bypass DeepGemm ([msg 187]). The server loaded successfully and warmup passed, but the NaN crash persisted during decode ([msg 195]).

Hypothesis 3: CUDA graph capture instability. After consulting the local research repository (FINDINGS.md) at <msg id=188-193>, the assistant learned that a previous successful NVFP4 deployment (Kimi K2-Thinking) on the same hardware had used --disable-cuda-graph. The assistant launched a new attempt with this flag ([msg 204]), along with --kv-cache-dtype auto to avoid forcing FP8 KV cache. The server loaded, but the DeepGemm and Transformers warnings persisted ([msg 208]).

The Research Pivot: Consulting Local Knowledge

A critical turning point came at [msg 188], when the user directed the assistant to "Read research in ./ that run other glm/kimi models." This instruction reframed the debugging effort. Instead of continuing to brute-force configuration combinations, the assistant consulted a local repository at /home/theuser/glm-kimi-sm120-rtx6000bw/ that contained findings from previous deployments of similar models on the exact same hardware.

The FINDINGS.md file (<msg id=191-192>) documented a successful deployment of Kimi K2-Thinking NVFP4 on the same eight Blackwell GPUs. The key findings included: the NaN issue was NOT the SM120 shared memory problem (already fixed in the main branch build), previous successful NVFP4 deployments used --disable-cuda-graph, and the DeepGemm + non-ue8m0 scale format warning was a known issue on Blackwell. The repository also contained benchmark data comparing TP8 and TP4 PP2 configurations, showing that TP4 PP2 significantly outperformed TP8 at high concurrency.

This research pivot transformed the debugging approach from trial-and-error to evidence-based reasoning. The assistant now understood that the NaN crash had been encountered before, and that the solution likely involved a combination of --disable-cuda-graph, careful KV cache dtype selection, and possibly bypassing DeepGemm entirely.

The Persistence of Warnings: A Diagnostic Dead End

Despite incorporating the findings from the research repository, the assistant's sixth attempt at [msg 204] still crashed with the same NaN error. The diagnostic check at [msg 208] revealed that both critical warnings persisted: DeepGemm was still enabled despite the --fp8-gemm-backend cutlass flag, and the Transformers 5.2.0 RoPE incompatibility warning was still active.

This was a devastating discovery. It proved that the assistant's configuration changes were not reaching the root cause. The DeepGemm warning persisted because it was triggered by hardware detection (SM120 Blackwell GPUs automatically enable DeepGemm features), not by the GEMM backend flag. The Transformers warning persisted because the model's glm_moe_dsa architecture was inseparable from version 5.2.0—the model repo did not provide custom config code via trust_remote_code, relying entirely on Transformers having the architecture built in.

The assistant had exhausted the approach of tweaking backend flags. Both known warnings persisted despite multiple configuration attempts spanning different attention backends, GEMM backends, NSA decode backends, CUDA graph settings, and KV cache dtypes. The debugging strategy needed to change—perhaps requiring source-level patches to SGLang, modifications to the model's configuration, or an entirely different deployment path.

Lessons from the Blackwell Gauntlet

This deployment effort reveals several fundamental truths about deploying cutting-edge AI models on new hardware:

1. Stable releases are not enough. The initial SGLang release (0.5.8.post1) lacked critical SM120 support that was only available in the main branch. Operators deploying on new GPU architectures must be prepared to build from source and track nightly development branches.

2. Model architecture support lags behind model releases. The GLM-5-NVFP4 model required Transformers 5.2.0 for its glm_moe_dsa architecture, but this version introduced its own compatibility issues (the RoPE warning). The dependency chain—model → Transformers → serving framework → CUDA kernels → GPU hardware—creates a compatibility matrix where each layer may have gaps.

3. Numerical stability is harder to debug than crashes. A model that loads successfully, captures CUDA graphs, and completes warmup can still produce garbage during decode. The prefill path and decode path use different CUDA kernels, and numerical issues may only manifest in the autoregressive generation loop. This asymmetry makes "it starts" an insufficient test of correctness.

4. Local empirical knowledge is invaluable. The FINDINGS.md repository, documenting previous deployments on the exact same hardware, provided more actionable information than the HuggingFace model card, the SGLang documentation, or GitHub issues. In the frontier of new hardware deployment, the most reliable source of truth is previous experience on the same machine.

5. Warnings are prophecies. The DeepGemm scale format warning and the Transformers RoPE warning, both present from the very first launch, turned out to be the root causes of the NaN crashes. The assistant treated them as advisory, but they were diagnostic gold. In complex systems, warnings should be investigated immediately, not deferred.

Conclusion

The deployment of GLM-5-NVFP4 on eight Blackwell GPUs was a journey through the bleeding edge of AI infrastructure. The assistant navigated hardware verification, source-code builds, dependency conflicts, memory tuning, and numerical stability debugging—each step revealing new dimensions of complexity in the intersection of quantized MoE models, sparse attention mechanisms, and next-generation GPU architecture.

At the end of the session captured in this chunk, the NaN crash remained unresolved. The assistant had identified the two likely culprits (DeepGemm scale format incompatibility and Transformers 5.2.0 RoPE parameter issues) but had not yet found a configuration that eliminated both. The persistence of the warnings despite multiple configuration changes suggested that a more fundamental fix was needed—perhaps patching the SGLang source code to handle the checkpoint's scale format, or modifying the model's configuration to avoid the RoPE incompatibility.

The session stands as a testament to the challenges of deploying at the frontier, where every component—model architecture, quantization format, serving framework, GPU hardware—is evolving simultaneously, and the only way forward is systematic, iterative debugging informed by local empirical knowledge.