[TRTLLM-9679][perf] Context request batching to reduce host overhead #9703
Conversation
Signed-off-by: Yuan Tong <[email protected]>
tongyuantongyu
force-pushed
the
ytong/ctx_batched_scheduler
branch
from
da9cfbc to
fdfe31d
Compare
📝 WalkthroughWalkthroughIntroduces a new ContextBatchingScheduler for TensorRT-LLM that extends SimpleScheduler with controls for deferring context request processing based on pending request and iteration thresholds. Configuration fields and conditional scheduler instantiation logic added. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
tensorrt_llm/_torch/pyexecutor/_util.py (1)
808-821: Clarify enabling condition and invariants for context batching schedulerThe selection logic is sound overall, but two details are worth tightening:
- Enabling condition semantics
if scheduler_config.max_pending_requests != 0:means any non‑zero value (including negative) enablesContextBatchingScheduler. Given the field description, it would be more intuitive to treat only strictly positive values as “enabled” and everything else as “disabled”:- if scheduler_config.max_pending_requests != 0: + if scheduler_config.max_pending_requests > 0:
num_fitting_requestsvs. actual scheduled work
When context requests are being held back,output.num_fitting_requestsstill counts them even thoughoutput.context_requestsis replaced with[]. If any downstream code assumes
num_fitting_requests == len(context_requests) + len(generation_requests), this invariant no longer holds. Please double‑check consumers ofSchedulerOutputand either:
- document that
num_fitting_requestsremains “capacity‑based” and may exceed the actually scheduled batch size when batching is deferred, or- adjust
num_fitting_requestsin the held‑back path to match the visible batch size.tensorrt_llm/llmapi/llm_args.py (1)
1273-1298: Validate new scheduler knobs and clarify their scopeThe new fields are wired correctly for the PyTorch backend, but a couple of follow‑ups would make them safer and clearer:
- Add basic validation so configs fail fast on obviously invalid values, e.g. non‑negative constraints:
@field_validator("max_pending_requests") @classmethod def validate_max_pending_requests(cls, v: int) -> int: if v < 0: raise ValueError("scheduler_config.max_pending_requests must be >= 0") return v @field_validator("max_pending_iterations") @classmethod def validate_max_pending_iterations(cls, v: int) -> int: if v < 0: raise ValueError("scheduler_config.max_pending_iterations must be >= 0") return v
- Clarify backend behavior in the descriptions (optional): these fields currently affect only the PyTorch backend (they’re not passed through
_to_pybind), so it may be worth noting that in the docstrings to avoid confusion for TRT users expecting the same knob to work there.The
mirror_pybind_fields(_SchedulerConfig)decorator is fine here since it only enforces that all C++ fields exist in Python; having extra Python‑only fields is allowed.tensorrt_llm/_torch/pyexecutor/scheduler.py (1)
221-262: Context batching logic matches intent; consider tightening edge‑case semanticsThe new
ContextBatchingSchedulercorrectly layers “hold context until we have enough, or until we’ve waited N stable iterations” on top ofSimpleScheduler. A few small polish points:
- Threshold semantics: with the current
create_py_executor_instancelogic (max_pending_requests != 0), negative values will also enable this scheduler and causenum_pending_requests >= max_pending_requeststo be true immediately. That effectively disables batching but still pays the stateful overhead. Using> 0on the caller side (and/or validation inSchedulerConfig) would make the behavior more intuitive.- Idle iterations: when there are no context requests,
pending_iterationsstill increments and periodically resets. This is harmless but you might want to short‑circuit whennum_pending_requests == 0to make the state machine easier to reason about.- Documentation (optional): a short class docstring summarizing the invariant (“defers context batches until either
max_pending_requestsis reached or we’ve hadmax_pending_iterationsconsecutive iterations without the pending set growing”) would help future readers.Functionally this looks solid and should do what the PR describes.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
tensorrt_llm/_torch/pyexecutor/_util.py(2 hunks)tensorrt_llm/_torch/pyexecutor/scheduler.py(1 hunks)tensorrt_llm/llmapi/llm_args.py(1 hunks)tests/unittest/llmapi/test_llm.py(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.py
📄 CodeRabbit inference engine (CODING_GUIDELINES.md)
**/*.py: The code developed for TensorRT-LLM should conform to Python 3.8+
Indent Python code with 4 spaces; do not use tabs
Always maintain the namespace when importing in Python, even if only one class or function from a module is used (e.g., usefrom package.subpackage import fooand thenfoo.SomeClass()instead offrom package.subpackage.foo import SomeClass)
Python filenames should use snake_case (e.g.,some_file.py)
Python class names should use PascalCase (e.g.,class SomeClass)
Python function and method names should use snake_case (e.g.,def my_awesome_function():)
Python local variable names should use snake_case, with prefixkfor variable names that start with a number (e.g.,k_99th_percentile = ...)
Python global variables should use upper snake_case with prefixG(e.g.,G_MY_GLOBAL = ...)
Python constants should use upper snake_case (e.g.,MY_CONSTANT = ...)
Avoid shadowing variables declared in an outer scope in Python
Initialize all externally visible members of a Python class in the constructor
For Python interfaces that may be used outside a file, prefer docstrings over comments
Python comments should be reserved for code within a function, or interfaces that are local to a file
Use Google style docstrings for Python classes and functions, which can be parsed by Sphinx
Python attributes and variables can be documented inline with type and description (e.g.,self.x = 5followed by"""<type>: Description of 'x'""")
Avoid using reflection in Python when functionality can be easily achieved without reflection
When using try-except blocks in Python, limit the except clause to the smallest set of specific errors possible instead of catching all exceptions
When using try-except blocks in Python to handle multiple possible variable types (duck-typing), keep the body of the try as small as possible and use the else block to implement the logic
Files:
tensorrt_llm/llmapi/llm_args.pytests/unittest/llmapi/test_llm.pytensorrt_llm/_torch/pyexecutor/scheduler.pytensorrt_llm/_torch/pyexecutor/_util.py
**/*.{cpp,h,cu,py}
📄 CodeRabbit inference engine (CODING_GUIDELINES.md)
All TensorRT-LLM Open Source Software code files should contain an NVIDIA copyright header that includes the current year at the top
Files:
tensorrt_llm/llmapi/llm_args.pytests/unittest/llmapi/test_llm.pytensorrt_llm/_torch/pyexecutor/scheduler.pytensorrt_llm/_torch/pyexecutor/_util.py
🧠 Learnings (1)
📚 Learning: 2025-07-28T17:06:08.621Z
Learnt from: moraxu
Repo: NVIDIA/TensorRT-LLM PR: 6303
File: tests/integration/test_lists/qa/examples_test_list.txt:494-494
Timestamp: 2025-07-28T17:06:08.621Z
Learning: In TensorRT-LLM testing, it's common to have both CLI flow tests (test_cli_flow.py) and PyTorch API tests (test_llm_api_pytorch.py) for the same model. These serve different purposes: CLI flow tests validate the traditional command-line workflow, while PyTorch API tests validate the newer LLM API backend. Both are legitimate and should coexist.
Applied to files:
tests/unittest/llmapi/test_llm.py
🧬 Code graph analysis (4)
tensorrt_llm/llmapi/llm_args.py (1)
tensorrt_llm/builder.py (1)
default(45-50)
tests/unittest/llmapi/test_llm.py (1)
tensorrt_llm/llmapi/llm_args.py (1)
SchedulerConfig(1274-1298)
tensorrt_llm/_torch/pyexecutor/scheduler.py (1)
tensorrt_llm/_torch/pyexecutor/kv_cache_connector.py (1)
SchedulerOutput(76-81)
tensorrt_llm/_torch/pyexecutor/_util.py (1)
tensorrt_llm/_torch/pyexecutor/scheduler.py (2)
SimpleScheduler(198-218)ContextBatchingScheduler(221-262)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pre-commit Check
🔇 Additional comments (2)
tensorrt_llm/_torch/pyexecutor/_util.py (1)
40-41: ImportingContextBatchingSchedulerlooks correctThe new import cleanly exposes the additional scheduler without affecting existing imports; no issues here.
tests/unittest/llmapi/test_llm.py (1)
2492-2502: Good targeted coverage for context batching configurationThis test cleanly exercises the new
SchedulerConfigknobs on the PyTorch backend (multiple prompts, capped batch size) and reuses the existing harness, so it should guard against regressions in the context‑batching behavior.
Signed-off-by: Yuan Tong <[email protected]>
tongyuantongyu
force-pushed
the
ytong/ctx_batched_scheduler
branch
from
1981ed2 to
d758edb
Compare
| max_pending_requests: int = Field( | ||
| default=0, | ||
| description= | ||
| "Max number of context requests allowed to be hold from being scheduled" | ||
| ) | ||
|
|
||
| max_pending_iterations: int = Field( | ||
| default=1, | ||
| description= | ||
| "Max number of iterations allowed to hold context requests from being scheduled" | ||
| ) | ||
|
|
There was a problem hiding this comment.
Could we group those 2 in a separate class. Maybe DelayedBatchingConfig? Also is this specific to context request only? If so, name should reflect that:
context_delayed_batching_config: Optional[DelayedBatchingConfig] = Field(
default=None, description="The delayed batching config to use for context requests")
Also, instead of using a max_pending_iterations, could we use a time-based delay? That's what is done in the Triton inference server. The problem with iterations is that time per iteration can vary significantly. Maybe max_delay_microseconds. And would rename max_pending_requests to max_delayed_requests
| len(fitting_requests)) | ||
|
|
||
|
|
||
| class ContextBatchingScheduler(SimpleScheduler): |
There was a problem hiding this comment.
We should have unit tests for this new scheduler to verify behaviour is as expected. For example, you could mock the output of super().schedule_request and verify that after making successive calls to ContextBatchingScheduler.schedule_request you get the expect batches.
|
Jus realized we already have similar feature in #7416. |
2 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.
Description
There is significant perf drop on batches with "few context + many generations". They are not eligible for CUDA graph and not large enough to hide host overhead. This is exceptionally severe when running small models on large GPUs.
Add a feature to delay scheduling the context requests, until they form a large enough batch.
Test Coverage
tests.unittest.llmapi.test_llm.test_llm_context_batching_configPR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
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.
Details
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 thestage-listparameter 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.mdand the
scripts/test_to_stage_mapping.pyhelper.kill
killKill all running builds associated with pull request.
skip
skip --comment COMMENTSkip 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-pipelineReuse 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.