1. 为什么第二篇要死磕“纯数字”讲原理
很多人看大语言模型训练的文章，第一反应是“公式太多、术语太密”，第二反应是“算了，我大概知道怎么回事就行”。但真到自己动手调参、看loss曲线、判断模型是不是训崩了的时候，脑子里没有一套数字直觉，基本就是盲人摸象。我见过不少同行，能把Transformer结构图默画出来，却说不清为什么学习率设成3e-4而不是1e-3，也解释不了为什么batch size翻倍之后梯度累积步数要跟着调。这就是典型的“结构懂、数字瞎”。
这篇连载二，我打算彻底抛开那些花哨的架构图，用最朴素的数字和类比，把大语言模型训练过程中真正起作用的几个核心量讲透。你不需要有数学系背景，只要会加减乘除、能看懂百分比，就能建立起一套判断训练是否健康的直觉。这套直觉的价值在于：当你面对一个陌生的训练任务时，能快速判断超参设置是否离谱、loss曲线是否正常、显存估算是否合理，而不是等跑了两天发现loss不降才拍大腿。
关键词里虽然没给具体词，但从标题“纯数字讲大语言模型训练原理”可以拆出几个核心关注点：参数量与显存的关系、学习率与batch size的配合、loss曲线的数字特征、梯度累积的等效换算、训练步数与数据量的匹配。这些点每一个都能用具体数字算给你看，而且算完之后你会发现，很多“玄学调参”其实是有明确数量级依据的。
适合谁看？如果你已经读过第一篇、对Transformer的基本组件有概念，但一到具体数字就发怵，这篇就是为你写的。如果你是完全零基础，也没关系，我会在必要的地方补一句“这个数是怎么来的”，保证你能跟上。整篇的节奏是：先建立数字直觉，再拆解每个核心量的计算逻辑，最后给出一套可以直接套用的估算流程。
提示：本文所有数字均为示例性计算，目的是展示数量级关系，实际训练中需根据硬件和任务调整。但数量级判断的逻辑是通用的。
2. 参数量、显存与计算量的三角关系
2.1 从“一个参数占多少字节”开始算
大语言模型的训练，本质上是在显存里同时存放好几份东西：模型参数本身、梯度、优化器状态、激活值。很多人只算了参数占多少显存，结果一跑就OOM，就是因为漏了后面几项。我们先从最基础的算起。
假设模型有10亿参数（1B），用混合精度训练，参数以FP16存储，每个参数占2字节。那么光参数本身占：10亿 × 2字节 = 2GB。这个数很好算。但训练时还需要一份FP32的master weight用于更新，这部分占4字节，又是4GB。梯度也用FP16存，2GB。优化器如果用Adam，需要保存一阶矩和二阶矩，通常用FP32，每个参数两个状态，共8字节，即8GB。这四项加起来：2+4+2+8 = 16GB。也就是说，1B参数的模型，光静态内存就要16GB左右，还没算激活值。
激活值这块更隐蔽。它跟batch size、序列长度、模型层数都相关。粗略估算，每层激活值约占batch_size × seq_len × hidden_dim × 层数 × 2字节的量级。举个例子：batch size=8，序列长度=1024，hidden_dim=2048，层数=24，那么激活值大约 8×1024×2048×24×2 ≈ 800MB。实际因为注意力机制还会更多，通常要乘个2到3倍。所以1B模型训练时，显存占用轻松超过20GB。这就是为什么很多消费级显卡跑不动1B以上模型的全量训练。
注意：上面算的是全量训练。如果做LoRA等参数高效微调，优化器状态和梯度只针对少量参数，显存会大幅下降。但本文讨论的是从零训练，所以按全量算。
2.2 计算量估算：6N法则的直观解释
训练一个Transformer模型，前向加反向的计算量有个经典估算：总浮点运算次数约等于 6 × 参数量 × token数量。这个6怎么来的？前向传播每个参数参与一次乘加，约2次运算；反向传播需要计算对权重和输入的梯度，约4次运算。所以每个参数每个token约6次运算。
假设模型1B参数，训练数据100亿token，那么总计算量约 6 × 1e9 × 1e10 = 6e19 FLOPs。一块A100的FP16算力约312 TFLOPS，实际利用率按40%算，有效算力约125 TFLOPS。那么训练时间约 6e19 / 1.25e14 ≈ 4.8e5秒，约133小时，也就是5天半。这个数字一出来，你就能判断：用单卡A100训1B模型100亿token，大概要一周。如果想三天跑完，要么加卡，要么减token，要么换更大算力的卡。
这个估算的意义在于，它让你在动手之前就能判断资源是否匹配。我见过有人用单张消费级卡想训7B模型，算一下计算量就知道不现实，但如果不算，可能白白浪费几天时间。
2.3 显存与计算量的权衡：为什么batch size不能无限大
batch size增大，计算并行度提高，GPU利用率上升，但显存占用也线性增长。更重要的是，batch size大到一定程度后，梯度估计的方差已经足够小，再增大带来的收益递减。通常的做法是：在显存允许范围内尽量增大batch size，直到GPU利用率达到80%以上，然后通过梯度累积来进一步等效增大batch size。
这里有个数字直觉：当batch size从8增加到16时，梯度方差减半，训练稳定性提升明显；从256增加到512时，方差只减少0.2%，几乎无感。所以实际训练中，batch size超过一定值后，更多是为了并行效率，而不是统计效率。这个阈值通常在几百到几千之间，取决于任务。
3. 学习率与batch size的数字配合逻辑
3.1 学习率不是孤立的：线性缩放与平方根缩放
学习率和batch size是一对孪生参数。业界有个经验法则：当batch size扩大k倍时，学习率也应扩大k倍（线性缩放），或者扩大sqrt(k)倍（平方根缩放）。为什么？因为batch size增大后，梯度的噪声减小，方向更准，所以可以迈更大的步子。但步子太大会导致震荡，所以平方根缩放更保守，适合大batch。
举个例子：原始配置batch size=32，学习率=1e-4。现在显存够了，batch size提到256，扩大了8倍。按线性缩放，学习率应设为8e-4；按平方根缩放，设为1e-4×sqrt(8)≈2.8e-4。实际中，我通常先用平方根缩放，观察loss曲线，如果下降太慢再往线性缩放靠。但注意，学习率超过1e-3后，很多模型会变得不稳定，需要配合warmup。
3.2 warmup步数怎么定：用数字说话
warmup是指在训练初期让学习率从0线性增加到设定值，避免一开始就大步长导致模型发散。warmup步数通常设为总步数的1%到5%。假设总训练步数=10000步，warmup取2%，就是200步。这200步内，学习率从0线性升到峰值。
为什么需要warmup？因为训练初期参数是随机的，梯度方向混乱，如果直接用大学习率，可能把参数推到很差的区域。warmup相当于先让模型“热身”，找到大致方向后再加速。实测中，warmup步数太少（比如10步）容易在初期loss尖峰，太多（比如20%）则浪费训练时间。2%到5%是个比较稳的区间。
3.3 学习率衰减：余弦还是线性
训练后期，学习率需要逐渐降到接近0，让模型收敛到局部最优。常见的有余弦衰减和线性衰减。余弦衰减的公式是：lr = min_lr + 0.5 × (max_lr - min_lr) × (1 + cos(π × step / total_steps))。这个曲线前期下降慢，后期下降快，适合大多数任务。线性衰减则是均匀下降。
从数字上看，余弦衰减在训练中期保持较高学习率，有利于跳出局部最优；线性衰减则更平稳。我个人的经验是：如果训练步数少于5000步，用线性衰减更简单；超过5000步，余弦衰减通常效果更好。min_lr一般设为max_lr的10%左右，比如max_lr=3e-4，min_lr=3e-5。
提示：学习率是最敏感的超参。如果loss曲线出现剧烈震荡或持续上升，第一反应应该是降低学习率，而不是改模型结构。
4. loss曲线的数字特征与异常判断
4.1 正常loss曲线的数字范围
大语言模型训练初期，loss通常从10左右开始下降。为什么是10？因为词表大小如果是50000，随机猜测的交叉熵损失约为ln(50000)≈10.8。所以初始loss在10到11之间是正常的。如果初始loss远高于11，说明初始化有问题；如果远低于10，可能数据有泄漏或标签错误。
训练过程中，loss会逐渐下降。一个健康的训练，loss在前10%的步数内下降最快，通常能从10降到5左右；然后进入缓慢下降期，从5降到3可能需要50%的步数；最后从3降到2.5又需要剩余40%的步数。这个“先快后慢”的曲线是正常的。如果loss下降太慢，可能是学习率太小；如果loss震荡剧烈，可能是学习率太大或batch size太小。
4.2 梯度范数：比loss更早发现异常
loss是滞后指标，梯度范数（grad norm）是领先指标。正常情况下，梯度范数在训练初期较大，然后逐渐减小并稳定在一个范围。如果梯度范数突然飙升到几千甚至几万，说明出现了梯度爆炸，需要立即降低学习率或增大梯度裁剪阈值。
梯度裁剪通常设为1.0。也就是说，如果梯度范数超过1.0，就按比例缩放回去。这个值不能太小，否则会抑制正常学习；也不能太大，否则起不到保护作用。实测中，1.0对大多数模型都适用。如果发现梯度范数经常在0.9到1.0之间徘徊，说明裁剪太频繁，可以适当提高到2.0。
4.3 训练loss降但验证loss升：过拟合的数字信号
当训练loss持续下降，验证loss在某个点后开始上升，这就是过拟合。数字上表现为：训练loss从3降到2，验证loss从3.2降到3.0后又升到3.5。这时候需要增加数据、减小模型、加正则化或提前停止。
但要注意，大语言模型训练中，验证loss通常和训练loss同步下降，因为数据量极大，过拟合不是主要问题。如果出现验证loss上升，先检查验证集是否和训练集分布差异太大，而不是急着加dropout。
5. 梯度累积与等效batch size的换算
5.1 梯度累积的数学等效
梯度累积解决的是显存不够但想要大batch size的问题。假设单卡只能放batch size=4，但想要等效batch size=32，那么累积步数=32/4=8。具体操作是：连续做8次前向和反向，每次不清空梯度，而是累加；第8次之后才更新参数并清空梯度。
数学上，这等价于用32的batch size做一次更新，因为梯度是线性可加的。但有个细节：如果用了BatchNorm，累积时统计量会不一致，不过Transformer一般用LayerNorm，不受影响。所以梯度累积对Transformer是安全的。
5.2 累积步数与学习率的联动
当你用梯度累积把等效batch size从4提到32时，学习率是否要跟着调？答案是：如果你原本的学习率就是按32的batch size设计的，那不用调；如果你原本按4设计，现在等效成32，那学习率应该按前面说的缩放规则调整。但更常见的做法是：先确定目标等效batch size，再据此设定学习率，然后用梯度累积去逼近这个等效batch size。
举个例子：目标等效batch size=256，学习率=3e-4。单卡只能放16，那么累积步数=16。训练时每16步更新一次。这样学习率就是按256设计的，不需要额外调整。
5.3 累积步数过多的副作用
梯度累积步数不是越多越好。如果累积步数太多，比如单卡batch size=1，累积256步，那么每次更新之间间隔很长，参数更新频率低，训练总步数减少，可能导致训练不足。而且，累积过程中如果某次前向出现异常，会影响整个累积周期。通常建议单卡batch size至少能放到8以上，累积步数不超过32。
6. 训练步数与数据量的匹配计算
6.1 一个token被训练几次才合适
大语言模型训练有个经验：每个token被训练1到4次比较合适。太少则欠拟合，太多则过拟合且浪费计算。假设你有100亿token的数据，模型参数量1B，那么总训练token数可以设为100亿到400亿。如果设为200亿，就是每个token训练2次。
这个“训练次数”叫epoch数。但大语言模型通常不按epoch训练，而是按总token数。因为数据量太大，一个epoch可能就要跑很久。所以更常见的做法是：设定总训练token数，然后根据batch size和序列长度算出总步数。
6.2 总步数的计算公式
总步数 = 总训练token数 / (等效batch size × 序列长度)。假设总训练token数=200亿，等效batch size=256，序列长度=2048，那么总步数 = 2e10 / (256×2048) ≈ 38147步。这个数字告诉你，需要更新参数约3.8万次。
如果单卡每秒能跑2步，那么需要约19000秒，约5.3小时。但这是理想情况，实际还要考虑数据加载、通信等开销，通常乘以1.5到2倍。所以实际可能需要10小时左右。这个估算让你在训练前就能规划好时间。
6.3 数据量不足时的数字信号
如果数据量不足，比如只有10亿token，但模型有7B参数，那么每个token可能被训练很多次。这时候验证loss会很快停止下降，训练loss继续降，过拟合明显。数字上表现为：训练loss降到1.5，验证loss停在3.0不降。这时候要么增加数据，要么减小模型，要么用数据增强。
我个人的经验是：数据量至少应该是参数量的10倍以上。比如1B模型，至少需要10B token。7B模型，至少需要70B token。低于这个比例，过拟合风险很高。
7. 实操中的数字检查清单
7.1 训练前的显存估算流程
在启动训练前，我习惯按以下步骤估算显存：
- 算静态内存：参数量 × (2+4+2+8) 字节 = 参数量 × 16字节。1B模型约16GB。
- 算激活值：batch_size × seq_len × hidden_dim × 层数 × 2 × 3（系数）。按前面例子约2.4GB。
- 加总和：16+2.4≈18.4GB。再加上CUDA上下文和碎片，实际需要20GB以上。
- 如果显存不够，优先减小batch size，其次用梯度累积，最后考虑模型并行。
这个流程能帮你避免“跑起来才发现OOM”的尴尬。
7.2 训练中的监控指标阈值
训练中我重点关注三个数字：
- loss：初始应在10左右，前10%步数降到5以下，最终降到2到3之间。
- grad norm：应在0.1到1.0之间，偶尔到2.0正常，持续超过5.0要警惕。
- 学习率：按计划衰减，如果发现学习率没变，检查调度器是否生效。
如果loss连续100步不降，先检查数据加载是否正常，再检查学习率是否太小。如果grad norm持续为0，说明梯度没回传，检查模型是否冻结了参数。
7.3 常见数字异常与对策
| 异常现象 | 可能原因 | 数字对策 |
|---|---|---|
| loss初始值远大于11 | 初始化错误 | 检查参数初始化，改用小方差初始化 |
| loss震荡剧烈 | 学习率太大 | 学习率除以2到5 |
| loss下降太慢 | 学习率太小或batch太小 | 学习率乘2，或增大batch |
| grad norm飙升 | 梯度爆炸 | 降低学习率，梯度裁剪设为1.0 |
| 验证loss上升 | 过拟合 | 增加数据，减小模型，加权重衰减 |
| 显存OOM | 静态内存或激活值超限 | 减小batch，梯度累积，或模型并行 |
这张表是我在实际训练中反复验证过的，基本覆盖了80%的常见问题。每次遇到异常，先查表，再动手调，比盲目试错高效得多。
7.4 一个完整的数字估算示例
假设你要训一个2B参数的模型，数据量50B token，单卡显存40GB，序列长度2048。先算静态内存：2B × 16字节 = 32GB。已经接近40GB了，激活值还没算。所以单卡肯定放不下全量训练。这时候要么用梯度累积加小batch，要么用模型并行，要么用LoRA。如果坚持全量，至少需要2张40GB卡做模型并行。
再算计算量：6 × 2e9 × 5e10 = 6e20 FLOPs。单卡有效算力125 TFLOPS，需要4.8e6秒，约55天。这显然不现实。所以要么加卡到8张，时间降到7天；要么减数据到10B token，时间降到11天。这些数字一摆出来，决策就清晰了。
注意：以上估算未考虑通信开销和实际利用率波动，实际时间通常比理论值长30%到50%。所以规划时留足余量。
8. 把数字直觉变成训练习惯
我刚开始训模型的时候，也是凭感觉调参，结果就是反复重启、反复试错，浪费了大量时间。后来强迫自己每次训练前先做数字估算，训练中盯住几个关键指标，慢慢就形成了一套判断体系。现在拿到一个新任务，我能在十分钟内估算出需要多少显存、多少时间、学习率大概设多少，准确率能到七八成。剩下的两三成，靠训练中的监控来微调。
这套数字直觉的核心就三句话：参数量决定静态内存，batch size和序列长度决定激活值，总token数决定训练步数。把这三个关系理清楚，大部分训练配置都能推导出来。至于学习率、warmup、衰减这些，都是在这些基础数字上做微调。
如果你刚开始接触大语言模型训练，建议先拿一个小模型（比如100M参数）练手，把上面这些数字都亲手算一遍，再跑一次训练，观察实际数字和估算的差距。跑过两三次之后，你对这些数字的敏感度就会大幅提升。到那时候，再看那些“玄学调参”的说法，你就能一眼看出哪些是有依据的，哪些是故弄玄虚。
最后分享一个我常用的技巧：在训练脚本里加一行代码，每100步打印一次loss、grad norm、学习率和当前显存占用。这四个数字放在一起看，基本能判断训练是否健康。如果四个数字都在预期范围内，就可以放心去干别的事；如果有异常，也能第一时间发现。这个习惯帮我省下了大量盯着屏幕的时间。
