vLLM Prefix Caching 适合重复长前缀请求吗

如果服务反复处理同一份长系统提示、长文档或同一会话历史，vLLM Prefix Caching 通常值得试；如果每个请求的前缀都不同，或者回答本身很长，收益就可能很小。它复用的是已经计算好的 KV cache，主要缩短 prefill（输入预填充）阶段，不会让 decode（逐 token 生成）变快。

判断标准可以压缩成一句话：重复前缀越长、命中越稳定、输入处理占比越高，越适合开启；输出很长、前缀经常改动或缓存容量不足时，不要只看“开启成功”就认为整体吞吐一定提升。

先看请求形状：重复的是哪一段

最适合 APC（Automatic Prefix Caching）的场景是“固定内容在前，变化问题在后”。例如每次都带同一份 8 万 token 的产品手册，只把用户问题换成“如何配置超时”或“怎样排查连接池”。多轮对话也有类似结构：旧历史在前，新一轮消息追加在后。

反过来，如果模板在每次请求开头插入随机追踪值、当前时间，或者把用户问题放进系统提示中，token 序列从前面就发生变化，后续块自然难以命中。这里不要只比较字符串看起来是否相似，真正参与匹配的是分词后的前缀与缓存块边界。

开启后，先把命中条件做稳定

离线引擎可以显式设置 enable_prefix_caching=True；使用服务命令时也可以写成下面这样。命令只表达配置示意，模型名和显存参数要按自己的部署调整。

# 显式开启前缀缓存；模型和端口按部署环境替换
vllm serve  \
  --enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

应用侧要固定消息顺序、系统提示版本、文档拼接规则和 tokenizer 配置。不要为了追踪请求而把 request-id 放进共享前缀；可以把它放在日志或变化段。vLLM 以缓存块和前缀链计算哈希，只有完整可复用的部分才有意义，因此“前 90% 一样”不等于每次都能按 90% 命中。

如果服务是多租户的，命中还要和信任边界一起设计。vLLM 文档提供可选的 cache_salt，相同 salt 的请求才共享首个缓存块；租户隔离时让每个信任组使用稳定且不可猜的 salt，公共知识库场景则可以按明确的共享范围复用。

怎么测：把 prefill 和 decode 分开

至少准备两组请求：第一组使用一份固定长前缀连续提问，第二组每次修改前缀中的一个关键 token。两组都固定模型、采样参数和输出上限。观察 TTFT、输入 token 数、输出 token 数以及整体延迟；如果命中有效，通常先看到 TTFT 或输入处理时间下降，而输出 token 很多时，总耗时差距会被 decode 抵消。

下面的请求体是结构示意，重点是保持前两条消息一致，把问题放到末尾；严格 JSON 不加入注释，字段含义用文字说明。

{
  "messages": [
    {"role": "system", "content": "固定的系统规则与版本化文档"},
    {"role": "user", "content": "固定的长文档内容"},
    {"role": "user", "content": "本次变化的问题"}
  ],
  "cache_salt": "同一信任组使用的稳定值"
}

最后再看容量：前缀缓存占用 KV cache 空间，若并发请求把空间挤满，旧块会被淘汰，命中率就会下降。生产上线前用真实的前缀长度分布和并发量压测，而不是用一条短 prompt 得出结论。

常见问题

开启 Prefix Caching 会缓存模型回答吗？不会。它缓存输入处理阶段可复用的 KV 状态，回答仍会按当前请求继续生成。

前缀相同但 TTFT 没降，先查什么？先查分词后是否真的一致、共享部分是否跨过可缓存块边界，再查 KV cache 容量和淘汰情况；不要先盲目调大输出参数。

什么时候可以不启用？请求前缀短且变化频繁、输出阶段明显占主导，或缓存空间已经导致频繁淘汰时，先保持默认路径并用对照数据验证更稳妥。