把“训练大模型”这件事讲清楚最好的方式之一是把它看成“烤蛋糕”。这个比喻不是新发明但真正有价值的地方在于你能否把烘焙流程里的每个环节和大模型训练里的数据、模型架构、算力、超参数一一对上号。对上了你会发现很多之前觉得玄的东西其实都有对应的操作对不上比喻就是比喻听个热闹回头还是看不懂训练日志。这篇文章适合两类人看。第一类是刚接触 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前几步数据、环境、参数都看不出问题。每次实验都要记录配置、数据版本、日志、评测结果。出问题后这些记录是你定位问题的唯一线索。没有记录排查就只能靠猜效率会非常低。把训练大模型看作烘焙不是要把过程简单化而是为了避免在最容易出错的环节里失去方向。数据不到位后面再调参都补不回来架构和任务不匹配再多的算力也是在错误方向里狂奔学习率、批次、监控做得不扎实训练过程就是盲烤。真正落地时最该盯住的不是“我用了多大的模型”而是输入数据干不干净、训练日志正不正常、评估指标是否真实反映业务目标。先跑通一个小模型再逐步扩大规模比一开始就追求大模型要稳得多。