把“训练大模型”这件事讲清楚，最好的方式之一，是把它看成“烤蛋糕”。这个比喻不是新发明，但真正有价值的地方在于：你能否把烘焙流程里的每个环节，和大模型训练里的数据、模型架构、算力、超参数一一对上号。对上了，你会发现很多之前觉得玄的东西，其实都有对应的操作；对不上，比喻就是比喻，听个热闹，回头还是看不懂训练日志。
这篇文章适合两类人看。第一类是刚接触 LLM 训练的同学，你不需要先啃完论文，先跟着烘焙流程把整个训练链路走一遍，对数据、预训练、微调、部署会有一个整体框架。第二类是需要和技术以外角色沟通的人，产品经理、业务同事、老板、客户，如果你需要解释“为什么训练一个模型这么贵”“为什么模型效果不稳定”“为什么不能随便加数据”，烘焙流程里的食材、烤炉、火候、翻车，都能当现成的沟通语言。
下面我按烘焙一整个蛋糕的流程，把 LLM 训练重新拆一遍。比喻归比喻，该落到地上的数据量、显存、学习率、loss 曲线，一个都不会少。
1. 这个比喻成立的前提：烤蛋糕和训练模型到底哪里像
1.1 两类读者该怎么用这个比喻
对刚接触大模型的人，最大的障碍不是某个数学公式难懂，而是整个训练流程太抽象。你很难直观理解“为什么要准备这么多数据”“为什么参数也叫超参数”“为什么训练完还要评估”。但如果把“预训练”换成“烘烤”，把“微调”换成“上糖霜”，把“评估”换成“试吃”，流程顺序和前后依赖关系一下子就有了画面。
我一般会在带新同学时用这个比喻做第一课，但会提前说明：比喻只负责建立框架，不负责替代技术细节。真正设计训练实验、排查训练失败原因时，还是要回到数据样本、梯度范数、显存占用这些具体指标。一个工具能不能用，要看它的边界在哪里，比喻也一样。
对需要沟通成本的人来说，这个比喻最大的作用是解释资源投入。食材不好，蛋糕做出来不会好吃；烤箱不够，配方再好也烤不熟；火候不对，前面全部白干。训练大模型从来不是“把一堆文本丢进一个黑盒”那么简单，它是由数据质量、算力规模、超参数设计和验证机制共同决定的系统工程。
1.2 一张表看懂训练全流程的烘焙对应关系
我先把一套完整的对应关系列出来。这张表也是整篇文章的骨架。
| 烘焙阶段 | LLM 训练环节 | 具体对象 |
|---|---|---|
| 食材采购与筛选 | 数据收集与清洗 | 网页、书籍、代码、对话文本，去重去噪 |
| 切配与称量 | Tokenizer 与数据配比 | token 切分、词表大小、不同来源数据混合比例 |
| 配方与模具设计 | 模型架构选择 | Transformer、参数量、层数、注意力头 |
| 模具花纹设计 | 预训练任务定义 | 自回归、掩码语言模型、损失函数 |
| 烤箱预热 | 环境准备与学习率预热 | warmup、分布式初始化、混合精度 |
| 烘烤过程 | 预训练 | 前向传播、反向传播、参数更新 |
| 出炉冷却 | 评估与验证 | 验证集 loss、困惑度、下游任务评测 |
| 上糖霜装饰 | 微调与对齐 | SFT、RLHF、奖励模型 |
| 切块上架 | 部署与推理 | 量化、推理服务、缓存和并发控制 |
| 翻车重做 | 训练失败排查 | 损失不降、梯度爆炸、过拟合、数据泄漏 |
后面每一节，都是这张表里某一行或者某几行的展开。
2. 食材决定上限：数据收集、清洗与切配
2.1 面粉要过筛，文本要去重
做蛋糕的第一步不是开烤箱，而是处理食材。面粉如果结块，后面怎么搅拌都会不均匀；大模型训练里的文本数据如果不处理，训练出来的模型也会一言难尽。
文本清洗常见的工作包括：去重、去噪、统一编码、过滤低质量内容。去重尤其重要。训练数据里如果大量重复，模型会对重复片段产生过度记忆，泛化能力变差。你希望模型学到的是语言规律，而不是把某几段文本背下来。
实操时我建议先做一个小样本验证集。从全量数据里抽几千条样本，把清洗流程跑通，确认没有格式错误、没有编码乱码、没有大量重复段落，再上全量处理。很多训练事故，追溯到根因都在数据阶段：你以为数据没问题，结果里面混了一大段乱码或者重复文本，训练后期 loss 掉不下去，排查半天才发现是数据源头的问题。
2.2 Token 化就是在切配和称量
食材要切成合适的大小才能进模具，文本要切成 token 才能进模型。这一步通常由 tokenizer 完成，常见做法是基于 BPE 这类子词算法进行切分。
词表大小、切分方式、特殊 token 的设计，都会影响模型对文本的处理效率。中文场景下，一个字符可能被切成一个或几个 token，代码和数学符号也有自己的切分规律。上下文窗口就像模具容量，一次能装多少 token 决定了模型能读多长的内容。你会发现，同样是“长文本能力”，不同模型的真实效果受限于 tokenizer 和上下文窗口的配合，而不只是写个窗口大小参数那么简单。
这里有个容易被忽略的判断标准：切分效率。同样的文本量，如果 tokenizer 切出来的 token 数明显偏多，训练和推理成本都会上涨。所以我在评估一个预训练模型时，会先拿一批中文、英文、代码混合文本跑一遍 token 统计，而不是只看模型参数大小。
2.3 数据配比：高低筋面粉不能乱掺
蛋糕配方里，高筋粉和低筋粉的比例决定了成品的口感。预训练数据也一样，通常会把网页、书籍、代码、数学、对话等不同来源的数据按比例混合。网页数据多，模型通用知识面广；代码数据多，推理和结构化能力更强；书籍数据多，长文本表达更流畅。
这种配比没有固定答案，要看模型的最终用途。但有一点必须做：记录。每一版数据配比、清洗规则、样本总量，都要像记录配方一样保存下来。否则训练出了问题，你连“这次到底喂了什么数据”都说不清，复现和排查都无从谈起。
数据配比还有一个容易踩的坑：某些来源的数据会被偷偷重复计算。比如清洗时没有去重，导致代码类数据占比比预期高出一倍，模型输出风格就会偏。我一般会在训练前统计每个来源的 token 占比，跑完清洗后再统计一次，两边对照，误差太大就先查清洗流程。
3. 配方和模具：模型架构与训练目标
3.1 配方不是越复杂越好
模型架构的选择，对应的是蛋糕配方设计。参数量、层数、隐藏维度、注意力头数，这些都是配方里的原料配比。增加参数量通常能提升能力，但训练成本不是线性上涨，而是明显变贵。更关键的是，模型规模和训练数据规模要匹配。数据不够大而模型很大，容易过拟合；数据很大而模型很小，算力又被浪费。
很多人会把“参数量大不大”当成模型强不强的唯一指标。实际上，一个适合任务的架构，要综合考虑任务类型、数据规模、可用算力和部署成本。单纯堆参数量，就像做蛋糕时把所有配料都加倍，烤出来不一定好吃。
我的建议是：在资源不充裕时，先用一个很小的模型把完整流程跑通，确认数据、训练、评估、部署每个环节都没有问题，再按比例扩展模型规模。扩展时也保留一套可对比的小模型评测结果，方便判断变大之后到底带来了多少真实收益。
3.2 模具决定蛋糕形状：预训练任务设计
预训练任务就像模具上的花纹，决定了模型最终会呈现什么能力。现在主流的大语言模型用的是自回归任务：给定前面一段 token，预测下一个 token。这个设定让模型擅长文本生成。掩码语言模型则是遮盖一部分 token 让模型去还原，更适合学习双向语义表示。
这里有个经验：预训练任务定义不对，后面做多少微调都别扭。就像一个蛋糕模具已经定了形状，你后续上再多糖霜也改不了结构。所以在选基座模型或者设计自己的预训练任务时，先想清楚你到底要一个什么样的模型。要做对话助手，那就选生成式架构；要做语义表示，那双向编码器可能更合适。
损失函数也是模具的一部分。交叉熵是训练语言模型最常用的目标函数，但不同的损失设计会影响模型对难易样本的处理方式。作为入门阶段，先理解“损失函数是模型优化的方向标”就够了，等跑起来再观察不同损失设计对输出的影响。
4. 烤炉、火候与翻面：算力、学习率与状态监控
4.1 烤箱脾气要先摸清：算力环境和分布式并行
食材和配方再好，最后都要靠烤箱完成烘焙。对训练来说，烤箱就是 GPU 集群。显卡型号、显存大小、卡间通信带宽、数据加载速度，每一项都会影响训练效率和稳定性。
分布式训练里，数据并行、张量并行、流水线并行，本质上是在解决“如何让更多卡协同工作又不过度通信”的问题。多卡训练时，如果卡间通信效率低，你会发现 GPU 利用率上不去，训练整体很慢。判断瓶颈时不要只看卡的数量，要看实际吞吐：每秒钟处理了多少 token，或者多少样本。如果 GPU 利用率低，优先检查数据加载是否成为瓶颈，而不是盲目加卡。
混合精度训练（比如 BF16、FP16）能省显存、加速计算，但伴随的数值精度风险也需要关注。就像调烤箱风道，省电高效，但如果热风不均，蛋糕就会受热不一致。跑训练时如果出现 loss 异常波动或 NaN，先检查是不是数值精度设置在特定数据分布下出了问题。
4.2 温度曲线比温度本身更重要：学习率与批次大小
烘焙不能一直用一个温度，训练模型也不能一直用一个学习率。学习率预热（warmup）对应的是烤箱预热阶段：刚开始让模型以较小的学习率启动，避免早期梯度剧烈震荡，后面再逐步提高到设定值。
学习率过大的典型后果是 loss 飞升、梯度爆炸，像烤箱温度过高，表面焦了里面没熟；学习率过小，loss 下降很慢，像温度不够，烤了半天还是生面团。批次大小影响梯度稳定性，大批次通常需要配合更高的学习率，还要同步调整预热步数。这些参数不是孤立存在的，它们像一个联动系统。
我最常跟别人说的一句话是：不要一上来就照着大模型的训练配置抄。别人的配置是基于他们的数据规模、模型规模和集群条件调出来的，直接搬过来很可能水土不服。先拿小模型、小数据把一套配置跑通，再基于实际表现去调，才是更稳的路。
4.3 烘焙日志：哪些信号说明蛋糕还在正常长高
训练过程中，你要周期性确认蛋糕是不是在正常膨胀。最直接的信号是训练 loss 曲线。正常情况是前面下降快，后面逐渐变缓。如果 loss 不降、震荡剧烈，或者出现 NaN，就要停下来排查，不要指望“再跑一会儿自己就好了”。
梯度范数也是一个重要指标。梯度范数突然异常增大，往往意味着优化过程开始不稳定。吞吐量则告诉你训练快慢是否正常，比如每秒处理多少 token。显存占用能反映模型、数据、中间激活是否超出资源上限。
还有一件事，我建议当成铁律：定期保存 checkpoint。不只是最后保留一个最终权重。训练经常会在第几十个小时出问题，这时候如果只有最后一个 checkpoint，回退都很麻烦。像蛋糕烤到一半断电，只要你有面糊和配方，重新烤一炉并不难。多保存几个检查点，能省大量返工时间。
5. 出炉别急着切：评估、冷却与 Bad Case 试吃
5.1 多个指标同时看，不要只看 loss
蛋糕出炉不能只看表面颜色，模型训练完也不能只看训练 loss。训练 loss 低，说明模型记住了训练数据里的模式，但不代表它对没见过的新数据表现好。验证集上还要再测一次。如果训练 loss 低、验证 loss 高，那就是过拟合，模型记住了训练集细节，但没有学到可泛化的规律。
更完整的评估还要包括下游任务评测。常见的公共评测有知识类、推理类、代码类榜单，但这些榜单分数也只是参考。一个模型在榜单上表现好，不代表它在你的具体业务场景里好用。评估题目的分布、难易程度和真实应用场景的匹配度，往往比“总分高不高”更关键。
我建议每个训练阶段都固定跑同一组评测集，保留结果对比。这样你才能知道每一次参数调整、数据改动、模型升级，到底带来了正向还是负向变化。不然凭感觉调参，最后很难定位问题。
5.2 手工试吃：用典型 case 验证真实能力
指标之外，还要有人工“试吃”环节。准备一组典型输入，比如通用问答、文本总结、代码补全、翻译、多轮对话，依次让模型输出，然后观察输出质量：内容是否完整、格式是否符合要求、有没有重复、有没有明显的错误事实、有没有答非所问。
这一步极其有效。很多模型跑完指标看起来不错，但一问细节就露馅。试吃时碰到的 Bad Case，要记录下来并分析原因。可能是训练数据里本身就缺少相关类型，可能是微调时把模型带偏了，也可能是评估指标没有覆盖到某个维度。
我自己在试吃时喜欢模拟真实用户输入，而不是用标准评测题。真实用户不会按照你的模板提问，他们的表达更随意，更容易暴露模型的短板。
6. 糖霜不是越厚越好：微调、对齐与反馈
6.1 继续烤还是换配方：继续预训练与 SFT 怎么选
蛋糕烤好后，通常会根据客户口味做调整。对应到模型训练，就是微调。继续预训练是在原有模型基础上，用领域数据继续训练底层能力，适合领域数据量大、需要让模型深入理解某个专业领域的场景。指令微调（SFT）则是用“指令 + 理想回答”的样本，教模型学会按照用户指令输出，更适合让模型适配具体的任务形式。
这里有个常见误解：把 SFT 当成万能药，以为只要喂足够多指令样本，模型能力就会全面变强。实际情况是 SFT 主要改变的是输出形式和服从指令的能力，底层知识和推理能力还是预训练阶段打下的基础。SFT 数据集的“质量”比“数量”重要，几千条高质量样本，效果可能好过几百万条低质量拼凑数据。
选择继续预训练还是 SFT，核心看你要解决什么问题。领域知识不足，走继续预训练；输出格式不对、不跟指令，走 SFT。两者的数据准备方式、训练损失设计、训练成本都不一样，不能混为一谈。
6.2 RLHF 和过度对齐：糖霜过厚蛋糕会腻
RLHF（基于人类反馈的强化学习）可以理解为最后的糖霜装饰。先训练一个奖励模型，用来判断“哪个回答更符合人类偏好”，然后让主模型根据奖励信号调整输出。DPO 这类方法则是绕过显式奖励模型，直接用偏好数据做对齐，相当于换了一种上糖霜的手法。
糖霜的问题是容易过量。过度对齐时，模型会变得过于讨好奖励模型，输出开始模板化、机械地重复“我来帮你解决这个问题”这类套话，甚至频繁拒绝回答。表面上奖励分数可能在涨，但真实用户体验变差。这就是典型的“糖霜盖住了蛋糕本味”。
我的经验是：在对齐过程中要保留一组“底模对照”。微调和对齐后的模型，要时不时和原始模型做输出对比。如果发现某些原本稳定的能力明显回退，就要考虑是不是对齐目标设计出了问题。
7. 上架之后还要控温：部署、量化与推理优化
7.1 蛋糕烤好不等于能进展示柜：部署前的改造
训练完成的模型，距离对外提供服务还有一段路。蛋糕要切块、装盒、进展示柜，模型要做推理优化。最常做的是量化，比如把权重从 FP16 量化到 INT8 或 INT4，减少显存占用，提升推理速度。但量化不是无条件免费的，模型效果会有一定损失。
判断量化是否可行，不能用“跑不跑得动”做标准，要实测。我一般会先在测试集上跑一遍原始精度模型的结果，再跑一遍量化后的结果，对比关键指标变化。如果指标下降在可接受范围内，再考虑上量化。有些模型对量化很敏感，损失明显，那就只能维持更高精度。
部署时还要考虑推理框架的选择，不同框架对模型的支持程度、算子优化、动态 batch 处理能力都不一样。这部分建议以实测为准，不要只看网上的基准分数。
7.2 模型服务像蛋糕柜：吞吐、延迟和缓存要配平
展示柜需要恒温恒湿，模型服务需要控制吞吐、延迟和显存占用。KV cache 是推理时缓存历史 token 计算结果的技术，能显著减少重复计算。批处理则是把多个请求合并处理，提高吞吐，但并发太大，显存会先撑不住。
上线前要做压测，不要只盯着平均延迟。要看 p50 和 p95 延迟，看错误率，看显存峰值。p50 好不代表 p95 好，有些请求在长上下文、超长输出场景下会严重拖慢速度。还要考虑是否做缓存，高频问题可以缓存答案，减少重复计算，但长尾问题缓存命中率低，不能指望靠缓存解决所有性能问题。
8. 翻车现场：训练失败的症状、误判与排查顺序
8.1 烤糊、塌陷、夹生分别对应什么问题
训练翻车的表现和烤蛋糕翻车有很强的对应关系，我整理了一个常见症状表：
| 翻车状态 | 训练表现 | 常见原因 | 优先排查方向 |
|---|---|---|---|
| 烤糊（表面焦黑） | loss 飞升、梯度爆炸、NaN | 学习率过大、数据异常、数值不稳定 | 学习率、输入数据、混合精度设置 |
| 塌陷（出炉塌成饼） | loss 不降、模型输出单一重复 | 学习率过小、模型容量不足、数据太少 | 模型规模、训练步数、数据量 |
| 夹生（外熟内生） | 训练 loss 低但验证 loss 高 | 过拟合、数据泄漏、评估集与训练集重叠 | 数据去重、评估集构建、正则化 |
最常见也最容易误判的是“夹生”。你可能以为模型已经训练得很好了，因为训练集表现极好，结果一到新数据就崩。这时候要第一时间怀疑数据泄漏或者过拟合，而不是急着调参数。
8.2 排查时先看配料，再看烤炉，最后怀疑配方
训练出了问题时，我建议按固定顺序排查，不要东一榔头西一棒子。
第一，看数据。抽取几条训练样本，确认格式正确、切分正常、标签对得上。这个步骤成本最低，但经常能发现问题源头。很多“模型不收敛”的最终原因，是数据里混入了大量空文本或乱码。
第二，看环境。GPU 是不是真的在工作，显存有没有爆，日志有没有卡死，卡间通信是否正常，磁盘读取速度是否跟上。环境问题容易被忽略，因为它的报错不一定直接提示“环境问题”。
第三，看参数。学习率、批次大小、预热步数、权重衰减，这些超参数在当前数据规模下是否合理。不要直接抄大模型配置，先用小规模实验验证。
第四，看代码逻辑。损失函数是否写对、梯度是否正确更新、评估逻辑是否严谨、checkpoint 是否保存成功。这一步放在最后，因为它最容易让人陷入细节，但如果是代码 bug，前几步数据、环境、参数都看不出问题。
每次实验都要记录配置、数据版本、日志、评测结果。出问题后，这些记录是你定位问题的唯一线索。没有记录，排查就只能靠猜，效率会非常低。
把训练大模型看作烘焙，不是要把过程简单化，而是为了避免在最容易出错的环节里失去方向。数据不到位，后面再调参都补不回来；架构和任务不匹配，再多的算力也是在错误方向里狂奔；学习率、批次、监控做得不扎实，训练过程就是盲烤。真正落地时，最该盯住的不是“我用了多大的模型”，而是输入数据干不干净、训练日志正不正常、评估指标是否真实反映业务目标。先跑通一个小模型，再逐步扩大规模，比一开始就追求大模型要稳得多。
