[None][refactor] refactor the CUDA graph runner to manage all CUDA graphs

[QiJune]

Summary by CodeRabbit

• Refactor
  • Centralized CUDA graph lifecycle and memory management, improving performance, stability, and cleanup.
  • Faster warmup and reduced memory fragmentation through pooled allocations and unified release.
  • Streamlined forward path with reliable fallback to eager execution when graphs aren’t applicable.

Description

Test Coverage

GitHub Bot Help

/bot [-h] ['run', 'kill', 'skip', 'reuse-pipeline'] ...

Provide a user friendly way for developers to interact with a Jenkins server.

Run /bot [-h|--help] to print this help message.

See details below for each supported subcommand.

run [--reuse-test (optional)pipeline-id --disable-fail-fast --skip-test --stage-list "A10-PyTorch-1, xxx" --gpu-type "A30, H100_PCIe" --test-backend "pytorch, cpp" --add-multi-gpu-test --only-multi-gpu-test --disable-multi-gpu-test --post-merge --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" --detailed-log --debug(experimental)]

Launch build/test pipelines. All previously running jobs will be killed.

--reuse-test (optional)pipeline-id (OPTIONAL) : Allow the new pipeline to reuse build artifacts and skip successful test stages from a specified pipeline or the last pipeline if no pipeline-id is indicated. If the Git commit ID has changed, this option will be always ignored. The DEFAULT behavior of the bot is to reuse build artifacts and successful test results from the last pipeline.

--disable-reuse-test (OPTIONAL) : Explicitly prevent the pipeline from reusing build artifacts and skipping successful test stages from a previous pipeline. Ensure that all builds and tests are run regardless of previous successes.

--disable-fail-fast (OPTIONAL) : Disable fail fast on build/tests/infra failures.

--skip-test (OPTIONAL) : Skip all test stages, but still run build stages, package stages and sanity check stages. Note: Does NOT update GitHub check status.

--stage-list "A10-PyTorch-1, xxx" (OPTIONAL) : Only run the specified test stages. Examples: "A10-PyTorch-1, xxx". Note: Does NOT update GitHub check status.

--gpu-type "A30, H100_PCIe" (OPTIONAL) : Only run the test stages on the specified GPU types. Examples: "A30, H100_PCIe". Note: Does NOT update GitHub check status.

--test-backend "pytorch, cpp" (OPTIONAL) : Skip test stages which don't match the specified backends. Only support [pytorch, cpp, tensorrt, triton]. Examples: "pytorch, cpp" (does not run test stages with tensorrt or triton backend). Note: Does NOT update GitHub pipeline status.

--only-multi-gpu-test (OPTIONAL) : Only run the multi-GPU tests. Note: Does NOT update GitHub check status.

--disable-multi-gpu-test (OPTIONAL) : Disable the multi-GPU tests. Note: Does NOT update GitHub check status.

--add-multi-gpu-test (OPTIONAL) : Force run the multi-GPU tests in addition to running L0 pre-merge pipeline.

--post-merge (OPTIONAL) : Run the L0 post-merge pipeline instead of the ordinary L0 pre-merge pipeline.

--extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" (OPTIONAL) : Run the ordinary L0 pre-merge pipeline and specified test stages. Examples: --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx".

--detailed-log (OPTIONAL) : Enable flushing out all logs to the Jenkins console. This will significantly increase the log volume and may slow down the job.

--debug (OPTIONAL) : Experimental feature. Enable access to the CI container for debugging purpose. Note: Specify exactly one stage in the stage-list parameter to access the appropriate container environment. Note: Does NOT update GitHub check status.

For guidance on mapping tests to stage names, see docs/source/reference/ci-overview.md
and the scripts/test_to_stage_mapping.py helper.

kill

kill

Kill all running builds associated with pull request.

skip

skip --comment COMMENT

Skip testing for latest commit on pull request. --comment "Reason for skipping build/test" is required. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

reuse-pipeline

reuse-pipeline

Reuse a previous pipeline to validate current commit. This action will also kill all currently running builds associated with the pull request. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

[QiJune]

/bot run

[QiJune]

It looks correct to me, but what's the motivation for the refactor? It's good that all of ModelEngine's CUDA graph related code is now in one centralized place for sure, but I'm a little leery about coupling CUDAGraphRunner and ModelEngine so tightly. I mean that we're in a circular dependency situation now: ModelEngine depends on and uses CUDAGraphRunner and CUDAGraphRunner depends on and uses ModelEngine. This can make the logic a bit hard to follow because the control flow now alternates between ModelEngine and the CUDAGraphRunner in many places.

Hi @mikeiovine , the motivation is to make the CUDAGraphRunner manage all the cuda graphs, thus,ModelEngine does not need to know the details. This is the first step to make CUDAGraphRunner more modularized. We will address the issues in future PRs.

[tensorrt-cicd]

PR_Github #16185 [ run ] triggered by Bot

[tensorrt-cicd]

PR_Github #16185 [ run ] completed with state FAILURE
/LLM/main/L0_MergeRequest_PR pipeline #12173 completed with status: 'FAILURE'

[mikeiovine]

the motivation is to make the CUDAGraphRunner manage all the cuda graphs, thus,ModelEngine does not need to know the details

Thanks for bearing with me as I try to understand the long-term plan. Do we want to eventually fully invert the dependencies? So you inject a model engine into a CUDAGraphRunner, and PyExecutor uses a Union[CUDAGraphRunner, ModelEngine]. Then, all you have to do to enable CUDA graph is wrap your model engine. Or is the goal simply to remove CUDA graph related clutter from ModelEngine?

[QiJune]

/bot run

[tensorrt-cicd]

PR_Github #16289 [ run ] triggered by Bot

[QiJune]

the motivation is to make the CUDAGraphRunner manage all the cuda graphs, thus,ModelEngine does not need to know the details

Thanks for bearing with me as I try to understand the long-term plan. Do we want to eventually fully invert the dependencies? So you inject a model engine into a CUDAGraphRunner, and PyExecutor uses a Union[CUDAGraphRunner, ModelEngine]. Then, all you have to do to enable CUDA graph is wrap your model engine. Or is the goal simply to remove CUDA graph related clutter from ModelEngine?

Hi @mikeiovine , the later. Our model engine is too complex with more than 2000 loc. I think we would have a Runner and a CUDAGraphRunner. Then, ModelEngine can choose to initiate one depends on cuda graph configs.

[tensorrt-cicd]

PR_Github #16289 [ run ] completed with state SUCCESS
/LLM/main/L0_MergeRequest_PR pipeline #12245 completed with status: 'FAILURE'

[QiJune]

/bot run

[tensorrt-cicd]

PR_Github #16333 [ run ] triggered by Bot

[tensorrt-cicd]

PR_Github #16333 [ run ] completed with state SUCCESS
/LLM/main/L0_MergeRequest_PR pipeline #12279 completed with status: 'FAILURE'

[QiJune]

/bot run --only-multi-gpu-test

[tensorrt-cicd]

PR_Github #16363 [ run ] triggered by Bot

[tensorrt-cicd]

PR_Github #16363 [ run ] completed with state SUCCESS
/LLM/main/L0_MergeRequest_PR pipeline #12294 (Partly Tested) completed with status: 'SUCCESS'

[QiJune]

/bot skip --comment "The single test failure is a known issue that was waived in PR #7194"

[QiJune]

/bot skip --comment "The single test failure is a known issue that was waived in PR #7194"

[tensorrt-cicd]

PR_Github #16441 [ skip ] triggered by Bot

[tensorrt-cicd]

PR_Github #16441 [ skip ] completed with state SUCCESS
Skipping testing for commit 7ff0405