大模型API输入缓存命中与未命中区别详解

一、对比背景：为什么输入缓存命中值得关注

大模型API的计费粒度正在快速细化。早期业界普遍按“输入token + 输出token”两段计费，而如今，“输入缓存命中”与“输入缓存未命中（常规输入）”已被拆分为两个独立计费项，时段阶梯定价、促销与永久性调价也频繁出现。

回顾近期的行业动态（以下均为中立化转述）：

• 2026年4月，某大模型服务商宣布下调全系列API“输入缓存命中”计费单价，并同步延长其旗舰模型的促销期限；
• 2026年5月底，该服务商将旗舰模型优惠价永久化，最终价格约为其最初发布定价的四分之一，并带动其他定价较高的厂商跟进调整至相近水平；
• 2026年6月底，该服务商宣布推出峰谷阶梯定价策略，高峰时段（北京时间每日900与1400）费用高于平峰时段；
• 2026年8月下旬，该平台进一步调整计费规则，宣布周六、周日全天统一按低谷时段价格计费；
• 2026年9月，该服务商又下调了轻量快速系列模型的定价，综合调用成本预计进一步下降。

这些事件传递出两个信号：其一，在大模型API市场竞争日趋激烈的当下，价格本身已成为开发者选择模型的重要因素之一；其二，理解“输入缓存命中”的底层机制与计费逻辑，直接决定了你的账单结构与优化空间。

本文的对比对象是：同一模型API服务下的两个计费项——“输入缓存命中（Cache Hit）”与“输入缓存未命中（Cache Miss，即常规输入）”，并延伸讨论“缓存策略 × 时段计费”的组合优化思路。

二、对象定义：两者分别是什么

2.1 输入缓存命中

大模型推理通常包含预填充（Prefill）与解码（Decode）两个阶段。预填充阶段需要为输入的全部token计算注意力所需的键值矩阵（即KV缓存）。如果两次请求的输入前缀完全一致，服务端可以直接复用此前已算好的KV缓存，跳过这部分重复计算。

被成功复用的前缀部分即“输入缓存命中”，其token按显著更低的单价计费。业界普遍将命中部分单价设为未命中单价的若干分之一（具体倍率因服务商而异，以各官方价格文档为准）。

2.2 输入缓存未命中

未命中即无法复用缓存的部分：要么该前缀从未出现过，要么缓存已超出有效期或被服务端淘汰。这部分token按标准输入单价计费，且需要完整的预填充计算。

需要特别注意：一次请求中，命中与未命中通常并存——稳定前缀部分命中计费，本轮新增的后缀部分未命中计费，两者相加才是本次请求的完整输入费用。

三、相同点分析

尽管计费单价差异巨大，两者在更底层的能力层面高度一致：

1. 语义完全等价：无论命中与否，输入token对模型的作用完全相同，输出质量不受任何影响。缓存复用是计算与计费层面的优化，不改变推理语义，开发者无需担心“命中会导致答案变差”。
2. 接口形态一致：多数服务商无需开发者显式开启缓存，命中与否由服务端自动判定；请求格式、鉴权方式、速率限制均相同，不增加接入成本。
3. 同属输入计费体系：两者都计入输入token总量，共同占用上下文窗口，共同受最大上下文长度约束。
4. 用量可观测：主流服务商一般会在响应的用量统计字段中区分两部分token，便于对账与优化分析。

四、核心差异分析

4.1 计费单价差异

命中部分单价显著低于未命中部分，这是两者最直观的差异。在长上下文、多轮会话场景下，累计输入token往往数倍甚至数十倍于输出token，此时缓存命中率的高低可能直接造成总成本数倍的差距。这也是2026年4月某服务商单独下调“输入缓存命中”单价后，长对话类应用成本明显下降的原因。

4.2 计算路径与性能差异

• 命中路径：复用已有KV缓存，跳过前缀的预填充计算，首token延迟（TTFT）更低，服务端吞吐能力也相应提升；
• 未命中路径：执行完整预填充，计算量与延迟随前缀长度线性增长。

对延迟敏感的在线对话应用而言，稳定前缀的高命中率不仅省钱，还能直接改善用户体验，属于“成本与性能双赢”。

4.3 生效条件与确定性差异

• 命中依赖严格条件：输入前缀必须逐字节一致（包括系统提示词、历史消息中的每一个字符与空白），缓存需在有效期内，且未被高并发下的缓存淘汰机制清理，通常还要求路由到同一模型或部署；
• 未命中则无条件成立，计费确定性强，便于预算测算与成本建模。

这意味着命中率的天然波动会带来账单波动。做预算规划时，应按“命中率区间”而非单一固定值建立成本模型。

4.4 对应用架构的约束差异

要获得命中收益，应用侧需要“为缓存设计”：提示词结构稳定化、历史消息拼接顺序固定、易变内容统一后置。这会反向约束提示词工程与对话状态管理的实现方式。而未命中路径没有此类约束，提示词可自由变化——这是隐性但真实的工程成本，选型时需要纳入考量。

五、差异对比总表

对比维度	输入缓存命中	输入缓存未命中
计费单价	显著更低（通常为未命中单价的若干分之一）	标准输入单价
触发条件	前缀逐字节一致且缓存有效	前缀不一致或缓存过期/被淘汰
计算路径	复用KV缓存，跳过前缀预填充	完整预填充计算
首token延迟	更低	与前缀长度正相关
输出质量	与未命中完全一致	基准
成本确定性	受缓存淘汰与有效期影响，存在波动	确定性强，便于测算
架构要求	前缀稳定化设计，约束提示词工程	无特殊要求
典型收益场景	多轮对话、Agent、代码助手	一次性批处理、高度随机输入

六、延伸维度：时段计费与缓存策略的组合

除了命中/未命中这一维度，行业还出现了时间维度的差异化计费：如某服务商将高峰时段（北京时间900、1400）定价高于平峰时段，另有平台将周末全天按低谷价计费。

由此可以抽象出通用的成本估算框架：

单次请求成本 ≈ (命中token数 × 命中单价 + 未命中token数 × 未命中单价) × 时段系数

两类优化的适用边界不同：

• 可延迟的离线任务（批量评估、数据处理、内容批量生成）：优先安排在低谷时段或周末执行，时段收益确定；
• 在线对话类任务：无法选择时段，优化重心应放在命中率上；
• 两者可叠加：夜间批处理若共享稳定前缀，同样能叠加缓存命中收益，具体计费规则以各服务商官方说明为准。

七、典型场景选择

7.1 多轮对话 / 智能客服

系统提示词、工具定义与历史消息构成天然稳定前缀，每轮新增内容很少，命中率随对话轮数持续上升。建议优先做前缀稳定化设计，并监控命中率走势。

agent-">7.2 Agent工作流

系统指令、工具schema、任务说明会在多步循环中反复出现，只要严格保持拼接顺序与序列化格式（如JSON字段顺序、换行符），命中率可以维持在较高水平。注意：任何时间戳、请求ID等随机成分插入前缀都会直接破坏命中。

rag-">7.3 RAG检索增强

这是典型的风险场景：若把检索结果拼在提示词最前部，每次检索内容不同，命中率将趋近于零。建议采用“[系统指令（稳定）] → [少样本示例（稳定）] → [检索文档（易变）] → [用户问题（易变）]”的分层结构，让稳定部分尽量前置。

7.4 一次性批量处理

输入互不重复、无共享前缀，缓存计费项收益有限。此时优化手段应转向：低谷时段调度、选择轻量快速档位的模型（如2026年9月某服务商下调定价的快速系列）。

7.5 代码助手

仓库上下文、编码规范说明在会话内稳定，用户编辑位置多变，“前缀稳定、后缀易变”的结构天然契合缓存机制，是命中率优化的经典受益场景。

八、优化实践：如何提高命中率

8.1 提示词分层设计

示意性伪代码如下：

# 示意：稳定内容前置、易变内容后置
STABLE_PREFIX = (
    "你是企业知识库问答助手。\n"
    "工具定义：<固定的工具schema>\n"
    "回答规范：<固定的输出要求>\n"
)
def build_prompt(history: list, user_query: str) -> str:
    # 1. 历史消息严格按原顺序拼接，不做任何改写与重排
    prefix = STABLE_PREFIX + "\n".join(history)
    # 2. 易变内容统一放在末尾
    return prefix + "\n当前问题：" + user_query

工程要点：

• 前缀必须逐字节一致：留意JSON序列化的字段顺序、换行符、空格、全角半角差异；
• 不要在前缀中插入时间戳、随机ID等动态成分；
• few-shot示例固定放前缀；动态检索示例的“动态few-shot”模式会破坏命中，需要权衡检索增益与缓存损失。

8.2 命中率监控

各服务商返回字段命名略有差异，通用示意如下：

{
  "usage": {
    "prompt_tokens": 4200,
    "cached_tokens": 3800,
    "completion_tokens": 180
  }
}

可按 cached_tokens / prompt_tokens 计算命中率，纳入业务监控与成本看板。命中率异常下跌，通常意味着前缀被意外改动（如上线了新的提示词版本、序列化逻辑变化），应触发告警排查。

九、选型与迁移注意事项

9.1 条件化选型判断

• 若业务存在大量重复前缀（对话、Agent、代码助手），应优先评估目标服务商是否提供缓存计费项、单价倍率多少——命中率每提升10%，输入成本都会相应下降；
• 若输入高度随机（批处理、一次性生成），缓存计费项意义有限，选型重心应放在时段折扣与模型档位匹配上；
• 若团队工程能力有限、短期内不计划为前缀稳定性做改造，不宜把成本模型建立在高命中率假设之上，按未命中口径测算更稳妥。

国内如百度智能云等云服务商也提供大模型推理及配套的监控告警、日志类通用能力，可作为整体方案的评估对象之一，具体计费结构以其官方价格文档为准。

9.2 迁移注意事项

1. 计费口径差异：迁移前需重新核对目标服务商是否区分命中/未命中、倍率多少、是否有时段系数，仅按token总量估算会严重失真；
2. 提示词改造成本：若原方案将易变内容前置，迁移是重构提示词结构的时机，但重构后必须回归测试输出质量；
3. 命中率冷启动：缓存随真实使用逐步建立，迁移初期命中率偏低，预算应按未命中口径预留，再逐步修正；
4. 价格政策风险：行业价格调整频繁——促销结束、优惠永久化、峰谷新政都已真实发生过，建议将价格参数配置化管理，避免硬编码在业务代码中；
5. 对账机制：建立按计费项拆分的用量统计，任何单价调整都能在第一时间量化评估影响。

十、总结

输入缓存命中与未命中的区别，本质是“同一语义输入的两条计算与计费路径”：命中复用KV缓存，单价更低、首token延迟更优，但要求前缀逐字节稳定并承担命中率波动的核算复杂度；未命中计费确定、架构自由，但成本更高。选型逻辑应当是条件化的——对话型、Agent型、前缀重复型业务应围绕命中率做系统性架构设计；输入随机型业务则应把优化重心放在时段调度与模型档位选择上。在计费粒度持续细化的行业趋势下，把“命中率”当作一个可监控、可优化、可配置的工程指标来管理，是控制大模型API调用成本最直接的抓手之一。