✏️ 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，而是把它写成：

这里的 α 是每个 RL token 的有效算力系数。但要小心：α 的大小，取决于你把什么叫作一个 D_RL token。

α 应该多大？先问 token 口径

这取决于你怎么定义 D_RL：

• 如果 D_RL 指所有 rollout token，也就是模型在 RL 回路里生成、评估、筛选过的 token，那么 α 会偏小。长 CoT RL 里，大量 token 只是前向生成，系数会向 2-3 靠近。
• 如果 D_RL 指真正进入梯度更新的高质量 token，那很多 rollout / verifier / 多次采样的成本都被藏进每个 update token 背后，等效 α 反而可能大于 6。
• 如果任务需要大量采样、自我验证、长链路推理，α 到底变大还是变小，取决于你把这些生成 token 记进分母，还是把它们当作隐藏开销。

这也是 RL 难算的地方：它同时有「推理式生成」和「训练式更新」，而现代推理模型正在把越来越多成本放到前者。

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

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

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

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

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

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

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

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

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

把三项写出来：

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

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

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

预训练 vs 推理

所以：

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

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

预训练 vs RL

所以：

如果 α = 6，表示每个 RL token 像一次完整训练一样贵：

如果 α = 4，表示部分 token 只做生成、部分 token 才做更新：

如果长 rollout 占主导，α 向 2-3 靠近：

🔑 在 rollout-token 口径下，RL token 数完全可能超过预训练 token 数。

但如果你只数「真正用于反向传播的 update token」，并把 rollout / verifier / 多次采样都当作隐藏开销，那么等效 α 可能大于 6，这时 D_RL 又会小于 D_pretrain。这不是矛盾，而是分母不一样。

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

现在把这个框架用到 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 时间。

用公式看：

在 rollout-token 口径下，如果 α 越来越接近 2-3，那为了让 RL 算力追上预训练，D_RL 就会自然变成 D_pretrain 的几倍：

🔑 这就是「RL token 可能超过预训练」的来源：不是因为每个 token 更贵，而是因为 rollout token 更便宜、可以做得更多。

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

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

真正的瓶颈也会随之改变：当生成 rollout 的算力不再是唯一瓶颈，高质量、可验证的 RL 环境就会变得更关键。代码沙盒、数学题库、工具任务、自动 evaluator，本质上都是在给 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 模型只训 2T token

题目：假设有一家初创公司训练了一个 100B active 参数模型，只用了 2T token，刚好接近 Chinchilla optimal。问题是：在「训练 + 推理总账」框架下，它的算力分配出了什么问题？如果目标是服务大量用户，应该怎么调整？

直觉答案是：训练和推理严重不平衡。

算一下：

如果它真的想服务大量用户，假设生命周期推理量是 200T token：

推理算力大约是训练算力的 30 多倍。这说明什么？说明这个模型如果要承接大规模推理，训练投入太薄了。

但这里有一个关键翻转：该往哪个方向调，取决于你把什么当作约束。

视角 A：推理需求是给定的

公司必须服务这么多用户，推理算力降不下来。那你的结论就是：增加训练投入。

具体做法是：同一个 100B 模型不要只训 2T token，而是训到 60T-100T token，让训练算力追上预期推理规模。

🔑 这就是「过训」的合理性来源：不是训练部门忽然想多烧 GPU，而是被未来推理规模反推出来的。

视角 B：训练预算是给定的

如果公司只能承担 2T token 的训练预算，那结论反过来：不要服务那么大的推理规模。它应该限制用户量、只服务高付费客户，或者把模型定位成研究模型，而不是全民级产品。

现实中，视角 A 更常见。AI 公司的商业模式通常是服务规模化，推理需求由市场拉动，训练是可控投入。所以更常见的路径是：给定推理规模，反推训练量应该做到什么程度。

这家公司有三种调整方式：

1. 同一个 100B 模型训到 60T-100T token：推理成本不变，模型更强，总账更合理。
2. 训一个更大的模型：能力可能更强，但单次推理成本也会变高，不一定是总账最优。
3. 训一个更稀疏的 MoE 模型：比如总参数更大，但 active 参数更小，让模型有更大容量吸收训练数据，同时保持推理成本低。

🔑 现代前沿模型偏爱稀疏 MoE，正是因为架构选择、训练配比、推理经济学是一整套联动决策。

📌 应用到 Tbox：评估一个模型是否「训练充分」时，不要只看它跟 Chinchilla 比过训多少倍，还要看它的训练量是否跟预期服务规模匹配。一个小模型训了 100T token，可能是在准备大规模服务；只训 2T token，可能更像研究性质或中低流量部署。

练习 2：RL token 会超过预训练 token 吗？

题目：如果未来 RL 在前沿模型里的算力占比继续上升，RL token 数会超过预训练 token 数吗？在什么条件下会？

回到公式：

所以：

答案是：会，但前提是 α 下降到小于 6，并且 RL 的边际收益还没饱和。

几个数字就能看清：

🔑 α 越小，RL token 越多。便宜的 token，就应该多做。

这正是 long CoT RL 的关键趋势：一次 rollout 可能生成几千到几万 token，但真正做梯度更新的只是其中一部分。

• Rollout 生成阶段：主要是前向，α ≈ 2
• 梯度更新阶段：前向 + 反向，α ≈ 6
• 加权平均后：如果生成占比越来越高，α 会向 2-3 靠近

于是：

也就是说，RL token 数完全可能达到预训练的 2-3 倍。

但它要正式超过预训练，至少需要三个条件：

1. RL 主要由长 rollout 推理构成：生成很多，更新相对少，α 变小。
2. RL 的边际收益仍然显著：模型还没在 RL 上饱和。
3. 有足够高质量、可验证的 RL 环境：否则生成再多 token，也只是噪音。

第 3 条可能才是当前真正的瓶颈。算力可以扩，rollout 可以生成，但可验证任务、真实环境、自动 evaluator、代码沙盒、数学题库这些东西没那么容易扩。

📌 应用到 Tbox：如果你的产品是 agent、代码生成、数学求解、数据分析这类有可验证输出的系统，那么用户交互数据 + 成功 / 失败信号，本身就可能成为 RL 数据源。这是应用层公司在 AI 时代容易被低估的一种战略资产。