✏️ LLM 定价的数学原理 06：训练、RL 与推理的算力总账

一、先统一口径：这里的 N 是「参与计算的参数量」

先把一个容易混的点说清楚。

在这篇里，N 指的是每个 token 实际参与乘加的参数量，也就是 N_compute：

• 对稠密模型：N_compute ≈ N_total
• 对 MoE 模型：N_compute ≈ N_active，也就是每个 token 激活的专家参数 + 共享参数

为什么不用总参数量？因为这篇算的是算力，不是存储容量。MoE 可能有 1T 总参数，但每个 token 只走其中一小部分；它的显存压力看 N_total，每 token FLOPs 更接近看 N_active。

🔑 一句话：这一篇的 N 是「每个 token 实际算过多少参数」，不是「模型文件里一共有多少参数」。

二、三本账：预训练、RL、推理

一个模型从研发到部署，主要有三类算力支出：

1. 预训练（pre-training）：喂大量文本，让模型学语言和世界
2. RL / 后训练（reinforcement learning / post-training）：喂高价值任务，让模型学推理、偏好和对齐
3. 推理（inference）：用户实际调用模型，持续消耗 GPU 时间

这三项看起来很不一样：

• 预训练像一次性修高速公路
• RL 像反复调路标、测速、规则和导航策略
• 推理像每天真的有车在路上跑

但它们最后都会落到同一个东西上：GPU 时间。

所以真正的问题是：

如果一家 AI 公司有一笔固定算力预算，它应该把多少花在预训练、多少花在 RL、多少留给推理？

三、6ND：训练算力的第一性公式

先看预训练。一个常用的一阶估算是：

其中：

• N：每个 token 参与计算的参数量
• D：训练 token 数
• 6：一次完整训练里，前向 + 反向的大致 FLOPs 系数

这个 6 从哪里来？

拆成两步看：

前向传播（forward pass）：模型读入 token，算出预测。

• 每个参数大致参与一次乘法 + 一次加法
• 所以一个 token 的前向计算约为 2N

反向传播（backward pass）：模型根据误差更新参数。

• 反向要算梯度、传播梯度、累积更新
• 粗略说约为前向的 2 倍，也就是 4N

合起来：

训练 D 个 token：

四、推理算力：只有前向，没有反向

推理时不更新参数，只做前向传播。

所以每处理一个 token，大致是：

模型一生处理的总 token 数记作 D_inference，包括用户输入、系统 prompt、工具返回、模型输出等所有真的进过模型的 token。

于是：

这跟前几篇的推理公式是同一个世界观：每个 token 要把相关参数跑一遍，只是这里先不展开 memory-bound / KV-bound / batch 摊销这些工程细节，而是把它们压成一个生命周期总账。

五、RL 是中间态：既像推理，又像训练

RL / 后训练最容易算错，因为它不是单纯的「再训练一点数据」。

一个典型 RL 回路里至少有两类工作：

1. Rollout：让模型生成答案、推理链、代码、行动轨迹。这部分像推理，主要是前向。
2. Update：根据奖励信号、偏好、验证器结果更新模型。这部分像训练，需要反向传播。

而且 RL 的机器效率通常比预训练差：

• decode 是自回归的，串行性更强
• rollout 可能要多次采样，最后只保留一部分
• reward model / verifier / evaluator 也会吃算力
• 小 batch、变长序列、在线数据流都会拉低 MFU

所以更稳妥的写法不是硬说 RL 系数一定是 4 或 6，而是把它写成：

这里的 β 是有效 GPU 时间系数，已经把 rollout、反向传播、多次采样、验证器和低利用率都折进去了。

β 应该多大？

这取决于你怎么定义 D_RL：

• 如果 D_RL 指所有 rollout token，β 会相对小一些
• 如果 D_RL 指真正进入训练更新的高质量 token，β 会大很多
• 如果任务需要多次采样、自我验证、长链路推理，β 也会变大

在这篇里，咱们只需要一个定性事实：

🔑 RL 每个有效 token 通常比预训练 token 更贵。

也就是在很多前沿训练场景里，可以把 β 想成高于 6 的有效系数。这个判断比某个具体数字更重要。

六、关键启发式：不是三项成本严格相等，而是边际收益要接近

现在进入核心问题：预训练、RL、推理三项怎么分配？

严格地说，最优点不是「三项总成本完全相等」，而是：

最后一块 GPU 时间投到三项里的任何一项，带来的边际收益应该差不多。

如果预训练的边际收益远高于推理，说明模型还不够强，应该多训练；如果推理的商业回报远高于继续训练，说明模型已经足够好，应该扩大部署；如果 RL 的收益突然变高，说明模型能力瓶颈可能从「知识不够」转到了「会不会把能力用出来」。

不过在很多 power-law 形式的系统里，「边际收益接近」常常会导向一个粗略现象：

预训练、RL、推理的算力占比会落在同一个数量级，而不是一项占 99%，另外两项只是零头。

这就是咱们后面推导的启发式前提。

七、三项算力平衡时，会发生什么？

把三项写出来：

如果三项生命周期算力在同一个量级，先写成近似相等：

最漂亮的地方来了：N 可以消掉。

也就是说，模型有多大在这个比例关系里消失了。剩下的只是 token 数之间的关系。

预训练 vs 推理

所以：

🔑 一个成功模型一生处理的推理 token，应该和预训练 token 在同一个数量级，并且可能是它的几倍。

注意，这不是说两者精确相等，而是说：如果预训练是 100T token 级别，推理生命周期也不应该只是 1T，而应该进入几百 T 这个量级。

预训练 vs RL

所以：

如果 RL 的有效系数 β = 8-12，那么：

🔑 RL 的 GPU 时间可以接近预训练，但它的有效 token 数往往会少一些。

这修掉了一个常见误解：RL 不是因为 token 数巨大才重要，而是因为每个有效 token 贵、信息密度高、对最终产品能力影响大。

八、这解释了「为什么模型会过训」

现在把这个框架用到 Chinchilla。

Chinchilla scaling law 的经典结论可以粗略记成：

也就是：如果你只关心固定训练算力下模型能力最优，训练 token 数大约是参数量的 20 倍。

举个简化数字：如果一个模型每 token 激活的参数量是 100B，Chinchilla 推荐的训练 token 是：

但生命周期总账给出的方向不一样。

如果一个前沿模型的商业生命周期推理量是 100T-600T token，那么按上面的平衡关系：

这就比 2T 高出 15-100×。

🔑 所谓「相对 Chinchilla 过训」，不是说 Chinchilla 错了，而是它优化的是一个更窄的问题：只看训练算力，不看之后漫长的推理账单。

现实商业目标不是「给定训练预算，训练出最优模型」，而是：

给定训练 + RL + 推理的总预算，训练出生命周期 ROI 最好的模型。

在这个目标下，小一点、稀疏一点、训练得更久一点常常是合理的：你先多花训练算力，把每次推理的 active 参数量压低、质量抬高，然后在海量推理里把这笔账赚回来。

九、一个费米估算：从推理量反推训练量

咱们不需要知道任何公司的内部数字，也能做一个数量级估算。

假设某个前沿模型 family 在高峰期平均处理：

10M-100M token / 秒

商业主力生命周期是：

1-3 个月 ≈ 2.6M-7.8M 秒

那么总推理 token 量是：

也就是：

约 30T-800T token

按 D_inference ≈ 3D_pretrain 反推：

D_pretrain ≈ 10T-260T token

这个范围很宽，因为里面混着许多真实世界变量：不同模型变体、缓存命中、路由策略、免费用户与付费用户比例、输入输出 token 结构、模型退役节奏。但它已经足够说明一件事：

🔑 只要模型真的会被大规模使用，预训练 token 数被推到几十 T 到几百 T，并不奇怪。

这不是「为了刷 benchmark 硬训」，而是生命周期经济学自然推出来的。

十、RL 在产业里的位置：不是小尾巴，而是第二本大账

很多人对 RL 的直觉还停留在「少量人工偏好数据」「最后对齐一下」。这个直觉已经不够用了。

在更强的模型上，RL / 后训练可能包括：

• 数学、代码、工具使用、长任务的 rollout
• 多次采样后用 verifier 选优
• reward model、process reward、rule-based judge
• 自我博弈、自我改写、自我批改
• 针对产品场景的行为约束和安全训练

它不一定有预训练那么多原始 token，但它可能吃掉接近预训练的GPU 时间。

用公式看：

当 β 很大时，即使 D_RL 小于 D_pretrain，RL 算力也能追上预训练。

🔑 这就是「RL token 略少，但 RL 算力不小」的来源。

所以当你看到头部实验室越来越强调 RL、推理模型、验证器、长链路任务，不要只理解成「数据质量更高了」。更准确的说法是：

预训练的边际收益下降后，下一块 GPU 投到 RL 里，可能比继续无差别喂网页文本更划算。

十一、这个框架能帮你判断什么？

1. 判断一家模型公司的算力规划

如果一家公司训练很猛，但没有足够推理入口，它可能训练出了没人充分使用的资产。

如果一家公司推理流量巨大，但训练和 RL 投入明显不足，它可能在用旧模型硬扛需求，长期会被质量和成本同时压住。

健康的前沿实验室，三本账应该互相咬合：训练创造能力，RL 把能力变成稳定行为，推理把能力变成收入和数据回流。

2. 判断架构选择

MoE 为什么重要？因为它让 N_compute 低于 N_total。

在三本账里，N 同时乘在预训练、RL、推理上。只要能降低每 token 的 active compute，就等于同时改善三本账。MoE、KV 压缩、speculative decoding、routing、cache reuse，本质上都在试图让这个乘数变小，或者让它被更好地摊掉。

3. 判断产品层 routing

如果你在做模型路由，不应该只看「单次 API 单价」。

同样标称能力下，一个模型如果训练更充分、RL 更扎实、推理栈更健康，它可能：

• 更少重试
• 更少工具调用失败
• 更少需要长 prompt 补救
• 更少需要人工兜底

这些都会回到真实成本里。最便宜的 token，不一定带来最便宜的任务结果。

十二、一段话总结

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

1. 如果一个 100B active 参数模型只训了 2T token，刚好接近 Chinchilla optimal。它如果想服务海量用户，可能会遇到什么问题？你会建议它继续加大模型，还是继续加训练 token？
2. 如果 RL 的多次采样从每题 4 次变成每题 64 次，公式里的 β 会怎么变？这会让 D_RL 相对 D_pretrain 变多还是变少？
3. 如果某家公司拥有巨大的自有应用流量，而另一家公司只卖 API，谁更有理由把训练 token 推到 Chinchilla 推荐值的几十倍？为什么？
4. 一个模型的 API 单价很低，但经常需要重试、长 prompt 补救、外部工具兜底。用这篇的总账视角看，它真的便宜吗？