You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2610525
Browse filesBrowse the repository at this point in the historyBrowse files
perf(ncclep): right-size the NCCL EP receive budget
The NCCL EP receive buffer is sized at moe_expert_rank_capacity_factor x the
ideal token count, and every MoE activation saved for backward inherits that
padding. At 1.5 that accounted for 86.8 GB of the 114.1 GB step peak on
nemotron_3_nano_8gpu_gb300_bf16 (+45.9 GB mem-max-allocated vs the HybridEP
baseline) and 135.3 GB on qwen3_30b_a3b gb300 bf16, which OOMed.
These recipes set moe_router_force_load_balancing, so the routing is balanced by
construction. Measured against the ragged HybridEP receive buffers, the worst
case is 1.0072x the ideal token count over 2208 samples for nemotron_3_nano and
1.0050x over 930 samples for qwen3_30b_a3b. Drop the factor to 1.05, which still
leaves 7x (nemotron_3_nano) to 10x (qwen3_30b_a3b) the observed excess and
recovers ~26 GB and ~40 GB respectively. PagedStashRunner is wired on the
capacity factor rather than on paged stashing, so if a routing ever does exceed
the static budget it replays the step dropless and grows the budget: an
underestimate costs a rerun, not correctness.
Also gate moe_paged_stash on the quantized recipes. PagedStashManager only
stashes tensors carrying TE's grouped_tensor_scale_inv attribute, so in BF16
nothing is ever stashed and the run logs "Paged stash: max_tokens_dict is None,
skipping stash buffer allocation" - it was pure hook overhead. The MXFP8 recipes
keep it, where it allocates a real pool and does cut the transient peak.
Signed-off-by: Malay Nagda <malayn@nvidia.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments