fix(moe): Avoid hang in TEGroupedMLP when a rank has zero local tokens#4851
Closed
jubick1337 wants to merge 8 commits into
Closed
fix(moe): Avoid hang in TEGroupedMLP when a rank has zero local tokens#4851jubick1337 wants to merge 8 commits into
jubick1337 wants to merge 8 commits into
Conversation
When a rank receives zero locally-routed tokens (a common edge case under heavy EP imbalance or small global batches), TEGroupedMLP.forward used to skip linear_fc1 / linear_fc2 entirely while peer ranks still executed them. The resulting autograd graphs diverged across ranks, causing the next DDP / EP collective to hang. Some GroupedGEMM backends also fail outright on empty input. Detect the zero-local-tokens condition right after tokens_per_expert is materialized as a Python list. Synthesize one zero-vector token per local expert with a zero routing probability, run the regular forward path, and then slice the synthetic rows back off before returning so the caller's empty-output contract is preserved. Slicing keeps the autograd hooks on the linear modules attached so backward fires on this rank just like on peers, which is what re-aligns the cross-rank graphs. The fused-impl early return path is left untouched.
Contributor
|
This PR has been automatically converted to draft because all PRs must start as drafts. When you are ready for review, click Ready for Review to begin the review process. This will:
See the contribution guide for more details. |
Victarry
reviewed
May 21, 2026
Comment on lines
+562
to
+580
| # When this rank has no locally-routed tokens, append one synthetic | ||
| # zero-vector token per local expert with zero routing probability. | ||
| # This keeps linear_fc1 / linear_fc2 active in both forward and | ||
| # backward so that DDP / EP collectives see a consistent autograd | ||
| # graph across ranks; otherwise a rank with zero local tokens diverges | ||
| # from its peers and the collective hangs (and some GroupedGEMM | ||
| # backends fail outright on empty input). The synthetic rows are | ||
| # sliced back off before this function returns. | ||
| is_dummy_forward = sum(tokens_per_expert) == 0 | ||
| if is_dummy_forward: | ||
| dummy_hidden = permuted_local_hidden_states.new_zeros( | ||
| (self.num_local_experts, permuted_local_hidden_states.shape[1]) | ||
| ) | ||
| dummy_probs = permuted_probs.new_zeros((self.num_local_experts,)) | ||
| permuted_local_hidden_states = torch.cat( | ||
| [permuted_local_hidden_states, dummy_hidden], dim=0 | ||
| ) | ||
| permuted_probs = torch.cat([permuted_probs, dummy_probs], dim=0) | ||
| tokens_per_expert = [1] * self.num_local_experts |
Contributor
There was a problem hiding this comment.
Hi, @jubick1337, thanks for the PR!
But this fix is kind of hack, actually it's better to put the fix in TE to make sure every operation will work and have backward gradient even the number of tokens is zero. We fixed similar issues in this way before as in NVIDIA/TransformerEngine#648
Author
13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a rank receives zero locally-routed tokens (a common edge case under heavy EP imbalance or small global batches), TEGroupedMLP.forward used to skip linear_fc1 / linear_fc2 entirely while peer ranks still executed them. The resulting autograd graphs diverged across ranks, causing the next DDP / EP collective to hang. Some GroupedGEMM backends also fail outright on empty input.
Detect the zero-local-tokens condition right after tokens_per_expert is materialized as a Python list. Synthesize one zero-vector token per local expert with a zero routing probability, run the regular forward path, and then slice the synthetic rows back off before returning so the caller's empty-output contract is preserved. Slicing keeps the autograd hooks on the linear modules attached so backward fires on this rank just like on peers, which is what re-aligns the cross-rank graphs.
The fused-impl early return path is left untouched.
What does this PR do ?
Issue tracking
For PRs from open-source community contributors:
Linked issue:
Contribution process
Pre-checks
Code review
Feel free to message or comment the @mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!
All PRs start as draft. If you open a non-draft PR, it will be automatically converted to draft.
Step 1: Mark PR as "Ready for Review"
.github/CODEOWNERS.Final Review might get declined if these requirements are not fulfilled.
Step 2: Final Review
For PRs that change
megatron/core, once all expert reviewers have approved, theFinal Reviewlabel is applied automatically and final reviewers are assigned.For PRs outside
megatron/core, this step is skipped.Step 3: Approved
Once all required reviewers have approved, the
Approvedlabel is applied automatically.Merge
Any member of mcore-engineers will be able to merge your PR.
For MRs into `dev` branch
The proposed review process for `dev` branch is under active discussion.MRs are mergable after one approval by either
eharper@nvidia.comorzijiey@nvidia.com.