vLLM prefix caching怎样减少重复提示词延迟

vLLM prefix caching 要减少重复提示词延迟，需要同时满足两个条件：引擎启用了 Automatic Prefix Caching（APC），后续请求又拥有与已有请求一致、仍可复用的输入前缀。把固定规则和共享文档稳定地放在前面，把每次变化的问题放在后面，通常比单纯打开开关更值得先做。它节省的是重复输入的预填充计算，不是直接重用上一份答案。

官方地址：https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/

设想一个设备手册问答服务：同一份手册被反复询问“怎样更换滤芯”“指示灯表示什么”。每次都把整份手册作为输入，用户往往关心回答开始出现之前的等待。下面围绕这类请求设计接入方式，不提供未经测量的加速倍数，示例也未在本文执行。

确认请求是否有可复用的共同前缀

先区分“内容相似”和“前缀一致”。两个问题主题相近，并不代表输入开头一致；同一份手册放在随机请求标识后面，也不等于形成很长的共同前缀。应检查最终送入模型的消息模板、角色顺序、固定文本以及文档内容，找到差异从哪里开始。

适合优先尝试的，是长文档被重复提问、稳定系统提示词服务大量请求，或者聊天历史逐轮追加的场景。若每次输入都不同，或者绝大部分时间用于生成很长的回答，APC能改善的部分就可能有限。先问“延迟主要花在哪里”，再判断是否值得围绕缓存调整请求组织。

以设备手册为例，可以为文档选择一个稳定版本，并保持同一版本的文本规范化方式一致。不要在请求前端反复改变章节排序、插入不同的页眉或附加随机空白。这里的建议是减少无意义的输入差异，不是为了命中而删掉用户问题或必要的业务信息。

把稳定内容放在真正的共同前缀里

一种清楚的组织方式是：固定回答规则、同一版手册、当次问题。若业务确实需要时间、工单号或追踪标识，优先判断它们是否必须进入模型上下文；仅用于日志关联的标识可以留在应用日志中。确实影响回答的信息必须保留，也不能为了缓存效果违反消息角色和指令层级。

# 固定部分在不同问题之间保持一致；示例只构造文本，不发起推理
rules = "依据下面的设备手册回答。资料没有说明时明确指出。\n"
manual = "设备手册正文：这里替换为应用持有的同一版完整手册。\n"
questions = ["怎样更换滤芯？", "指示灯闪烁表示什么？"]

# 将差异问题置于共同前缀之后，避免前端追踪标识打断前缀
prompts = [rules + manual + "\n用户问题：" + q for q in questions]

聊天接口还会把消息转换成模型使用的聊天模板。因此，只比较业务日志中一个文本字段可能不够。应把模板版本与分词器配置纳入接入记录，在模板升级后重新观察实际请求表现。不同模板生成的token序列可能不同，不能只看界面中展示的文字是否相同。

显式启用并固定模型配置

在线服务可使用引擎参数 --enable-prefix-caching 显式启用。下面的目录是部署者需要替换的模型目录，不是可直接下载的模型名称；硬件、依赖以及模型支持情况需符合自己的部署环境。

# 将模型目录替换为已经准备好且与环境兼容的模型
vllm serve /models/your-supported-model --enable-prefix-caching

离线接口可以在创建引擎时传入 enable_prefix_caching=True。如果已有服务配置显式设置过关闭，应在实际启动入口处统一配置，避免只改了一份没有被读取的文件。不同版本的默认行为不应靠旧文章推断，记录本次使用的版本及最终生效参数更便于比较。

第一次接入建议只改变缓存开关，先固定模型、并行设置、输入模板与输出长度。一次同时改变模型精度、并发、调度参数和缓存开关，即便响应变快，也很难说明收益来自哪里。示例命令只是配置表达，不意味着任何机器都能直接装载该模型。

分清KV复用与答案复用

APC缓存的是符合前缀条件的KV计算结果。后续问题仍然要参与推理，生成结果也仍由本次输入和生成参数决定。它与“按完整问题查一份已存好的最终回复”属于不同层次，应用不应把前缀命中当成回答已经完成。

官方设计采用基于哈希的缓存标识：当前块内容、此前块的关联信息以及必要的额外标识共同决定可复用对象。因此，同一段文本出现在不同前文后面，不应被当作一个与上下文无关的任意段落缓存。LoRA、多模态等输入也存在额外区分因素。

实际可复用范围还受缓存匹配粒度和模型结构影响，不保证文本中每一个共同字符都对应可跳过的计算。接入阶段先让稳定前缀自然变长，再根据对应版本和模型文档研究细粒度参数，不必先为一个短提示词设计复杂的块边界填充。

用冷暖对照观察首字延迟

为设备手册场景准备三组请求：共享同一手册但问题不同的一组、输入长度接近但开头不同的一组，以及第一次处理该前缀的请求。保持输出长度限制与并发条件一致，分别记录首个输出token到达时间、整体耗时和输出token数。

不要只拿第一次和第二次完整响应时间做结论。首次模型运行还可能包含其他预热成本，排队压力和输出长度也会改变总耗时。比较时重复采样并保持负载条件一致，注明数据来自冷缓存还是暖缓存。本文没有实际测量，因此不列出速度数字。

如果首字延迟改善明显、完整响应时间变化不大，先看输出长度及生成阶段占比。这与APC主要节省预填充工作的定位并不矛盾。若首字时间也没有改善，再从前缀是否一致、请求是否落到具有对应缓存的实例，以及缓存是否仍可用等方面分析。

处理命中不足与部署限制

常见的应用侧问题包括：每次在最前面加入新时间戳、对共享文档随机拼接段落、模板不一致，或在多实例间随机分散同一组重复请求。先消除这些结构差异，再讨论更复杂的缓存部署。路由优化应同时考虑负载均衡，不应为命中让单个实例长期过载。

缓存复用也不是永久存储承诺。容量竞争、服务重启及部署变化都可能让后续请求重新计算。系统设计应允许未命中时正常工作，把命中作为性能收益，而不是保证请求正确性的前提。

为什么一样的手册没有带来明显加速？

检查手册之前是否出现变化内容，再看最终模板与实际token前缀。同时区分首字等待与整段回答耗时，避免把长输出的生成成本归因于前缀没有复用。

可以直接用APC代替业务答案缓存吗？

不能按同一个接口语义使用。答案缓存处理完整回复的复用与失效，APC处理模型内部的重复前缀计算，两者需要各自的使用条件。

是否要修改所有提示词来追求命中？

优先稳定本来就相同的规则和材料。会改变语义、权限或回答质量的信息不应为命中而删改，缓存收益应服从业务正确性。

官方资料：https://docs.vllm.ai/en/latest/configuration/engine_args/；https://docs.vllm.ai/en/latest/design/prefix_caching/。