大模型训练为什么这么贵？从 FLOPs、batch size 到 RL 后训练账本

大模型训练贵，不只是因为 GPU 贵，而是因为没有用好GPU才贵。

真正贵的是一整条训练链路：总 FLOPs、batch size、并行策略、通信、显存、后训练、检查点（checkpoint，用于实现断点续训）和失败恢复。

如何用好GPU，这里涉及一条工程链，今天我们就来介绍这条链。

上一篇我们讲解了单个 token 的稳定推理逻辑，本文则聚焦模型训练的算力成本逻辑。

这两篇都来自同一期播客的启发：Dwarkesh Patel 对 Reiner Pope 的访谈 The math behind how LLMs are trained and served。

先说明一下：这篇会分两层。

第一层，是播客里直接涉及的内容：总 FLOPs、batch size、并行策略、MoE、pipeline parallelism（流水线并行）、RL 后训练、Chinchilla、memory bandwidth（内存带宽）。

第二层，是企业训练落地的延展：检查点、失败重跑、实验管理、集群稳定性。

一、总 FLOPs：训练成本的第一行

大模型训练贵，首先不是因为“用了几张 GPU”，而是因为这次训练到底要跑多少总 FLOPs。

先区分几个容易混用的词：

FLOP 指一次浮点运算。
FLOPs 常用来表示浮点运算总次数，也就是总计算量。
FLOPS（也可写作 FLOP/s） 指每秒浮点运算次数，表示硬件算力或计算速度。

所以，讨论一次训练消耗多少计算，应该看总 FLOPs；讨论一张 GPU 算得多快，才看 FLOPS（FLOP/s）。

不过行业里也会混用。有些资料会把 FLOPs/FLOPS 写得不那么严格，阅读时要结合上下文判断：它说的是“总计算量”，还是“每秒算力”。

每个 token 进入模型，都要经历大量矩阵计算。训练时不只是前向计算，还包括反向传播、梯度计算和参数更新。

模型越大，训练 token 越多，训练步数越长，总计算量就越高。

GPU 小时是外层表达，总 FLOPs 更接近训练账本的第一层计量方式。

当然，总 FLOPs 不是唯一成本。真实训练成本还会受 GPU 利用率、通信效率、存储、调度 影响。但如果连总计算量都没算清楚，只看 GPU 单价，很容易误判成本。

一句话：

训练账本的第一行，不是卡数，而是总计算量。

二、Batch size：吞吐、稳定性和效果之间的平衡

batch size 决定一次训练吃多少数据，也影响硬件利用率、显存容量、通信开销、训练稳定性和最终效果。

Reiner Pope 在访谈里用 batch size 解释 token 成本和速度，尤其是在 serving（推理）场景里。

放到训练场景，batch size 同样关键。

batch 太小，GPU 可能吃不饱，吞吐不高。

batch 变大后，梯度估计方差会降低，训练信号更稳定，吞吐也可能更好；但它同时会改变学习率缩放和优化器行为。

实际训练中，batch size 放大后一般需遵循线性缩放规则同步调整学习率，具体方案取决于优化器、模型结构与训练目标。

如果学习率、权重衰减、动量、训练步数等参数没有配合调整，才可能导致收敛变慢或泛化效果下降。

所以，batch size 并非越大越好。

它是在硬件利用率、显存容量、通信开销、训练稳定性和收敛效果之间找平衡。

三、并行策略：不是多加几张卡就会线性变快

大模型训练要靠并行策略，但并行本身会引入通信成本。

当模型大到单张 GPU 放不下，或者训练时间长到无法接受，就必须把训练拆到多张卡、多台机器，甚至多个机柜里。

常见并行方式可以先粗略分成两大类：

• 数据并行：每张卡加载完整模型，分别计算不同批次数据；算出梯度后，通过 AllReduce 等通信算子同步梯度均值或总和，核心是保证各卡模型参数保持一致。实际训练里，还可能先做梯度累积（Gradient Accumulation），再参与同步，用来摊薄通信开销。
• 模型并行：把模型本身拆到多张卡上。常见做法包括张量并行，也就是把层内张量拆开；流水线并行，也就是按层或阶段拆开。MoE 模型里还会用到专家并行，可以理解为模型并行的一种特殊形式：不同 Expert 分布在不同设备上，输入 token 通过专家路由进入对应 Expert 计算。

这期播客里也讲到 MoE、expert parallelism（专家并行）、pipeline parallelism（流水线并行），以及模型在 GPU、rack（机柜）、scale-up domain 之间怎么分布。

关键问题是：多卡不是简单相加。

不同显卡、服务器之间需要频繁通信与参数同步。通信会吃掉一部分加速收益。

所以训练不是“卡越多就越接近线性加速”，而是：

计算和通信能不能配合得上，决定了加卡后的边际收益。

四、通信账本：GPU 不只是在计算，也可能在等待

训练集群里，GPU 等通信、等同步，本质上也是成本。

很多时候，GPU 算完一部分之后，要等梯度同步、参数更新、激活传递、expert routing（专家路由）、pipeline stage（流水线阶段）对齐和数据加载。

如果网络带宽、拓扑设计或通信算法跟不上计算速度，GPU 完成本地计算后，就会进入空闲（Idle）状态，等待跨卡或跨机同步。

这种空闲时间会直接拉低 GPU 有效利用率。尤其是在按时间计费的场景里，GPU 即使没有做有效计算，也仍然在产生成本。

可以粗略理解成：

GPU 利用率低，意味着“付费时间”不等于“有效计算时间”。

如果一个训练任务里 GPU 有效利用率只有 50%，那就相当于你付了 100% 的 GPU 时间，但只有一半时间真正转化成了有效计算。

Reiner Pope 的访谈里有一个重要底层视角：训练和推理都受 compute performance（计算性能）、memory bandwidth（内存带宽）、memory capacity（内存容量）等硬件约束影响。

放到大规模训练集群中，还要额外考虑网络架构与拓扑结构。

训练系统真正难的地方，不只是“把模型跑起来”，而是让大量 GPU 长时间、稳定、高效地一起工作。

五、RL 后训练：不一定最烧卡，但账本更复杂

RL 后训练（如 RLHF，基于人类反馈的强化学习）单轮计算量通常低于全量预训练，但有效收益的单位成本更难控制。

这期播客里也讨论了 RL、inference token、pretraining token 之间的成本关系。

在 RL 后训练里，模型不只是“读数据，然后更新参数”。

它还可能需要先生成大量候选答案，这一段属于推理成本；再用 reward model（奖励模型）或 verifier（验证器）打分，属于评估成本；最后做 policy optimization，属于训练成本。

这个循环往往要反复跑很多轮。

这意味着 RL 后训练里既有训练成本，也有推理成本；它不只是“轮数多”，还包含大量生成、筛选和评估带来的冗余计算。

更麻烦的是，这些计算不一定都能直接转化成模型效果提升。

预训练更偏向在海量数据上做规模化计算。RL 后训练则更像“小批量数据、多轮试错、不断评估和调整”。

所以后训练不是“比预训练小，所以就简单”。

它的复杂度在于循环多、实验多、评估多，而且训练账本和推理账本会在这里交叉。

六、Chinchilla 和加码训练：训练多一点，可能是为了推理便宜一点

从播客里的推导视角看，训练和推理之间存在 trade-off：模型不一定只追求训练阶段最优，也可能为了长期推理经济性，在训练阶段投入更多计算。

播客里提到 Chinchilla-optimal，也讨论了模型训练和推理之间的成本平衡。

Chinchilla 的核心启发是：

在固定计算预算下，不能只把模型做大，也要给模型足够多的训练 token。更通俗地说，参数量和训练 token 数需要匹配，而不是一味堆参数、少喂 token。

更专业一点说，Chinchilla 讨论的是 compute-optimal 训练：在给定计算预算下，模型参数量与训练 token 数需按比例扩展，最大化算力利用率。

这个视角主要讨论通用大语言模型。到了垂直领域小模型或特定任务模型，数据质量、任务分布和业务目标也会改变最优选择。

我们也可以理解“加码训练”的思路：

这并非模型出现“过拟合”，而是在推理成本占比极高的场景下，主动在训练阶段增加计算投入，换取长期线上服务的效率与质量。

如果一个模型训练得更充分，推理时表现更好，或者可以用更小的模型达到相近效果，那么多花一些训练成本，可能会在长期推理里被摊回来。

以上分析均基于公开研究结论，并非各大厂商内部真实成本数据。

这也是为什么不能孤立地看训练成本。训练和推理是一组总账。

七、企业落地延展：检查点、失败重跑和实验管理

这部分不是播客主线，但在企业训练里非常关键。

如果把播客主线看成“训练的数学和系统账本”，那企业落地还要再补几笔：检查点（checkpoint）、失败恢复、实验管理、监控告警、数据版本、训练复现。

检查点（checkpoint）是训练里的保险，用于实现断点续训。

它可以防止训练中断后从头再来。但保存检查点也需要存储、I/O 和跨节点同步。

检查点保存太少，失败后损失大；保存太频繁，又会占用存储 I/O 带宽，写入期间也可能降低计算效率，减少有效训练时间。

检查点保存什么精度，保存完整状态还是部分状态，也会影响存储成本和恢复速度。

失败重跑更容易被低估。

训练失败可能来自代码 bug、数据问题、硬件故障、网络问题，也可能来自数值不稳定，比如梯度爆炸、NaN、精度下溢。

而且在大规模训练里，失败不是一个可以完全忽略的小概率事件。

集群越大，训练时间越长，遇到硬件故障、网络抖动、存储异常的概率就越高。千卡级别任务跑很多天，真正要关心的不是“会不会出问题”，而是“出了问题能不能快速恢复”。

所以企业做训练，不能只算“理想情况下跑完要多少钱”。

同时还要考量：任务中断能否快速恢复、数据是否需要重新分片加载、异常任务是否持续占用资源、故障能否快速定位、实验能否复现、调参记录是否完整，以及重跑与项目延期带来的损失。

训练账本里最容易被忽略的一项，往往不是跑完，而是没跑完。

八、企业看训练成本，不能只问“每卡多少钱”

训练成本要看完整链路：总计算量、利用率、并行效率、通信、存储、后训练、检查点和失败恢复。

要看什么	为什么重要
总 FLOPs	决定训练底盘成本
GPU 利用率	决定付费时长中有多少转化为有效计算
batch size	影响吞吐、稳定性和效果
并行策略	决定多卡加速比能否接近理想状态
通信和拓扑	决定 GPU 是否进入 Idle 等待
RL 后训练	混合训练、推理、评估和试错成本
检查点（checkpoint）	影响存储、I/O、跨节点同步和失败恢复
失败恢复	决定重跑成本与项目延期损失
实验管理	决定试错成本和复现能力

训练不是租到 GPU 就结束。

训练是让 GPU、网络、存储、调度、数据和模型，在一条长时间运行的工程链路里协同起来。

只看 GPU 单价，很容易低估真实成本。

写在最后

大模型训练为什么这么贵？

答案不是一句“GPU 贵”。

更准确地说：

大模型训练贵，是因为它把总 FLOPs、batch size、并行策略、通信、显存、后训练、检查点（checkpoint，用于实现断点续训）和失败恢复，全部绑在了一条长时间运行的工程链路上。

推理账本关注：一个 token 怎么被稳定服务出来。
训练账本关注：模型能力怎么被持续算出来。

下一次再看到“某模型用了多少张卡、训练了多少天”，不要只看卡数。

还要问：

• 总计算量是多少？
• batch size 怎么设？
• GPU 利用率是多少？
• 并行策略怎么做？
• 通信有没有拖慢？
• RL 后训练花了多少？
• 失败后能不能恢复？
• 重跑损失谁来承担？

这才是训练背后的真实账本。