Repository navigation
Mario/overlap moe kernel integration - #3651
Conversation
Add a mega_moe MoE dispatch config and MegaMoeTokenDispatcher that runs DeepGEMM's fused dispatch + SwiGLU expert compute + combine kernels (forward and backward) over the expert-parallel group. Includes a benchmark against the bf16 TorchTokenDispatcher path.
|
nice, benchmark numbers? |
mega-moe is 1.55× faster (35.4% lower fwd+bwd time), while using slightly less peak memory. Note: we are currently investgating an MFU issue unrelated to this kernels so the speedup might change. |
…o/overlap-moe-kernel-integration Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Mega MoE is now a `MegaMoEExpertCompute` installed on `GroupedExperts.compute` by `configure_moe_runtime`, like the other expert compute backends, instead of a token dispatcher that injected a `fused` callback into `GroupedExperts.forward`. Because the kernel fuses dispatch and combine, it consumes undispatched tokens and their routing: `FusedDispatchExpertCompute` describes such a compute, and `FusedTokenDispatcher` hands the tokens to it without communicating. `GroupedExperts.forward(x, *routing)` forwards either `num_tokens_per_expert` or `top_scores, selected_experts_indices` to its compute. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
1f1ff90 to
0609006
Compare
…e extra Mega MoE kernels come from prime-mega-moe, a closed-source DeepGEMM fork. Its wheel is built by hand and attached to the prime-kernels release; prime-rl pins the URL and never builds it from source. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
SonicMoE landed on main squashed (#3535) with an ExpertCompute.validate hook and GroupedExperts.set_compute. Mega MoE adopts both: MegaMoEExpertCompute.validate carries the expert-structure checks and configure_moe_runtime installs it through set_compute. uv.lock was regenerated with the previous deep_gemm wheel URL because the prime-mega-moe wheel is not uploaded yet; re-run uv lock once it is. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ck compiles with fullgraph The fused forward was a custom op wrapped in a Python autograd.Function that saved x.to(bfloat16).contiguous() for backward. When the block compiles with fullgraph under activation checkpointing, dynamo rejects that saved tensor because it aliases the autograd.Function's input inside the checkpoint subgraph. Make the backward a custom op too and register autograd on prime_rl::mega_moe_forward, saving the op's own inputs. Both ops take the caller's dtypes, run the kernels in bf16, and return gradients in the inputs' dtypes, so the expert dW dtype is unchanged.
Main moved the DeepSeek V4 clamped SwiGLU to `activations.ClampedSilu`; the helper still imported a `ClampedSwiglu` from `deepseek_v4.moe` that no longer exists, so constructing `MegaMoEExpertCompute` failed for every model. `ClampedSwiglu` in `activations.py` is a different function (sigmoid * 1.702, `up + 1`) that the kernel does not compute, so it stays rejected.
garrett361
left a comment
There was a problem hiding this comment.
Looks really good, just had organization comments and questions, mainly.
…nel-integration # Conflicts: # packages/prime-rl-configs/src/prime_rl/configs/trainer.py
| ) | ||
| self.validate(experts) | ||
| hidden = experts.down_proj.shape[1] | ||
| reserve_sms_for_comm(num_reserved_sms) |
garrett361
left a comment
There was a problem hiding this comment.
Looks good, thanks for all the iteration on this! I'd still like to clean up some of the internals of mega_moe.py and the kernel names at some point (still requires a number of fairly technical and non-obvious mappings to follow), but let's get this in and clean up later.
LMK what you would cleanup / refractor I can finish it today and we can merge tomorrow then. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit fecda7f. Configure here.
a5c0048 to
af43116
Compare

Integration of our closed mega-moe based on Sonic Moe's abstractions
Note
High Risk
Introduces a new distributed training path with persistent cross-rank kernels, strict NCCL/SM and buffer sizing constraints, and a proprietary deep_gemm dependency; misconfiguration can deadlock or fail at runtime.
Overview
Adds Mega MoE as a new expert-parallel MoE dispatch path (
model.moe.dispatch.type = "mega_moe") that fuses token dispatch, SwiGLU expert GEMMs, and combine into prime-mega-moedeep_gemmkernels, overlapping EP communication with compute. Config coversprecision(bf16 / mxfp8 / fp8 / fp8_bwd),max_tokens_per_rank(auto-derived from the micro batch in RL/SFT), andnum_reserved_smswith a startup check thatNCCL_MAX_CTAS≤ reserved SMs to avoid deadlocks with FSDP NCCL.Trainer wiring uses
FusedTokenDispatcherplusMegaMoEExpertCompute(custom autograd ops, symmetric buffers, optional MXFP8 casting);model.moe.computeis ignored when Mega MoE is selected.GroupedExpertsnow accepts fused compute that takes routing tensors directly. Docs, a multi-GPU benchmark vs the bf16 Torch dispatcher path, activation-checkpointing registration, SFT timing sync, and a unit test that Mega MoE requiresep > 1are included.Reviewed by Cursor Bugbot for commit e433a59. Bugbot is set up for automated code reviews on this repo. Configure here.