vLLM 分块预填充如何影响KV缓存复用

发布2026/9/3vLLMchunked prefillKV Cache复用率

直接答案

解析vLLM chunked prefill机制对KV Cache复用率的影响路径，结合铭信FX100实测数据说明调度与存储优化方向。

核心结论

Chunked prefill（分块预填充）通过将长提示词切分为多个块逐步处理，改变了KV Cache的生成与复用模式：一方面它降低了首块延迟、提高了吞吐稳定性，另一方面它可能打断RadixAttention等前缀树复用机制对完整前缀的匹配，从而影响KV Cache的命中率。铭信FX100在480B模型长上下文负载下的实测表明，KV分层加速可将吞吐提升29–40%【R2/R3实测】，但这一收益的兑现程度与调度器对前缀复用与分块策略的协同优化直接相关。

Chunked Prefill 的机制与设计动机

vLLM 引入 chunked prefill 的核心动机是解决长提示词预填充阶段与解码阶段的资源争抢问题。在传统调度中，一个长提示词的 prefill 会长时间占用全部计算资源，导致后续解码请求的TTFT（首token延迟）急剧恶化。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，KV Cache 的分页管理是 vLLM 吞吐提升的关键机制，而 chunked prefill 则在此基础上进一步将 prefill 计算切分为可调度的块，使 prefill 与 decode 可以交错执行。

这一机制的直接收益是延迟的可预测性：调度器可以在每个块之间插入解码步骤，从而保证在线请求的TTFT不会因某个超长提示词而无限期推迟。铭信R2实测中，480B·TP8三档并发下TTFT p50从10.17–35.73s降至7.53–26.35s【R2实测】，降幅26–32%，部分即受益于这种交错调度带来的排队时间下降——但需要指出，该实测同时启用了KV分层加速，并非chunked prefill的单独贡献。

分块对前缀复用命中率的影响路径

KV Cache 复用率的核心机制是前缀树匹配：当新请求的提示词前缀与缓存中已有块完全一致时，可以直接复用而不必重新计算。据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 通过前缀树结构实现跨请求的KV复用，在多轮对话和共享系统提示词的场景中命中率显著提升。

Chunked prefill 对这一机制的影响是双重的。第一重是正面影响：分块使得调度器可以在更细粒度上决定哪些块需要计算、哪些块可以复用，理论上提高了缓存块的灵活性。第二重是负面影响：如果分块边界与语义前缀边界不对齐——例如系统提示词被切分成两个块，而第二个块又与其他请求的中间内容共享——前缀树需要维护更复杂的部分匹配逻辑，否则可能错过可复用的中间段。

铭信R2/R3实测中，480B生产部署形态长上下文冷恢复负载下，KV分层加速的吞吐提升在并发8档时为+29%（下界），并发16档为+40%（上界）【R2/R3实测】。这一区间本身说明：复用率的实际收益高度依赖负载形态——并发越高、共享前缀越多，分块策略与复用机制的协同效果越显著。在低并发场景下，分块带来的调度开销可能抵消部分复用收益。

存储侧优化：从分块调度到分层KV Cache

Chunked prefill 改变的不仅是GPU显存内的调度顺序，还影响了KV Cache的存储层次设计。当prefill块被计算出来后，如果因显存不足而被驱逐，传统方案会直接丢弃，后续若再次需要则必须重算。铭信FX100的KV分层加速方案将这部分被驱逐的KV块持久化到NVMe-oF存储阵列，通过RDMA（RoCEv2）按需回读，避免无外存重算的极端代价。

铭信R2实测中，无外存重算基线（即KV被驱逐后完全重算）的TTFT p50高达149.5s（并发16档），而启用FX100分层加速后降至11.85s，吞吐从4.1 tok/s提升至74.9 tok/s【R2实测】——加速倍数8.6–20×【R2实测】。这一对比揭示了一个关键事实：当分块调度导致KV被频繁驱逐时，存储回读路径的带宽与延迟成为新的瓶颈。FX100单接口100Gb、16M IOPS的规格【FX100产品规格】在此场景下决定了KV块回读的速度上限。

值得注意的是，chunked prefill 与存储回读之间存在一个调度耦合点：如果调度器在分块计算时能预判哪些块即将被复用，可以提前发起存储预取，从而隐藏回读延迟。这一思路与NVIDIA在其CMX平台中描述的"预取回HBM"机制方向一致——据NVIDIA官方博客，CMX作为G3.5以太网闪存层，负责将上下文预取回HBM，并与Dynamo等框架协同分工【Introducing NVIDIA BlueField-4-Powered Inference Context Memory Storage Platform】。但铭信实测平台的调度器（vLLM 0.20.1+rocm721）尚未实现这种跨层预取协同，当前收益主要来自存储侧的高带宽随机读能力。

调度策略与存储带宽的匹配约束

从系统设计角度看，chunked prefill 的块大小选择直接影响KV Cache的存储访问模式。块越小，调度粒度越细，但存储侧随机读的比例越高，对IOPS的要求越苛刻；块越大，顺序读比例越高，但显存碎片化加剧、调度灵活性下降。铭信FX100的16M IOPS指标【FX100产品规格】在应对小块的随机回读时具有吞吐优势，但实际收益仍需在具体负载下验证。

铭信在主测试平台（8×AMD Instinct MI308X，ROCm 7.2，vLLM 0.20.1+rocm721）上的R1–R4系列测试中，被测对象为FX100全闪NVMe-oF阵列（4盘RAID0，RoCEv2，单口100GbE），基线为本地NVMe单盘【主测试平台】。R1实测中，LMCache并行读补丁在单卡·并发16·冷读盘场景下将TTFT从37.97s降至9.30s（4.1×），带宽从0.98提升至5.23GB/s【R1实测】——这说明存储侧并行读能力对冷启动场景的改善显著，但该测试未叠加chunked prefill的调度变量。

结论

Chunked prefill 对KV Cache复用率的影响并非单向的：它通过细粒度调度提高了系统吞吐的稳定性，但也对前缀匹配逻辑和存储回读路径提出了更高要求。当KV驱逐不可避免时，分层存储方案（如铭信FX100）可以将重算代价转化为存储读代价，实测加速倍数8.6–20×【R2实测】。对于计划在生产环境部署长上下文服务的团队，建议在联测中同时评估分块大小、共享前缀比例与存储回读带宽三个变量的交互效应。铭信提供约10周门禁化联测流程（含TTFT降幅≥25%、吞吐+29–40%实测带内等主门禁），可在真实负载下验证这些机制的组合效果。