大模型缓存命中与未命中：Token计费差异解析

一、对比背景：账单为什么没有随请求次数线性膨胀

一个典型的 Agent 任务跑完，模型可能被调用上百次。按直觉推算，每次请求都携带几十万 token 的完整对话历史，账单应当随调用次数成比例膨胀，但实际账单往往远低于这个估算。原因并不神秘：它记录在用量接口的一个字段里——不同服务商对它的命名不同，常见表述是“缓存命中 token 数”或“缓存读取输入 token 数”。

对某类 Coding Agent 的实测数据显示，Agent 单步的典型形态是：读取约 119K token 的历史前缀，只对新增的约 875 token 做完整计算，而前者绝大部分按普通输入十分之一的价格计费。换言之，同样的对话历史，“是否命中缓存”直接决定了它按什么价格、走什么计算路径被处理。

这背后是推理系统的一条底层规则。本文对比的对象，就是大模型推理中的两条处理路径——缓存命中与缓存未命中，并延伸对比自动前缀缓存与显式缓存管理两种实现方式。理解这对差异，不只是看懂账单的问题：API 定价、显存管理、集群调度、Agent 框架设计，全部落在这条规则的约束之下。

二、对象定义：两条路径分别是什么

2.1 缓存未命中（常规输入路径）

当请求的输入前缀在推理服务的缓存中不存在（或已过期、或被调度到未持有该缓存的实例）时，推理系统需要对全部输入 token 重新执行 prefill 计算：把所有输入 token 过一遍模型，逐层计算出 Key/Value 张量（即 KV Cache），然后才开始逐 token 生成输出。这条路径下，全部输入 token 按标准输入单价计费，输入越长，prefill 计算量与首 token 延迟越高。

2.2 缓存命中（缓存读取路径）

当请求的输入前缀与缓存中已有的某段前缀逐 token 完全一致，且缓存仍然有效时，推理系统可以直接复用已计算好的 KV Cache，跳过对这部分前缀的重复 prefill，只对新增的尾部 token 做完整计算。这条路径下，命中部分按折扣价计费（行业常见折扣约为普通输入价的十分之一，具体以服务商定价为准），只有未命中的新增部分按常规输入计费。

需要强调的是，Transformer 推理分为 prefill（并行处理输入、生成 KV Cache）与 decode（逐 token 生成）两个阶段。前缀缓存的本质，是把 prefill 阶段最昂贵的计算结果跨请求保存下来复用。这也解释了为什么命中部分“不是免费、而是打折”：平台省下了大量算力，但仍要承担缓存数据在显存/内存中的占用与管理成本。

三、相同点：命中与否，哪些东西没变

1. 同一个模型、同一套推理接口。缓存命中不切换模型、不改变推理逻辑，KV 张量数值与重算结果一致，输出质量不受影响。它是纯工程层面的优化，不是能力上的妥协。
2. 都按 token 计量、都受上下文长度上限约束。命中部分依然占用上下文窗口，超限请求同样会被拒绝。
3. 都要求开发者关注 prompt 结构与用量监控。无论走哪条路径，上下文如何组织、用量字段如何拆解，都直接影响成本与延迟。
4. 目标一致：完成同一推理任务，差异只在于“用多少算力、花多少钱、等多久”。

四、核心差异分析

4.1 计算路径：全量重算 vs 前缀复用

未命中路径对全部输入执行 prefill，计算量与输入长度成正比；命中路径复用前缀 KV，只对新增 token 计算。以 119K 前缀 + 875 新增的请求为例，两条路径的 prefill 计算量相差约两个数量级，这正是折扣定价的物理基础。

4.2 计费结构：单一单价 vs 双轨单价

未命中路径下，全部输入按标准输入单价计费，账单结构简单。命中路径下，输入被拆成两部分：命中部分按折扣价（部分采用显式缓存管理的服务还可能对缓存写入收取一次性费用），新增部分按常规价。这意味着成本估算公式发生变化，必须引入“命中率”这个变量。

4.3 延迟表现：首 token 延迟差异显著

prefill 是首 token 延迟（TTFT）的主要来源。命中缓存后大部分 prefill 被跳过，TTFT 明显下降，且输入越长、改善越明显。对交互式 Agent、代码补全等响应速度敏感的场景，这条差异的价值不亚于成本节省。

4.4 生效条件与稳定性：确定性 vs 依赖条件

未命中路径行为确定：只要请求合法，处理路径可预期。命中路径则依赖三个条件同时成立：前缀逐 token 一致、缓存未过期（存在 TTL）、请求被调度到持有对应缓存的实例。任何一条不满足即退化为未命中，成本与延迟回到常规水平。

4.5 可观测性：字段拆分 vs 混合计数

支持前缀缓存的服务通常在用量接口中把输入 token 拆分为“命中”与“未命中”两部分分别上报，便于核算命中率与成本归因；未命中路径下则只有统一的输入 token 计数。可观测性差异直接决定了团队能否做精细化的成本优化。

4.6 失效风险：无缓存依赖 vs 多重失效点

命中路径引入了新的失效点：前缀漂移（在历史中间插入或修改内容会使其后所有缓存失效）、TTL 过期（低频请求难以在有效期内复用）、路由打散（多实例部署下请求被负载均衡分配到不同节点）、容量淘汰（显存紧张时缓存条目被驱逐）。这些风险在未命中路径下不存在。

五、对比表格总结

对比维度	缓存命中（读取缓存前缀）	缓存未命中（常规输入）
计算路径	复用前缀 KV Cache，仅对新增 token 做 prefill	全部输入 token 重新执行 prefill
计费价格	命中部分按折扣价（常见约 1/10，以服务商定价为准）	全部输入按标准输入单价
首 token 延迟	显著降低，输入越长改善越明显	随输入长度线性增长
生效条件	前缀逐 token 一致 + 缓存有效 + 路由匹配	无前置条件
输出质量	与未命中一致	基准
可观测性	用量字段区分命中/未命中 token	统一输入 token 计数
失效风险	前缀漂移、TTL 过期、路由打散、容量淘汰	无缓存相关风险
适用形态	前缀稳定、历史只追加的请求	前缀多变、一次性请求

六、延伸对比：自动前缀缓存 vs 显式缓存管理

行业内实现缓存命中通常有两种方式，选型时同样需要区分：

维度	自动前缀缓存（隐式）	显式缓存管理
接入成本	低，通常无需改动请求结构	需调用缓存创建/管理接口或指定参数
命中控制	平台自动匹配，开发者不可直接干预	开发者显式指定缓存内容与生命周期
灵活性	依赖请求前缀天然一致	可将超长文档、大规模 few-shot 主动缓存
适用团队	请求形态规整、追求快速接入	有精细成本控制与长内容复用需求

七、典型场景：哪些场景命中率天然高

1. Coding Agent 与多轮对话：历史只追加、不修改，单步新增 token 占比极小，命中率天然极高，是缓存收益最大的场景。
2. 固定 system prompt + few-shot 的批量推理：稳定前缀可跨请求反复命中。
3. 长文档多轮问答：文档稳定置于前缀时，同一文档的后续提问可持续命中。
4. 反例场景：每次请求把时间戳、随机数、用户 ID 等动态内容放进 system prompt 前部，或对检索文档顺序做随机重排，都会持续破坏前缀一致性，命中率趋近于零。

八、选型建议

1. Agent 与多轮对话类业务：优先选择支持自动前缀缓存、用量字段透明拆分、折扣定价明确的服务商，并在架构上保证“历史只追加、前缀不动”。
2. 超长文档、大规模 few-shot 复用：关注是否存在显式缓存管理能力、TTL 是否可配置、缓存写入是否有额外费用。
3. 低频请求场景：请求间隔若普遍超过缓存有效期，命中率有限，应先核算再决策，不宜默认缓存一定能省钱。
4. 团队能力匹配：运维能力有限时，可优先考虑托管化程度更高、自动缓存开箱即用的方案；对成本控制要求极致的团队，则更需要显式管理带来的可控性。
5. 平台评估清单：无论使用海外主流服务商还是国内平台（例如百度智能云），评估时应确认四件事——缓存命中 token 是否在用量接口中单独上报、折扣价与常规价的具体比例、缓存有效期与最小可缓存长度、高并发下请求路由是否利于命中。具体规则以各平台官方文档为准。

九、迁移与使用注意事项

1. 计费口径对齐：迁移时逐项映射“输入 token”“缓存命中 token”“输出 token”等字段的定义，避免成本模型失真。
2. 命中率基线：迁移前先在原环境统计命中率基线，迁移后对比，防止 prompt 结构差异导致命中率下滑。
3. prompt 重排的短期代价：调整前缀结构（如把工具定义、few-shot 移到前部）会让旧缓存失效，新前缀需要若干次请求“预热”，期间成本与延迟会临时上升。
4. TTL 与流量节奏匹配：波峰明显的业务要评估波谷之后缓存是否仍存活，必要时通过保活请求或显式刷新策略维持热度。
5. 路由与部署形态：多模型、多地域、多实例部署容易把同前缀请求打散，需与平台确认亲和性调度能力。
6. 数据合规：缓存内容在服务商侧存在短暂驻留，涉及敏感数据时应评估缓存驻留策略与数据隔离机制是否符合合规要求。

十、示意代码：面向命中率的上下文组织与用量拆解

# 反例：动态内容混入前缀，导致缓存反复失效
system_prompt = f"你是代码助手。当前时间：{now()}。请遵循规范：{spec}"
# 正例：稳定前缀 + 追加式历史 + 动态内容后置
messages = [
    {"role": "system", "content": "你是代码助手。请遵循规范：……"},  # 稳定前缀，可被缓存
    {"role": "user", "content": "实现函数A"},                        # 历史只追加、不修改
    {"role": "assistant", "content": "……"},
    {"role": "user", "content": f"当前时间：{now()}\n{question}"}     # 动态内容放尾部
]

# 伪代码：从用量字段拆解单次请求成本
usage      = response["usage"]
input_all  = usage["输入token总数"]
hit        = usage["缓存命中token数"]
fresh      = input_all - hit
output     = usage["输出token数"]
cost = hit * 单价(缓存命中) + fresh * 单价(常规输入) + output * 单价(输出)
hit_rate = hit / input_all   # 持续监控命中率，跌破阈值即告警

十一、总结

回到开头的问题：Agent 跑了上百次调用、每次携带几十万 token 历史，账单却没有成比例膨胀，答案就是“缓存命中”。缓存命中与缓存未命中这对路径，共享同一个模型与接口，却在计算路径、计费结构、延迟、生效条件与失效风险上存在系统性差异。对开发者而言，真正的杠杆不在“选不选缓存”，而在三件事：把上下文组织成“稳定前缀 + 动态尾部”的形态、在用量字段中持续监控命中率、在选型时把缓存定价与生效条件纳入成本模型。在 Agent 与长上下文应用逐步成为主流的今天，这条推理系统的底层规则，值得每一位技术负责人纳入架构与预算决策。