docs(glm52): MegaMoE (DeepGEMM PR #323) evaluated — measured out at decode payloads

[xiaguan]

Records the EP-communication follow-up after #567: a fresh post-#567 profile and a measured evaluation of DeepGEMM MegaMoE (the fused dispatch→GEMM→SwiGLU→GEMM→combine mega-kernel) as a candidate for the GLM5.2 EP8 MoE decode chain.

What was measured (jz-38 8×H200)

• Post-perf(glm52): DeepGEMM masked grouped expert GEMM — c64 1113 → 1475 tok/s, solo step 21.6 → 19.6 ms #567 re-profile (19.6 ms/step baseline): dispatch+combine kernels now cost 4.75 ms/step median×instances, 7.73 ms/step wait-inclusive — the MoE block (~103 µs/layer kernel-resident, ~145 µs wait-inclusive) is the largest bucket left in the step.
• MegaMoE SM90 FP8×FP8 (deepseek-ai/DeepGEMM#323, tip includes a "Tune SM90 MegaMoE decode heuristics for GLM5.2" commit) at GLM5.2 shapes (hidden 6144, intermediate 2048, 256 experts, top-k 8, EP8): accuracy suite 28/28 PASS (diff ~6e-4), but the fused kernel has a ~200 µs/call structural floor at decode payloads — ~2× slower than our unfused graph-replayed chain (201.7 µs at 1 token/rank vs ~103 µs/layer). swapAB kill-switch and symm-buffer size probes ruled out as causes.

Verdict

Not usable for decode on H200. The community's "2.7× at bs=1" is measured against a Python-orchestrated per-kernel DeepEP v2 baseline — the launch/orchestration overhead MegaMoE fuses away is already gone in our whole-step CUDA graph. The remaining EP-comm lever is #542's wait-structure half (rank-arrival stagger: the 4.75 → 7.73 ms/step gap).

Docs-only change; repro commands in the doc were run on jz-38 (checkout preserved at ~/develop/xingming/megamoe-deepgemm).

🤖 Generated with Claude Code