企业官网建设流程全解析

一、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 Caching

KV 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个Token，TTFT ≈ prefill(2500)

• 2000个Token命中缓存：Prefill仅需处理500个Token，TTFT ≈ prefill(500)

命中率80%，TTFT降低80%。这不是近似，因为Prefill计算量随未命中Token数线性缩放。

不同工作负载的实测数据：

2.3 成本对比

主流提供商的缓存定价策略：

缓存Token的价格通常是未缓存Token的1/10。Anthropic的定价逻辑很直接：缓存Token的服务成本低90%，所以收费也低90%。

三、命中率怎么算？

3.1 正确公式

DeepSeek Harness官方给出的计算公式：

cache hit rate = cacheRead / (input + cacheRead + cacheWrite) × 100%

其中：

• input：本轮新增的、未命中缓存的Token

• cacheRead：从缓存读取的Token（即命中部分）

• cacheWrite：写入缓存的Token（首次计算并存储）

关键：分母必须包含cacheWrite。如果只用cacheRead / (input + cacheRead)，首次请求（input=0, cacheRead=0, cacheWrite=全部）会得到0/0，而后续请求会高估命中率。

3.2 一个例子

一轮请求：input=200，cacheRead=800，cacheWrite=0

命中率 = 800 / (200 + 800 + 0) =80%

3.3 两种统计口径

vLLM用户常遇到一个困惑：服务端日志显示的命中率（如45.7%）和单个请求usage字段算出的（如86.7%）差距很大。原因是：

• 服务端命中率：最近N次prefix cache查询的平均值，反映一段时间内所有请求的整体情况

• 请求级命中率：cached_tokens / prompt_tokens，只代表当前这一个请求

排查问题时建议同时看两个口径：服务端看趋势，请求级看单次异常。

四、什么在破坏命中率？

缓存命中要求前缀的精确匹配——从第一个Token开始，字节和顺序完全一致。任何位置的变化都会让该位置之后的所有内容失效。

4.1 前缀失效的常见原因

一个被反复提及的典型反面案例：某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 Token；2.5 Pro：2048 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推理成本结构的第一杠杆。把前缀稳定下来，把静态内容前置，把动态内容后置——这三件事做到位，命中率自然上去，延迟和账单自然下来。