[#16801][fix] Use layer-aware KV indices in Vanilla attention - #16803
[#16801][fix] Use layer-aware KV indices in Vanilla attention#16803mihai-chiorean wants to merge 5 commits into
Conversation
|
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 (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughVanilla attention now detects layer-specific KV cache layouts, defers cache-index lookup until execution, and passes the executing layer index for ordinary and MLA generation. Tests cover deferred lookup, eager fast paths, layer selection, and MLA behavior. ChangesVanilla cache index resolution
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 |
Vanilla attention metadata is prepared once and shared by every layer. Resolving block IDs during prepare therefore has no layer identity, so VSWA, hybrid-linear, and multi-pool managers can reject the lookup or return indices for the wrong page-index space. Defer block-ID resolution for layer-specific managers and query with the executing layer in ordinary and MLA generation paths. Preserve the existing prepared-once lookup for uniform single-pool managers to avoid adding overhead to that path. Signed-off-by: Mihai Chiorean <mihai.v.chiorean@gmail.com>
Signed-off-by: Mihai Chiorean <mihai.v.chiorean@gmail.com>
KVCacheManagerV2 can use different page-index scales for layers that share one physical pool. Treat that manager capability as layer-specific so Vanilla resolves cache indices with the executing layer instead of the pool default. Signed-off-by: Mihai Chiorean <mihai.v.chiorean@gmail.com>
Detect differing per-layer page-index scales once and cache the result in attention metadata. Uniform single-pool V2 managers keep the prepared-once lookup, while heterogeneous layouts still resolve indices with the executing layer. Signed-off-by: Mihai Chiorean <mihai.v.chiorean@gmail.com>
Signed-off-by: Mihai Chiorean <mihai.v.chiorean@gmail.com>
5412ca0 to
aaaf44a
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
I think Vanilla Attention @yihwang-nv is more familiar, could you please help to review? |
Summary
Fixes #16801.
Resolve Vanilla-attention KV block indices with the executing layer whenever
the cache layout is layer-specific.
Vanilla metadata is shared across layers. Resolving indices during metadata
preparation without
layer_idxcan select the wrong sliding window, physicalpool, or V2 page-index scale. The same problem affects ordinary and MLA
generation.
Implementation
heterogeneous-scale V2 managers.
layer_idx=self.layer_idxin ordinary and MLAgeneration.
Validation
Validated on DGX Spark / GB10 (SM121) with Gemma 3 1B, the PyTorch
VANILLAattention backend, KVCacheManager V1, a 661-token prompt, and 32 decoded tokens.
VSWA production path
max_attention_window=[512, 512, 512, 512, 512, 1024]is_vswa=TrueUniform single-pool control
max_attention_window=[1024]is_vswa=FalseThis confirms that layer-dependent layouts resolve indices with the executing
layer while uniform layouts retain the existing prepared-once fast path.
Additional validation:
tests/unittest/_torch/attention/test_vanilla_attention.py: 8 tests and3 subtests passed on SM121.
passed.
gap and potential uniform-layout overhead were addressed before submission.
Coverage includes VSWA, linear attention, multi-pool, heterogeneous and uniform
V2 scales, ordinary generation, and MLA generation.
Scope
No public API or kernel changes. Layer-invariant layouts retain their existing
prepared-once behavior.
PR Checklist
Dev Engineer Review
QA Engineer Review
Added unit tests for:
The tests are outside
tests/integration/test_lists/. No correspondingtest-db/orqa/entries were identified.Verdict: needs follow-up — CBTS or integration coverage is not documented for the new unit tests.