Repository navigation
perf(moe_ep): add folded K128/N64 tuning candidate for Hopper MXFP4 x FP8 MegaMoE - #6465
Conversation
Add the H100/H200-validated folded producer configuration to the bounded Hopper MXFP4 candidate pool. Keep heuristic defaults and existing candidates in order, and let the runtime candidate hash invalidate stale tuning caches. Cover candidate discovery, fallback behavior and cache provenance with host tests.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
Add the measured K128 N16 configuration and folded N64 group-264, group-132, and tail-pair configurations from the H200 EP2 token sweep. Preserve existing tactic order and heuristic defaults, and update the documented candidate counts. Validation: 23 existing host tests; changed-file pre-commit checks; exact normalized tactic parity with the GPU-validated eight-point sweep. AI-assisted.
Exercise the folded C111/group-330 and C121/group-132 tail-pair tactics against the independent raw-weight oracle. Use H2560/I640 and 129 tokens per rank to cover full and partial N64 tiles, along with repeated forwards on the same workspace. Validation: both cases passed on 2x H200 with two pytest passes per rank and no skips; Slurm job 5143668. Changed-file pre-commit checks passed. AI-assisted.
|
/bot run tests/moe_ep/test_moe_ep_sm90_pull_mxfp4_mega_multirank.py |
|
@flashinfer-bot run tests/moe_ep/test_moe_ep_sm90_pull_mxfp4_mega_multirank.py |
|
[FAILED] Pipeline #75210503 — 23/31 executed test jobs passed Compared with nightly #74968837. Unit Tests
✅ Pass · 🟡 Old failure · ❌ New failure · ⏱ Test timeout · Failure detailsTimeouts, infrastructure, or incomplete jobs
|
📌 Description
Expand the bounded tuning candidates for Hopper MXFP4 × FP8 MegaMoE, motivated by the latency observed on a Qwen3.8-Flash-Next-style routed MoE workload.
For an intermediate size of 640, K256 configurations are filtered out by alignment requirements, leaving three eligible configurations in the existing candidate pool. The pool misses useful K128 configurations across different token counts.
Changes
Add five measured M256/K128 configurations:
(1,1,1), group-330 configuration with two dispatch warps and FC1 store offload.(1,1,1)configurations with group hints 132, 264, and 330.(1,2,1), group-132 configuration with tail-pair scheduling.All five use one scheduler stage. The folded configurations use one dispatch warp, early FC1 publication, and direct FC1 stores.
For the target shape, the eligible candidate pool grows from 3 to 8 configurations. Existing heuristic defaults are preserved; autotuning selects among the expanded candidates.
Benchmark configuration
[tokens_per_rank, 2560]per rank; EP=2.Performance
Both columns report tuned performance: the best of the original 3 candidates versus the best of the 8 candidates available with this PR.
Selection minimizes Compute latency; operator E2E is reported from the same selected configuration. Each configuration uses 10 warmups and 50 CUDA-event samples. The reported latency is the maximum of the two ranks’ median latencies. Before/after comparisons use measurements from the same tuning process at each token count.
All latencies are in µs. Latency reduction is calculated as
(original − PR) / original × 100%.Compute includes prestaged MegaMoE execution, EP communication, and final top-k reduction. Operator E2E additionally includes input quantization/staging and output copy; weight preparation and JIT compilation are excluded. These are operator measurements, not model TTFT.
At 256 tokens/rank, the configuration selected by Compute is 2.688 µs slower in operator E2E. At 512 tokens/rank, the original configuration remains selected.
Validation
Measurements were collected with the exact registered configurations using
repro_driver.pyon pinned source2394fa705; the final branch was not separately timed. The workload uses synthetic weights and balanced routing rather than a full model execution.Summary by CodeRabbit
Performance
Bug Fixes
Tests