docs: correct TRT-LLM FPM availability and KV-transfer success metric side - #9882
Conversation
… side trtllm-observability.md said `trtllm_kv_transfer_success_total` is recorded on the prefill side; the 1.2.0 TRT-LLM implementation records it on the decode worker, in lock-step with the sibling KV-transfer latency/bytes/speed histogram counts. planner/README.md and kubernetes/model-deployment-guide.md said vLLM is the only backend with ForwardPassMetrics. TRT-LLM has supported FPM for non-attention-DP workers since the FpmDirectPublisher landed; SGLang has the Dynamo-side pipeline wired but the upstream SGLang FPM module is not in the 1.2.0 SGLang runtime image. Replaced the "vLLM-only" claims with a per-backend support matrix. Signed-off-by: Dan Gil <dagil@nvidia.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughUpdated documentation across three files to clarify backend support for observability features: refined TensorRT-LLM's KV transfer metric description to specify decode-worker recording behavior, and expanded guidance on ForwardPassMetrics availability across vLLM, TensorRT-LLM, and SGLang backends with specific gating conditions and runtime prerequisites. ChangesBackend Capability and Observability Documentation Clarifications
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
… side (ai-dynamo#9882) Signed-off-by: Dan Gil <dagil@nvidia.com> Signed-off-by: Chi Xing <cxing@nvidia.com>
Overview
Three docs were inconsistent with the 1.2.0 TRT-LLM implementation:
docs/backends/trtllm/trtllm-observability.md:159saidtrtllm_kv_transfer_success_totalis recorded on the prefill side. The 1.2.0 implementation records it on the decode worker, in lock-step with the sibling KV-transfer latency/bytes/speed histogram counts. Verified againstcomponents/src/dynamo/trtllm/request_handlers/handler_base.pyandcomponents/src/dynamo/trtllm/metrics.py.docs/components/planner/README.md:127said FPM is "currently only available for vllm". TRT-LLM has supported FPM for non-attention-DP workers sinceFpmDirectPublisherlanded (PRs feat(trtllm): publish ForwardPassMetrics via FpmDirectPublisher (non-attention-DP) #8356 and perf(trtllm): publisher off request-loop + batched KV walk #8892); SGLang has the Dynamo-side pipeline wired but the upstream SGLang FPM module is not in the 1.2.0 runtime image. Replaced with a per-backend support matrix.docs/kubernetes/model-deployment-guide.md:316carried the same vLLM-only claim in the "Recommended Backend" table. Updated to match the planner README matrix.Changes
docs/backends/trtllm/trtllm-observability.md— correct counter sidedocs/components/planner/README.md— per-backend FPM support matrixdocs/kubernetes/model-deployment-guide.md— update FPM rowNo code or example changes. Pure documentation correctness fix.
Test plan
planner/README.mdtosglang-observability.md#forward-pass-metrics-fpmresolvesFixes NVBug 6204453 / DYN-3091.
Summary by CodeRabbit