简介：大模型缓存命中指请求前缀与近期请求完全一致时，服务端复用中间计算结果，命中部分常可按约0.1倍原价计费。本文拆解缓存视角下的Token成本构成与命中率评估方法，给出静态前置、历史只追加、调度贴时效等优化路径，并提示TTL失效、前缀漂移与计费规则变动等风险，帮助开发者在多轮对话与长上下文场景中理性降本。
先明确对象：本文分析的是大模型API调用中的Token成本，重点是输入侧——也就是由缓存命中状态决定的那部分成本。读完本文，你可以回答三个问题：缓存命中为什么直接影响账单？我的业务能不能吃到这份折扣？要吃到它需要做哪些改造、承担哪些约束？
这类成本问题高频出现在以下场景：多轮对话助手（历史上下文逐轮累积）、基于长文档的检索问答（知识文档反复随请求发送）、Agent多步任务（工具定义与系统指令每步重复）、批量评估与数据处理流水线（相同提示词模板跑大量样本）、代码辅助（同一代码库上下文被反复携带）。
需要强调的是：成本分析不是简单比较“哪个服务单价更贵”。同样的单价，调用结构不同、前缀设计不同、调用节奏不同，最终账单可能相差数倍。评估Token成本，必须把计费规则、应用架构和使用方式放在一起看。
很多人不理解缓存为什么重要，是因为忽略了一个基础事实：大模型API是无状态的。服务端默认不替你保存对话——每一轮请求，客户端都必须把系统提示、全部历史消息、相关文档重新发送一遍，服务端从头处理完整输入。
这意味着重复是结构性的。举例示意：设固定的系统提示与知识前缀为P个Token，用户每轮新增q个Token，则第n轮请求的输入约为 P + (n-1)×q。对话越长，真正“新”的内容占比越低——有开发者统计，在典型长对话中，重复发送的历史上下文可占到输入Token的九成以上（原文给出的观察值约为97%）。这些重复内容既占用传输，也会在服务端被反复执行长上下文的预填充计算，最终全部计入输入Token账单。
缓存命中要解决的，正是这部分重复：既然每次都在算几乎相同的前缀，能不能把算过的结果留下来复用？
机制：当本次请求的开头部分（前缀）与近期某次请求的对应部分逐字节一致时，服务端可以复用此前已计算好的中间结果（业界通称KV缓存），跳过对这部分前缀的重复计算。注意两个关键词：一是“开头”，缓存按前缀匹配，中间某段一致不算；二是“逐字节一致”，原文的说法很直白——前缀变一个字节就作废。
计费：命中部分按大幅低于原价的标准计费，原文给出的常见水平是0.1倍原价，相当于打一折；未命中部分与输出部分仍按原价计费。各服务商的折扣系数、是否对缓存写入单独计价存在差异，具体应以实际所用服务（例如百度智能云的大模型服务或其他同类平台）的最新计费说明为准。
成本公式（通用口径）：
单次请求成本 ≈ 命中Token数 × 命中单价 + 未命中Token数 × 输入原价 + 输出Token数 × 输出单价
示意拆解（用相对倍率表达，不代表任何真实价格，设输入原价为1）：
| 计费项 | 相对倍率（示意） | 生效条件 |
|---|---|---|
| 输入——命中部分 | 约0.1 | 前缀逐字节一致，且在缓存时效内 |
| 输入——未命中部分 | 1 | 前缀变化、首次出现或已过期 |
| 输出 | 1（多数服务对输出不打折或规则不同） | 与缓存无关 |
| 缓存写入 | 部分服务另有计价 | 以计费说明为准 |
由此可见：缓存命中的本质，是把输入成本从“按全量原价”变成“按命中率加权”。命中率越高、长前缀越长，折扣放大效应越明显。
前缀稳定性。前缀中的任何一个动态字段——时间戳、请求ID、随机数、按用户变化的称呼——都会让匹配在那一字节断掉，其后所有内容全部按原价计费。最常见的失误是把“当前日期”或“会话编号”注入在系统提示开头。观察方法：把两次请求的完整输入做逐字节对比，看第一个差异出现的位置。
缓存时效（TTL）。缓存有保质期，原文提到常见的量级是5分钟：两次调用间隔超过时效，即使前缀完全一致，也要按未命中重新计算。不同服务的TTL不同，部分平台还支持延长或预热等机制，具体以所用服务说明为准。TTL决定了“缓存的便宜是有条件的便宜”。
前缀长度与结构。命中收益 ≈ 命中Token数 × (1 − 0.1)。几十Token的短提示即使全部命中，绝对节省也很有限；而包含长系统提示、大知识文档或长历史的请求，命中一次的价值才显著。
调用频率与节奏。多轮对话的应答间隔、批处理任务的调度间隔，决定了请求是否落在TTL窗口内。高密度连续调用天然容易持续命中；间隔数小时甚至一天的低频调用，命中率几乎为零。
并发与会话分布。多个并发会话是否共享相同的大前缀（例如同一套系统提示与工具定义），会影响整体命中量；同一会话的请求若被并行乱序处理，也可能打破前缀的追加关系。
模型版本与计费口径。是否支持前缀缓存、命中价系数、TTL长短，都可能随模型版本或计费规则调整。长期依赖缓存的应用需要把这一点纳入变更评估。
第一步，建立用量口径。 从服务端用量明细中提取每笔请求的输入Token数、命中Token数、输出Token数（主流平台的用量明细通常区分命中与未命中部分）。
第二步，定义核心指标。
| 指标 | 定义 | 用途 |
|---|---|---|
| 输入命中率 | 命中Token ÷ 输入Token总量 | 衡量前缀治理效果 |
| 输入侧节省比例 | 命中率 × (1 − 0.1)（按0.1倍命中价估算） | 估算输入降本上限 |
| 单轮输入增长曲线 | 每轮请求输入Token随轮次的变化 | 识别上下文膨胀 |
| 输出/输入比 | 输出Token ÷ 输入Token | 判断优化重心在输入还是输出 |
第三步，示意估算。 以下为通用伪代码，用于在自有数据上做敏感性分析：
hit_ratio = cached_tokens / total_input_tokenssaving_ratio = hit_ratio * (1 - hit_price_factor) # hit_price_factor≈0.1，以计费说明为准# 按应用、场景、会话维度汇总，接入账单周期复盘
第四步，区分固定与弹性。 系统提示、工具定义、知识文档属于“固定前缀”，用户输入属于“弹性部分”。固定前缀占比越高、越稳定，可优化空间越大；反之，如果每次请求的头部内容都在变，说明架构上还有硬伤要先修。
第五步，峰值与均值并重。 高并发短间隔场景（如客服高峰时段）容易持续命中；评估收益时不能只看平均值，要分别统计高峰与低谷的命中率。
第六步，纳入预算与告警。 把命中率、Token消耗、单会话成本做成看板并设置预算阈值。命中率骤降往往对应提示词被意外改动或代码升级引入了动态字段——它既是成本指标，也是变更质量的哨兵。
原文给出的心智模型转变非常关键：缓存优化的目标不是把提示词写得短，而是让重复的部分稳定、靠前、逐字节一致。围绕这一点，可执行的优化动作包括：
静态前置、动态后置。 系统提示、能力说明、工具定义、长文档等不变内容放在提示词最前面；用户问题、检索结果、日期、个性化信息等变化内容放到末尾。这是收益最大、改动最小的一条。
清理前缀中的动态字段。 排查时间戳、随机ID、会话编号、用户名等是否出现在前缀里，要么移除，要么后移到必然变化的位置。
历史消息只追加、不重写。 多轮对话中不要在轮间重排消息顺序、不要重新格式化历史文本。特别提醒：不要轻易用“裁剪历史”来省Token——裁剪会改变前缀、清空已积累的命中，而完整历史中的旧内容恰恰是按命中价计费的。多数情况下，“保住前缀连续性”比“删掉旧文”更划算，这也与原文强调的保护前缀一致。
让调度贴近TTL窗口。 批量评估、文档问答、回归测试等可集中调度，让相同前缀的请求密集落在缓存时效内执行。反过来，天然低频长间隔的任务不应指望缓存省钱，也不要为凑命中而人为拖延或堆积请求——那可能损害业务时效。
会话亲和与并发治理。 保证同一会话的请求按序处理；在并行场景中，尽量让共享大前缀的请求安排在同一时段，提高整体命中量。
命中率进入变更管理。 任何提示词或调用代码的改动，都应评估对前缀的影响，并在发布后观察命中率曲线是否回稳。
先机制、后工具。 原文的实践结论值得记住：与其追逐零散的“省Token技巧”，不如先把计费机制和前缀治理做扎实——机制理解错位时，再多工具也只是表面修补。
优化清单（可直接自查）：
| 浪费场景 | 成本表现 | 治理动作 |
|---|---|---|
| 动态内容前置（如开头注入日期） | 命中率长期接近零，全量按原价 | 静态前置、动态后置 |
| 每轮重写或重排历史 | 已积累命中被反复清零 | 历史只追加、格式冻结 |
| 低频任务指望缓存省钱 | 几乎全部未命中 | 重新评估调度密度或放弃该预期 |
| 只盯输入不看输出 | 输出成本占比被系统性忽视 | 输出长度一并纳入预算与监控 |
| 无用量与命中率监控 | 成本异常无法归因 | 建立Token与命中率看板、告警 |
| 为省Token粗暴裁剪历史 | 破坏前缀，命中收益清零 | 评估裁剪与命中的净收益再决策 |
回到最初的问题：什么是缓存命中？它是服务端对“重复前缀”的复用机制；它如何影响费用？命中部分常可按约0.1倍原价计费，输入成本因此从“全量原价”变成“按命中率加权”。
核心结论可以归纳为四条：
在多轮对话、长上下文、高频调用这类场景里，缓存治理往往是投入产出比最高的降本起点；而在低频、短提示场景，精力应更多放在输出长度控制与调用结构治理上。成本优化的第一步，永远是先看清自己账单的结构。