一、Token命中率到底是什么1.1 从KV Cache说起LLM以自回归方式生成文本每生成一个新Token都需要“回头看”前面所有Token的Key和Value张量来计算注意力。如果每次生成都重新计算全部历史Token的K/V计算量会随序列长度线性增长推理将变得极其昂贵。KV Cache就是为了解决这个问题模型在Prefill阶段计算完每个Token的K/V后把它们存起来后续Decode阶段直接复用不再重算。可以把KV Cache理解成模型推理过程中的“草稿纸”——之前算过的中间结果下次直接翻出来用。1.2 从KV Cache到Prefix CachingKV Cache解决的是单次请求内部的重复计算问题。而现实场景中大量请求之间共享相同的前缀——比如同一个System Prompt、同一套工具定义、同一段对话历史。Prefix Caching前缀缓存就是把跨请求的KV Cache也复用起来如果新请求的前缀和之前某个请求完全一致系统直接加载已缓存的KV张量跳过整个Prefill前向计算。Token命中率衡量的就是这种“前缀复用”的覆盖程度。1.3 一句话定义Token命中率 本轮请求中从缓存读取的Token数 / 总输入Token数。二、命中率为什么能省时间、省钱2.1 跳过Prefill直接生成LLM推理分两个阶段Prefill处理全部输入Token计算KV和Decode逐Token生成输出。Prefill是延迟的主要来源因为要跑完整个Transformer前向传播。命中缓存意味着这部分Token的Prefill被完全跳过——没有矩阵乘法、没有注意力计算、没有显存带宽消耗。KV张量已经在GPU显存里等着被读取。OpenAI官方数据Prompt Caching可以将首Token延迟TTFT降低最高80%输入Token成本降低最高90%。2.2 数字直觉假设一个请求有2500个输入Token无缓存Prefill全部2500个TokenTTFT ≈ prefill(2500)2000个Token命中缓存Prefill仅需处理500个TokenTTFT ≈ prefill(500)命中率80%TTFT降低80%。这不是近似因为Prefill计算量随未命中Token数线性缩放。不同工作负载的实测数据场景典型命中率TTFT降低聊天机器人同一会话85-95%85-95%RAG固定检索模板70-85%70-85%Agent工具调用80-95%80-95%2.3 成本对比主流提供商的缓存定价策略提供商缓存读取价格缓存写入价格TTLOpenAI标准输入的10%标准输入的125%约5-10分钟Anthropic标准输入的10%标准输入的125%5分钟 / 1小时可选缓存Token的价格通常是未缓存Token的1/10。Anthropic的定价逻辑很直接缓存Token的服务成本低90%所以收费也低90%。三、命中率怎么算3.1 正确公式DeepSeek Harness官方给出的计算公式cache hit rate cacheRead / (input cacheRead cacheWrite) × 100%其中input本轮新增的、未命中缓存的TokencacheRead从缓存读取的Token即命中部分cacheWrite写入缓存的Token首次计算并存储关键分母必须包含cacheWrite。如果只用cacheRead / (input cacheRead)首次请求input0, cacheRead0, cacheWrite全部会得到0/0而后续请求会高估命中率。3.2 一个例子一轮请求input200cacheRead800cacheWrite0命中率 800 / (200 800 0) 80%3.3 两种统计口径vLLM用户常遇到一个困惑服务端日志显示的命中率如45.7%和单个请求usage字段算出的如86.7%差距很大。原因是服务端命中率最近N次prefix cache查询的平均值反映一段时间内所有请求的整体情况请求级命中率cached_tokens / prompt_tokens只代表当前这一个请求排查问题时建议同时看两个口径服务端看趋势请求级看单次异常。四、什么在破坏命中率缓存命中要求前缀的精确匹配——从第一个Token开始字节和顺序完全一致。任何位置的变化都会让该位置之后的所有内容失效。4.1 前缀失效的常见原因破坏因素为什么致命System Prompt中插入动态内容时间戳、随机数每轮前缀都变后续全部失效工具Schema顺序或描述微调工具定义在Prompt前部改动使后面全部失效历史消息重新渲染空格、标记、序列化格式即使语义相同字节不同就匹配失败切换模型或effort level每个模型/effort level有独立缓存相同内容放在不同消息角色改变Token边界前缀不再匹配一个被反复提及的典型反面案例某AI编程工具请求中33K Token全是系统提示等前缀内容实际问题只占很小部分但因前缀频繁变动命中率极低Token开销巨大。4.2 缓存TTL时间窗口缓存不是永久的。OpenAI的缓存约在5-10分钟无访问后失效。Anthropic提供5分钟和1小时两种TTL选项。对于Agent工作负载每轮间隔可能达数十秒到数分钟TTL是命中率的关键约束。一项研究显示将TTL从1分钟提高到1小时可达命中率从85.4%跃升至98.6%。4.3 缓存容量与淘汰GPU显存有限KV Cache占用量随Token数线性增长。一个100K Token的KV Cache在MiniMax-M2.5上约占12 GB HBM。并发用户一多缓存很快被占满淘汰策略LRU等开始工作旧的缓存被清出。当多轮对话和单轮请求混合时长时间会话会累积高访问计数导致已结束会话的过期KV状态残留在缓存中挤占真正需要复用的空间。五、怎么把命中率打上去5.1 核心原则静态在前动态在后缓存基于前缀匹配所以Prompt的排列顺序至关重要[系统提示 / 核心指令] ← 最稳定变化最少 [工具定义 / Schema] ← 较稳定改一次影响大 [项目上下文 / 知识库] ← 会话级稳定 [对话历史] ← 每轮追加 [最新用户消息] ← 每轮变化Anthropic的实践总结很精辟用messages更新内容而不是改system prompt。把Plan Mode的指示、skill加载等都作为对话消息追加缓存的前缀就保持完整。5.2 最小可缓存长度不是所有Prompt都能触发缓存OpenAI共享前缀至少1024个Token才能触发缓存命中以128 Token为增量Gemini 2.5 Flash最小1024 Token2.5 Pro2048 Token短Prompt的缓存意义有限优化重点应放在长前缀的复用上。5.3 自动压缩的缓存友好设计长对话触发压缩如Claude Code的/compact时如果摘要器用完全不同的System Prompt整段历史会被重新处理。DeepSeek Harness的做法值得借鉴把摘要指令从新的System Prompt移到消息末尾复现最近一次已路由请求的System、Tools和历史消息再追加一条尾部user指令——这样摘要请求变成已预热请求的“前缀扩展”而非从零开始的新请求。5.4 监控命中率像监控Uptime一样Anthropic工程团队的告诫值得记住“A few percentage points of cache miss rate can dramatically affect cost and latency.”监控要点在请求日志中跟踪cacheRead、cacheWrite、input三个桶的Token数关注趋势而非单点值对比服务端整体命中率和请求级命中率定位异常新版本发版前预热缓存避免上线后第一波请求全部冷启动六、面试口述总结“Token命中率衡量的是LLM推理中前缀缓存的复用程度定义是cacheRead / (input cacheRead cacheWrite)。它的底层机制是KV Cache——模型把历史Token的Key/Value张量存下来下次不再重算。Prefix Caching把这种复用扩展到跨请求只要前缀精确匹配就能跳过整个Prefill阶段。收益非常显著TTFT最高降低80%输入Token成本最高降低90%缓存Token通常只按标准价格的10%计费。影响命中率的核心因素是前缀的精确匹配性——System Prompt里插时间戳、工具Schema顺序变化、切换模型都会让缓存失效。优化原则就一条静态在前动态在后用messages更新而不是改system prompt。面试里常被追问的是为什么命中了还要看cacheWrite因为分母不含写入量会高估命中率为什么服务端和请求级命中率数字不一样因为统计口径不同——服务端是时间窗口平均请求级是单次快照。”七、一句话收束Token命中率不是一个“锦上添花”的指标而是LLM推理成本结构的第一杠杆。把前缀稳定下来把静态内容前置把动态内容后置——这三件事做到位命中率自然上去延迟和账单自然下来。