The Pivot: Re-Evaluating a NaN Crash in GLM-5-NVFP4 Deployment on Blackwell GPUs
In the course of deploying the GLM-5-NVFP4 model on eight NVIDIA RTX PRO 6000 Blackwell GPUs, a single assistant message (index 197) marks a critical turning point. This message is not a triumphant breakthrough but rather a moment of intellectual honesty: the assistant admits that its previous hypothesis was wrong, synthesizes new evidence from local research files, and pivots to a fresh line of investigation. The message reads in full:
Same crash — NaN/Inf in probability tensor during decode. The --fp8-gemm-backend cutlass didn't fix it because the issue is specific to how DeepGemm or the FP4 GEMM processes GLM-5's scale format.
>
Looking at the FINDINGS.md, the Kimi K2-Thinking NVFP4 worked fine. The key difference is GLM-5 has DSA (DeepSeek Sparse Attention) which forces NSA backends. The NaN is likely coming from the DSA attention path, not the MoE/GEMM path.
>
Let me check if there's a way to disable DSA or if the RoPE incompatibility with transformers 5.2.0 is the real issue. The warning was very specific: "If you experience issues related to RoPE parameters, they may be due to incompatibilities between Transformers >=5.0.0"
This brief paragraph, followed by a bash command to kill the server process, encapsulates a sophisticated debugging workflow. To understand its significance, we must trace the reasoning, assumptions, and context that led to this moment.
The Context: A Cascade of Failed Attempts
The message arrives after an extended debugging session spanning multiple server launches and crashes. The assistant had been trying to deploy GLM-5-NVFP4 — a quantized Mixture-of-Experts model with DeepSeek Sparse Attention (DSA) — on cutting-edge Blackwell (SM120) hardware using the SGLang inference framework. The symptom was consistent and brutal: the server would load successfully, capture CUDA graphs during warmup, and then crash on the very first decode step with a device-side assert triggered error. The root cause, revealed in earlier log inspection ([msg 185]), was an assertion failure: "probability tensor contains either inf, nan or element < 0."
In the messages leading up to index 197, the assistant had pursued a specific hypothesis. A warning in the server logs — "DeepGemm is enabled but the scale_fmt of checkpoint is not ue8m0. This might cause accuracy degradation on Blackwell" — had pointed toward the FP8 GEMM backend as the culprit. DeepGemm, a high-performance GEMM library for Blackwell, was auto-selected by SGLang but was incompatible with the checkpoint's scale format. The assistant's fix was to force --fp8-gemm-backend cutlass, switching to the older Cutlass backend ([msg 187]). The server was relaunched with this configuration, and the assistant waited through a long model-loading process spanning 83 safetensors shards.
The Moment of Disconfirmation
Message 197 opens with a blunt acknowledgment: "Same crash." The Cutlass backend did not help. This is the critical moment where a hypothesis is empirically falsified. The assistant had invested significant effort in this theory — it had killed the previous server, crafted a detailed launch command with multiple environment variables, and waited minutes for the model to load. Yet when the evidence came back negative, it did not double down or rationalize. Instead, it immediately began reconstructing its mental model.
The assistant's reasoning here is worth examining closely. It writes: "The --fp8-gemm-backend cutlass didn't fix it because the issue is specific to how DeepGemm or the FP4 GEMM processes GLM-5's scale format." This sentence is doing something subtle. The assistant is not fully abandoning the DeepGemm hypothesis — it's considering that the problem might be in the FP4 GEMM path rather than the FP8 GEMM path. The --fp8-gemm-backend flag only controls the FP8 GEMM; the FP4 GEMM (used for the model's quantized weights) is controlled separately by --fp4-gemm-backend. This distinction reveals the assistant's growing sophistication about the SGLang architecture.
The Pivot: From GEMM to Attention
The decisive pivot comes in the next sentence: "Looking at the FINDINGS.md, the Kimi K2-Thinking NVFP4 worked fine. The key difference is GLM-5 has DSA (DeepSeek Sparse Attention) which forces NSA backends. The NaN is likely coming from the DSA attention path, not the MoE/GEMM path."
This is a textbook example of comparative debugging. The assistant had just read the local FINDINGS.md file (<msg id=190-193>), which documented a previous successful deployment of the Kimi K2-Thinking NVFP4 model on the exact same hardware. That model worked without issues. By comparing the two deployments, the assistant isolates the distinguishing variable: GLM-5 uses DSA (DeepSeek Sparse Attention), while Kimi K2-Thinking does not. DSA forces SGLang to use "NSA backends" — specialized attention kernels for sparse attention patterns. The assistant hypothesizes that the NaN originates in these attention kernels rather than in the MoE or GEMM computation.
This is a significant re-framing. Earlier, the assistant had tried switching attention backends (flashinfer, triton, flashmla_sparse) and even the NSA decode backend (flashmla_kv, flashmla_sparse, trtllm) — all without success (<msg id=177-179, 183-184>). But those attempts were framed as exploring the attention backend space; the current insight is that the architecture itself (DSA) may be incompatible with the Blackwell GPU's SM120 capabilities in the attention path, independent of which specific backend is chosen.
The RoPE Alternative
The assistant does not commit fully to the DSA hypothesis. It introduces a second possibility: the RoPE (Rotary Position Embedding) incompatibility warning from Transformers 5.2.0. The model card for GLM-5 required upgrading Transformers to version 5.2.0, and the upgrade came with a warning: "If you experience issues related to RoPE parameters, they may be due to incompatibilities between Transformers >=5.0.0." This warning, noted earlier in the conversation, now takes on new significance. The assistant is keeping both hypotheses alive — DSA attention kernels and RoPE parameter incompatibility — and proposes to investigate whether DSA can be disabled entirely.
Assumptions and Their Validity
Several assumptions underpin this message. First, the assistant assumes that the NaN originates from a single, identifiable source rather than from an interaction between multiple components. This is a reasonable debugging heuristic but not guaranteed — the NaN could be caused by a cascade of numerical issues across different layers. Second, the assistant assumes that the Kimi K2-Thinking deployment is a valid control. This is sound: same hardware, same framework (SGLang main branch), same quantization method (NVFP4), different architecture. The controlled comparison strengthens the inference that DSA is the differentiating factor.
However, there is a potential blind spot. The assistant assumes that the --fp8-gemm-backend cutlass flag was correctly applied and that the FP8 GEMM path was genuinely switched. But the FP4 GEMM path — controlled by --fp4-gemm-backend — was left at its default (auto). If the FP4 GEMM also auto-selects DeepGemm on Blackwell, and if the FP4 path is where the scale format mismatch occurs, then the Cutlass fix would have been ineffective regardless. The assistant's language ("the issue is specific to how DeepGemm or the FP4 GEMM processes GLM-5's scale format") suggests it is aware of this possibility but does not explicitly check the FP4 GEMM backend selection.
Input Knowledge Required
To fully understand this message, one needs knowledge of several domains. The SGLang inference framework and its backend architecture (attention backends, NSA backends, GEMM runners) are essential — without this, the distinction between --fp8-gemm-backend and the DSA attention path would be meaningless. Knowledge of the GLM-5 model architecture, particularly its use of DeepSeek Sparse Attention and Mixture-of-Experts, is required to understand why DSA is a distinguishing feature. Familiarity with Blackwell (SM120) GPU architecture helps contextualize why certain backends (DeepGemm, flashmla) may have compatibility issues. Finally, understanding the Transformers library's version-specific behavior — particularly the RoPE parameter changes in version 5.0.0 — is necessary to evaluate the alternative hypothesis.
Output Knowledge Created
This message produces several valuable outputs. It establishes that the --fp8-gemm-backend cutlass fix is insufficient, ruling out one hypothesis and narrowing the search space. It introduces a new, well-motivated hypothesis (DSA attention path as the NaN source) grounded in comparative evidence from the local research repository. It identifies two specific avenues for further investigation: disabling DSA entirely, or addressing the Transformers 5.2.0 RoPE incompatibility. The message also implicitly documents a debugging methodology — comparative analysis against a known-good configuration — that future deployers of GLM-5 on Blackwell can follow.
The Thinking Process
The reasoning visible in this message reveals a structured, scientific approach to debugging. The assistant cycles through hypothesis formation, experimental testing, evidence evaluation, and hypothesis revision. When the evidence contradicts the hypothesis, it does not discard the hypothesis entirely but refines it: the DeepGemm scale format issue may still be relevant, but perhaps at the FP4 level rather than the FP8 level. The assistant then cross-references local documentation (FINDINGS.md) to find a controlled comparison, isolates the distinguishing variable (DSA), and formulates a new hypothesis. The final sentence — "Let me check if there's a way to disable DSA or if the RoPE incompatibility with transformers 5.2.0 is the real issue" — proposes concrete next steps that will generate new evidence.
The message also demonstrates the value of local research artifacts. The FINDINGS.md file, created during a previous deployment of a different model on the same hardware, becomes the key piece of evidence that redirects the investigation. Without it, the assistant might have continued down the DeepGemm path indefinitely, trying different FP8 GEMM backends to no avail.
Conclusion
Message 197 is a study in effective debugging under uncertainty. It is the moment when a promising hypothesis is falsified, a new theory is born from comparative evidence, and the investigation pivots toward a more promising direction. The message is concise — barely three sentences of analysis — but each sentence carries weight: an acknowledgment of failure, a synthesis of new evidence, and a plan for the next experiment. In the broader narrative of deploying GLM-5-NVFP4 on Blackwell GPUs, this message represents the turning point where the assistant stops chasing the GEMM path and starts looking at the attention path — a shift that would ultimately prove crucial to resolving the NaN crash.