大模型定价分层：缓存命中率如何重塑成本结构

一、标价上涨背后的定价逻辑变化

近期某新一代大模型API的定价调整引发了开发者社区的广泛讨论。从表面数据看，输出侧价格从上一代的中低档位跃升至每百万token百元级别，输入侧未命中缓存的价格也上调至每百万token二十元，整体涨幅令人瞩目。但如果仅停留在标价对比层面，很容易得出“全面涨价”的简单结论，而忽略了定价结构本身正在发生的深层变化。

让我们先梳理关键价格档位的变化趋势：

• 输出侧：从上代产品每百万token约二十七元提升至百元级别，绝对涨幅显著；
• 输入侧（未命中缓存）：从上代约六点五元提升至二十元，涨幅约三倍；
• 输入侧（缓存命中）：从上代约一点一元提升至二元，涨幅相对温和。

值得注意的是，各档位之间的价格比值关系发生了结构性调整。上一代产品中，未命中输入价格约为命中价格的六倍；新一代产品中，这一比值拉大到了十倍。输出价格与缓存命中输入价格之间的比值，更是从约二十五倍扩大到了五十倍。

这种比值关系的重塑，说明定价策略不再是简单的“全线调价”，而是在引导特定的使用模式。

二、缓存命中率：被忽视的成本杠杆

要理解上述比值变化的意图，需要先理解大模型推理中缓存机制的技术原理。

在典型的对话或Agent场景中，每次请求通常包含系统提示词（system prompt）、历史对话上下文以及当前用户输入。其中系统提示词和部分历史上下文在多次请求之间是高度重复的。缓存机制的核心思想是：将这部分重复内容的键值缓存（KV Cache）保留在推理基础设施中，后续请求命中缓存时无需重新计算，从而大幅降低算力开销。

这意味着，缓存命中率的高低直接决定了输入侧的实际计费成本。而不同使用场景下，缓存命中率的差异可能是天壤之别。

行业常见的技术方案中，有团队通过分离式推理架构将编程场景的缓存命中率做到百分之九十以上。这类架构将预填充（prefill）与解码（decode）阶段解耦，使缓存复用更加高效。

三、两种典型场景下的真实成本测算

为了更直观地展示缓存命中率对综合成本的影响，我们构建两个典型场景进行测算。

agent-">场景A：企业级Agent（高缓存命中率）

假设条件：

• 输入输出比约为20:1（长上下文编程Agent的常见比例）
• 缓存命中率约90%

输入侧实际单价计算：

实际输入单价 = 缓存命中价 × 命中率 + 未命中价 × (1 - 命中率)
            = 2 × 0.9 + 20 × 0.1
            = 1.8 + 2.0
            = 3.8 元/百万token

综合每百万token成本：

综合成本 = (输入token数 × 实际输入单价 + 输出token数 × 输出单价) / 总token数
        = (20 × 3.8 + 1 × 100) / 21
        ≈ 8.4 元/百万token

场景B：散户开发者（低缓存命中率）

假设条件：

• 输入输出比约为5:1（短对话、每次prompt不同）
• 缓存命中率约20%

输入侧实际单价计算：

实际输入单价 = 2 × 0.2 + 20 × 0.8
            = 0.4 + 16.0
            = 16.4 元/百万token

综合每百万token成本：

综合成本 = (5 × 16.4 + 1 × 100) / 6
        ≈ 30.3 元/百万token

成本分化对比

指标	场景A（企业Agent）	场景B（散户开发者）
缓存命中率	90%	20%
输入输出比	20:1	5:1
实际输入单价	3.8元/百万token	16.4元/百万token
综合成本	约8.4元/百万token	约30.3元/百万token
成本倍率	基准	约3.6倍

同一个模型，两个场景的单位成本相差约三点六倍。这意味着，标价上涨对不同用户群体的实际影响截然不同。

四、定价分层的技术合理性

从推理基础设施的角度看，这种定价分层并非毫无依据。

高缓存命中场景下，推理集群的算力利用率更高。预填充阶段的重复计算被大幅消除，单位token对应的GPU时间显著下降。服务提供方能够以更低边际成本服务这类请求，因此让利空间更大。

低缓存命中场景下，每次请求都需要完整的预填充计算，KV Cache频繁创建和销毁，对显存带宽和调度系统造成更大压力。从资源消耗角度看，收取更高费用具有一定的成本合理性。

这实际上形成了一种基于资源消耗程度的差异化定价：复用程度越高，单价越低；复用程度越低，单价越高。

五、面向开发者的成本优化建议

理解了定价结构之后，开发者可以有针对性地优化自身的使用模式，降低综合成本。

5.1 提高缓存命中率的工程实践

稳定系统提示词：将system prompt设计为固定内容，避免每次请求动态拼接。对于Agent场景，可以把工具定义、角色设定等固定部分前置且保持不变。

前缀复用设计：在多轮对话中，尽量保持前缀内容的一致性。例如，不要在中途修改历史消息的格式或顺序，否则会导致后续所有缓存失效。

合理的上下文管理：并非所有历史对话都需要完整保留。可以通过摘要压缩、关键信息提取等方式控制上下文长度，同时保持前缀的稳定性。

# 推荐做法：固定前缀，动态后缀
messages = [
    {"role": "system", "content": FIXED_SYSTEM_PROMPT},  # 始终不变
    {"role": "user", "content": historical_summary},      # 稳定摘要
    {"role": "user", "content": current_query}            # 动态变化
]
# 不推荐：每次重构系统提示词
messages = [
    {"role": "system", "content": f"当前时间{now}，用户{name}..."},  # 每次都变
    ...
]

5.2 输入输出比的优化

输出token的单价远高于输入，因此控制输出长度是降低成本最直接的手段。具体措施包括：

• 在提示词中明确约束输出格式和长度；
• 使用结构化输出（如JSON Schema）减少冗余文本；
• 对于分类、提取等任务，优先使用短输出模板。

5.3 场景与模型的匹配

并非所有任务都需要最高能力的模型。对于简单的分类、格式化、信息抽取等任务，使用轻量级模型即可满足需求，成本可能相差一个数量级。建议建立任务复杂度评估机制，动态路由到不同规格的模型。

六、成本评估的正确姿势

面对任何一次定价调整，开发者都应当建立基于自身场景的加权成本模型，而非简单对比标价。核心评估步骤：

1. 统计实际输入输出比：通过日志分析历史请求的平均输入输出token比例；
2. 测量缓存命中率：关注API返回的缓存命中相关字段，计算实际命中比例；
3. 计算加权单价：代入本文的公式，得出每百万token的综合成本；
4. 对比业务价值：将成本与任务完成质量、开发效率提升等因素综合考量。

七、小结

大模型API的定价正在从“单一标价”走向“结构化分层”。输出价格与缓存命中价格的比值扩大，本质上是在奖励高复用、高缓存命中的使用模式，同时对低复用场景收取更高的资源溢价。

对于企业级Agent开发者而言，如果能够通过架构设计将缓存命中率维持在较高水平，实际成本涨幅可能远小于标价涨幅；而对于每次prompt都不同的散户开发者，则需要更加关注输出长度控制和模型选型优化。

理解定价结构，才能驾驭定价变化。希望本文的测算框架和优化建议，能够帮助你在新一轮价格调整中找到最适合自身业务的成本策略。