fix(trtllm): expose env var to force engine side conversation dp assignment#11705
Conversation
Signed-off-by: Guan Luo <41310872+GuanLuo@users.noreply.github.com>
Signed-off-by: Guan Luo <41310872+GuanLuo@users.noreply.github.com>
WalkthroughChangesConversation affinity routing
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
components/src/dynamo/trtllm/request_handlers/handler_base.py (1)
1154-1179: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUse the combined affinity flag when forwarding
conversation_params. Incomponents/src/dynamo/trtllm/request_handlers/handler_base.py:1154-1178, the config override path buildsconversation_paramsbut still drops it at the call site becauseconv_kwargsis gated only byconv_affinity. That leaves override-only requests with neitherconversation_paramsnorscheduling_params. Reuse the combined flag here and add a regression test for override enabled + engine detection disabled.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/src/dynamo/trtllm/request_handlers/handler_base.py` around lines 1154 - 1179, The conversation_params forwarding logic near conv_kwargs incorrectly checks only conv_affinity; gate it with the combined affinity condition that also includes self._engine_conversation_affinity_override, so override-only requests receive conversation_params while preserving scheduling behavior. Add a regression test covering the override-enabled, engine-detection-disabled case and verify the generated request includes conversation_params.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@components/src/dynamo/trtllm/request_handlers/handler_base.py`:
- Around line 1154-1179: The conversation_params forwarding logic near
conv_kwargs incorrectly checks only conv_affinity; gate it with the combined
affinity condition that also includes
self._engine_conversation_affinity_override, so override-only requests receive
conversation_params while preserving scheduling behavior. Add a regression test
covering the override-enabled, engine-detection-disabled case and verify the
generated request includes conversation_params.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 7b686791-5243-4844-8e88-76c8ba84a149
📒 Files selected for processing (3)
components/src/dynamo/trtllm/backend_args.pycomponents/src/dynamo/trtllm/request_handlers/handler_base.pycomponents/src/dynamo/trtllm/workers/llm_worker.py
Signed-off-by: Guan Luo <41310872+GuanLuo@users.noreply.github.com>
…TestConversationAffinity MagicMock auto-creates truthy attributes; config.conversation_affinity was returning a MagicMock object instead of False, making _engine_conversation_affinity_override truthy and causing the affinity-off test cases to take the conversation_params branch instead of the scheduling_params branch. Refs: #11705
Raise RuntimeError at startup when --conversation-affinity / DYN_ENGINE_CONV_AFFINITY is set on a TRT-LLM build that lacks ConversationParams (<=1.3.0rc20). The existing guard only covered the auto-detection path. Refs: #11705
The __init__ guard fires for any HandlerBase constructed with a bare MagicMock() config (truthy conversation_affinity attribute), breaking existing tests that don't pin it. CONVERSATION_PARAMS_AVAILABLE is also False in the CPU test environment, compounding the breakage. Refs: #11705
Raise RuntimeError on first request when DYN_ENGINE_CONV_AFFINITY is set on a TRT-LLM build that lacks ConversationParams (<=1.3.0rc20). The existing guard only covered the engine auto-detection path. Guard goes in _generate_locally_impl (not __init__) because CONVERSATION_PARAMS_AVAILABLE is False in the CPU test environment. Pin config.conversation_affinity=False in all MagicMock-based handler helpers so the guard does not fire spuriously in tests. Refs: #11705
Three tests in test_trtllm_unit.py verify the env var and CLI flag are read correctly and default to False. Two tests in TestConversationAffinity cover the override path behavior: - override=True suppresses dp_rank and forwards conversation_params (regression case for the conv_kwargs gate) - override=True raises RuntimeError when ConversationParams API is missing (guard added in _generate_locally_impl) Refs: #11705
Per review: consolidate the two runtime checks into the existing `if _conversation_affinity is None` block so both the override guard and the engine-detection guard fire exactly once (on first request), then simplify `conv_affinity = self._conversation_affinity`. Update the two override tests to reset `_conversation_affinity = None` before driving the handler so the lazy init path is exercised. Refs: DYN-3570
…ath (#11738) Signed-off-by: Yuewei Na <nv-yna@users.noreply.github.com> Co-authored-by: Yuewei Na <nv-yna@users.noreply.github.com>
test_trtllm_trace_propagation: _make_engine bypasses __init__ but _generate_started now reads _engine_conversation_affinity_override unconditionally — add the missing default (False) alongside the existing _conversation_affinity = False. test_trtllm_engine_conversation_affinity: the override test patches ConversationParams but not CONVERSATION_PARAMS_AVAILABLE in llm_engine, so the guard fires in a real TRT-LLM 1.3.0rc20 environment. Patch llm_engine.CONVERSATION_PARAMS_AVAILABLE = True to match the intent. Refs: DYN-3570
Signed-off-by: Guan Luo 41310872+GuanLuo@users.noreply.github.com
Overview
Adds
--conversation-affinity/DYN_ENGINE_CONV_AFFINITYto let operators force engine-side conversation-affinity attention-DP routing for TRT-LLM workers, without relying on engine auto-detection. Useful when the engine reports no conversation-affinity capability at handler construction time (e.g. older TRT-LLM, disagg scenarios where the engine is not yet initialized).Details
backend_args.py: registers--conversation-affinity(negatable bool, envDYN_ENGINE_CONV_AFFINITY, defaultFalse) and addsconversation_affinity: booltoDynamoTrtllmConfig.llm_worker.py: passesconfig.conversation_affinityintoRequestHandlerConfig.handler_base.py: stores the override as_engine_conversation_affinity_overrideand ORs it with the engine-detected_conversation_affinityflag when deciding whether to useConversationParamsvs.SchedulingParams.Where should the reviewer start?
components/src/dynamo/trtllm/request_handlers/handler_base.py— the routing decision atconv_affinity = self._conversation_affinity or self._engine_conversation_affinity_overrideand theconv_kwargspath below it.components/src/dynamo/trtllm/backend_args.py— new flag registration.Related Issues
🚫 This PR is NOT linked to an issue: