Skip to content

fix(megatron): gate device_id process-group init (AIMA-227) - #939

Draft
gphuang wants to merge 1 commit into
mainfrom
fix/megatron/device-id-init-opt-in
Draft

fix(megatron): gate device_id process-group init (AIMA-227)#939
gphuang wants to merge 1 commit into
mainfrom
fix/megatron/device-id-init-opt-in

Conversation

@gphuang

@gphuang gphuang commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Summary

Tracking: AIMA-227. Introduced through PR #807 and merged to main through PR #856.

Makes the device_id injection into torch.distributed.init_process_group opt-in through enable_init_process_group_device_id (default false).

Passing device_id forces eager RCCL communicator creation and adds about 16 GiB/GPU outside the torch caching allocator. This exhausts the remaining VRAM on Llama-70B FP8 and causes the AIMA-227 throughput regression.

An exact same-HEAD FP8 check recovered the 16 GiB, matched the old memory baseline, and completed 10/10 iterations with the patch disabled. Llama also completed without the patch on stock 26.3 and 26.5.

The patch is gated instead of deleted because the historical failure involved Flux-schnell on Megatron with TransformerEngine. If that workload still deadlocks on v26.5 with the patch disabled, the affected Flux recipes should opt in explicitly.

Test plan

  • 6 unit tests cover the gating truth table and default value.
  • Llama BF16 patch ON/OFF: valid loss, 50/50 iterations per arm.
  • Llama FP8 patch OFF: old memory baseline restored, 10/10 iterations.
  • Stock 26.3 without the patch: 20/20 iterations.
  • Flux-schnell Megatron/TE on v26.5: patch ON versus OFF.

The device_id injection forces eager RCCL communicator creation for the world
PG and every Megatron sub-group. On llama3-70B BF16 FSDP2 (1 node x 8 MI355X,
TP/PP/EP=1, ROCm 26.5) that costs +16.0 GiB/GPU peak VRAM and +9.9 s of
startup for no throughput change (-0.07 %, within noise over two interleaved
repeats per arm). The memory is invisible to the torch caching allocator --
max reserved is byte-identical across arms -- so it is communicator-side.

The deadlock the patch guards against did not reproduce on that recipe with
the patch disabled, on ROCm 26.5 or on stock 26.3 (whose bundled Primus
predates the patch). It is kept rather than removed because multi-node and
TP/PP/EP > 1 were not tested, and gated behind
enable_init_process_group_device_id (default false) so no recipe pays 16 GiB
unknowingly. The existing FSDP2 and ODC guards are preserved.

Also corrects the docstring's ~768 MiB estimate, which understated the
measured cost by ~21x.

Adds a test pinning the full condition truth table plus the shipped default,
so the default cannot silently flip back.
@gphuang
gphuang requested review from botaohu001 and luiza-amd July 30, 2026 12:42
@gphuang

gphuang commented Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Note: original repro question folded into PR summary

The original repro question has been folded into the PR summary; the current request is tracked in the historical Flux-schnell question.

@gphuang

gphuang commented Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Note: Llama result folded into PR summary

The detailed Llama patch-OFF result has been folded into the PR summary; it does not cover the historical Flux-schnell workload tracked in the current question.

@gphuang
gphuang requested review from amital-amd and jasainio July 30, 2026 13:37
@gphuang

gphuang commented Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Question: historical Flux-schnell repro

@amital-amd — could you share the exact image/commit, config, node count, parallelism, and hang point from the original Flux-schnell Megatron/TE deadlock? We need one v26.5 patch ON/OFF liveness check before merging.

@gphuang gphuang changed the title fix(megatron): make device_id init_process_group patch opt-in (AIMA-227) fix(megatron): gate device_id process-group init (AIMA-227) Jul 30, 2026
@amital-amd

Copy link
Copy Markdown

@gphuang I did not have those details. Could not find them from logs, probably deleted them during cleanup of dir to save space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants