推理成本决定大模型竞争格局：从能耗与吞吐出发的成本模型推演

一、为什么“每度电能产多少 token”是一个关键问题

讨论大模型市场格局，常见的切入点是参数规模、榜单排名、评测分数。但对真正把模型接入生产系统的团队而言，决定长期胜负的往往不是某一次评测的名次，而是单位经济性：生成一个 token 需要多少算力、多少电、多少折旧，最终折算成多高的服务成本。

推理成本是唯一能同时连接“技术效率”和“商业可持续性”的指标。它向下约束硬件选型与集群设计，向上决定 API 定价、免费额度、以及是否可能长期维持低价策略。因此，把“每度电能产出多少 token”算清楚，比讨论单点跑分更有解释力。

下面建立一个可复算、可替换假设的成本模型。文中所有数值均为用于说明量级关系的示例性假设，读者可替换为自己集群的真实参数重新计算。

二、第一步：单 token 能耗的推算方法

2.1 有效功耗的构成

单卡功耗不能只看芯片本身。一个可用于推理的集群，实际功耗至少包括：

• 加速卡本身的运行功耗；
• 机房制冷开销；
• 网络交换、CPU、内存与存储的配套开销；
• 供电与配电损耗。

业界通常用 PUE（Power Usage Effectiveness）描述“总能耗 / IT 设备能耗”。设单卡运行功耗为 P，PUE 为 k，则单卡分摊的总功耗近似为 P × k。这是做成本估算时最容易被低估的一环——只按芯片标称功耗计算，会系统性低估 20%～30%。

2.2 吞吐量：真正的分母

生成阶段（decode）是逐 token 自回归的过程，吞吐量以“每卡每秒输出 token 数”衡量。这个数值强依赖于模型规模、批大小（batch size）、量化精度、KV Cache 策略与调度实现。

关键点在于：吞吐量不是一个固定值，而是一个可优化区间。连续批处理（continuous batching）、PagedAttention 类显存管理、 speculative decoding、量化推理等手段，都会显著改变分母。因此成本估算应给出区间而非单点值。

2.3 计算示例

假设某前沿模型在批量推理场景下：

• 单卡运行功耗约 700W；
• PUE 取 1.3，则有效功耗约 900W，即 900 焦耳/秒；
• 单卡聚合输出速度取 1000 token/秒（保守区间可取 500～3000）。

则每输出 1 个 token 的能耗为：

900 J/s ÷ 1000 token/s = 0.9 J/token

一度电为 3,600,000 焦耳，因此：

3,600,000 ÷ 0.9 ≈ 400 万输出 token / 度

这个量级说明：在合理优化的集群上，电力成本在单 token 总成本中占比并不高。真正的成本大头往往是硬件折旧、集群利用率与闲置浪费。

三、第二步：输入侧与混合比例的影响

3.1 预填充为何更“便宜”

预填充（prefill）阶段对输入序列做并行计算，可一次处理大量 token，吞吐远高于逐 token 生成的 decode 阶段。若假设预填充吞吐约为每卡每秒 1 万 token，则单 token 能耗约为：

900 J/s ÷ 10000 token/s = 0.09 J/token

即每度电可处理约 4000 万输入 token，量级上比输出侧高一个数量级。这解释了一个工程事实：长输入、短输出的场景（如文档摘要、检索增强问答）单位成本显著低于长输出场景（如长文生成、多轮推理链）。

3.2 输入输出比例决定综合成本

真实业务中输入与输出 token 并存。设典型比例为 3:1（输入:输出），则综合能耗为加权平均：

(3 × 0.09 + 1 × 0.9) / 4 ≈ 0.2925 J/token

对应每度电约产出 1200 万混合 token。若按输出侧与输入侧的不同单价折算收入，可得到“每度电对应的收入区间”。原文给出的 100～800 美元/度的宽区间，本质上反映的是吞吐量与混合比例的不确定性——这也正是成本模型必须做成参数化表格而非单一数字的原因。

3.3 一个可复用的估算脚本

def cost_per_million_tokens(
    card_power_w=700,
    pue=1.3,
    decode_tps=1000,
    prefill_tps=10000,
    in_out_ratio=3.0,
    price_per_kwh=0.6,   # 示例电价，单位：元/度
):
    joule_per_sec = card_power_w * pue
    e_out = joule_per_sec / decode_tps        # J/token
    e_in = joule_per_sec / prefill_tps        # J/token
    e_mix = (in_out_ratio * e_in + e_out) / (in_out_ratio + 1)
    tokens_per_kwh = 3_600_000 / e_mix
    kwh_per_million = 1_000_000 / tokens_per_kwh
    return {
        "joule_per_token_mixed": round(e_mix, 4),
        "tokens_per_kwh": int(tokens_per_kwh),
        "kwh_per_million_tokens": round(kwh_per_million, 4),
        "power_cost_per_million": round(kwh_per_million * price_per_kwh, 4),
    }
print(cost_per_million_tokens())

这段脚本的价值不在于具体输出，而在于把“电价、PUE、吞吐、比例”四个变量显式暴露出来，便于团队按自己集群的实测数据替换。任何不可参数化的成本结论都不可信。

四、从成本结构看市场格局的演化方向

4.1 低价策略的可持续性取决于利用率而非电价

由上面的模型可知，电力成本在单 token 成本中占比有限，硬件折旧才是主项。而折旧成本与集群利用率强相关：同样一批卡，利用率 30% 与 70% 的单 token 摊销成本可能相差一倍以上。

由此可推出两个判断：

1. 能够长期维持低价的服务方，靠的不是“电便宜”，而是高利用率 + 高吞吐优化 + 规模化采购；
2. 单纯以低价获客、但利用率不足的服务，其价格不可持续，会在算力紧张或硬件迭代时被迫回调。

这意味着市场竞争的实质是工程效率竞争，而非单纯的资本补贴竞争。

4.2 成本下降会推动能力下沉与场景扩散

当单位 token 成本下降一个量级，原本不经济的长上下文、多轮 agent 调用、批量数据加工等场景会变得可行。这带来的不是“同一个市场里的价格战”，而是市场边界的扩张：更多任务被纳入自动化范围，推理总需求反而上升。

历史上算力单位成本下降多次出现“单价降、总支出升”的现象，原因正是新场景被激活。因此，评估一个模型或平台的影响，不能只看它抢了多少存量份额，还要看它是否打开了新的可服务场景。

4.3 闭源与开源的边界由“总拥有成本”决定

原文的强判断是“未来闭源模型必死无疑”。更严谨的表述应当是：闭源模型的定价空间受限于自建或托管开源模型的总拥有成本（TCO）。

企业选择闭源 API 的理由通常包括：免运维、弹性、能力上限高、合规与支持服务。选择自建开源的理由包括：数据可控、单位成本可优化、可深度定制。两者的分界线随以下因素移动：

因素	倾向闭源 API	倾向自建/托管
请求量	低、波动大	高、稳定
团队运维能力	弱	强
数据敏感性	低	高
定制需求	少	多
能力要求	逼近前沿	中等即可满足

因此更准确的结论是：中间地带的闭源服务会被挤压，而具备明确能力溢价或服务溢价的部分仍有空间。成本模型的作用，是让企业在每个具体场景下算清这条分界线在哪里。

五、给开发者的实践建议

1. 建立自己的成本仪表盘：把 PUE、卡功耗、实测吞吐（分 prefill/decode）、输入输出比例、电价、折旧年限作为固定字段，定期更新。不要引用他人的单点数字做容量规划。
2. 区分 prefill 与 decode 做优化：长输入场景优先优化批处理与缓存复用；长输出场景优先优化解码策略与显存管理。两者优化手段不同，混为一谈会浪费投入。
3. 用利用率反推架构：先估算业务波峰波谷，再决定自建规模与弹性 API 的配比。峰值全部自建通常不经济。
4. 关注单位任务成本而非单位 token 成本：一个任务需要多少 token、多少重试、多少人工兜底，才是最终账。token 单价低但重试率高的方案可能更贵。
5. 把成本模型纳入技术选型评审：模型选型不应只由评测分数决定，应同时给出“任务质量 / 单位任务成本”的比值。

六、小结

“每度电能产多少 token”之所以值得认真计算，是因为它把模糊的“算力竞争”还原成了可验证的工程问题：功耗、PUE、吞吐、比例、利用率、折旧。评测排名会随版本迭代反复变化，而成本结构的差异是结构性的、难以短期抹平。

对市场格局的判断因此应回归两条主线：一是工程效率决定谁能长期维持合理价格；二是成本下降会扩张而非仅仅重分配市场。对企业与开发者而言，最稳妥的策略不是押注某一次榜单结果，而是建立自己的成本模型与优化闭环——在价格与能力都快速变化的阶段，能算清账的一方始终占据主动。