Repository navigation
[PD] Bound cached-prefix DCP transfers by pack capacity - #40376
Conversation
|
/rerun-test test/registered/disaggregation/test_kimi_linear_pd_dcp4.py |
|
Results for 🚀 |
ShangmingCai
left a comment
There was a problem hiding this comment.
Looks good. Nice fix.
|
/tag-and-rerun-ci |
|
/rerun-group disaggregagtion |
|
⛔ Known groups: |
|
/rerun-test disaggregation |
|
Results for ⛔
Please provide the full path, e.g. |
|
/rerun-group disaggregation |
|
Results for 🚀 🚀 🚀 🚀 🚀 🚀 🚀 🚀 |
Motivation
A prefill radix hit can leave very little compute while the decode worker still needs a long KV prefix. DCP pack buffers introduced in #35762 are sized from the prefill compute-chunk bound, but this cached-prefix send can be much larger. It then falls back to per-token RDMA and loses most of the packing benefit.
Split these sends to fit the existing allocation. This extends the scheduler grid-splitting mechanism from #30545 to DCP packing, where it was previously bypassed unless hetero-TP staging was enabled.
Modifications
No new flags. The existing allocation formula is retained; on the measured configuration it remains 4 × 31.5 MiB per prefill rank.
Accuracy Tests
GPU and performance measurements used eight B200s with
lmsysorg/sglang:dev, base993d1fccbaafe3e79d91567d2fc1d665cc94fa50, and candidate55d10370c7. The latest peer-scoping and test changes were validated with the CPU suite and mutation checks below; the GPU matrix was not rerun.Speed Tests and Profiling
Kimi Linear 48B-A3B Instruct on 8 × B200, NIXL; prefill TP4 on GPUs 0–3, decode TP4 on GPUs 4–7. DCP condition uses decode EP4/DCP4; controls use EP1/DCP1 and EP4/DCP1. FP8 KV, BF16 weights, 64-token pages, 8192-token prefill chunks, tokenspeed_mla, prefill graphs disabled, decode graph max batch 32, max running requests 32. Decode radix caching is disabled in every performance condition.
Warm shapes, flush both worker caches, warm the common prefix, then measure unique suffixes with OSL=1. C1: 12 requests; C8: 32 requests. Arithmetic means of 5 candidate repeats and 2 repeats per control. Each cell is requests/s / mean TTFT (ms).
Zero per-token fallback warnings across all candidate runs. Cached-prefix C8 throughput improves about 10.9× / 16.6× over main and reaches 95.0% / 95.6% of TP4 → TP4. This is near parity on this proxy, not an exact-parity or K3/DCP8 claim. Cold C1 varied substantially between runs, so its small differences should not be treated as a reliable speedup or regression.
The allocation-only change from #40336 was also tested. It increases headroom, but these prefixes with C=8192/D=4 still exceed it: C8 remained at 1.42 / 0.70 requests/s with fallback. This does not contradict its reported improvement for a prefix that fits the larger allocation; bounded sends remove the prompt-length threshold.
A separate instrumented run measured roughly 0.25 ms per gather for index upload, stream setup, helper/launch, and synchronization, excluding initial JIT outliers. Preparing/enqueueing an 11-segment send averaged about 1 ms. Instrumented client timings are excluded from the table.
Reproduction
Start a TP4 prefill worker and the desired TP4 decode configuration behind the PD router. Common worker flags used here:
Prefill:
--disaggregation-mode prefill --port 30001 --disaggregation-bootstrap-port 8998 --nccl-port 31001. Decode:--disaggregation-mode decode --port 30002 --base-gpu-id 4 --nccl-port 31002 --ep-size 4 --dcp-size 4. For the controls, use decode EP1/DCP1 or EP4/DCP1.The client preserves every response, cache-hit count and TTFT. Change prefix to 163840 for the longer-prefix case, or prefix=0/unique=32768 for cold prefill. Set concurrency=1/requests=12 for C1.
GPU correctness: run
test/registered/disaggregation/test_kimi_linear_pd_dcp4.pywithSGLANG_TEST_PD_LONG_CONTEXT_TOKENS=65536andSGLANG_TEST_PD_DISAGG_BACKEND=nixlormooncake.Checklist
CI States
Latest PR Test (Base): ⏳ Run #35517946934
Latest PR Test (Extra): ❌ Run #35517946812
Latest PR Test (AMD ROCm 10): ⏳ Run #35517946956