开源权重模型把推理单价打到新低点

两家开源权重模型团队同日公布新的推理单价。数字可以争论，方向已经清楚：参数量不再是唯一海报，每百万 token 的成本开始被拿出来比。企业采购说，他们终于可以和云账单对得上；工程负责人则承认，批处理、KV 缓存和更激进的量化，才是把单价压下来的主要手段。

把“更便宜”写成新闻很容易。难的是把账单拆开：输入和输出是否同价、失败重试算不算、长上下文加成有没有被藏在脚注里。单价一旦成为公开指标，这些口径就必须一起公开，否则比较会重新滑回参数竞赛。

公开的是单价，藏住的是口径

过去一年，团队习惯用参数量和基准测试说话。这一次技术博客把每百万 token 的价格放在标题里。可是同一套权重，在不同的批大小、不同的输出长度下，真实成本可以差出一倍以上。采购合同如果只写一个数字，上线后仍会为账单吵架。

更稳妥的做法，是把单价定义成可复现的公式：包含平均输出长度、缓存命中率、以及 2xx 以外的重试。谁能把这张表算给对方看，谁的低价才站得住。

用同一套公式核对报价

下面这段示例把一次请求拆成预填和生成两部分，再按缓存命中折算。它不是生产计费系统，但足够让商务和工程对着同一张表说话。

from dataclasses import dataclass

@dataclass
class Price:
    input_per_m: float   # 每百万输入 token
    output_per_m: float  # 每百万输出 token

def request_cost(price: Price, prompt_tokens: int, output_tokens: int, cache_hit: float) -> float:
    """cache_hit: 0~1，命中部分按输入价的 10% 计。"""
    cached = int(prompt_tokens * cache_hit)
    fresh = prompt_tokens - cached
    input_cost = (fresh * price.input_per_m + cached * price.input_per_m * 0.1) / 1_000_000
    output_cost = output_tokens * price.output_per_m / 1_000_000
    return round(input_cost + output_cost, 6)

def monthly_bill(price: Price, qps: float, avg_in: int, avg_out: int, cache_hit: float, hours=24 * 30) -> float:
    reqs = qps * 3600 * hours
    return round(reqs * request_cost(price, avg_in, avg_out, cache_hit), 2)

# 例：峰值 8 QPS，提示 2.4k、输出 400，缓存命中 55%
print(monthly_bill(Price(0.15, 0.60), qps=8, avg_in=2400, avg_out=400, cache_hit=0.55))

把这段跑一遍，会发现：输出 token 稍一变长，账单的斜率会立刻超过输入侧。这也是为什么厂商开始把输出、工具调用和长上下文加成拆开——他们不是在跟用户过不去，而是在把真实的算力结构写进价目表。

采购口径在变

客户开始要求把可用吞吐写进合同，而不是只写模型名字。评测集上的分数还在，验收改成了高峰时段的延迟和失败率。一个常见条款是：P95 延迟超过约定值的请求，不计费或按折扣结算。这比“支持十万上下文”更难作假。

开源权重降低了切换成本，也抬高了比较的精度。谁都能把同一套权重拉起来，差的是调度、量化策略和运维。单价竞争的下一阶段，会从海报数字变成对账能力。

下一张表

观察者预计，推理单价会在未来两个季度继续被当作公开指标。真正要盯的是：降价之后，幻觉率、工具调用成功率和人工接管次数有没有被一起折进报价单。便宜但需要人反复改的生成，并不便宜。

对应用团队来说，现在就该把 token 会计做进产品：哪些功能走短摘要，哪些才配得上长上下文。等账单先来，再回头加开关，通常已经晚了。