The Connection Refused: A Pivotal Moment in Debugging GLM-5-NVFP4 on Blackwell

Introduction

In the course of deploying the GLM-5-NVFP4 model on 8 NVIDIA RTX PRO 6000 Blackwell GPUs, a single message captures the moment when multiple debugging hypotheses collapse simultaneously. Message 196 is a diagnostic probe—a curl command followed by a log tail—that returns a stark verdict: "Connection refused." The server, which had appeared to load successfully and pass its warmup phase, has crashed again. This message is not merely a test; it is the culmination of an iterative debugging process that had already cycled through attention backends, quantization backends, CUDA graph settings, and KV cache configurations, all of which failed to resolve the persistent NaN crash during decode.

The Message

The assistant executed the following command via SSH on the remote machine:

ssh 10.1.230.175 'curl -v --max-time 60 http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"glm-5\",\"messages\":[{\"role\":\"user\",\"content\":\"Hi\"}],\"max_tokens\":10}" \
  2>&1; echo "==="; tail -5 ~/sglang-glm5.log'

The output told a clear story:

* Host localhost:8000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
*   Trying [::1]:8000...
* connect to ::1 port 8000 from ::1 port 42954 failed: Connection refused
*   Trying 127.0.0.1:8000...
* connect to 127.0.0.1 port 8000 from 127.0.0.1 port 60640 failed: Co...

The "===" separator appears, but the tail output is truncated—the server died so quickly that the log tail may not have been captured, or the connection failure was the only meaningful signal. Either way, the message delivers unambiguous evidence: the server process is no longer running.

Why This Message Was Written

This message was written as a direct follow-up to the previous test (msg 195), which had sent a similar curl request and received an empty response. An empty response from a server that had just completed warmup is ambiguous—it could mean the request timed out, the server returned an empty completion, or the server crashed mid-request. The assistant needed to disambiguate. By adding the -v (verbose) flag to curl, the assistant could see the raw TCP connection behavior. If the server was alive but returning empty responses, curl would show a successful HTTP connection and a 200 response with empty content. If the server had crashed, curl would show "Connection refused."

This diagnostic refinement reveals a key aspect of the assistant's reasoning: it was systematically eliminating ambiguity. The previous test (msg 195) used curl -s (silent mode) which suppresses progress and error output. When that returned nothing, the assistant couldn't tell whether the server had crashed or was simply slow or misconfigured. The verbose curl in message 196 was designed to answer that specific question.

The Broader Debugging Context

To understand the full weight of this message, one must appreciate the debugging journey that preceded it. The assistant had been trying to deploy GLM-5-NVFP4—a quantized Mixture-of-Experts model using NVIDIA's FP4 quantization—on Blackwell GPUs (SM120 architecture), a combination that pushed the boundaries of what the sglang serving framework supported.

The saga began with a device-side assert triggered error during decode, accompanied by the critical error message: "probability tensor contains either inf, nan or element < 0." The model was producing NaN logits during the decode phase, crashing the server whenever it tried to generate tokens.

The assistant had pursued multiple hypotheses:

Attention backend incompatibility: The model uses DSA (DeepSeek Sparse Attention), which forces NSA backends (flashmla_kv for decode). The assistant tried switching to triton, flashmla_sparse, and fa3 backends. The triton backend crashed with an assertion error about NSA+FP8 KV cache incompatibility. The flashmla_sparse backend appeared to work during warmup but still crashed during actual decode.
DeepGemm scale format mismatch: A warning appeared repeatedly: "DeepGemm is enabled but the scale_fmt of checkpoint is not ue8m0. This might cause accuracy degradation on Blackwell." The assistant hypothesized that DeepGemm's auto-selection on Blackwell was causing numerical instability because the checkpoint's scale format didn't match what DeepGemm expected. This led to trying --fp8-gemm-backend cutlass (msg 187).
CUDA graph capture issues: The assistant considered whether CUDA graph capture was introducing instability and consulted the local FINDINGS.md, which documented that previous successful NVFP4 deployments used --disable-cuda-graph. The server launched in msg 187 with --fp8-gemm-backend cutlass appeared to load successfully. By msg 194, it had passed warmup and was accepting requests. This was the most promising attempt yet. But by msg 196, it had crashed.

Assumptions Made

Several assumptions underpinned the approach taken in this message:

The server was still running. The assistant assumed that the server started in msg 187 might still be alive, despite the empty response in msg 195. The empty response could have been caused by a slow model, network latency, or a request timeout rather than a crash. The verbose curl test was designed to check this assumption.

The DeepGemm fix was the right approach. The assistant had invested significant effort in the hypothesis that forcing --fp8-gemm-backend cutlass would resolve the NaN issue. The server's apparent successful startup and warmup seemed to validate this hypothesis. Message 196 was the test that would confirm it—or, as it turned out, refute it.

The warmup phase was representative. The server had passed its prefill warmup (CUDA graph capture completed successfully across all 8 GPUs) and had even handled a prefill batch successfully. The assistant may have assumed that if warmup passed, the decode path would also work. This assumption proved incorrect—the crash occurred specifically during the decode phase when actual token generation began.

Input Knowledge Required

To fully understand this message, one needs knowledge of:

The sglang serving framework: How it launches models, handles warmup, and processes requests. The distinction between prefill (processing input tokens) and decode (generating output tokens) is critical—the crash was decode-specific.
CUDA kernel execution model: The "device-side assert" error indicates that a CUDA kernel detected an invalid condition (NaN/Inf values) during execution. The asynchronous nature of CUDA errors means the crash may appear at a different point than where the actual numerical issue originated.
Blackwell (SM120) architecture: The new GPU architecture introduces changes to shared memory, tensor cores, and instruction set that require updates to CUDA kernels. The sglang main branch was specifically needed for the SM120 shared memory fix (PR #14311).
FP4 quantization and DeepGemm: The model uses NVIDIA's modelopt FP4 quantization, which interacts with the GEMM (General Matrix Multiply) backend. DeepGemm is an optimized kernel library that auto-selects on Blackwell but may have compatibility issues with certain checkpoint formats.
DSA/NSA sparse attention: GLM-5 uses DeepSeek Sparse Attention, which introduces specialized attention backends (NSA) that handle the sparse attention pattern. These backends have their own CUDA kernels and compatibility constraints.

Output Knowledge Created

This message produced critical knowledge:

The server was crashing, not just returning empty responses. This ruled out a whole class of potential issues (request routing, tokenizer problems, timeout misconfiguration) and confirmed that the crash was real and reproducible.
The --fp8-gemm-backend cutlass fix was insufficient. Despite the promising startup, the server still crashed during decode. The DeepGemm scale format hypothesis was either wrong or only part of the problem.
The crash was deterministic and fast. The server crashed almost immediately upon receiving a request—the curl connection was refused, meaning the process had already exited by the time the test was run (just seconds after the previous test).
A new debugging direction was needed. The failure of the cutlass backend approach meant the assistant would need to look elsewhere—perhaps at the RoPE parameter incompatibility warning from Transformers 5.2.0, or at the interaction between NSA backends and FP4 quantization on SM120.

The Thinking Process Visible in Reasoning

The assistant's reasoning, visible across the conversation leading to this message, reveals a systematic debugging methodology:

Hypothesis generation and prioritization: The assistant identified the DeepGemm scale format warning as the most likely cause of NaN outputs, prioritizing it over other warnings (like the RoPE incompatibility). This prioritization was reasonable—the DeepGemm warning explicitly mentioned "accuracy degradation on Blackwell," which directly matched the symptom of NaN logits.

Iterative refinement of diagnostics: Each test was designed to answer a specific question. When curl -s returned empty (msg 195), the assistant didn't just retry—it upgraded to curl -v to get connection-level visibility. This shows a methodical approach to instrumentation.

Leveraging local knowledge: The assistant consulted FINDINGS.md (msg 193), which documented previous NVFP4 deployments on the same hardware. This is a hallmark of good debugging—using institutional knowledge to avoid repeating past mistakes. The findings noted that --disable-cuda-graph was used in successful deployments, but the assistant's current attempt (msg 187) did not include this flag.

Parallel exploration: While waiting for the server to load (which took several minutes due to the 83 safetensors shards), the assistant simultaneously read research files. This efficient use of waiting time shows awareness of the cost of sequential operations.

Pattern recognition: The assistant recognized that the crash pattern—successful load and warmup, then crash on first decode request—was identical across multiple configuration attempts. This consistency pointed to a fundamental incompatibility rather than a configuration tweak.

Mistakes and Incorrect Assumptions

Several aspects of the approach in this message reveal incorrect or incomplete assumptions:

Over-reliance on the DeepGemm hypothesis: While the DeepGemm scale format warning was suspicious, it was only one of two warnings that appeared during startup. The Transformers 5.2.0 RoPE parameter warning was equally prominent but received less attention. The assistant may have been biased toward the DeepGemm explanation because it was more specific ("accuracy degradation on Blackwell") and more actionable (there was a clear flag to change the GEMM backend).

Incomplete application of local knowledge: The FINDINGS.md documented that successful NVFP4 deployments used --disable-cuda-graph. The assistant noted this but did not include it in the current attempt (msg 187). If the CUDA graph capture was introducing numerical instability on SM120, this omission could explain the continued crashes.

Assuming warmup success implied decode success: The server's warmup phase only tests prefill (processing input tokens). The decode path (generating output tokens) involves different CUDA kernels—particularly the attention and sampling kernels. A crash that only manifests during decode suggests the issue is in the decode-specific code path, which warmup does not adequately test.

Conclusion

Message 196 is a moment of diagnostic clarity in a complex debugging session. The "Connection refused" response transformed an ambiguous empty response into definitive evidence of a server crash. It forced a reevaluation of the debugging strategy, demonstrating that the DeepGemm hypothesis—while promising—was not the complete answer. The message exemplifies the iterative nature of debugging cutting-edge ML deployments: each failed hypothesis narrows the search space, each diagnostic refinement reveals more information, and each crash brings the investigator closer to the root cause. In the context of deploying a quantized MoE model on new GPU architecture with a rapidly evolving serving framework, such moments of clear negative evidence are as valuable as positive results—they eliminate possibilities and sharpen the focus on what remains.