Skip to content

fix(ci): stabilize failing functional test recipes - #5253

Closed
Connor-XY wants to merge 4 commits into
NVIDIA:mainfrom
Connor-XY:yxu1/ci-functional-test-stability-fixes
Closed

fix(ci): stabilize failing functional test recipes#5253
Connor-XY wants to merge 4 commits into
NVIDIA:mainfrom
Connor-XY:yxu1/ci-functional-test-stability-fixes

Conversation

@Connor-XY

@Connor-XY Connor-XY commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

What

Combine the CI recipe mitigations from:

Follow-up from the latest GitLab/JET BERT logs: bert_mcore_tp1_pp4_vp2 still hung after the batched-P2P change, with one rank blocked in DataLoader queue.get while another timed out in batched pipeline P2P. This PR now also sets --num-workers: 0 for that BERT recipe.

The fixes are kept as separate commits so each mitigation remains easy to inspect or revert independently.

Why

These are all test-config-only fixes for functional tests that are currently failing or flaky in CI.

BERT pp4/vp2 hang

bert_mcore_tp1_pp4_vp2 originally failed as an intermittent pipeline-parallel P2P hang. Disabling P2P overlap routes the interleaved pp4/vp2 recipe to batched P2P (batch_isend_irecv) instead of the unbatched per-pair P2P path that can lazily create 2-rank NCCL communicators in inconsistent order.

The follow-up GitLab/JET failure shows the recipe update was applied (overlap_p2p_comm=False) and the hang moved to a batched COALESCED NCCL operation after iteration 15, while another rank was parked in get_batch / DataLoader queue.get. Setting --num-workers: 0 removes the worker subprocess and pin-memory queue from this small functional test.

T5 dataloader hang

The affected T5 recipes can surface as finalize_model_grads all-reduce timeouts, but fault-handler dumps show the stuck rank parked in get_batch / DataLoader queue.get. Setting --num-workers: 0 removes the worker subprocess queue from these small functional tests.

GRPO CUDA-graph memory guardrail

The GRPO throughput recipes fail their memory guardrail after the CUDA graph sizing default changed to exponential plus mixed-prefill grid. Pinning --inference-dynamic-batching-cuda-graph-sizing-distribution: linear restores the pre-change sizing behavior for these tests. This still needs CI confirmation because mixed-prefill count may also contribute to peak memory.

Validation

  • Parsed the updated BERT YAML locally with python3 / PyYAML.
  • Inspected the failing GitLab/JET BERT logs and confirmed the recipe was using --no-overlap-p2p-communication, overlap_p2p_comm=False, and still timing out in batched P2P while another rank was blocked in DataLoader queue.get.

Needs Run functional tests to validate the CI-dependent failure modes.

Supersedes #5240, #5241, and #5242.

@copy-pr-bot

copy-pr-bot Bot commented Jun 10, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@Connor-XY

Copy link
Copy Markdown
Contributor Author

/ok to test a5f57c6

Connor-XY and others added 4 commits June 10, 2026 17:26
…ved-PP NCCL deadlock

bert_mcore_tp1_pp4_vp2 intermittently hangs in a pipeline-parallel P2P recv
(ProcessGroupNCCL RECV timeout on PIPELINE_MODEL_PARALLEL_GROUP). The interleaved
(VPP) schedule defaults to overlap_p2p_comm=True, which forces batch_p2p_comm=False
and takes the unbatched _p2p_ops path. Unbatched send/recv on the >2-rank PP group
lazily creates a new 2-rank NCCL communicator per pair; under pp4+vp2 these lazy
inits can be entered in inconsistent order across ranks and deadlock (the run logs
the "unbatched P2P op ... new 2-rank NCCL communicator" warning right before hanging).

Observed: 9/9 retries hung, always on a RECV, at rotating ranks (0/1/3/4/6) and
varying SeqNums/iterations, with no numerical error -> a comms-layer lazy-comm-init
deadlock, not a code or numerical regression. p2p_communication.py is unchanged
since 2026-03 (path dates to 2024), so this is a latent hazard.

Disabling P2P overlap routes the test to batched _batched_p2p_ops (single
batch_isend_irecv on the existing group, no per-pair lazy comms). pp=4 > 2 satisfies
the interleaved+no-overlap assert in arguments.py.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Connor-XY <45385219+Connor-XY@users.noreply.github.com>
…5 functional tests

t5_mcore_tp1_pp1_vp1 (+ the two *_resume_torch variants) intermittently hang in
CI. The fault-handler dump shows the stuck rank's main thread parked in the input
pipeline, not a collective:

  pretrain_t5.py:148 get_batch -> rerun_state_machine.py __next__
   -> torch/utils/data/dataloader.py _try_get_data -> multiprocessing/queues.py:113 get  (blocked)

A dataloader worker fails to deliver the next batch, so that rank never enters the
step's gradient all-reduce; the ranks that did get their data then time out in
finalize_model_grads (600s NCCL watchdog) and the run aborts -- surfacing as a
misleading "collective timeout". Training is numerically healthy up to the hang
(no NaN). build_pretraining_data_loader uses num_workers=2 + pin_memory +
persistent_workers and sets no DataLoader timeout, so a stalled worker blocks
forever. The same recipe runs clean on fast local storage, so the trigger is the
CI data mount / worker pipeline, not the model.

--num-workers 0 loads batches in-process (no worker subprocesses, no pin-memory
queue, worker_init_fn skipped), removing the queue.get hang surface. Test data is
tiny so the perf impact is negligible.

Note: candidate fix to validate in CI (the stall does not reproduce on fast local
storage). If it still hangs with num_workers=0, the trigger is raw I/O on the data
mount and the follow-up is a DataLoader timeout + local data staging.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Connor-XY <45385219+Connor-XY@users.noreply.github.com>
…throughput

gpt_grpo_tp4_pp1_dp2_8b_throughput (+ _cudagraphs variant) fail their
mem-allocated-bytes guardrail: peak ~69.2GB vs ~60.9GB golden (+13.6%, tol 10%).
lm-loss passes -- training is numerically correct; only peak memory grew.

Bisected the regression to a single commit (last-pass bdcaf26 -> first-fail
16b7194, the only commit between): PR NVIDIA#3509 "Change the cudagraph distribution
from linearly to exponentially-decreasing + grid for mixed prefill", which made
`exponential` the default sizing distribution and added a mixed-prefill grid.

Set --inference-dynamic-batching-cuda-graph-sizing-distribution=linear to pin the
pre-NVIDIA#3509 behavior for these tests.

Caveat: these recipes use --inference-dynamic-batching-num-cuda-graphs 1, so the
sizing distribution mainly selects the single captured graph size; NVIDIA#3509 also added
the mixed-prefill grid (--inference-dynamic-batching-cuda-graph-mixed-prefill-count,
default 16) which may be a separate memory driver. If `linear` alone does not bring
peak memory under the 10% bound in CI, the follow-up lever is reducing the
mixed-prefill-count (or the inference team confirms exponential+grid is the intended
default and the golden is rebaselined).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Connor-XY <45385219+Connor-XY@users.noreply.github.com>
bert_mcore_tp1_pp4_vp2 still hangs in the GitLab/JET pipeline after enabling batched P2P. The failing JET child log shows the update is applied (--no-overlap-p2p-communication, overlap_p2p_comm=False), then training reaches iteration 15 before rank 0 times out in _batched_p2p_ops / batch_isend_irecv while rank 7 is blocked in DataLoader queue.get.

Use --num-workers 0 for this tiny functional test to remove the worker/pin-memory queue hang surface, matching the T5 dataloader stabilization used in this same PR.

Signed-off-by: Connor-XY <45385219+Connor-XY@users.noreply.github.com>
@Connor-XY
Connor-XY force-pushed the yxu1/ci-functional-test-stability-fixes branch from 538bb38 to 518a64d Compare June 11, 2026 00:26
@Connor-XY Connor-XY closed this Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants