[AMD][CI] CI: fix AMD 2-GPU multimodal-gen partition-count abort - #34328
Conversation
… per shard run_suite.py gave every standalone file a partition of its own when CI did not pass a precomputed partition plan, and aborted when the suite had more standalone files than --total-partitions. The AMD 2-GPU lanes hardcode --total-partitions 3, so growing STANDALONE_FILES["2-gpu"] to seven files failed every shard before a single test ran. Build the assignment with the same LPT pass the precomputed plans use, so standalone files share shards with the parametrized cases and the shard count no longer constrains the suite. Co-authored-by: quitenode <quitenode@users.noreply.github.com>
Co-authored-by: quitenode <quitenode@users.noreply.github.com>
Co-authored-by: quitenode <quitenode@users.noreply.github.com>
|
Offline-validated this fix against the exact 08/09 failure — it greens the 2-GPU multimodal-gen shards. 👍 Repro of the pre-fix abort (run 31327057626, With this PR's
So all 3 red 2-GPU Tested on MI300X (gfx942), image |
|
/rerun-failed-ci |
1 similar comment
|
/rerun-failed-ci |
|
@amd-bot ci-status |
CI Status for PR #34328Merge verdict: The fix works — the exact bug this PR targets ( Note This PR's changed code is exercised and verified: the new unit test Changed files: Executed CI failure attribution: AMD: multiple multimodal-gen shard failures (0 related to this PR) · NPU: 1 shard failure (0 related) · Others: gate/finish/extra jobs are fast-fail cascades of the above. AMD run still pending (do not count as passed). AMD Executed Failures
Other Executed Failures
Details / what to do before merge
Generated by amd-bot using Claude Code CLI |
…fails Packing standalone files into shards alongside parametrized cases exposed them to a failure that is not theirs: without --continue-on-error the shard returned as soon as the parametrized pytest run failed, so the standalone files assigned to it never ran. That is a regression for the AMD 1-gpu lane, where test_generate_zimage_turbo_cli.py previously owned a shard of its own and was therefore independent of the cases -- and the AMD lanes run no coverage check, so the skip would be silent. Record the exit code and carry on to the standalone files instead. --continue-on-error keeps its meaning between standalone files. Co-authored-by: quitenode <quitenode@users.noreply.github.com>
_run_partition_assignment recomputes both the estimate and the missing-estimate list while it runs, so filling them in for symmetry with the plan path only added code to keep correct. Co-authored-by: quitenode <quitenode@users.noreply.github.com>
|
Thanks @bingxche — all three points addressed. Fast-fail skipping standalone files (0ad51a5): fixed, and you're right that 1-gpu is the real regression — on HIP the only standalone file left is Unread Description scope: added a "Which lanes change behavior" section covering the 1-gpu recomposition (3 parametrized + 1 standalone shard → 4 mixed shards) and why the other no-plan lanes are unaffected — matches your list. Not actioned, both pre-existing and happy to take in a follow-up: the now-dead |
…u-partition-guard-e992 # Conflicts: # .github/workflows/pr-test-amd-rocm720.yml Co-authored-by: quitenode <quitenode@users.noreply.github.com>
…-project#34328) Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: quitenode <quitenode@users.noreply.github.com>
…-project#34328) Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: quitenode <quitenode@users.noreply.github.com>
…-project#34328) Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: quitenode <quitenode@users.noreply.github.com>
Motivation
Every
multimodal-gen-test-2-gpu-amdshard on bothpr-test-amdandpr-test-amd-rocm720fails before running a single test (e.g. run 31327057626):run_suite.pyreserved one whole partition per standalone file whenever CI did not pass a precomputed partition plan, and bailed out when a suite had more standalone files than--total-partitions. The AMD lanes hardcode--total-partitions 3, so the guard tripped as soon asSTANDALONE_FILES["2-gpu"]grew past three entries (#33725 and #33775 took it to seven).Raising the hardcoded count (as the previously closed #33879 did) fixes it only until the next standalone file is added, and each extra AMD partition is a serial 2-GPU job with its own container and dependency install. This removes the coupling instead: the shard count no longer has to track the standalone file count.
Worth noting the same guard had already silently cost the AMD lane its parametrized coverage — at exactly three standalone files,
parametrized_partitionswas 0 and all three shards ran only standalone files. Balanced packing restores those cases.Modifications
partitioning.py: addassign_partition(), returning one shard's slice of the deterministic LPT pass.run_suite.py: when no--partition-plan-jsonis given, build the shard assignment withbuild_local_partition_assignment()— the same LPT pass over parametrized cases and standalone files thatcompute_diffusion_partitions.pyuses for the precomputed plans — instead of the index-based scheme, and drop the guard. Both plan sources now feed one executor (_run_partition_assignment), so the two code paths cannot drift;auto_partition()and the already-dead_get_standalone_file()go away.gen_diffusion_ci_outputs.py: import the partition helpers frompartitioningdirectly, sincerun_suiteno longer re-exportspartition_items_by_lpt.unit/test_suite_partitioning.py: every shard count schedules each case and standalone file exactly once, including counts below the standalone file count.part: [0, 1, 2]comments in the two AMD workflows.No workflow partition counts change. For the 2-GPU suite the three AMD shards come out at 2642s / 2597s / 2652s estimated, versus ~2506s per shard for the two parametrized shards before the breakage, so per-shard runtime is unchanged. Four of the seven standalone files (
test_ipc_a2a_2_gpu,test_pynccl_a2a_capture_2_gpu,test_dp_serving_2_gpu,test_usp_replicated_parity_2_gpu) self-skip on non-CUDA platforms, so the ROCm shards only newly executetest_ar_modelsandtest_diffusion_bcg_tp2_zimage_turbo.Separate pre-existing bug found while investigating
scripts/ci/utils/diffusion/diffusion_case_parser.pyAST-parsesSTANDALONE_FILESout ofrun_suite.py, but that dict moved toserver/gpu_cases.pyin #24630. The parser therefore reports zero standalone files, so the CUDA partition plans have not scheduled any standalone test since June, andverify_diffusion_coverage.pydoes not notice because it derives its expectations from the same parser. Fixing it is deliberately not part of this PR: it would newly schedule nine never-run standalone files on the CUDA lanes and would immediately fail the coverage job, which exits non-zero for standalone files missing aSTANDALONE_FILE_EST_TIMESentry (test_generate_zimage_turbo_cli.pyhas none).Which lanes change behavior
Only the lanes that run without a precomputed plan, which is AMD plus two small CUDA jobs:
pr-test-amd,pr-test-amd-rocm720): aborted before any test; now 3 balanced shards of cases + standalone files.test_generate_zimage_turbo_cli.py(the only standalone file left on HIP, sinceis_hipdropstest_update_weights_from_disk) now shares a shard. It keeps running even when cases in that shard fail; see the fast-fail note below.multimodal-gen-test-1-5090: no standalone entries for the suite, one partition, so the same LPT call over the same items — identical case list and order.bcg-diffusion: emptyPARAMETRIZED_CASE_GROUPS, one standalone file, one partition — the same file runs; only the report'sis_standaloneflag differs, and nothing consumes that job's report.STANDALONE_FILESis empty anyway),1-gpu-b200andunittake the file-suite branch, component-accuracy has its own branch, and MUSA has a separaterun_suite.py.A shard no longer stops before its standalone files when a parametrized case fails without
--continue-on-error. Standalone files are separate pytest runs that only share a shard because the shard count is fixed; keeping the early return would have made the AMD 1-GPU standalone file collateral damage of unrelated case failures, silently, since the AMD lanes run no coverage check.Validation
multimodal-gen-test-2-gpu-amdshard 0: no longer aborts — it received an assignment (2-gpu 1/3, 7 parametrized cases) and ran for 22 min, 5 passed / 2 errors. Both errors are a broken LTX-2.3 checkpoint in the runner's model cache (transformer/has no weight file), unrelated to partitioning. Shards 1 and 2 are still queued behind the serial 2-GPU matrix.multimodal-gen-unit-test-amd: 1272 passed / 5 skipped, including the 22 newtest_suite_partitioning.pycases.multimodal-gen-test-1-5090,bcg-diffusion): run 31443692138 (attempt 2).Accuracy Tests
N/A — CI orchestration only.
Speed Tests and Profiling
N/A.
Checklist
Review and Merge Process
/tag-and-rerun-ci,/tag-run-ci-label,/rerun-failed-ciCI States
Latest PR Test (Base): ✅ Run #31636186876
Latest PR Test (Extra): ❌ Run #31636186592