前缀缓存是什么
前缀缓存（automatic prefix caching）把多个请求里完全相同的 prompt 前缀算出的 KV 直接复用，跳过重复的 prefill 计算。系统提示、固定模板、few-shot 示例这类每次请求都一模一样的前缀，是收益的主要来源。vLLM 用 --enable-prefix-caching 开启，较新版本可能已默认开启，以所用版本文档为准。
基本信息
| 启用 | vLLM：--enable-prefix-caching（部分版本默认开启） |
|---|---|
| 匹配粒度 | 以 KV 块为单位做前缀匹配，不足一个块的前缀无法命中 |
| 收益场景 | 大批请求共享同一段长前缀 |
| 代价 | 缓存占用 KV 显存，与并发请求共享同一份预算 |
| 观察 | 前缀缓存命中率相关指标，名称以本机 /metrics 实际输出为准 |
典型使用场景
- 网关统一注入长系统提示：所有请求共享同一前缀，命中率高、收益最直接
- 固定 few-shot 示例的分类或抽取任务：示例文本不变，前缀天然可复用
- Agent 与工具调用场景：工具描述与协议说明写在系统提示里，每次请求都重复，缓存收益明显
- 多轮对话共享同一系统提示：每轮只增长尾部内容，头部可复用
- RAG 固定模板：检索内容前的那段指令格式保持不变
启用与观察
启用与观察
# 启动时开启（部分版本已默认开启，以版本文档为准）
vllm serve <模型路径> --enable-prefix-caching
# 观察命中情况：指标名随版本微调，先看实际输出再写表达式
curl -s http://127.0.0.1:8000/metrics | grep -i prefix_cache
# 对照压测：同一提示词并发 1 与并发 32 各跑一轮，比较 TTFT 与 prefill 耗时
# 结论要固定提示词、并发档位与数据集，否则差异无法归因什么会让命中率垮掉
| 写入前缀的内容 | 后果 | 规避办法 |
|---|---|---|
| 时间戳、请求 ID、随机数 | 每个请求前缀都不同，几乎无法命中 | 把这类内容移到前缀之后或尾部 |
| 每次重排顺序的 few-shot 示例 | 前缀逐字节不同即视为不匹配 | 固定示例顺序 |
| 前缀短于一个 KV 块 | 块粒度的匹配无从建立 | 把稳定内容集中放在提示开头 |
命中率高不等于端到端变快：缓存省下的是 prefill 部分，若瓶颈在排队或 decode，加速有限。看收益要同时对照 TTFT 与排队时长。
缓存会长期占用显存，挤占可用于并发的 KV 空间：上线后要一并观察 KV 水位，确认并发能力没有因此被压到低于预期。