大模型推理定价逻辑与成本结构解析

一、标价上涨的表象与实质

近期某大模型新版本发布后，其API定价引发了广泛讨论。从表面数字看，输出侧价格从上一代的每百万token约27元上涨至100元，输入侧从未命中约6.5元、命中约1.1元调整为未命中20元、命中2元。各档位涨幅在3到4倍之间，看似”全线上涨”。

但定价从来不是单一维度的数字游戏。真正决定用户实际支出的，是有效单价——即综合考虑缓存命中率、输入输出比例之后，每百万token的综合成本。理解这一点，需要先拆解几个关键比值的变化。

1.1 缓存命中与未命中的价格比

在上一代定价中，未命中输入价格约为命中价格的6倍；新版本中，这一比值被拉大到10倍。输出对缓存命中的比值，也从约25倍扩大到50倍。

这意味着什么呢？缓存命中档的涨幅是所有档位中相对温和的，而输出档涨得最凶。定价策略在明确传递一个信号：鼓励缓存复用，惩罚高频输出。

1.2 为什么缓存命中如此关键

在大规模语言模型的推理过程中，KV Cache（键值缓存）用于存储已计算过的注意力键值对。当后续请求的prompt前缀与之前请求一致时，系统可以直接复用这些缓存，跳过重复的prefill计算。

从工程角度看，prefill阶段是计算密集型的，而decode阶段是内存带宽密集型的。缓存命中节省的主要是prefill阶段的计算开销，但decode阶段的成本依然存在。因此，输出侧价格难以下降，而输入侧命中缓存可以大幅打折。

二、两类用户的成本分化

假设两个典型场景，可以清晰看到同一模型下不同使用模式的成本差异。

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

假设输入输出比约为20:1（长上下文编程Agent中很常见），缓存命中率90%：

• 输入侧有效单价 ≈ 2 × 0.9 + 20 × 0.1 = 3.8元/百万token
• 输出侧单价 = 100元/百万token
• 综合每百万token成本 ≈ (20 × 3.8 + 1 × 100) / 21 ≈ 8.4元

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

假设输入输出比5:1，缓存命中率20%：

• 输入侧有效单价 ≈ 2 × 0.2 + 20 × 0.8 = 16.4元/百万token
• 输出侧单价 = 100元/百万token
• 综合每百万token成本 ≈ (5 × 16.4 + 1 × 100) / 6 ≈ 30.3元

同一个模型，场景A的单位成本约为场景B的3.6分之一。表面上的”全线上涨”，实际上对长期跑相同system prompt、prefix高度复用的企业客户是打折的，而对每次prompt都不同的散户开发者则是原价甚至溢价。

三、Agent时代的成本逻辑变了

对话时代，一次交互几十到几千token，用户对价格不敏感，也用不了多少钱。但Agent时代完全不同。

在长上下文编程Agent场景中，单个任务动辄数千步工具调用、几十万token消耗。这类任务如果按旧版价格跑，单次调用是亏钱的——因为推理侧的显存占用、KV Cache存储、decode阶段的带宽消耗，都随上下文长度线性甚至超线性增长。

3.1 架构层面的成本驱动因素

新版本模型采用了更大规模的稀疏架构：参数总量达到2.8万亿级别，896个专家中激活16个。虽然激活参数控制得很好，但以下成本项不可忽视：

• 常驻显存权重：即使稀疏激活，全部专家权重仍需常驻显存或高效换入换出，对显存容量和带宽提出更高要求。
• 专家路由通信开销：MoE架构中，token需要被路由到不同专家，跨设备通信开销随专家数量和分布式程度上升。
• 注意力机制优化：混合注意力机制下的kernel优化需要大量工程投入，才能在实际推理中达到可接受的吞吐。

这些成本最终都会反映在定价中。换句话说，模型能力的提升不是免费的，它需要真金白银的算力投入。

3.2 分离式推理架构的作用

某云厂商在其技术方案中采用了分离式推理架构，将prefill和decode阶段部署在不同资源池中，根据各自的计算特性独立扩缩容。这种架构的核心收益在于：

• Prefill阶段可以批量处理，提高GPU利用率；
• Decode阶段可以针对内存带宽优化，降低单token延迟；
• 缓存命中率在编程场景中可做到90%以上。

高缓存命中率直接压低了输入侧的有效单价，使得企业级Agent场景的综合成本反而低于表面标价所暗示的水平。

四、开发者如何优化推理成本

理解定价逻辑后，可以从以下几个方向优化实际支出：

4.1 提高缓存命中率

• 稳定system prompt：将不随请求变化的指令、工具定义、上下文模板固定在前缀中。
• 复用对话历史：在多轮交互中，尽量保持前缀一致，避免每次重新组织prompt。
• 利用前缀缓存接口：主流推理服务通常提供显式缓存标记或自动缓存机制，合理使用可显著降低成本。

4.2 控制输出长度

输出侧是成本大头。在Agent场景中，可以通过以下方式控制输出：

• 让模型输出结构化数据而非自然语言长文；
• 设置合理的max_tokens上限；
• 对中间步骤使用更轻量的模型，仅关键决策使用大模型。

4.3 选择合适的输入输出比

如果业务场景输出占比高，可以考虑：

• 将部分生成任务拆解为检索+短生成；
• 使用流式输出配合早停策略；
• 对非关键路径使用小模型。

4.4 监控与归因

建立token级成本监控，按业务线、Agent任务、用户维度归因，识别高成本环节。代码示意：

# 伪代码：按任务维度统计token成本
cost_per_million_input_hit = 2
cost_per_million_input_miss = 20
cost_per_million_output = 100
def estimate_cost(input_tokens, output_tokens, cache_hit_rate):
    hit = input_tokens * cache_hit_rate
    miss = input_tokens * (1 - cache_hit_rate)
    input_cost = (hit * cost_per_million_input_hit + miss * cost_per_million_input_miss) / 1_000_000
    output_cost = output_tokens * cost_per_million_output / 1_000_000
    return input_cost + output_cost

五、总结

大模型推理定价的上涨，不能只看标价数字。缓存命中率、输入输出比、架构成本共同决定了实际支出。企业级Agent场景凭借高缓存复用率，有效成本可能远低于表面价格；而散户开发者如果每次prompt都不同，则承担了接近原价的成本。

对于开发者而言，理解这套定价逻辑的意义在于：优化缓存策略、控制输出长度、合理选择模型规模，比单纯比较标价更能决定最终账单。在Agent时代，成本优化本身就是工程能力的一部分。