Repository navigation
[None][fix] MegaMoE CuteDSL: fence the router's SMEM size row before … - #22241
Draft
nv-guomingz wants to merge 1 commit into
Draft
nv-guomingz wants to merge 1 commit into
nv-guomingz wants to merge 1 commit into
Conversation
…the async-proxy broadcast The NVLink token-comm router builds each rank's per-expert histogram with generic-proxy SMEM atomics and then broadcasts it to every peer with cp.async.bulk (the sizes_by_rank row) and cp.reduce.async.bulk (the totals). Those bulk copies read SMEM through the async proxy, and a CTA barrier only orders the generic proxy, so without fence.proxy.async.shared::cta the copy can read counts whose atomics are not yet visible to it. A peer then receives a partial row, builds push tables that disagree with the destination's pool layout, and the source's routes land in the wrong pool rows: their FC2 rows never reach the source's combine plane and its tokens come back wrong. Seen with Nemotron-3 Ultra BF16 (512 experts, top-22) at EP32 on GB200 in the max_tokens_per_rank=256 build (single router data CTA): 13-68% of tokens wrong per launch for T >= 64, GSM8K 35-73 instead of 94.8; EP16 and the 512/1024 builds happened not to expose the race. token_comm_dedup.py already has this fence; add the same fence (plus the barrier) before both broadcasts in token_comm.py: the single-data-CTA histogram and the multi-CTA helper's totals. Verified at EP32 (8 x GB200 NVL72 nodes): a backend-vs-fp32-reference check of the BF16 leaf passes in every bucket (256-bucket launches at T=32..256, uniform and skewed routing, repeated launches, create_moe chunked path), with every rank's router tables consistent after each launch. Signed-off-by: Guoming Zhang <137257613+nv-guomingz@users.noreply.github.com>
This branch has not been deployed
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.
…the async-proxy broadcast
The NVLink token-comm router builds each rank's per-expert histogram with generic-proxy SMEM atomics and then broadcasts it to every peer with cp.async.bulk (the sizes_by_rank row) and cp.reduce.async.bulk (the totals). Those bulk copies read SMEM through the async proxy, and a CTA barrier only orders the generic proxy, so without fence.proxy.async.shared::cta the copy can read counts whose atomics are not yet visible to it. A peer then receives a partial row, builds push tables that disagree with the destination's pool layout, and the source's routes land in the wrong pool rows: their FC2 rows never reach the source's combine plane and its tokens come back wrong.
Seen with Nemotron-3 Ultra BF16 (512 experts, top-22) at EP32 on GB200 in the max_tokens_per_rank=256 build (single router data CTA): 13-68% of tokens wrong per launch for T >= 64, GSM8K 35-73 instead of 94.8; EP16 and the 512/1024 builds happened not to expose the race. token_comm_dedup.py already has this fence; add the same fence (plus the barrier) before both broadcasts in token_comm.py: the single-data-CTA histogram and the multi-CTA helper's totals.
Verified at EP32 (8 x GB200 NVL72 nodes): a backend-vs-fp32-reference check of the BF16 leaf passes in every bucket (256-bucket launches at T=32..256, uniform and skewed routing, repeated launches, create_moe chunked path), with every rank's router tables consistent after each launch.
@coderabbitai summary
Description
Test Coverage
PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.