Repository navigation
[executorch][ci] Split unittest-cuda into kernel and system shards - #24047
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24047
Note: Links to docs will display an error until the docs builds have been completed. ⏳ 8 Pending, 1 Unrelated FailureAs of commit f800e4b with merge base 6368414 ( BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
|
This PR needs a
|
91352c3 to
491e1ca
Compare
unittest-cuda has timed out at 90 min on every main run since a04a9f9 made the SDPA autotune tests ~6.5 min slower; the job was already at 83-89 min before that. Split it into a matrix: - kernel: Triton kernel and autotune tests (SDPA, tq4 SDPA, int4 matmul, int5 large GEMM, fused MoE, deltanet, topk, autotune inputs/launch params, mutation cache). ~42 min of pytest. - system: everything else under backends/cuda/tests and passes/tests (lowering passes, op dispatch, export/partitioner/runtime), plus the pybindings device tests, C++ shim tests, and Qwen 3.5 MoE / Gemma 4 31B model tests. ~28 min of pytest. The system shard runs the test directories with the kernel and quantized GEMM files ignored, so new tests default to it. Test plan: CI on this PR; both unittest-cuda shards should finish well under the 90 min timeout.
491e1ca to
f800e4b
Compare
Stacked on #24047. `CudaDFlashNative.FinalWholeBlockFitsExactlyAndPreservesAllPrefillRows` has failed in `unittest-cuda-muse-glimmer-batching` since #24043. It failed on that PR's own CI and on `main` at 8d9eec3: ``` cuda_dflash_native_test.cpp:612: Failure Expected: (drained.draft_forwards - drain.draft_forwards) > (drained.static_draft_forwards - drain.static_draft_forwards), actual: 1 vs 1 ``` The test expected the decode at position 78 to drain the 79 hidden rows through the dynamic draft before running the static draft. But `run_target` drains every owner it touches right after it appends hidden rows (added in #24042). So the 78-row prefill already drains down to the fresh context (32 in this fixture). The decode then holds at most one block (16) of rows and runs a single static draft. The dynamic forwards happen during the prefill, before the stats snapshot the test took. This is a bug in the test's measurement window, not in the executor. The fix takes the first snapshot before the prefill and checks two things: - the prefill runs only dynamic draft forwards (at least one); - the decode runs exactly one draft forward, and it is static. Test plan: - `clang-format` is clean on the changed lines. - No local GPU, so the test relies on CI: `unittest-cuda-muse-glimmer-batching` on this PR should pass.
unittest-cudahas hit its 90 min timeout on everymainrun since a04a9f9 (#24004). That commit made the SDPA autotune tests about 6.5 min slower (test_triton_sdpa.pywent from 10.4 to 16.9 min). The job already took 83–89 min before it, so the extra time pushed it over the limit. Example run: https://github.com/pytorch/executorch/actions/runs/39464763398/job/118773442760This PR splits the job into a two-shard matrix:
unittest-cuda (kernel): Triton kernel and autotune tests. That covers SDPA, split-K SDPA, SDPA NaN, tq4 SDPA, int4 matmul, int5 large GEMM, quantized GEMM family, fused MoE, fused deltanet decode, chunk gated delta rule, topk, autotune inputs and launch params, and the Triton mutation cache. About 42 min of pytest.unittest-cuda (system): everything else underbackends/cuda/testsandbackends/cuda/passes/tests. That covers the lowering passes (off-graph KV, DFlash off-graph KV, SDPA split-K replacement), quantized op dispatch, and export, partitioner and runtime tests. This shard also runs the pybindings device tests, the C++ shim tests, and the Qwen 3.5 MoE and Gemma 4 31B model tests. About 28 min of pytest.Kernel tests are listed explicitly in
KERNEL_TESTS. The system shard runs the test directories and passes--ignorefor the kernel files and for the quantized GEMM files thatunittest-cuda-quantized-gemmalready runs, so any new test file goes to the system shard by default. Both shards still do the full install and build, includingexecutor_runner, because both have e2e tests that need it. Both pytest calls now pass--durations=20.Test plan:
backends/cuda/tests/test_*.pyfiles with no overlap.bash -non the script for each shard.python -m unittest .ci/scripts/tests/test_muse_glimmer_batching_ci.pypasses. That test parsescuda.yml.unittest-cudashards should finish well under 90 min.