Repository navigation
[Bugfix][MoE] Apply expert_map remapping for CUTLASS FP4 MOE expert parallel - #59042
robertgshaw2-redhat merged 7 commits into
Conversation
Signed-off-by: Markov Ilya <markovilya197@gmail.com>
Signed-off-by: Markov Ilya <markovilya197@gmail.com>
Signed-off-by: Markov Ilya <markovilya197@gmail.com>
Resolve test_cutlass_moe.py import conflict: keep remap_topk_to_local and kMxfp4Dynamic from main. Signed-off-by: Markov Ilya <markovilya197@gmail.com>
|
✅ @ilmarkov, CI is now available for this PR.
|
|
/ci run |
|
❌ This PR is 4 commits behind upstream |
|
/ci run |
|
❌ This PR is 2 commits behind upstream |
|
/ci run |
|
✅ Triggered Buildkite CI #94172 for commit |
CI selector (shadow): 34 test steps (74 jobs) instead of 70 (95 jobs)Shadow mode: this changes nothing about what CI runs. It shows what the evidence-based selector would pick for this PR, next to today's rules. How it works. Feedback welcome: reply here if it would skip a step this change needs, or runs something unrelated. Selector would run (34)
Would skip (today's rules run them) (49)
Would add (today's rules do not run them) (13)
AMD mirrors: would skip (64)
AMD mirrors: would add (7)
6 changed files · base |
…arallel (vllm-project#59042) Signed-off-by: Markov Ilya <markovilya197@gmail.com>
Kimi-K3 with --quantization-config '{"moe": {"weight": "int4_per_group_32"}}'
fails at startup on gfx942 since vllm-project#59042:
ValueError: AiterMxfp4Experts does not support this MoE deployment since
... quantization scheme ...
The gfx942 requant (vllm-project#51274) converts the MXFP4 experts to packed int4 at load
and builds the kernel with make_mxfp4_moe_kernel(experts_cls=AiterMxfp4Experts).
vllm-project#59042 added a fail-closed experts check to make_mxfp4_moe_kernel that only
tries MXFP4 quant keys, which AiterMxfp4Experts accepts on gfx950 only, so the
check rejects the int4 experts on gfx942. Stock decode is affected.
Accept (kInt4Static32, None) in AiterMxfp4Experts on gfx942 only, and try it
as the last MXFP4 scheme candidate so the check validates the int4 weights as
what they are. gfx950 is unchanged: its MXFP4 candidates still match first.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Xavier Aguilar <xavier.aguilarfruto@amd.com>
Kimi-K3 with --quantization-config '{"moe": {"weight": "int4_per_group_32"}}'
fails at startup on gfx942 since vllm-project#59042:
ValueError: AiterMxfp4Experts does not support this MoE deployment since
... quantization scheme ...
The gfx942 requant (vllm-project#51274) converts the MXFP4 experts to packed int4 at load
and builds the kernel with make_mxfp4_moe_kernel(experts_cls=AiterMxfp4Experts).
vllm-project#59042 added a fail-closed experts check to make_mxfp4_moe_kernel that only
tries MXFP4 quant keys, which AiterMxfp4Experts accepts on gfx950 only, so the
check rejects the int4 experts on gfx942. Stock decode is affected.
Accept (kInt4Static32, None) in AiterMxfp4Experts on gfx942 only, and try it
as the last MXFP4 scheme candidate so the check validates the int4 weights as
what they are. gfx950 is unchanged: its MXFP4 candidates still match first.
Tests pin AiterMxfp4Experts' quant schemes per arch and run the experts check
for every AITER MXFP4 backend on the archs it is deployed on, faking the arch
so any ROCm CI machine covers all of them. The gfx942 int4 cases fail on main.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Xavier Aguilar <xavier.aguilarfruto@amd.com>

Purpose
Fixes silent MoE corruption when running CUTLASS NVFP4 or MXFP4 MoE with expert parallelism.
CutlassExpertsFp4 and CutlassExpertsMxfp4 accepted expert_map in apply() but never used it. With EP enabled,
topk_idsstayed in global expert space while weights are local, so tokens were to the wrong experts.This showed up as degenerate outputs (e.g. ~0% GSM8K on RedHatAI/GLM-5.3-MXFP4 with DP=8 / EP=8 see issue #58729 ).
PR remaps global
topk_idslocal ids viaexpert_mapbefore CUTLASS FP4/MXFP4 grouped GEMM.Test Plan
gsm8k validation
server:
client:
result:
(Result before was 0% score)
pytests:
pytest tests/kernels/moe/test_cutlass_moe.py::test_remap_topk_ids_to_local -vpytest tests/kernels/moe/test_cutlass_moe.py::test_cutlass_fp4_moe_EP -vpytest tests/kernels/moe/test_ocp_mx_moe.py::test_make_mxfp4_moe_kernel_validates_cutlass_expert_parallel -vpytest tests/kernels/moe/test_ocp_mx_moe.py::test_make_mxfp4_moe_kernel_rejects_cutlass_unsupported_expert_parallel -vNew remapping kernel overhead is ~1.6 us, i.e. ~1% of Gemm kernel.
Changes:
remap_topk_to_localkernel fromgpt_oss_triton_kernels_moe.pyintofused_moe/utils.pyand reuse it from both GPT-OSS Triton and CUTLASS paths.out_dtypesupport (int32 for CUTLASS, int64 default for GPT-OSS) in theremap_topk_to_localkernel._supports_parallel_configforCutlassExpertsFp4/CutlassExpertsMxfp4: allow EP with allgather_reducescatter; still block FlashInfer NVLink / DeepEP HT backends (same as FP8).make_mxfp4_moe_kernelvalidation so compressed-tensors CUTLASS bypass fails fast on unsupported parallel configs (adapted from Add guard for Cutlass MXFP4xMXFP4 DP/EP kernel #59033 ).Fixes [Bug]: GLM MXFP4 returns 0 GSM8K on GB200 (DEP8+EP8, vLLM 0.30.0) #58729
Essential Elements of an Effective PR Description Checklist
supported_models.mdandexamplesfor a new model.