The SM100-Only Trap: Diagnosing MoE Backend Failures on Consumer Blackwell GPUs

In the high-stakes world of deploying large language models across multi-GPU clusters, few moments are as instructive as a clean failure. Message 281 of this opencode session captures exactly such a moment — a brief but pivotal exchange where the assistant, having just watched a server crash with a cryptic traceback, correctly diagnoses the root cause, acknowledges a mistaken assumption, and pivots to a more promising strategy. The message is deceptively short — just two sentences and a bash command — but it encapsulates the kind of rapid diagnostic reasoning that separates effective ML engineering from aimless trial-and-error.

The Context: Chasing MoE Backend Performance

To understand this message, we must first understand what led to it. The assistant had been working for hours to deploy the GLM-5-NVFP4 model — a massive Mixture-of-Experts (MoE) architecture with 256 experts — across 8 NVIDIA RTX PRO 6000 Blackwell GPUs. After overcoming a critical NaN crash during decode by selecting working NSA attention backends (trtllm), the assistant established baseline throughput of approximately 225 output tokens per second and began exploring ways to improve performance.

The key insight from profiling was that all 8 GPUs were running at 100% utilization but only drawing 55% of their power budget (approximately 330W out of 600W TDP). This suggested the tensor cores weren't being saturated — the MoE kernels were likely inefficient for the small matrix dimensions typical of single-token decode. The natural next step was to experiment with different MoE runner backends, each implementing the expert computation through different kernel libraries.

In message 276, the assistant had investigated the available FP4 MoE code paths and identified five backends: flashinfer_cutlass (the current default), flashinfer_trtllm, flashinfer_cutedsl, triton, and sgl_kernel_cutlass. The flashinfer_trtllm backend seemed particularly promising — it used TRT-LLM-style FP4 kernels that might be better optimized for the Blackwell architecture. The assistant killed the running server in message 277 and relaunched it in message 278 with --moe-runner-backend flashinfer_trtllm.

The Failure: A Traceback Tells the Story

Message 279 revealed the result: a Python traceback crashing through fused_moe_triton/layer.py into flashinfer/fused_moe/core. The flashinfer_trtllm backend had failed at runtime. The error was not a configuration typo or a missing dependency — it was a fundamental compatibility issue.

This is where message 281 begins. The assistant writes:

Right — flashinfer_trtllm MoE is SM100-only (datacenter Blackwell). Won't work on SM120. Let me try cutlass (sgl_kernel) and flashinfer_cutedsl instead, and also look into tuning the flashinfer_cutlass kernels since these are new GPUs with no pre-tuned configs.

The first sentence is a masterclass in concise diagnosis. The assistant immediately recognizes the failure mode: flashinfer_trtllm is implemented only for SM100 — NVIDIA's datacenter Blackwell architecture (the B200 and B100 GPUs) — and does not support SM120, which is the consumer/workstation variant used in the RTX PRO 6000 cards. This distinction matters because, while both are "Blackwell" in marketing terms, the actual GPU microarchitectures differ in ways that affect kernel compatibility. The TRT-LLM-style FP4 kernels in flashinfer were presumably developed and tested only on datacenter hardware, leaving consumer Blackwell users with fewer options.

The Diagnostic Reasoning

What makes this message interesting is what it reveals about the assistant's thinking process. The assistant had assumed — reasonably — that a backend labeled as supporting "FP4" would work across all Blackwell variants. The traceback from message 279 disproved this assumption. Rather than chasing the error deeper into the flashinfer source code or attempting workarounds, the assistant applied domain knowledge about NVIDIA's GPU architecture segmentation to immediately identify the root cause.

This is a pattern we see repeatedly in expert ML engineering: the ability to map a runtime error to architectural constraints without needing to read every line of the failing code. The assistant knew that SM100 and SM120 are distinct compute architectures within the Blackwell family, and that kernel implementations are often written and tested for only one variant. The flashinfer_trtllm backend, which wraps TRT-LLM's FP4 kernels, had simply never been ported to SM120.

The Pivot: Two Paths Forward

Having identified the dead end, the assistant charts two concrete next steps. The first is to try alternative backends: cutlass (which refers to the sgl_kernel CUTLASS-based implementation) and flashinfer_cutedsl (which uses NVIDIA's CuteDSL library for grouped GEMM operations). These represent different kernel implementations that might work on SM120 and potentially offer better performance than the current flashinfer_cutlass default.

The second path is more strategic: tuning the flashinfer_cutlass kernels. The assistant notes that "these are new GPUs with no pre-tuned configs." This is a crucial observation. The RTX PRO 6000 Blackwell is a recent release, and kernel libraries like flashinfer ship with tuning configurations optimized for common GPU architectures (like the H100 or A100). For a brand-new architecture, the default configurations may be far from optimal — using wrong block sizes, tile dimensions, or scheduling parameters that leave the tensor cores underutilized. The user reinforces this direction in message 280 with "Also probaby tune the kernels, this is really new gpu," confirming that kernel tuning is the expected next step.

The Broader Significance

This message, for all its brevity, illuminates several important themes in modern ML infrastructure work. First, it demonstrates the practical consequences of NVIDIA's GPU architecture fragmentation. The distinction between SM100 and SM120 is not merely academic — it directly determines which kernel implementations are available, and engineers deploying on consumer Blackwell hardware must navigate a narrower ecosystem of compatible software.

Second, it highlights the iterative nature of performance optimization. The assistant didn't stop at "it crashed" — it immediately understood why it crashed and formulated a new plan. The kill command at the end (pkill -9 -f sglang) is a routine cleanup operation, but it signals readiness to move to the next experiment without dwelling on the failure.

Finally, the message underscores the importance of kernel tuning as a performance lever. When GPUs are running at 100% utilization but only 55% power, the bottleneck is not raw compute capacity but kernel efficiency. Tuning — finding the optimal block sizes, tile configurations, and scheduling parameters for a specific GPU-model combination — can dramatically improve throughput without changing any model weights. For a deployment on brand-new hardware like the RTX PRO 6000 Blackwell, this tuning step is not optional; it is the primary path to unlocking the hardware's full potential.

Conclusion

Message 281 is a small but revealing snapshot of ML engineering in practice. In two sentences, the assistant diagnoses a failed experiment, identifies an architectural incompatibility, and pivots to a more promising strategy. The message shows that effective debugging is not about reading every line of a traceback but about mapping errors to known constraints — in this case, the SM100 vs. SM120 divide in NVIDIA's Blackwell family. It also shows that performance optimization is a process of elimination: try the promising backend, learn from its failure, and redirect effort toward approaches that match the actual hardware. The kernel tuning path that emerges from this message would go on to shape the remainder of the deployment effort, as the assistant worked to create custom MoE configurations for the RTX PRO 6000 Blackwell GPUs.