Skip to content

[Fix] [SM120] quantization: Requantize block-FP8 MoE weights to UE8M0 for DeepGEMM - #43556

Merged
Fridge003 merged 2 commits into
sgl-project:mainfrom
lucifer1004:fix/sm120-deepgemm-moe-ue8m0-requant
Oct 20, 2026
Merged

Fridge003 merged 2 commits into
sgl-project:mainfrom
lucifer1004:fix/sm120-deepgemm-moe-ue8m0-requant

Conversation

@lucifer1004

@lucifer1004 lucifer1004 commented Oct 10, 2026 •

Copy link
Copy Markdown
Contributor

Motivation

On SM120, should_deepgemm_weight_requant_ue8m0 returns False for every caller, so block-FP8 MoE experts served by the DeepGEMM runner keep their FP32 checkpoint scales. SM120's grouped GEMM converts FP32 scales to UE8M0 itself, and it faults (CUDA error 719) on scales that are not powers of two.

With nvidia/Qwen3.8-Flash-Next-NVFP4 and --speculative-moe-runner-backend deep_gemm, the block-FP8 MTP draft experts crash at the first prefill graph capture, at every token count. The same weights with power-of-two scales run.

#39065 (open, fixing #39063) makes the same guard change by inferring a grouped layer from weight.ndim == 3, without tests. This PR differs in two ways:

  • Fp8MoEMethod passes grouped_moe=True explicitly.
  • It adds a regression test.

Split out of #42566 at a maintainer's request. #42566 now carries only the TP block-scale refinement, which depends on this change for its DeepGEMM path on SM120.

Fixes #39063

Modifications

  • Keep the SM120 exemption for dense block-FP8 GEMMs, which run on CUTLASS or Triton with FP32 scales there.
  • Requantize grouped MoE weights to UE8M0 as on SM90 and SM100.
  • should_deepgemm_weight_requant_ue8m0 and requant_block_scale_ue8m0_for_deepgemm take a keyword-only grouped_moe flag, which Fp8MoEMethod sets for its expert weights.

Accuracy Tests

test/registered/unit/layers/quantization/test_deepgemm_ue8m0_requant.py adds a case for the SM120 grouped-MoE requant.

Two existing tests in that file fail on SM120 hosts both with and without this PR:

  • test_helper_requants_supported_deepgemm_bf16_once
  • test_compressed_tensors_block_processing_preserves_ue8m0_marker

They patch DeepGEMM's UE8M0 flags on but not the device, and SM120 deliberately skips the dense requant they exercise. The file passes on the CPU runner it is registered for.

End to end, together with the TP refinement in #42566:

  • nvidia/Qwen3.8-Flash-Next-NVFP4 at TP2 with its own MTP head (NEXTN 3/1/4, draft experts on DeepGEMM) scores 0.976 on GSM8K through the chat template (lm-eval gsm8k, 1,319 questions, flexible-extract) on 2x RTX PRO 6000.
  • Without this change, the same draft experts on DeepGEMM fault on SM120 at TP1 already.

Checklist

This PR was written with AI assistance (Claude); I reviewed every line.

🤖 Generated with Claude Code


CI States

Latest PR Test (Base): ❌ Run #39355945695
Latest PR Test (Extra): ❌ Run #39355945781
Latest PR Test (AMD ROCm 10): ❌ Run #39355945903

…MM grouped GEMM

On SM120, should_deepgemm_weight_requant_ue8m0 returned False for every
caller, so block-FP8 MoE experts served by the DeepGEMM runner kept their
checkpoint FP32 block scales. SM120's grouped GEMM converts FP32 scales to
UE8M0 itself, and on scales that are not powers of two the kernel faults
(CUDA error 719): Qwen3.8-Flash-Next's block-FP8 MTP experts with
--speculative-moe-runner-backend deep_gemm crashed at the first prefill
graph capture, at any token count; the same weights with power-of-two scales
run.

Keep the SM120 exemption for dense block-FP8 GEMMs, which run on CUTLASS or
Triton with FP32 scales there, and requant grouped MoE weights as on SM90 and
SM100.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Zihua Wu <13583761+lucifer1004@users.noreply.github.com>
@github-actions github-actions Bot added the quant LLM Quantization label Oct 10, 2026
lucifer1004 added a commit to lucifer1004/sglang that referenced this pull request Oct 13, 2026
lucifer1004 added a commit to lucifer1004/sglang that referenced this pull request Oct 13, 2026
…TP shards that split checkpoint blocks (upstream PR, on sgl-project#43556)
lucifer1004 added a commit to lucifer1004/sglang that referenced this pull request Oct 17, 2026
…UE8M0 for the SM120 DeepGEMM grouped GEMM

Signed-off-by: Zihua Wu <13583761+lucifer1004@users.noreply.github.com>
@github-actions

This comment has been minimized.

@Fridge003

Copy link
Copy Markdown
Collaborator

/rerun-test test/registered/unit/layers/quantization/test_deepgemm_ue8m0_requant.py

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Rebase Required Before Re-run

A major update has landed on main. Your PR is diverged relative to required base commit 6a39ddf1f2e0.

Re-run was not dispatched. What to do:

  • Rebase your branch onto the latest main and push again
  • Follow issue #21065 for context
  • CI-fix PRs may request the bypass-maintenance label to skip this check

@Fridge003

Copy link
Copy Markdown
Collaborator

/rerun-test test/registered/unit/layers/quantization/test_deepgemm_ue8m0_requant.py

@github-actions

github-actions Bot commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

🚀 ubuntu-latest (1 test): ✅ View workflow run

cd test/ && python3 registered/unit/layers/quantization/test_deepgemm_ue8m0_requant.py

@github-actions

This comment has been minimized.

@Fridge003 Fridge003 changed the title [Bugfix][SM120] Requant block-FP8 MoE weights to UE8M0 for the DeepGEMM grouped GEMM [Fix] [SM120] quantization: Requantize block-FP8 MoE weights to UE8M0 for DeepGEMM Oct 20, 2026
@Fridge003
Fridge003 merged commit 67d9ee1 into sgl-project:main Oct 20, 2026
106 of 123 checks passed
Rockdu added a commit to radixark/miles that referenced this pull request Oct 31, 2026
…rouped MoE

SGLang v0.5.23 (sgl-project/sglang#43556) added a grouped_moe flag to
should_deepgemm_weight_requant_ue8m0: on SM120 dense block-FP8 GEMMs keep
fp32 scales, but the grouped MoE GEMM runs on DeepGEMM and SGLang now
requantizes expert scales to UE8M0 when loading. miles asked without the
flag, so on SM120 it sent fp32 scales for expert weights that SGLang holds
in UE8M0, and a weight update would write them in the wrong format. Pass
grouped_moe for expert weights, as SGLang's own MoE call does. Other GPUs
are unaffected: there the flag does not change the answer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rockdu added a commit to radixark/miles that referenced this pull request Oct 31, 2026
The grouped_moe fix for SGLang v0.5.23 (sgl-project/sglang#43556) passes
`grouped_moe` to should_deepgemm_weight_requant_ue8m0 for every FP8 weight.
The ROCm image stays on sglang-miles-v0.5.22-final, whose function has no
such parameter, so after this bump merges every ROCm FP8 weight update
(e.g. tests/e2e/megatron/test_qwen3_30B_A3B/test_amd_moriep_fp8_bridge.py)
would raise TypeError. PR CI does not show it: with the ci-sglang-pr pin,
the ROCm job installs the v0.5.23 stack over its image.

The SGLang compat module now drops `grouped_moe` when the installed function
does not take it, which is exactly the call main makes today.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

quant LLM Quantization

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] SM120 grouped FP8 DeepGEMM weight preparation skips UE8M0 requantization

2 participants