Probing the FP4 GEMM Backend: A Targeted Source Code Inspection in SGLang's Server Args

Introduction

In the middle of deploying the massive Qwen3.5-397B-A17B-NVFP4 model across eight Blackwell GPUs, the assistant encountered a critical failure: the model was producing garbage output followed by a "NaN happened" finish reason. This article examines a single, seemingly modest message — a sed command executed over SSH — that represents a pivotal diagnostic step in resolving this numerical instability. The message, message index 5845 in the conversation, is a bash command that reads a specific section of SGLang's server_args.py file to understand the available FP4 GEMM runner backends. While the command itself is simple, its placement in the debugging narrative reveals the assistant's systematic reasoning, its assumptions about code structure, and the challenges of deploying novel quantization formats on cutting-edge GPU hardware.

The Problem: NaN Outputs on Blackwell

The context leading up to this message is essential. The assistant had just completed building the latest SGLang main branch from source and had successfully launched the Qwen3.5-397B-A17B-NVFP4 model — a 397-billion-parameter MoE model with 512 experts and NVFP4 quantization — across eight RTX PRO 6000 Blackwell GPUs. The initial launch failed with an assertion error about hybrid GDN models requiring the triton attention backend on Blackwell, which was quickly corrected. After restarting with --attention-backend triton, the model loaded in about two minutes and appeared healthy.

However, the first inference test revealed a catastrophic problem. When prompted to write a Python function for prime number checking, the model responded with nothing but repeated exclamation marks — "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!" — captured as reasoning_content. A second test with a simple greeting produced an even more alarming result: the response content was null, and the finish_reason was "NaN happened". This is a definitive signal that floating-point computations inside the model's inference path have produced Not-a-Number values, typically indicating numerical instability in the quantization kernels or matrix multiplication backends.

The assistant immediately identified the likely culprit: the FP4 GEMM runner backend. The model uses NVFP4 quantization (4-bit floating point), which requires specialized GPU kernels for matrix multiplication. On Blackwell GPUs (compute capability SM120), these kernels must be explicitly compatible with the new architecture. The default backend, flashinfer_cutlass, was suspected to be incompatible with SM120, causing the numerical blowup.

The Investigation: Probing Server Args

Message 5845 represents the assistant's first concrete step in diagnosing this backend incompatibility. The command is:

ssh root@10.1.230.174 'sed -n "252,270p" /root/sglang-main/python/sglang/srt/server_args.py'

This is a targeted probe: the assistant wants to read lines 252 through 270 of the server_args.py file, which is the central configuration file for SGLang server arguments. The choice of line range is not arbitrary — in the preceding message (msg 5844), the assistant had already searched for fp4_gemm_runner_backend and related terms in this file, finding a reference at line 469 (fp4_gemm_runner_backend: str = "flashinfer_cutlass") and a function at line 252 (def add_fp4_gemm_runner_backend_choices(choices)). By reading lines 252-270, the assistant hopes to see the full definition of this function and, crucially, the list of available FP4 GEMM runner backends that can be selected.

The output reveals several function definitions:

def add_fp4_gemm_runner_backend_choices(choices):
    FP4_GEMM_RUNNER_BACKEND_CHOICES.extend(choices)


def add_deterministic_attention_backend_choices(choices):
    DETERMINISTIC_ATTENTION_BACKEND_CHOICES.extend(choices)


def add_radix_supported_deterministic_attention_backend_choices(choices):
    RADIX_SUPPORTED_DETERMINISTIC_ATTENTION_BACKEND.extend(choices)


def add_radix_eviction_policy_choices(choices):
    RADIX_EVICTION_POLICY_CHOICES.extend(choices)


def add_rl_on_policy_target_choi...

What the Command Revealed — And What It Didn't

The output is revealing in an unexpected way. The add_fp4_gemm_runner_backend_choices function is present, but it merely extends a pre-existing list called FP4_GEMM_RUNNER_BACKEND_CHOICES with additional choices passed as a parameter. The actual list of available backends — the initial values of FP4_GEMM_RUNNER_BACKEND_CHOICES — is not defined in this line range. It must be defined earlier in the file (or imported from another module). The function shown is a registration mechanism that allows plugins or extensions to add new backends to the existing list, not the definition of the list itself.

This is a subtle but important distinction. The assistant's assumption that lines 252-270 would contain the backend choices list proved incorrect. The actual list of available FP4 GEMM runner backends — which likely includes values like "flashinfer_cutlass", "sgl-kernel", "petit_nvfp4", and potentially others — is defined elsewhere, probably at the top of the file or in a constants module. The sed command captured the extension mechanism but not the core data.

However, the output is not useless. It confirms the architecture of the backend selection system: SGLang uses a modular design where a base list of backends can be extended by calling add_fp4_gemm_runner_backend_choices(choices). This tells the assistant that the backend choices are extensible, and that the initial list must be found by searching earlier in the file or by examining the FP4_GEMM_RUNNER_BACKEND_CHOICES variable directly.

Analysis of the Approach

The assistant's debugging methodology here is noteworthy. Rather than consulting documentation, running Python introspection, or searching the web for known SM120 FP4 compatibility issues, the assistant goes directly to the source code with a precise sed command. This reflects several assumptions:

  1. The codebase is the authoritative source of truth. The assistant trusts that the available backends are defined in server_args.py and that reading the relevant section will reveal them.
  2. Line numbers from the previous grep are reliable. The assistant found add_fp4_gemm_runner_backend_choices at line 252 and assumes that reading a block starting there will capture the relevant context. This is a reasonable heuristic but, as we've seen, it missed the actual data.
  3. The backend list is static and defined at module level. The assistant expects to find a literal list or tuple of backend names, not a dynamic extension mechanism.
  4. The fix is a configuration change, not a code patch. By looking for alternative backends, the assistant assumes that one of the existing backends will work on SM120 and that simply changing the --fp4-gemm-runner-backend flag will resolve the NaN issue. These assumptions are all reasonable given the context. The assistant has already successfully deployed the Kimi-K2.5 INT4 model with a different backend configuration, and it knows that the Blackwell GPUs require specific kernel support. The NaN outputs strongly suggest a kernel incompatibility, and the most likely fix is to switch to a backend that explicitly supports SM120.

Broader Context and Significance

This message sits at a critical juncture in the deployment workflow. The assistant has successfully:

  1. Built the latest SGLang main branch from source
  2. Applied SM120 patches for FlashInfer allreduce fusion and Torch symmetric memory
  3. Corrected the attention backend from flashinfer to triton for hybrid GDN models
  4. Launched the server and verified it loads correctly But the model produces garbage. The FP4 quantization path is the most likely source of the numerical instability, and understanding the available backends is the first step toward fixing it. The assistant's next steps would logically be: - Search for where FP4_GEMM_RUNNER_BACKEND_CHOICES is initially defined - Check if "sgl-kernel" or "petit_nvfp4" are available alternatives - Test each alternative backend to find one that works on SM120 The message also illustrates a broader theme in the conversation: the challenges of deploying cutting-edge AI models on new GPU architectures. Blackwell (SM120) is a recent architecture, and many software components — from CUDA toolkits to inference engines to quantization kernels — require explicit support. The assistant has already navigated multiple such compatibility issues in this session, including patching SGLang for SM120 support in allreduce and symmetric memory, installing the open NVIDIA kernel module for VM passthrough, and selecting the correct attention backend for hybrid models. The FP4 GEMM backend is the latest in this series of Blackwell-specific configuration challenges.

Conclusion

Message 5845 is a small but revealing moment in a complex debugging session. A simple sed command, executed with a specific hypothesis about the cause of NaN outputs, probes the structure of SGLang's FP4 GEMM backend selection system. While the command doesn't immediately reveal the available backends — capturing only the extension mechanism rather than the base list — it confirms the modular architecture of the backend system and points the way toward further investigation. The message exemplifies the assistant's systematic, code-driven debugging approach and highlights the intricate compatibility challenges that arise when deploying state-of-the-art quantized models on next-generation GPU hardware. The NaN outputs would eventually be resolved by explicitly configuring the FP4 GEMM and MoE runner backends, but this source code inspection was an essential step in that diagnostic journey.