✏️ LLM 定价的数学原理 03：从推理耗时到推理成本

📖

上一篇咱们把推理过程写成了方程，解出了延迟最优的「甜蜜点」。这一篇，咱们换个视角看同一套方程——从用户视角换成运营方视角。同一套底层公式，Y 轴一换，整张图就讲一个完全不同的故事。看完你会理解：为什么不 Batch 的运营成本会比甜蜜点贵几千倍、AI 服务的规模经济到底来自哪里、第三方 inference provider 的商业逻辑是什么，以及为什么「贵 + 快」做得到、而「便宜 + 慢」物理上不可行。

🧭

前情提要：上一篇把推理过程写成方程解出了「甜蜜点 ≈ 300 × 稀疏度倒数」这个延迟最优的 Batch 大小。但那张图回答的是用户视角的问题——「我要等多久」。这一篇咱们换成运营方视角——「我每生产一个 token 要花多少钱」。

一、延迟和成本：两件不同的事

咱们要先把两件事分开：延迟和成本，看的是同一个推理过程，但视角完全不同。

延迟（上一篇画的图）

我是用户，我盯着屏幕等
我关心：我要等多久才能拿到一个 token？
Y 轴 = T（每生成一个 token 花的总时间）

成本（这一篇要画的图）

我是服务运营方（OpenAI、Anthropic、某个 provider）
我关心：我每生产一个 token，要花多少钱？
Y 轴 = ?

那 Y 轴到底该是什么？得想一下。

二、推出每 token 成本公式

钱花在哪？

运营推理服务，你付的是**「租 GPU 的时间费」**。比如 H100 大约 $2/小时。所以一段时间内的总成本：

\text{总成本} = \text{GPU 单价} \times \text{这段时间的长度}

为简化，我们把 GPU 单价当作 1（选一个货币单位）。那么一次推理的总成本就直接等于 T：

\text{某次推理的总成本} = T

单位：每 token 成本

但运营方关心的不是「一次推理多少钱」，而是「每个 token 多少钱」——因为他向用户也是按 token 收费。

那这次推理产出了多少 token？

🔑 重点在这里：一次「前向传播」（把所有参数搬运一遍 + 算一遍），会生成 B 个 token——Batch 里每个用户都拿到一个新 token。

所以：

\text{每 token 成本} = \frac{\text{总成本}}{\text{产出的 token 数}} = \frac{T}{B}

🔑 这就是工程师们在白板上反复写的那个 T/B。Y 轴就是它。

三、把 T/B 写出来：可摊销 vs 不可摊销

回想上一篇的核心方程：

T = \max(T_{memory},\ T_{compute})

T_{memory} = \frac{N_{total}}{BW} + \frac{B \times L \times b}{BW}, \quad T_{compute} = \frac{B \times N_{active}}{C}

每 token 成本 = T/B，咱们把每一项都除以 B，三项的形态立刻分化得很明显：

T_compute / B：算力常数

\frac{T_{compute}}{B} = \frac{B \times N_{active} / C}{B} = \frac{N_{active}}{C}

🔑 算力成本是常数——不依赖 B。这很合理：每个用户都要「算自己那份」，所以平均到每用户的算力时间就是固定的。

T_memory / B：双曲线 + 常数

\frac{T_{memory}}{B} = \underbrace{\frac{N_{total}}{B \times BW}}_{\text{双曲线}} + \underbrace{\frac{L \times b}{BW}}_{\text{常数}}

🔑 两项形态完全不同：

搬参数项除以 B 之后变成双曲线——B 越大这一项越小，这就是 Batch 的经济学价值！

搬 KV 项除以 B 之后变成常数——因为 B 既出现在分子（用户多就要搬多）又出现在分母（摊给多人），完全抵消了

后者正是咱们一直说的「KV 摊不掉」——不管 Batch 多大，人均 KV 搬运成本不变。

合起来：每 token 成本

🎯

\text{Cost/token} = \max\left(\underbrace{\frac{N_{total}}{B \times BW}}_{\text{搬参数（双曲线）}} + \underbrace{\frac{L \times b}{BW}}_{\text{搬 KV（常数）}},\ \underbrace{\frac{N_{active}}{C}}_{\text{算力（常数）}}\right)

三项中只有第一项被 B 摊销，后两项都摊不掉。

四、画出成本图

横轴还是 B，但 Y 轴换成了 每 token 成本。咱们一项一项画。

第一项：搬参数 / B（双曲线）

N_total / (B × BW)，B 越大越小：


成本
  │
  │ ╲
  │  ╲
  │   ╲
  │    ╲
  │      ╲
  │        ╲___
  │            ─────────────
  │
  └─────────────────────► B
  0

🔑 B 越接近 0，这一项就涨得越离谱——一个用户独自扛下所有参数搬运成本，完全没摊销，贵到离谱。这就是为什么「不 Batch」的经济学根本不成立。

第二项：搬 KV / B（常数，KV 线）

L × b / BW，水平线，高度由上下文长度决定。

第三项：算力 / B（常数，算力线）

N_active / C，另一条水平线。

三项叠加：要小心几何关系

把三项叠加，关键问题：算力线和 KV 线，谁高谁低？

要让甜蜜点（双曲线下降时与水平线相交）能存在，算力常数线必须高于 KV 常数线：

\frac{N_{active}}{C} > \frac{L \times b}{BW}

🔑 物理含义：在「正常」的模型 + 上下文配置下，算力是比 KV 更「贵」的成本——所以达到甜蜜点之后，瓶颈是算力，不是 KV。这跟上一篇默认的「短上下文场景内存项可忽略」是一致的。

所以成本图实际上长这样：


成本
  │ ╲
  │  ╲           ← 双曲线段（memory-bound）
  │   ╲             双曲线 + KV 常数
  │    ╲
  │     ╲
  │      ╲___
  │  ─────────╳───────────── ← 算力常数 N_active/C
  │           ↑ 甜蜜点
  │
  │  ─────────────────────  ← KV 常数 L×b/BW（在算力常数下方）
  │
  └──────────────────────► B

最终成本曲线 = 取上面那条：


成本
  │ ╲
  │  ╲      ← memory-bound 区（双曲线主导）
  │   ╲
  │    ╲
  │     ╲___
  │  ────────╳──────────── ← compute-bound 区（算力常数主导）
  │          ↑
  │        甜蜜点
  │
  └──────────────────────► B
  0

五、读这张图：三个区域

区域	谁主导	状态	运营方处境
B 很小	双曲线	成本爆炸	运营方亏死
甜蜜点	双曲线 = 算力	成本接近最低点	最佳运营点
B 很大	算力常数	成本平稳在算力下界	饱和，再加 Batch 没收益

成本下界

注意右侧的水平渐近线高度。在正常配置下（算力线高于 KV 线）：

\text{Cost/token 下界} \approx \frac{N_{active}}{C}

🔑 这是单 token 成本的物理下限。它的意思是「工人全速干活时，每个用户那份工作的成本」——再大的 Batch 也省不了，因为算的工作量是每个用户独有的，Batch 帮不上忙。

六、回答三个常见问题

有了这张图，前两篇里反复出现的几个问题都能给出干净的几何答案。

问题 1：「不开 Batch 差 1000 倍」从哪来？

代入 B=1 时（一个用户独占）的成本：

\text{Cost/token}(B=1) \approx \frac{N_{total}}{BW}

代入甜蜜点（B ≈ 几千）时的成本：

\text{Cost/token}(\text{甜蜜点}) \approx \frac{N_{active}}{C}

两者比例：

\frac{N_{total}/BW}{N_{active}/C} = \frac{N_{total}}{N_{active}} \times \frac{C}{BW} = \text{稀疏度倒数} \times 300

代入 DeepSeek V3：18 × 300 ≈ 5400 倍。

🔑 这就是「差 1000 倍」的精确来源——其实是 5400 倍。不开 Batch 的经济学根本不成立，这不是工程偷懒，是物理上就这样。

当然现实里没人真用 B=1 跑——continuous batching、多用户排队这些机制几乎一定会把 B 抬上来。这个 5400× 是理论上界，意义不在”真的会差这么多”，而在告诉你：Batch 不是性能调优可选项，是经济学必需品。

问题 2：为什么 AI 服务有强烈的规模经济？

把成本曲线想象成一个梯子：

大厂（OpenAI / Anthropic）：用户量充足，能稳定把 Batch 钉在甜蜜点 → 人均成本接近下界
小厂：用户量不到甜蜜点，比如 Batch 只能撑到 500，最优是 5000 → 卡在双曲线下降段中部
独占模式：单个企业客户独占 GPU → 卡在最左端，成本按 1/B 急剧上涨

🔑 「用户量增长直接转化为利润率改善」是 AI 服务的结构性性质——只要还在双曲线段，每多一个用户都是边际成本递减。这也是为什么大厂对小厂有结构性成本优势——小厂的 Batch 开不起来，人均成本永远高一档。

问题 3：第三方 inference provider 的商业逻辑是什么？

像 Together AI、Fireworks、DeepInfra 这类第三方 inference provider 的生意，本质就是上面那条曲线在变现：

📌 本质：把多个小客户的请求合并成一个大 Batch——单个客户自己跑达不到的 Batch 大小，聚合起来就能跑到甜蜜点。Provider 的毛利，就来自这一次 Batch 摊销出来的差价。

📎 顺便澄清一下：OpenRouter 这种聚合 API 网关自己不做推理，它只是把请求路由到上游 provider、统一计费抽佣。真正在做 batch 聚合的是上游的 inference provider；OpenRouter 的价值更多在统一接口和模型选择，不是 batch 经济学。

注意聚合本身有天花板：不同模型不能共享 Batch，所以一个 inference provider 的有效 Batch 仍然受限于它服务的模型分布。

七、回到「贵+快」与「便宜+慢」之谜

第一篇开头咱们留了个问题：能不能「100× 价格换 100× 速度」、或者「100× 慢换 100× 便宜」？现在咱们能自己用图回答了。

把延迟图和成本图叠在一起


延迟图（用户视角）        成本图（运营视角）

T                          Cost/token
│      ╱                  │ ╲
│    ╱                    │  ╲
│  ╳   ← 延迟最优在交叉点  │   ╲___
│ ╱                        │      ╳ ← 成本最优也在交叉点
│                           │       ─────── 之后水平
│                           │
└──────► B                  └──────────► B
   ↑                            ↑
  在交叉点之前：               在交叉点之前：
  加 Batch 不影响延迟         加 Batch 显著降成本

  在交叉点之后：               在交叉点之后：
  加 Batch 直接增加延迟        加 Batch 几乎不再降成本

🔑 几何关键事实：两张图的交叉点是同一个 B——都是 B = 300 × 稀疏度倒数，因为底层是同一个方程。

这意味着什么？

运营方面对一个抉择：

B = 甜蜜点：成本接近下界 ✅，延迟也接近下界 ✅，完美
B > 甜蜜点：成本几乎不再降低，但延迟开始线性上涨
B < 甜蜜点：延迟没变好（还是物理下界），成本按 1/B 急剧上涨，纯亏

🔑 理性的运营方就该把 Batch 钉在甜蜜点。这不是「在用户体验和成本之间艰难权衡」——两者在同一个点上同时最优。这是 LLM 推理经济学最优雅的一个性质。

「加速档」在做什么？

各家供应商提供的「加速档」（比如某 provider 用几倍的价格换两到三倍的速度）干的事其实很简单：让你独占 Batch 里更大的一份份额，把整个系统从甜蜜点往「B 更小」的方向挪。

普通模式：你和上千个用户共享一台机器
加速档：让你「占 N 个用户的位置」，等效 Batch 变小 → 移到延迟图的更左边
但延迟图左边是平的（已经撞到物理下界），所以速度只能提升有限的倍数
同时把成本曲线推到双曲线段，成本暴涨 → 所以要按倍数收溢价

🔑 为什么不能「100× 价格换 100× 速度」？ 因为延迟下界是参数搬运时间这个物理墙。加速档能做的最多就是把你从 compute-bound 区拉回 memory-bound 区，达到那个延迟下界——再多花钱也撞不破这堵墙。

那「便宜+慢」呢？

也讲不通。因为成本曲线在 B > 甜蜜点 之后是水平的——你愿意多等也省不了钱。

🔑 结论：

✅ 「贵+快」可行（直到撞墙）

❌ 「便宜+慢」不可行（成本下界是硬性物理常数）

八、一张表收尾

量	公式	几何	对 B 的依赖
搬参数成本 / token	`N_total / (B × BW)`	双曲线	可摊销（B 越大越便宜）
搬 KV 成本 / token	`L × b / BW`	水平线	摊不掉
算力成本 / token	`N_active / C`	水平线	摊不掉
总成本 / token	`max(双曲+KV, 算力)`	先降后平	在甜蜜点最低
成本下界	`≈ N_active / C`	右侧水平渐近线	B 趋于无穷时的极限

核心方程：

\boxed{\ \text{Cost/token} = \max\left(\frac{N_{total}}{B \cdot BW} + \frac{L \cdot b}{BW},\ \frac{N_{active}}{C}\right)\ }

「不开 Batch 差多少倍」的来源：

\boxed{\ \frac{\text{Cost}(B=1)}{\text{Cost}(\text{甜蜜点})} \approx 300 \times \frac{N_{total}}{N_{active}}\ }

九、留几个可以自己想的问题

某 provider 给你报价 GPT-4 级别模型 $0.5/1M tokens（输出），你估算它的算力下界对应实际成本约 $0.3/1M tokens。这家 provider 处于成本曲线的哪个区域？如果它的用户量突然减少 50%，会发生什么？
如果 KV 那条水平线追上甚至超过算力线，几何上会发生什么变化？甜蜜点还存在吗？成本下界变成了什么？这种情况会在什么场景出现？
一家服务商的所有用户都是「短对话 + 高频访问」（KV 小 + B 大），另一家是「超长对话 + 低频访问」（KV 大 + B 小），两家的成本曲线形状有什么不同？哪家更脆弱？
如果未来出现一种硬件，把 BW 翻 10 倍但 C 不变（更平衡的硬件），成本曲线的形状会怎么变？甜蜜点会移动到哪？「不开 Batch 差多少倍」会变成多少？

🚀

下一篇预告：咱们一直在背景里念叨的那个「麻烦制造者」——KV cache——下一篇就正面拆它：那个神秘的 b（每 token 占多少字节）到底是什么、为什么不同模型之间差距这么大、GQA / MLA / 跨层共享这些技术各自在解决什么问题。最有意思的一段：咱们会从 Gemini 1.5 Pro 当年的长上下文阶梯定价反推出每 token 字节数——任何 AI API 的定价结构，都像 X 光片一样让你看见内部架构。