大模型API峰谷定价的经济学解读

一、背景：一次“回归成本”的定价结构调整

近期，国内某头部大模型服务商对API计费进行了调整，方向有两个：一是引入峰谷定价，低谷时段给出明显折扣；二是重新划分了输入、输出与上下文缓存三类token的价格梯度。表面上看只是价格数字的变化，实质上反映了大模型推理服务从“补贴获客”走向“成本定价”的行业拐点。

在国内，百度智能云等云平台同样以token为基本计量单位对外开放大模型能力，“按用量计费+差异化定价”已成为行业共识。理解这类调价背后的经济学逻辑，对每一个依赖大模型API的开发团队都有直接价值：价格结构变了，架构与用法也应该跟着变。

二、峰谷定价的经济学内核：算力是不可储存的商品

2.1 为什么借用电力行业的“老办法”

峰谷定价（peak-load pricing）并不是新发明，电力、电信、航空、酒店行业早已实践多年。它的适用前提有三个，而大模型推理恰好全部满足：

1. 产品不可储存。一度电、一秒GPU算力如果不能在产生时被消费，就永远浪费了。推理算力同理，凌晨闲置的显卡集群无法“存起来”留给白天使用。
2. 产能刚性。GPU集群从采购、上架到稳定服务以月为单位计，短期内供给接近一条垂直线，无法随需求灵活伸缩。
3. 需求波动巨大。推理负载在一天内呈现明显的双峰与深谷，峰谷负载比可以达到数倍。

在这样的成本结构下，固定成本（集群建设、机房、电力基本负荷）占比极高，而边际成本（多服务一个请求的额外开销）相对较低。经济学的定价原则是：高峰时段的用户承担容量成本，低谷时段的用户只需覆盖边际运营成本。因此，低谷降价并不是“亏本让利”，而是把本来会闲置浪费的算力以任意正价格卖出，都是增量收入，同时还能摊薄全系统的平均成本。

2.2 价格歧视的精细化

换个角度看，峰谷定价也是一种基于“支付意愿”的价格分层：

• 在线对话、生产链路中的实时调用，对时延敏感、对价格不敏感，属于高支付意愿用户，自然留在高峰时段；
• 批量评测、语料清洗、合成数据生成等离线任务，对时延不敏感、对价格高度敏感，属于低支付意愿用户，会被折扣“撬动”到低谷时段。

理想的结果是一个帕累托改进：厂商提高了设备利用率与总收入，实时用户获得了更充裕的峰值容量，价格敏感用户以更低成本完成了任务。拉姆齐定价的思想也在此体现——对需求弹性小的时段定高价，对弹性大的时段定低价，让稀缺的算力流向最需要它的地方。

三、被忽视的主角：缓存计费为何影响最大

3.1 这次调整中“涨得最凶”的是缓存

不少人把注意力放在输入、输出单价的数字上，但真正影响成本结构的是上下文缓存（context cache）的计价变化。此前部分厂商把缓存命中价格定得极低，甚至出现旗舰模型的缓存命中单价与轻量模型的普通输入单价几乎持平的情况——从成本角度看，这更像一种获客补贴而非可持续定价。本轮调整后，缓存价格回归到与其真实成本相匹配的水平，反而是“正常化”了。

3.2 缓存的成本逻辑

理解缓存定价，要先理解推理的执行过程。大模型处理请求分为预填充（prefill）与解码（decode）两个阶段：预填充要对全部输入token做一遍并行计算，生成注意力的键值缓存（KV Cache）；解码阶段则逐token生成输出。如果两次请求的前缀完全相同，预填充的结果可以直接复用，省掉大量重复计算。

这意味着：

• 对厂商：缓存命中省去了重复的预填充计算，但缓存需要在显存/内存中驻留一段时间，占用存储与带宽资源，还有生命周期管理成本。缓存命中比未命中便宜是成本使然，但不应该便宜到接近免费。
• 对用户：缓存命中比例直接决定实际账单。同样的输入长度，命中率90%与命中率0%的成本可能相差一个数量级。

3.3 为什么Agent场景首当其冲

Agent是对缓存最敏感的应用形态，原因在于其工作模式：

1. 长稳定前缀。系统提示词、工具定义、少样本示例动辄数千甚至上万token，且在整次任务中保持不变。
2. 高频循环调用。Agent每一步工具调用都是一次完整请求，同一次任务内的请求会反复携带几乎相同的前缀。
3. 上下文持续累积。多轮交互使历史消息不断叠加，未命中缓存的重复计费部分随轮次近似线性增长。

做一个示意性测算：假设某Agent单次请求输入20,000 token，其中18,000 token是稳定的系统提示与工具定义，动态部分仅2,000 token。若缓存命中单价为普通输入的十分之一（示意比例），命中率从0提升到90%，单次请求的输入成本约可下降70%以上。在每天数万次调用的生产系统中，这就是每月数万元量级的差别。缓存单价的小幅波动，经过“长前缀×高频次”的放大，最终成为账单上最大的一块——这正是“最大涨幅其实是缓存”的原因。

四、需求侧画像：开发者的时间分布决定了政策效果

4.1 使用主体在国内

峰谷定价能否奏效，取决于需求的时间分布。以该服务为例，其使用大头并不是海外用户，而是国内开发者与企业。国内程序员的典型工作节奏是上午9点到12点、下午2点到6点，日均有效工作约7小时——并不是外界想象的996。但另一个事实同样重要：这种节奏每周7天几乎都在持续，AI编程助手已经成为日常工具而非尝鲜玩具。

4.2 由此形成的需求曲线

把上述两个事实叠加，可以推断出负载曲线的形状：每个工作日存在上午、下午两个高峰，午休形成一个小低谷，夜间则是深谷；周末白天维持次高峰，夜间同样空闲。峰值算力必须按白天的高峰去准备，夜间却大量闲置——峰谷定价正是针对这条曲线的精确响应。当夜间折扣幅度足够大时，弹性任务会自然迁移，白天的高峰压力得以缓解，厂商也能用更小的冗余容量支撑同样的总请求量。

五、开发者应对：缓存工程与错峰调度

价格结构变了，工程实践也应该跟着优化。以下几点是可以立刻落地的策略：

5.1 缓存友好的上下文设计

核心原则是“稳定前缀、动态后置”：

[稳定前缀]  系统提示 + 工具定义 + Few-shot 示例   ← 尽量逐字节不变，吃缓存命中
[动态后缀]  本轮用户输入 + 检索结果 + 中间状态     ← 每次变化的部分，按普通输入计价

具体注意：不要在稳定前缀中插入时间戳、随机ID、随请求变化的统计数字等“缓存杀手”；多轮对话延续同一会话前缀，而不是每次重排历史消息；工具定义等长文本尽早固定下来。

5.2 错峰批处理调度

把对时效不敏感的任务（批量评测、语料清洗、合成数据、回归测试）迁移到低谷时段，示意骨架如下：

import datetime
from queue import Queue
OFF_PEAK_HOURS = set(range(0, 8))  # 假设 0:00-8:00 为低谷时段
def in_off_peak(now: datetime.datetime) -> bool:
    return now.hour in OFF_PEAK_HOURS
class OffPeakScheduler:
    def __init__(self):
        self.pending = Queue()
    def submit(self, task):
        self.pending.put(task)
    def run(self):
        while not self.pending.empty():
            task = self.pending.get()
            if in_off_peak(datetime.datetime.now()):
                task.execute()                       # 低谷：立即执行，享受折扣
            else:
                task.suspend_until(next_off_peak())  # 高峰：挂起，等低谷再跑（省略实现）

再配合基本的成本可观测性——按“缓存命中/缓存未命中/输出”三类token分别统计，并为每类任务建立单位成本基线（如单次评测、单个需求的推理开销），就能在每次调价后快速评估影响并调整策略。

5.3 混合模型策略

高峰时段用轻量模型兜底处理简单请求，低谷时段再用旗舰模型批量复核与精修，是错峰定价下值得考虑的架构折中。它把“模型选择”从静态配置变成了随价格信号动态调整的调度问题，进一步压低单位任务成本。

六、结语：价格信号正在重塑应用架构

从经济学视角看，这轮调价没有任何“反常”：峰谷定价是对不可储存算力的标准定价方案，缓存差异化计价是对真实成本结构的还原。真正值得开发者关注的是，价格已经从“背景参数”变成了“架构信号”——缓存命中率、调用时段、任务时效性，都开始直接映射到账单。提前把上下文工程与错峰调度纳入设计考量的团队，会在下一轮成本竞争中占据明显优势。