这次我们来看一个很有意思的角度把 LLM 训练的全过程当成一次做烘焙。很多人在学习大模型时第一道坎不是理论看不懂而是概念太多、流程太长不知道把预训练、SFT、RLHF、评估、部署这些词按什么顺序放进脑子里。实际上训练大模型和烤一炉面包之间的相似程度远超你的想象都需要选料、揉面、发酵、整形、烘烤最后还要放凉了才能切。每一步火候不对、原料不干净、发酵时间不够出来的东西都不会好吃。这篇文章不带你调包也不讲高深数学而是用烘焙的工序把 LLM 训练从数据准备到部署上线的完整链路重新过一遍。读完你会对以下问题有清晰的判断预训练到底在学什么SFT 和 RLHF 分别解决什么问题为什么对齐后的模型有时反而变笨以及模型出炉后为什么要做量化蒸馏。如果你是刚接触大模型训练、想建立一个全局认知的开发者和算法工程师这篇文章可以直接收藏。1. 训练与烘焙全流程对照先把整条链路摆出来。下表是烘焙工序与LLM 训练阶段的完整映射后续每一节都会展开讲。烘焙阶段对应 LLM 训练环节核心问题选面粉和配料数据收集与清洗用什么学原料干不干净揉面预训练 Pretraining让模型学会语言规律和世界知识发酵算力扩展与模型规模增长为什么数据、参数、算力要一起涨整形监督微调 SFT让模型学会按指令对话调味RLHF / DPO 偏好对齐让模型的回答符合人类偏好烘烤定色评估 Evaluation怎么判断这炉模型熟没熟放凉与切块量化 / 蒸馏 / 部署上线把大模型压缩进实际生产环境这个对应关系不是生搬硬套。预训练阶段模型只学会补全文本就像基础面团只是面粉和水的混合物SFT 之后的模型才像被整形成面包胚经过 RLHF模型才拥有该说什么、不该说什么的味觉判断。理解这个逻辑后面看任何大模型技术文档都会顺很多。2. 选面粉数据收集与清洗烘焙的第一步不是开烤箱而是选料。面粉好不好直接决定面包能不能发起来。LLM 训练同理数据质量决定模型上限模型结构只是逼近这个上限的手段。2.1 数据从哪里来预训练数据的常见来源包括网页爬取、书籍、论文、代码仓库、百科、论坛帖子等。这些原材料统称语料库规模通常是数万亿 token。所谓 token可以理解成模型读取文本的最小单位一个英文单词可能拆成一个或几个 token一个汉字通常是 1 到 2 个 token。很多初学者会忽略一个事实模型不会主动区分这段话是知识还是垃圾。它只会根据统计规律学习。如果语料里 30% 是重复内容、广告信息、乱码 HTML模型学到的东西就会偏。2.2 清洗是脏活也是护城河数据清洗做的工作本质上和烘焙前筛面粉一样去重网页正文大量重复不去重会导致模型学会复读机。过滤去掉低质量页面、乱码文本、非自然语言内容。隐私处理删除个人手机号、邮箱、身份证等信息这是上线前必须做的合规动作。语言识别按语言分布控制各语种比例避免某一语种过度主导。处理后的数据还需要做 tokenization把文本转成模型能读的数字序列。这一步有一些现成框架可以复用比如 Hugging Face 的datasets和tokenizers。2.3 数据配比配料表决定风味烘焙配方讲究面粉、水、酵母的比例。LLM 训练同样讲究数据配比通用文本占多少、代码占多少、数学占多少、多语言占多少。不同的配比会训练出不同偏好的模型——代码占比高的模型编程能力强数学语料多的模型推理能力相对突出。这个配比在业内通常属于核心实验机密也是最值得花时间调的工程点之一。一句话总结模型训练 80% 的时间都在折腾数据真正写模型代码的时间占比很小。别一上来就追求大模型、大 GPU先把数据洗干净、配比想清楚。3. 揉面预训练到底在学什么材料备齐后进入最核心的环节预训练。这一步对应揉面——把面粉和水揉成有筋性的面团。筋性不是面粉自带的是揉出来的语言能力也不是模型天生有的是训练出来的。3.1 预训练目标下一个 token 预测预训练任务很简单给模型一段文本的前面部分让它预测下一个 token 是什么。比如给出今天天气真模型需要预测下一个字大概率是好。这个目标叫自监督学习因为不需要人工标注。互联网上的所有文本天然就是训练数据每段文本都可以切成前文-后文的监督对。# 伪代码预训练的一个训练步骤 for batch in dataloader: inputs batch[input_ids] # 输入 token 序列 labels batch[labels] # 目标 token 序列错位一位 logits model(inputs) # 前向传播 loss cross_entropy(logits, labels) # 计算损失 loss.backward() # 反向传播计算梯度 optimizer.step() # 更新参数模型参数量越大、训练数据越多它能记住的语言模式就越复杂。这个过程很像揉面刚开始面团不成形多揉几轮之后面筋网络才逐渐形成。对应到模型上就是训练初期 loss 快速下降、输出基本不成句训练中后期才开始生成连贯有意义的文本。3.2 预训练的硬件门槛预训练是 LLM 全流程里最烧钱的阶段不是普通开发者在单机上能完成的事。这里只给出量级判断具体数字以实际环境和模型规模为准数十亿参数的小模型需要多张高端 GPU训练数天到数周。百亿到千亿参数模型通常需要几十到上百张 GPU训练数周到数月。更大规模模型往往需要上千张 GPU 组成集群配合分布式并行策略。这也就是为什么绝大多数团队不会从零预训练大模型而是基于开源底座模型做微调。就像你不会从种小麦开始做面包而是直接买现成面粉甚至冷冻面团。3.3 分布式训练的通用姿势如果你确实需要自己训练小规模模型或者参与预训练任务需要了解三类并行策略策略解决什么问题通俗理解数据并行单卡放不下一个 batch多个人同时揉同一份面团张量并行单卡放不下整个模型把一块大面团分成几块同时揉流水线并行模型层数太多放不下一条流水线上每人负责一段工序框架层面 PyTorch 自带DistributedDataParallel大模型训练常用 DeepSpeed 和 Megatron-LM。不过这些属于进阶内容第一次接触预训练建议先用小模型在小数据集上跑通流程再逐步扩大规模。4. 发酵Scaling Law 与模型能力涌现面团揉好之后要等它发酵。发酵不是简单地等时间而是酵母在合适温度湿度下繁殖、产生气体把面团撑起来。模型的发酵过程就是算力和数据规模增加到一定程度后能力出现质变。4.1 Scaling Law 是什么OpenAI 在 2020 年发表的论文《Scaling Laws for Neural Language Models》提出了一个经验规律模型性能loss与参数量、数据量、计算量之间存在幂律关系。通俗理解就是模型越大、数据越多、算力越强效果越好但收益会递减。这个规律在工程上影响深远以前大家纠结模型结构后来发现规模比结构更能提升效果。模型扩大后训练数据也要同步扩大否则模型消化不良。算力投入存在边际效应到了一定规模后性价比急剧下降。4.2 涌现能力是玄学也是工程模型规模跨过某个阈值后会突然表现出一些小模型没有的能力比如思维链推理、上下文学习、代码生成等。这种现象被称为涌现能力。它和面包发酵到临界点突然膨大是一个感觉前面看着没什么变化烘烤后却完全换了一个形态。不过需要提醒的是涌现能力并不稳定。同样的能力在不同模型上的表现差异很大且高度依赖数据分布。工程上不能把业务押在一个可能涌现的能力上还是要用评测来验证。5. 整形SFT 监督微调发酵好的面团还是一个大面团要做成吐司还是法棍需要整形。对应到模型训练就是 SFT——用人工标注的指令数据把会补全文本的基础模型调教成会按指令回答问题的对话模型。5.1 为什么需要 SFT预训练模型只会做一件事续写文本。你问它北京的冬天怎么样它可能给你续写一段百科词条而不是像正常人那样聊天。SFT 就是用大量指令-回答对教模型学会对话的格式和语气。数据格式大致长这样[ { instruction: 北京的冬天怎么样, output: 北京冬季寒冷干燥气温一般在 -5℃ 到 5℃ 之间偶尔会有大风和降雪。建议穿羽绒服并注意保湿。 }, { instruction: 用一句话解释什么是数据库索引, output: 数据库索引是一种加速数据查询的数据结构类似于书籍的目录。 } ]SFT 使用的数据量远小于预训练通常只需要几万到几十万条高质量指令。它的作用不是输入新知识而是把模型已有的知识解锁成能按要求输出的形式。5.2 SFT 的关键点数据质量优先不要追求数量堆砌。几百条高质量指令的效果往往好过几万条脏数据。覆盖场景要全。分类、抽取、摘要、问答、写作、代码各场景都要有样本。注意指令多样性。同一个问题换多种问法模型才不容易过拟合到固定模板。目前做 SFT 最常用的开源工具是 LLaMA-Factory支持 LoRA、QLoRA 等高效微调方式单卡也能跑。后面第 10 节会给出具体建议路径。6. 调味RLHF 与 DPO 偏好对齐面团整形完面包胚还是原味的。要想好吃得调味。这个环节对应 RLHF——基于人类反馈的强化学习通俗说就是让模型学会什么回答是好的什么回答不能给。6.1 RLHF 的三段式流程训练奖励模型让人对同一个问题的多个回答打分排序训练一个能预测人类偏好分的奖励模型。用强化学习优化策略让对话模型生成回答用奖励模型打分通过 PPO 等算法更新模型参数。迭代重复生成-打分-更新过程模型逐步对齐人类偏好。人类排序 - 奖励模型 - 强化学习更新策略 - 新策略 - 新回答 - 再排序6.2 DPO更省事的替代方案RLHF 的工程复杂度很高要训练奖励模型、要调 PPO 的稳定性、超参很多。后来出现的 DPODirect Preference Optimization跳过显式奖励模型直接用偏好数据优化策略实现更简单、训练更稳定成为开源社区微调的主流选择。6.3 对齐税为什么对齐后的模型变笨了一个真实存在且经常被讨论的现象经过 RLHF 或 DPO 后的模型在数学、代码、推理等基准测试上分数可能下降因为对齐过程约束了模型的输出空间导致一些直给的正确回答被抑制成更安全、更委婉的表述。这个现象叫对齐税。工程上需要在帮助性、安全性、准确性之间做取舍没有免费午餐。对齐阶段还要注意安全和合规边界。涉及人脸生成、音色克隆、自动对话上线的场景必须确保数据来源合法、使用了有授权的素材和身份信息并且对生成内容做人工复核。7. 出炉检验评估模型效果面包烤出来不能直接卖得看颜色、听声音、按弹性。模型训练完也要评估判断这炉模型熟没熟、能不能上线。7.1 自动评估用公开 benchmark 测试通用能力MMLU、C-Eval 等代码能力HumanEval、MBPP数学能力GSM8K、MATH中文能力CMMLU、C-Eval这些测试的分数可以横向对比模型版本但不能完全代表真实业务效果。benchmark 刷分和实际好用之间经常有差距。7.2 人工评估最可靠的方式是让标注人员对模型回答打分。维度通常包括准确性、相关性、流畅度、安全性。人工评估能发现自动指标发现不了的问题比如模型看似回答流畅但其实在编造事实。一个简单好用的评估脚本模板import openai def evaluate_model(api_base, api_key, model_name, questions): client openai.OpenAI(base_urlapi_base, api_keyapi_key) results [] for q in questions: resp client.chat.completions.create( modelmodel_name, messages[{role: user, content: q}], temperature0.2 ) results.append(resp.choices[0].message.content) return results questions [ 解释一下什么是 Transformer 注意力机制, 写一个 Python 函数判断回文串, ] outputs evaluate_model( api_basehttp://127.0.0.1:8000/v1, api_keyEMPTY, model_nameyour_model, questionsquestions ) for q, o in zip(questions, outputs): print(f问题: {q}\n回答: {o}\n)7.3 过拟合的判断评估集和训练集必须严格分开。如果模型在训练集上效果很好、在验证集上效果大跌说明过拟合相当于面包烤得外皮焦黑、里面还没熟。此时应该增加数据多样性、加大正则化或者提前停止训练。8. 放凉切块量化、蒸馏与部署面包出炉后不能趁热切要放凉定型。模型训练完也不能直接上生产要经过压缩优化才能以合理的成本提供服务。8.1 模型压缩三板斧量化把模型权重从 FP16 压缩到 INT8 或 INT4减少显存占用和推理延迟。最常见的工具是 GPTQ、AWQ、bitsandbytes。蒸馏用大模型教师的输出训练小模型学生让小模型逼近大模型的效果。适合对延迟敏感的场景。剪枝去掉冗余参数减少模型体积。目前实际落地不如量化和蒸馏普遍。量化是部署中最常用的手段。一个 70B 模型在 FP16 下光权重就占约 140GB用 INT4 量化后可以降到约 35GB单张 48GB 显存的显卡就能跑。需要明确的是具体显存占用以实际模型和推理框架为准不同量化方法和上下文长度差异很大。8.2 部署形态选择本地部署使用 vLLM、Ollama、llama.cpp 等框架启动服务。API 服务把模型封装成 OpenAI 兼容接口。边缘部署量化后放到手机或嵌入式设备。部署时至少要回答这几个问题支持多长的上下文、并发多大、单个请求延迟多少、显存是否够用、是否支持流式输出。建议先用 vLLM 起一个本地服务做压测再决定要不要引入更重的推理集群。9. 训练中常见的翻车现场与排查下面整理训练和部署中最常见的几类问题按现象、原因、排查方式、解决方案整理成表。问题现象可能原因排查方式解决方案Loss 不下降学习率过大或过小、数据噪声大打印 loss 曲线检查数据样例调整学习率、增加 warmup、清洗数据Loss 突然飙升后不恢复训练不稳定学习率过高或 batch 过大查看 spike 前后参数变化降低学习率、梯度裁剪、减小 batch模型只会复读输入数据重复度过高或模型过拟合检查训练集去重情况加强数据去重、增加 dropout微调后通用能力下降灾难性遗忘同时评测微调前后通用 benchmark混合通用数据、用 LoRA 减少参数更新范围显存不足 OOM模型太大或 batch 太大观察显存监控曲线减小 batch、梯度累积、用 QLoRAAPI 调用报 400 / context length 超限输入超出模型最大上下文检查请求 token 数控制上下文长度分段输入模型输出不稳定解码参数设置不当对比不同 temperature 输出降低 temperature固定 seed服务端口冲突端口被占用检查端口占用进程修改服务端口排查问题时有个通用原则先复现再最小化。把出问题的输入样本单独拿出来测试逐步去掉上下文干扰往往能快速定位到是数据问题、模型问题还是推理参数问题。10. 实践建议从开源模型微调入门如果你是从零开始接触 LLM 训练不建议一上来就预训练。更务实的路径是从开源底座模型出发用 LoRA 或 QLoRA 做微调成本低、见效快。10.1 推荐的入门路径用 LLaMA-Factory 加载 Qwen、Llama 等开源模型。准备几千条高质量指令数据覆盖你想让模型学会的场景。先跑通训练流程再逐步调整数据配比和训练参数。用验证集评估效果对比微调前后差异。QLoRA 的核心思路是对预训练权重做 4-bit 量化只训练少量低秩适配器参数。效果上接近全参微调但显存占用大幅降低消费级显卡也能跑。# LLaMA-Factory 微调配置示例需按实际环境调整 model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft dataset: my_instruction_data finetuning_type: lora lora_rank: 64 lora_target: all output_dir: outputs/my_model per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.0e-4 num_train_epochs: 3 loraplus_lr_ratio: 1610.2 必须养成的工程习惯小参数先跑通先用 1B 模型、1000 条数据验证流程再上大模型。目录分清楚模型文件、原始数据、清洗后数据、训练日志、输出结果分开管理。每次训练都记录配置数据配比、超参、训练步数、评估结果方便复现和对比。服务访问范围要控制本地 API 服务不要裸暴露到公网Docker 部署建议加网络隔离和鉴权。涉及人脸、声音、版权素材的生成类模型务必确认训练数据来源合法获得必要授权输出内容上线前做合规审核。11. 总结回到最初的问题用烘焙理解 LLM 训练最有价值的不是一个类比而是它帮你建立了正确的流程认知。数据是面粉预训练是揉面规模是发酵SFT 是整形RLHF 是调味评估是出炉检验量化部署是放凉切块。每个阶段都有各自的难点和坑它们的优先级和投入比例截然不同。最先值得关注的一定是数据质量因为它的影响贯穿全流程。最容易踩的坑则是越过数据直接调模型结构和超参——面包发不起来多数时候不是烤箱问题是面粉和发酵条件出了问题。后续如果你想继续深入可以从三个方向扩展一是把评估体系建好让每次训练都有可比对的基线二是用 RAG 给模型补外部知识解决私有知识库场景三是把微调和部署流程做成自动化流水线减少重复劳动。这套以数据为中心的工程视角才是真正能迁移到大模型实战中的东西。建议收藏备用下次训练模型或者看技术方案时拿出来对照一下。