sm_120 (consumer/workstation Blackwell) FP8 status: NVIDIA's own kernels do not serve tensor/token-scaled FP8 GROUPED/MoE GEMM on SM_120 - a library-routing gap, not an absent FP8 path

CORRECTED 2026-10-04: THE HEADLINE CLAIM IN THIS RECORD'S NAME AND IN THE PARALLEL AGENT'S ORIGINAL WORDING WAS OVERSTATED, AND IS NOW REPLACED. What was originally asserted here was: 'RTX PRO 6000 (Blackwell workstation, sm_120) has NO FP8 path in the current generation, and NVIDIA's own CUTLASS is unvalidated on it, requiring 12 upstream patches.' BOTH HALVES OF THAT ARE TOO STRONG, for reasons the evidence below establishes. THE DEFENSIBLE CLAIM, which is what this record now asserts: on sm_120, TENSOR/TOKEN-SCALED FP8 GROUPED (MoE) GEMM falls back to Triton because NVIDIA's own kernels do not serve it; NVFP4 is the well-supported path on these cards. Equivalently, and without overstating: the FP8 GROUPED/MoE-GEMM path is unpopulated upstream and cuBLAS's fp8 grouped path returns CUBLAS_STATUS_NOT_SUPPORTED on sm_120 - a LIBRARY-ROUTING gap, NOT absent silicon capability. WHY 'NO FP8 PATH' OVERSTATES IT: the evidence establishes that the FP8 GROUPED/MoE-GEMM path specifically is unpopulated upstream, and that cuBLAS's fp8 grouped path does not support sm_120. It does NOT establish that sm_120 silicon cannot execute FP8 MMA. The SAME CUTLASS release demonstrably runs Blockwise-FP8 and MXFP8 on SM_120, and torch._scaled_mm FP8 works on these cards - it is the documented fallback in EVIDENCE 2. Reading a gap in one library's MoE path as an absence of silicon capability inverts the inference. THE '12 UPSTREAM PATCHES' NUMBER IS NOT CONFIRMED AND IS NOT RECORDED HERE AS FACT. No source found states a count of 12 required patches to run CUTLASS on the RTX PRO 6000. Do not repeat that figure anywhere in this repo. WHY THIS RECORD IS A SOURCE AND NOT A NUMBER SOURCE: it records evidence about library coverage only. It is not a vendor spec sheet and carries no FLOPS numbers, so it must not be used to justify a throughput figure for any sm_120 part. EVIDENCE 1 - vLLM issue 43507 (tgmerritt, NVIDIA, opened 2026-05-23, verified on real GB10/SM_121 hardware, still open): 'CUTLASS 4.5 does not ship a CollectiveBuilder specialization for tensor/token-scaled FP8 grouped GEMM on SM_120/SM_121.' CUTLASS 4.5 DOES ship SM_120 grouped GEMM for NVFP4, Blockwise-FP8 (per-block scales in the mainloop, example 87c) and MXFP8 blockscaled. What is missing is specifically the TENSOR/TOKEN-scaled FP8 (per-tensor dynamic scaling) specialization. The SM_120 dispatch policies exist in include/cutlass/gemm/dispatch_policy.hpp but are instantiated nowhere in CUTLASS - 'they appear to be placeholders for future work'. CUTLASS PR 3280 ('Add ptr-array TMA collective for tensor/token-scaled FP8 grouped GEMM', tgmerritt) was merged 2026-06-13, which post-dates this issue, so this gap was open as of the issue but the underlying collective work has since landed. EVIDENCE 2 - FlashInfer issue 3255 (opened 2026-05-07, RTX 5090 = sm_120, CUDA 13.0): fp8 GEMM routed to cuBLASLt fails on sm_120 with CUBLAS_STATUS_NOT_SUPPORTED on real model tensor shapes. Diagnosis: 'cutlass_sm12x is the correct and sufficient backend for sm_120 - it handles all K values via padding.' i.e. the FP8 failure on sm_120 is a LIBRARY-ROUTING gap, not proof that the silicon lacks an FP8 tensor path. WHAT IS SPECIFIC TO EACH CARD, versus what is family-wide: all RTX PRO Blackwell workstation parts and all GeForce RTX 50 parts are the same sm_120/sm_121 family, so the library gap applies identically to both. What is card-specific is only the marketing FP4 number: 4,000 AI TOPS sparse for the RTX PRO 6000 versus 1,617 AI TOPS sparse for the RTX PRO 4500. Do not read the family-wide gap as a card-specific capability difference. NOT separately verified for the RTX PRO 4500, and it does not need to be. NOT TO BE CONFUSED WITH A DIFFERENT, CORRECT 'NO FP8 PATH' CLAIM IN THIS REPO: data/accelerators/amd-radeon-rx-7900-xtx says the RDNA 3 RX 7900 XTX has no FP8 path. That is a DIFFERENT ARCHITECTURE (AMD RDNA 3) and that claim is correct as stated. The two claims are not in tension and neither was edited as a result of this correction.