perf(dflash): align replicated cache pages with target - #520
Conversation
Promote DCP-replicated sliding-window draft cache blocks to the common physical target block when the native draft block divides that alignment and the larger natural pages fit within the target-determined BlockPool stride. The scheduler LCM and allocated KV bytes remain unchanged while the bounded draft window consumes fewer shared block IDs. Incompatible block geometry and candidates that would enlarge the pool retain the backend-selected draft block. Focused and KV cache utility tests cover alignment, pool-growth rejection, and incompatible backend geometry. Assisted-by: OpenAI Codex <codex@openai.com>
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
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 |
|
Qualified runtime artifact: voipmonitor/vllm:glm53-flash-nvfp4-dflash2-mxfp8-dcp4-pagealign-vllmbfd30c0d-b12xd56c1163-cu133-torch213-20260829-r2, manifest digest sha256:9a0ce5badb50ac93647bf517573ac5578dee0dc8beccd58e699f44767b14495f, image ID sha256:2897d7a659453f256af37c26fa8aa933885af7cd28c8bda25c85912f8801c94c. The image source-lock label is 7d92e36e7e3d22fa4632f7b91bfdc0612a7ca267c7690d062f1c8cebe0aec26b and resolves integration tree 559049e2e214e3091d08138dab7ffe95cb10fd11. A production-style TP4/DCP4 launch on physical GPUs 4,5,6,7 with automatic 0.95 memory budgeting reported 15.87 GiB available for KV and 7,900,591 group-aware engine KV tokens (7.53 concurrent 1,048,576-token requests). Logs confirmed the 2304-token draft alignment, effective cache-group CP sizes (4,4,4,4,4,1), B12X PCIe all-reduce, B12X target kernels, B12X draft MXFP8 GEMM, FlashAttention 2 draft attention, and target plus DFlash decode graph capture through concurrency 16. A post-start OpenAI chat-completions smoke request completed successfully. |
|
Local pre-commit validation completed for both changed files after the source-qualified image run. All applicable hooks passed, including ruff check, ruff format, typos, Python 3.10 mypy, SPDX headers, lazy-import validation, forbidden-import validation, torch.cuda API validation, configuration-field validation, and the repository suggestion gate. The GitHub pre-run-check remains queued because no runner has accepted the job; it is not reporting a source failure. |
|
@coderabbitai review |
|
Status
Qualified on four RTX PRO 6000 Blackwell GPUs with TP4 and DCP4. The change is stacked on the replicated/sharded cache-group isolation in #519; #519 is stacked on the DFlash DCP implementation in #513.
Resulting behavior
DCP-replicated sliding-window draft cache groups retain the block selected by their attention backend while model KV specs are constructed. During mixed target/draft cache grouping, the planner promotes a smaller draft block to the greatest common physical block size of the sharded target groups only when both invariants hold:
Incompatible geometry and candidates that would enlarge the pool preserve the backend-selected draft block. No user-facing configuration flag or model-specific block constant is added. Because the promoted block divides every sharded target block before DCP scaling, scheduler LCM does not increase.
Compatibility impact
The optimization applies only when one cache specification contains both DCP-sharded groups and DCP-replicated sliding-window groups. DCP1, non-windowed replicated attention, caches without mixed replication modes, and memory-costly alignments retain their existing geometry.
Validation
Source qualification used PR commit
fd47007a6adc95f1a947d80dc2fd50745e22bdccin integration commitbfd30c0db01846a1de2e6a47d33aac3fb970b759(tree559049e2e214e3091d08138dab7ffe95cb10fd11) over the source-qualified GLM-5.3 stack. B12X wasd56c1163b6e019d828ed24f135c2efd05fdca6ea.Models:
local-inference-lab/GLM-5.3-Flash-NVFP4@520de24eabf507659eaef7c70f14fd584527facclocal-inference-lab/GLM-5.3-Flash-DFlash2-MXFP8@b6d33aa93fc1ac5b23a88251a1c0ce0bfe2ad17cRuntime configuration:
The GLM GDN backend resolves
FULLtoFULL_DECODE_ONLY; target and DFlash decode graphs were captured through concurrency 16.At an identical 12 GiB KV budget and 906 physical blocks:
Three 30-second sustained decode runs:
Raw output throughput is acceptance-dependent. The 2304 runs averaged 139.7/783.0 tok/s at accepted lengths 2.252/2.382 for CC1/CC16; normalized steps/s is the kernel/scheduler comparison signal.
Three 32k standalone prefill captures with 30-second sampling windows measured 10,637, 10,100, and 10,708 prompt tok/s (mean 10,482). The source-qualified 1152 runtime measured 10,529 prompt tok/s under the same 32k methodology.
A 25,210-token prompt followed by 3,072 generated tokens crossed both cache geometries. The warmed 2304 runtime reproduced the 1152 output SHA-256
acf8a33a8123fa87a857b83dcb089deb45f11d69af24010765ed183a92758637. One first request after an empty JIT cache produced a different long-horizon continuation, so the hash is evidence for warmed-path parity rather than a cross-cold-start determinism guarantee.Tests and static checks:
96 passed:tests/v1/core/test_kv_cache_utils.pyplustests/v1/spec_decode/test_dflash_replicated_dcp.pyruff check: passedruff format --check: passedReview requirement
OpenAI Codex assisted with implementation, tests, benchmarking, and pull-request text. Every changed line requires human review before merge.