大模型API降本关键：算清缓存命中率这笔账

一、只看标准定价，是成本评估的最大误区

团队在大模型 API 选型时，最常见的动作是把各家牌价抄进一张表：「输入 X 元/百万 tokens、输出 Y 元/百万 tokens」，谁低选谁。这个方法在短上下文、单轮调用的场景误差尚可接受；但一旦进入多轮对话、长文档问答、代码库分析、RAG 检索增强这类「大输入、小输出」的场景，结论就可能严重失真。

原因在于，它忽略了现代大模型计费体系中的一个核心变量：缓存命中率（Cache Hit Rate）。主流大模型服务普遍支持上下文缓存（Context Caching / Prompt Caching）能力——当请求输入的前缀部分与近期请求一致时，命中部分可按远低于标准价的「缓存价」计费。不同工程实现下，命中率可以从接近 0% 提升到 90% 以上，对应的实际输入价格差距可达 3-5 倍。也就是说，牌价看似高 50% 但命中率更高的服务，实际账单反而可能更便宜。

二、上下文缓存省的是什么钱

2.1 从推理的两个阶段说起

Transformer 推理分为两个阶段：

• 预填充（Prefill）：模型一次性读完所有输入 token，为每层注意力计算 Key/Value 矩阵并缓存（即 KV Cache），计算密集、成本高昂；
• 解码（Decode）：逐 token 生成输出，每一步读取 KV Cache 做注意力计算。

关键观察是：KV Cache 只取决于输入前缀本身。如果两次请求的前 20 万个 token 完全一致（例如相同的系统提示词 + 相同的知识文档），第二次请求就无需重算这段前缀，直接复用即可。缓存命中，省掉的正是这部分重复的预填充算力；计费让利，本质是把省下的算力成本部分返还给用户。

2.2 命中的三个前提

• 前缀严格一致：从第一个 token 开始逐位匹配，任何一处不同，其后内容全部失效；
• 在有效期内：缓存条目有 TTL（生存时间），超时未续期即失效；
• 未被淘汰：缓存空间有限，长期不命中的条目可能被逐出。

三、混合计费模型：一个公式算清实际输入成本

引入缓存后，输入 token 的计费被拆成两段：命中部分按缓存单价计费（业界常见为标准价的一到三折），未命中部分按标准单价计费。由此得到通用测算公式：

实际输入成本 = 输入量 × 命中率 × 缓存单价 + 输入量 × (1 − 命中率) × 标准单价

用一个假设的例子算一笔账：设某模型输入标准价为 4 元/百万 tokens，缓存命中价为 0.7 元/百万 tokens（约为标准价的 1.75 折，属常见区间），处理 1M tokens 输入：

命中率	命中部分	未命中部分	合计	相对标准价
0%	0 元	4.00 元	4.00 元	10 折
50%	0.35 元	2.00 元	2.35 元	约 5.9 折
80%	0.56 元	0.80 元	1.36 元	约 3.4 折
90%	0.63 元	0.40 元	1.03 元	约 2.5 折
95%	0.665 元	0.20 元	0.865 元	约 2.2 折

三个结论直接浮现：

1. 90% 命中率下，1M tokens 的实际输入成本约 1.03 元，相当于标准价打了 2.5 折；
2. 命中率从 0% 提升到 90%，成本相差近 4 倍——比任何牌价差异都大；
3. 命中率的边际收益始终为正：从 80% 提升到 90%，仍能再省约 24%。

两点边界需要留意：其一，缓存只作用于输入 token，输出 token 仍按输出单价全额计费，总成本 = 输入混合成本 + 输出量 × 输出单价；其二，部分计费规则还会对缓存写入收取少量费用或提供不同 TTL 档位，测算时应一并纳入。

四、三步估算你的真实命中率

4.1 结构估算法：给 prompt 做解剖

把一次请求的输入拆成「稳定前缀」与「易变后缀」：

• 稳定部分：系统提示词、few-shot 示例、工具（function calling）定义、挂载的参考文档——通常跨请求不变；
• 易变部分：本轮用户问题、最近几轮对话、实时检索片段。

稳定部分占输入总量的比例，就是命中率的天然上限。例如一个输入 10 万 token、其中 9 万来自固定知识文档的问答应用，理论上限即 90%。

4.2 实测法：读取 usage 统计字段

主流 API 响应中一般带有用量明细，典型形态示意如下：

{
  "usage": {
    "prompt_tokens": 120000,
    "cached_tokens": 102000,
    "completion_tokens": 640
  }
}

cached_tokens / prompt_tokens 即单次命中率。生产环境应把该字段接入日志与监控体系，按「接口—prompt 版本」两个维度聚合统计，观察分布而非单点值。

4.3 回放压测校准

在预发环境用真实历史流量回放，统计不同时段、不同负载下的命中率分布，避免用偶发的单次请求值外推全年预算。

五、提升命中率的五条工程实践

5.1 前缀稳定化：「不变」前置，「多变」后置

这是性价比最高的一条。推荐的 prompt 组织顺序：

[系统提示词（固定版本）]            ← 强稳定
[工具定义 / few-shot 示例]         ← 强稳定
[挂载知识文档（固定版本）]         ← 强稳定
[历史会话消息（只追加、不重写）]   ← 弱稳定
[本轮问题 + 实时检索片段]         ← 易变，置尾

典型反模式包括：

• 在 prompt 开头拼接时间戳、请求 ID、自增序号——哪怕一个 token 的差异，都会让后续全部前缀失效；
• 每轮对话都对历史消息做改写、重排或内联摘要；
• 系统提示词频繁微调措辞，且缺乏版本管理。

5.2 会话历史采用追加式组织

多轮对话中，历史消息天然「只增不改」，是理想的缓存前缀。若必须做摘要压缩，应把摘要结果放在稳定区之后拼接，而不是替换前缀本身。

5.3 系统提示词与文档的版本化管理

变更按版本号灰度放量，而非全量切换，既平滑成本波动，也便于归因命中率变化。

5.4 关注 TTL 与调用节奏

低频定时任务（如每小时一次的批量分析）可能每次都撞上缓存过期。可评估「在 TTL 内发送轻量保活请求」的净收益：用极小成本换取大额输入的缓存价，通常划算。

rag-">5.5 RAG 场景的两级上下文组织

检索片段每次都不同，天然难命中。可将高频引用的固定文档集作为稳定前缀，实时检索的小片段后置拼接；必要时对高频 query 的检索结果做预挂载。

六、选型与预算：一份可复用的测算清单

1. 收集牌价：输入标准价、缓存命中价、输出价，以及可能的缓存写入/存储费用；
2. 估算命中率：先按 prompt 结构估算上限，再实测校准；
3. 统计输入输出比：按应用真实 tokens 结构加权，计算单请求综合成本；
4. 纳入附加项：TTL 档位、限流与并发额度对命中率的间接影响；
5. 做敏感性分析：命中率 ±10%、输入量 ±20% 时，预算的波动区间；
6. 评估工程成本：前缀重构、监控接入所需的开发量与收益回收周期。

一个通用的测算函数：

def estimate_cost(input_tokens_m: float, hit_rate: float,
                  cache_price: float, base_price: float,
                  output_tokens_m: float, output_price: float) -> float:
    """单位：百万 tokens；价格单位保持自洽即可"""
    cached = input_tokens_m * hit_rate * cache_price
    fresh  = input_tokens_m * (1 - hit_rate) * base_price
    output = output_tokens_m * output_price
    return cached + fresh + output

目前包括百度智能云在内的主流大模型平台，普遍在模型服务中提供上下文缓存与用量统计能力，具体价格比例、TTL 规则以各平台官方文档为准。测算时用同一套公式套入不同平台参数，才能得到真正可比的结论。

七、结语

缓存命中率是大模型 API 成本中「藏在牌价之下」的变量：它由你的 prompt 工程质量决定，又反过来决定实际计费结构。正确姿势是双向发力——选型时用「混合计费公式 + 实测命中率」核算综合成本，工程上用「稳定前缀 + 追加式会话 + 版本化管理」把命中率做上去。当输入侧实际价格只有牌价的 2-3 折时，很多原本「太贵」的场景，会重新进入可行区间。