[None][perf] Preserve default V2 KV cache pool sizing#16783
Conversation
|
/bot run |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (6)
WalkthroughThe PR makes KV-cache warmup configuration conditional on an explicitly provided average sequence length, preserves DeepSeek-V4 fallback behavior, and adds Gemma 4 NVFP4 B200 performance-sanity coverage for pre-merge and post-merge CI runs. ChangesKV cache typical sequence handling
B200 performance-sanity coverage
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@jenkins/L0_Test.groovy`:
- Around line 4896-4898: Update the perfMode predicate near the stage
configuration logic to recognize stage keys containing "-PerfSanity-" in
addition to "-Perf-". Ensure both DGX_B200-PyTorch-PerfSanity-1 and
DGX_B200-PyTorch-PerfSanity-Post-Merge-1 receive performance mode and run with
--perf.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 591c9744-f352-4e46-a3fd-399cb1acaf56
📒 Files selected for processing (8)
jenkins/L0_Test.groovytensorrt_llm/_torch/attention_backend/sparse/deepseek_v4/cache_manager.pytensorrt_llm/_torch/pyexecutor/kv_cache_manager_v2.pytests/integration/defs/perf/_model_paths.pytests/integration/test_lists/test-db/l0_b200_perf_sanity.ymltests/scripts/perf-sanity/aggregated/gemma4_26b_a4b_nvfp4_blackwell.yamltests/unittest/_torch/attention/sparse/deepseek_v4/test_deepseek_v4_cache_manager.pytests/unittest/_torch/executor/test_kv_cache_manager_v2.py
|
PR_Github #61222 [ run ] triggered by Bot. Commit: |
|
/bot run |
|
PR_Github #61224 [ run ] triggered by Bot. Commit: |
|
PR_Github/16783-0b93b6f #61222 was force-killed by a newer pipeline run. |
|
PR_Github #61224 [ run ] completed with state
|
chzblych
left a comment
There was a problem hiding this comment.
Approved for the CI changes.
* Why? Using `max_seq_len` as the default typical sequence length over- allocates Gemma4's full-attention pool and exhausts its SWA pool. This prevents CUDA graph padding from allocating dummy requests and forces eager decode, leading to hugely degraded performance. * What? Only derive generic warmup constraints from an explicitly configured `avg_seq_len`, preserving allocator-derived pool sizing by default. Keep DeepSeek-V4's max-length fallback in its specialized cache manager. This restores the behavior for Gemma4 prior to `697738c1f6` introducing the new sizing logic for DeepSeek-V4. Signed-off-by: William Zhang <133824995+2ez4bz@users.noreply.github.com>
Signed-off-by: William Zhang <133824995+2ez4bz@users.noreply.github.com>
0b93b6f to
291449c
Compare
|
/bot run |
|
PR_Github #61341 [ run ] triggered by Bot. Commit: |
|
PR_Github #61341 [ run ] completed with state
|
Dev Engineer Review
KVCacheManagerV2._build_base_configso allocator fallback remains the default:typical_stepand warmupconstraintsare only constructed whenkv_cache_config.avg_seq_lenis explicitly set (i.e.,avg_seq_lengates the warmup constraint path). Theavg_seq_len > max_seq_lenvalidation is now conditional onavg_seq_lenbeing provided.DeepseekV4CacheManager._get_typical_seq_len(...)override to preserve DeepSeek-V4’s prior behavior by usingkv_cache_config.avg_seq_lenwhen set, otherwise falling back toself.max_seq_len.tests/scripts/perf-sanity/aggregated/gemma4_26b_a4b_nvfp4_blackwell.yaml.gemma_4_26b_a4b_nvfp4intests/integration/defs/perf/_model_paths.py.jenkins/L0_Test.groovy:DGX_B200-PyTorch-PerfSanity-1(pre-merge)DGX_B200-PyTorch-PerfSanity-Post-Merge-1(post-merge)l0_b200_perf_sanityonauto:dgx-b200-flexwithgpuCount=1.QA Engineer Review
Test files changed
tests/integration/test_lists/test-db/l0_b200_perf_sanity.ymltest_e2e[aggr_upload-gemma4_26b_a4b_nvfp4_blackwell-gemma4_26b_a4b_nvfp4_tp1_1k1k]under:stage: pre_mergestage: post_merge*b200*,ubuntu*,x86_64, backendpytorch, orchestratormpi,TIMEOUT (60)).Test code changed (unit tests)
tests/unittest/_torch/executor/test_kv_cache_manager_v2.pytest_default_uses_allocator_fallbacktest_avg_seq_len_builds_warmup_constraintstest_extra_tokens_are_in_context_capacity(now usesKvCacheConfig(avg_seq_len=264)explicitly)test_builds_warmup_constraints→test_default_uses_allocator_fallback)tests/unittest/_torch/attention/sparse/deepseek_v4/test_deepseek_v4_cache_manager.pytest_typical_seq_len_preserves_deepseek_v4_fallbackCoverage linkage to integration/test-db
tests/integration/test_lists/test-db/; the end-to-end Gemma4 regression is exercised vial0_b200_perf_sanity.yml.Verdict: needs follow-up (CBTS coverage availability not provided in the gathered context).
Description
Using
max_seq_lenas the default typical sequence length over-allocates Gemma4's full-attention pool and exhausts its SWA pool.
This prevents CUDA graph padding from allocating dummy requests
and forces eager decode, leading to hugely degraded performance.
Only derive generic warmup constraints from an explicitly configured
avg_seq_len, preserving allocator-derived pool sizing by default.Keep DeepSeek-V4's max-length fallback in its specialized cache manager.
This restores the behavior for Gemma4 prior to
697738c1f6introducingthe new sizing logic for DeepSeek-V4, and adds an E2E perf regression test
for it.
Test Coverage
PR 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)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.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
To see a list of available CI bot commands, please comment
/bot help.