大模型API定价逻辑与单位任务成本评估

一、问题的提出：单价上涨背后的真实成本信号

近期某代大模型API的定价调整引发了开发者社区的广泛讨论：输出价格较上一代提升数倍，输入与缓存命中价格也同步上调。表面上看，这是一次明确的价格上涨；但若仅停留在“每百万token多少钱”的对比层面，很容易得出片面结论。真正影响团队预算的，从来不是单价本身，而是完成一个典型任务所需要消耗的token总量，以及套餐额度与实际用量之间的折算关系。

本文不针对任何具体厂商产品做推荐或测评，而是从通用技术经济学的角度，拆解大模型API定价的评估方法，给出一套可复用的成本分析框架。

二、为什么单价对比容易失真

2.1 计价维度的非对称性

主流大模型API通常采用三段式计价：输入token、输出token、缓存命中token。三者的价格比例在不同厂商、不同代际之间差异显著。有的产品输入便宜、输出昂贵；有的则相反。仅比较“输出单价”或“输入单价”中的某一项，无法反映综合成本。

更合理的做法是构造一个加权单价：

def weighted_price(input_price, output_price, cache_price,
                   input_tokens, output_tokens, cache_tokens):
    """
    计算单次任务的加权成本（单位：元）
    价格参数单位为 元/百万token
    """
    cost = (input_tokens * input_price +
            output_tokens * output_price +
            cache_tokens * cache_price) / 1_000_000
    return cost

只有当输入输出比例与实际业务负载匹配时，这个加权值才有意义。

2.2 任务消耗量的差异被低估

不同模型完成同一任务所需的token量可能相差悬殊。原因包括：推理链长度不同、是否内置结构化输出、是否倾向于冗长解释、工具调用轮次多少等。一个在基准测试中排名靠前的模型，如果平均每任务消耗量显著高于竞品，那么即使单价持平，单位任务成本也可能更高。

因此，评估时必须引入平均每任务消耗量这一指标。它可以通过小规模抽样压测获得：

import statistics
def avg_tokens_per_task(samples):
    """
    samples: 每个元素为 (input_tokens, output_tokens) 的元组列表
    """
    totals = [i + o for i, o in samples]
    return statistics.mean(totals), statistics.median(totals)

均值反映总体预算，中位数反映典型体验，两者结合才能避免长尾任务拉偏判断。

三、套餐额度折算：被忽视的关键环节

3.1 订阅制与按量计费的换算

许多平台提供订阅套餐，宣称“每月固定费用，包含一定额度”。但额度通常以“折算金额”或“token总量”表示，二者不可直接比较。评估时需要把套餐还原为有效单价：

def effective_unit_price(monthly_fee, included_value):
    """
    monthly_fee: 套餐月费（元）
    included_value: 套餐包含的折算额度（元）
    返回：每元额度对应的实际成本系数
    """
    return monthly_fee / included_value

若某套餐月费为A元，包含折算额度为B元，则系数为A/B。系数越接近1，套餐越接近“按量计费”；系数明显大于1，说明套餐存在溢价，溢价部分对应的是稳定性、优先队列、技术支持等附加价值。

3.2 额度是否“够用”取决于任务画像

一个套餐的额度是否充足，取决于团队的任务画像：任务数量、平均消耗量、缓存命中率。可以用下面的公式做月度估算：

def monthly_cost_estimate(tasks_per_month, avg_tokens,
                          price_per_million, cache_hit_rate=0.0,
                          cache_discount=0.1):
    """
    price_per_million: 综合加权单价（元/百万token）
    cache_discount: 缓存命中部分相对正常输入价的折扣系数
    """
    effective_tokens = tasks_per_month * avg_tokens
    cached = effective_tokens * cache_hit_rate
    normal = effective_tokens - cached
    cost = (normal * price_per_million +
            cached * price_per_million * cache_discount) / 1_000_000
    return cost

这个估算揭示了一个常被忽略的事实：缓存命中率对总成本的影响可能比单价差异更大。在高重复性场景（如固定系统提示词、长文档问答）中，缓存命中价格的低廉可以显著摊薄整体成本。

四、能力与成本的联合评估框架

4.1 三维评估模型

建议从三个维度联合评估一个模型是否“贵得合理”：

1. 能力维度：在目标业务场景上的通过率、准确率、稳定性。基准测试排名可作为参考，但不能替代业务场景实测。
2. 消耗维度：平均每任务token消耗量、完成任务所需轮次、失败重试率。
3. 价格维度：加权单价、缓存命中价、套餐折算系数。

三者结合，才能得到单位有效任务成本：

单位有效任务成本 = 加权单价 × 平均消耗量 ÷ 任务成功率

分母的任务成功率是关键修正项。一个便宜但成功率低的模型，因重试带来的额外消耗可能反而更贵。

4.2 决策矩阵示例

场景特征	优先关注	建议策略
高频短任务、提示词固定	缓存命中价	优先利用缓存，压低输入成本
长文档理解、输入为主	输入单价与上下文窗口	关注输入计价与截断策略
复杂推理、输出较长	输出单价与消耗量	抽样压测平均输出长度
低频高价值任务	能力与稳定性	单价敏感度低，优先成功率

五、工程侧的降本实践

5.1 提示词与上下文管理

• 将稳定的系统提示词置于前缀位置，提高缓存命中概率；
• 对长上下文做分段摘要，避免每次全量传入；
• 使用结构化输出约束，减少无效输出token。

5.2 路由与分级

按任务难度分级路由：简单任务走轻量模型，复杂任务走强模型。这种策略在多数团队中能带来显著的成本下降，同时不牺牲关键任务质量。

5.3 监控与回归

建立token消耗的持续监控，按任务类型打点，定期回归平均消耗量与成功率。价格调整后，应重新跑一遍抽样压测，而不是沿用历史数据。

六、结论

大模型API的定价上涨本身不是问题，问题在于评估方法是否足够精细。单看每百万token单价，容易得出“贵”或“便宜”的粗结论；引入平均任务消耗量、缓存命中率、套餐折算系数和任务成功率之后，才能得到贴近真实预算的单位有效任务成本。

对开发者和企业而言，理性的做法是：建立自己的任务画像与压测基线，用代码化的方式持续核算成本，并在能力、消耗、价格三者之间寻找平衡点。价格只是输入变量之一，真正决定总成本的是任务结构本身。