企业助手经常重复发送制度、工具定义和长篇资料。提示词缓存可能减少这些重复输入的计算与费用，但只看一个命中率，容易把账单折扣误认为服务容量提升。本文关注精确前缀的计算状态复用，提出一套同时检查效果、成本和权限边界的工程验收方法。文中数字均为构造算例，不代表壹典实测或任何厂商报价；技术资料核对日期为2026年10月11日。
一、先明确：缓存复用的是哪一段工作
提示词缓存与语义答案缓存解决不同问题。前者复用已处理前缀的中间状态，仍然针对本次输入生成答案；后者可能直接返回历史答案，需要另外判断问题等价性、答案时效性与访问权限。把两者放进同一个“缓存命中”指标，会掩盖完全不同的正确性风险。
vLLM的自动前缀缓存主要节省预填充阶段对共享前缀的处理，不直接减少后续逐个生成新词元的解码工作。[1] 因此，长资料配短回答通常比短问题配长报告更值得测试。即使首字明显提前，长回答的总完成时间也未必同比缩短；共享服务因负载下降而改善排队，则属于需要另测的间接收益。
验收应区分三个层次：应用日志发现了重复文本，属于复用机会；服务端报告读取缓存，属于实际命中；请求在目标负载下更快、更便宜且质量合格，才属于业务收益。三者不能相互替代。若同时启用KV缓存量化，应把量化精度与前缀复用拆成两个实验变量，可结合大模型低比特量化验收的方法分别建立基线。
二、把提示词当作有版本的前缀结构
以客服知识问答为例，可以先组织稳定的角色约束与工具定义，再放经授权的版本化资料，最后附上当前问题和必要的动态状态。若把每次变化的时间戳、请求编号放在最前面，后续大段相同资料也可能失去前缀复用机会。不过，信息次序会影响模型行为，重排后必须重新评估回答质量，不能只追求缓存长度。
vLLM的设计以父块哈希、本块词元和附加身份信息构建块标识，只缓存完整块；缓存块也会因分配需要而被淘汰。[2] 这意味着“前半篇看起来一样”并不是充分条件。验收时应固定模型、分词器、聊天模板、工具模式和资料版本，并记录实际序列化后的前缀指纹；多模态内容还要保留对应的媒体身份。
本文建议建立前缀清单：每段的维护者、版本、生效范围、允许共享的用户群和预期更新频率。公共规则与客户专属资料不能因为文字相同就自动合并权限范围。对会变化的业务数据，应先保证新鲜度，再考虑复用；把过期库存或旧审批规则固定在前缀里，即使命中率很高，也是失败的优化。
版本切换时保留旧版流量的结束条件，并测量新版本的冷启动窗口。频繁滚动发布、负载均衡变化和大量不同长前缀都可能使缓存反复重建。因而需要观察连续业务时段，而非只在同一进程里重复一个请求，得到一个漂亮但无法持续的数字。
三、把命中次数、词元覆盖率与计费分开
建议至少同时记录请求命中率H和词元读取覆盖率R：H为缓存读取量大于零的请求数除以总请求数；R为缓存读取词元总量除以总输入词元量。若十个请求都只复用很短的开头，H可以是100%，R仍然很低。汇总时必须先求和再相除，不能让一个短请求与一个长请求的覆盖率获得同样权重。
用量字段需要按接口解释。OpenAI文档展示了输入总量及其cached_tokens、cache_write_tokens明细；Claude则把cache_read_input_tokens、cache_creation_input_tokens与未缓存的input_tokens分别报告。[3][4] 不能把后一种接口的input_tokens误当全部输入，也不能在已有总量上再重复加明细。应保存原始用量和账单版本，再转换到统一内部口径。
托管API的读取量是厂商用量证据，并不让调用方直接观察GPU上每个块的物理复用。自建推理服务可以增加块命中、实际预填充词元和排队指标，但也应标明计数位置及分母。跨平台比较时，先统一“整段输入”“符合缓存条件的前缀”和“实际读取”的定义，才有资格讨论谁的命中率更高。
生产统计应按任务类型、前缀版本和租户分层，并分别保留成功、失败、重试及取消请求的成本。只计算最终成功请求的用量，会漏掉反复写入缓存和重试带来的费用。缓存键、原文与身份信息的日志也应遵守现有访问控制，避免为了可观测性额外复制敏感内容。
四、用四组负载检验首字延迟与长尾
第一组测冷缓存：在隔离的测试环境中使用全新的、已知不会复用的前缀，或采用部署确实支持的清理机制。记录如何确认冷态。不要在正式服务上随意清空共享缓存，也不要把“第一次由本测试脚本发送”直接当成全系统第一次出现。
第二组测稳定暖缓存：先完成一次有效预热，再重复相同前缀而更换末尾问题。第三组测真实混合流量：按生产中前缀出现频率、输入输出长度和到达间隔回放，包含一次性请求。第四组测失效恢复：更新资料版本、超过生存期，或在自建环境中引入容量压力，检查命中下降后的延迟与恢复过程。
客户端首字延迟可定义为请求发出至收到第一个非空正文片段；总延迟定义为收到完整响应的时间。流式元数据、心跳与空片段不应被当作正文。对有独立推理事件的接口，还要声明是否将其计入首字。服务端排队时间与预填充时间分别记录，避免把网络或网关波动归因于缓存。
对照组与缓存组应固定模型、采样参数、输入集合、输出限制和到达模式，并尽量交错测试以减少时间偏差。不要把空闲时的暖缓存结果与高峰时的无缓存结果直接相减。报告吞吐、错误率和P50、P95、P99延迟，同时给出各组请求数；样本少时，尤其不能把少数极端值包装成稳定的P99结论。
验收阈值应来自业务预算。例如一个有严格首字要求的交互助手，可以把暖态首字改善、混合流量长尾不退化、冷态仍满足超时限制列为三项独立条件。具体秒数需要根据场景实测制定。缓存带来的容量变化还应回到企业大模型服务容量验证中，用相同到达负载重新测量，而不是把单请求加速比例直接乘进并发承诺。
五、用包含写入成本的算例判断是否划算
以下只是便于核算的假设：公共前缀P为8000词元，每次动态后缀S为500词元；普通输入每千词元记为1个成本单位，缓存写入倍率w为1.4，读取倍率r为0.2。一次写入后，另九次请求完整复用前缀，均处于有效复用窗口。输出长度及价格保持相同，暂不计输出、网络和运维费用。
十次均不缓存时，输入成本为10×(8+0.5)=85。缓存时为8×1.4+9×8×0.2+10×0.5=30.6，输入部分减少64%。这里写入倍率是该部分词元的总价格倍率，不能再加一次普通输入费。若十次请求都隔得太久、每次重新写入，按同一假设成本为10×(8×1.4+0.5)=117，反而高于85。
在“一次写入，其余全部命中”的简化窗口里，只有后续命中次数大于(w−1)/(1−r)，前缀部分才比全部按普通输入计费便宜；该式假设0≤r<1，并忽略其他成本。现实中应按每次请求的实际读、写和未缓存词元结算，再加入输出与失败重试费用。对部分命中、不同生存期混用，不能继续套用这个简式。
不同模型和平台的最短可缓存长度、写入价格、保留时间及失效条件并不相同，Claude文档就区分了缓存写入与读取及不同生存期。[4] 采购比较应保存测试当天适用的接口和价目版本。自建服务则应核算显存占用、吞吐变化与运维成本，不能把API的折扣倍率当作自建GPU节省比例。
六、缓存共享范围必须服从权限边界
vLLM安全文档指出，共用进程并不提供完整租户隔离；cache_salt可以限定前缀复用范围，但本身不是隔离边界。[5] 因此，命中加速不应成为绕过权限校验的理由。请求进入推理服务前，仍需验证用户身份和资料访问权；需要强隔离的场景，应在部署层设计独立实例等边界。
工程上可以由可信网关依据已验证的租户身份注入不可预测的缓存盐，并覆盖客户端自带的同名参数，避免用户自行选择他人的共享范围。文档授权变化后，必须更新检索结果和业务访问控制；轮换缓存盐仅影响后续复用，并不等于已经删除所有既有副本，删除要求仍需单独落实。
可以在授权的测试环境中构造两个测试租户：输入相同但不允许共享的资料，验证缓存身份是否不同，越权请求是否在推理前被拒绝；随后验证同一许可范围内可以正常复用。延迟相近不能证明隔离有效，应结合网关配置、身份映射和服务端观测形成证据。托管API还应核对其当前合同和数据保留条件，不能照搬某个自建框架的边界。
七、上线交付的是一份可复核的缓存收益记录
本文建议交付六项证据：已版本化的前缀清单；覆盖冷、暖、混合和失效场景的请求集合；原始用量与账单对照；分层延迟和错误率；质量回归结果；共享边界及回退记录。它们分别回答能复用什么、实际复用了多少、付了多少钱、用户是否受益、答案是否仍可靠以及异常时如何恢复。
初次上线应保留可关闭缓存策略的回退路径；对平台默认开启且无法关闭的机制，至少能回退前缀重排、显式缓存配置和应用路由变更。观察版本更新后的命中、写入成本和长尾联动，设置基于业务预算的告警。出现费用增加但延迟未改善时，先查重复写入、命中窗口与负载分布，不要直接加长保留时间。
提示词缓存值得实施的证据，应是相同质量与权限约束下，每个有效业务请求的总成本下降，且目标负载下的服务体验达到要求。只有命中率，没有请求结构、成本分解和冷态表现，尚不足以支持容量采购或服务承诺。这也是壹典在技术分析中强调的验收思路：先建立可复核证据，再把优化收益计入方案。