如果只看公开的训练曲线很容易产生一种错觉构建大语言模型就是把 Transformer 架构跑起来然后安静等待 loss 下降就行。真正推动过从零开始项目的人心里都清楚最终结果并不只由哪一次训练决定而是由四个阶段共同决定数据准备、预训练、后训练对齐、评估部署。这四个阶段的关系更像做菜食材决定上限火候决定下限调味决定是否可口最后端上桌让客人评价才算完整闭环。这篇文章就围绕这四个关键阶段展开。适合谁看不是只想扫一眼趋势的人而是手上有真实训练任务、准备从零开始练自己的模型或者至少想搞懂模型从数据到上线整个流程的程序员。我会把每个阶段最容易踩的坑摆出来也会把一些常规文档不太会写的选择逻辑解释清楚。1. 数据准备模型知识上限在源头就已锁定很多团队在启动项目时第一反应是找模型结构、调显卡配置却把数据当成“反正网上随便抓一点就能训练”。我的实际感受是数据对最终质量的影响经常被严重低估。同样一套底座配置数据清洗流程不同最终评测分数可以差出好几个点而且这部分差距很难通过后续加大训练步数来弥补。为什么数据这么关键因为语言模型的能力边界本质上是“它见过什么”决定的。模型架构决定学习效率但知识容量、表达风格、常识覆盖范围全部来自语料。所以数据准备并不是一个可有可无的“跑腿活”而是整个项目中投入产出比最高的环节。1.1 数据采集与去重数量不等于多样性原始语料通常来自网页抓取、开源代码、图书论文、论坛讨论等渠道。问题也很一致噪声高、格式混乱、重复严重。这里最容易被低估的是重复问题。精确去重比较好理解把完全相同的文档做哈希去重。但真正棘手的是模糊重复——网页模板、转载文章、转述内容它们看起来不完全一样但信息熵极低。如果这些内容大量进入语料模型会反复读到近似文本训练时长被浪费生成结果还会变得越来越模板化。模糊去重的常见做法是局部敏感哈希比如对文档做 n-gram 切分后生成多个哈希签名再用这些签名做相似度分桶。切分粒度需要根据数据形态调整网页文本一般用 5 到 8 个字符的 n-gram 比较合适代码数据因为结构性强可以适当调大。中文语料还需要额外处理简繁体、全半角符号差异不然同一个知识点会被算成两份不同内容。我见过不少项目把去重环节做得非常粗糙只做了文件级精确哈希结果训练语料里仍然混着大量重复段落。检查方法也很简单随机抽一批训练样本统计重复 n-gram 的占比。如果这个比例明显偏高去重流程还得继续做。一段简化版的处理逻辑可以这样写方便理解整个流程def deduplicate_documents(docs, ngram_size6, sim_threshold0.8): # 第一步计算每篇文档的哈希签名 signatures [] for doc in docs: tokens tokenize(doc) signature compute_minhash(tokens, ngram_sizengram_size) signatures.append(signature) # 第二步用分桶索引找到候选重复对 candidates find_similar_pairs(signatures, thresholdsim_threshold) # 第三步在候选对上做精确文本比对确认是否真的重复 keep set(range(len(docs))) for i, j in candidates: pair_sim text_similarity(docs[i], docs[j]) if pair_sim sim_threshold: # 保留质量更高的一篇另一篇标记为重复 if quality_score(docs[i]) quality_score(docs[j]): keep.discard(i) else: keep.discard(j) return [docs[i] for i in sorted(keep)]1.2 质量过滤与清洗先说清楚“干净”是什么不同目标任务的“干净”含义完全不同。通用对话模型需要保留丰富的生活化表达代码模型则要保留大量结构化代码和注释垂直领域模型反而要刻意筛掉无关信息。所以不要一上来就追求一套万能过滤规则。实践中通常用“强规则 弱模型”的分层过滤。强规则负责处理明显的机器垃圾语言识别、标点符号密度、符号重复率、文档长度、平均句长等。比如信噪比极低的页面字符重复率会异常高这类样本直接丢掉即可。接下来再用一个文本质量分类模型做打分——用少量人工标注样本训练一个小模型专门判断“这条语料是否像是人类高质量写作”。打分后设定阈值低分样本不进入训练集。还有一个反直觉的细节过滤太狠会损害长尾知识。很多低频专有名词、方言表达、冷门领域的知识恰恰藏在那些看起来“不够通顺”的网页里。所以实际操作中我不会把阈值卡得太死而是优先只过滤机器垃圾和严重格式错误保留边缘样本因为多样性的价值经常被低估。清洗时还要处理隐私和安全信息。邮箱、手机号、身份证号、地址这类内容应当脱敏而且不能只在某一处处理完就结束因为数据会经过多次流转和拼接。最简单的方式是建立统一的脱敏组件在下游的每个数据管道节点重复调用一次确保最终进入训练集时不会出现完整敏感信息。1.3 数据配比与采样策略别让模型偏科数据配比直接影响模型在中文、代码、数学、推理这些不同能力上的表现。一个常见的错误是目标偏中文就拼命灌中文语料结果代码和逻辑能力明显下降反过来如果通用网页数据占比过高模型聊天很流畅但写代码总是崩。表一个比较稳妥的起始配比范围数据类型占比范围作用通用网页文本50% - 65%提供常识和开放域知识代码数据10% - 20%提升逻辑、结构和指令执行能力数学与科学文本5% - 10%强化推理能力图书与长文档5% - 10%增强长文本建模和理解能力多语言平行语料3% - 8%改善多语种对齐和翻译能力指令与对话数据0.5% - 2%让底座模型初步具备对话形态具体数值不能照搬因为不同项目的目标场景差别很大。我的做法是先按一个初始配比训练小规模模型同时拆出多组验证集分别观察中文、代码、数学、通用对话上的 loss 变化。如果某个领域能力明显偏弱就在下一次迭代中调整配比而不是拍脑袋决定。采样策略上也要注意重复度。某个语料子集如果被反复上采样模型就容易出现“局部背诵”现象表现为生成时重复固定句式。低资源语言可以做适度上采样但要设置一个上限。更合理的路径是尽量提高低资源语料本身的采集质量而不是靠重复喂数据硬撑。分词器训练同样属于数据工程的一部分。词表大小和语料匹配度会影响训练效率。中文场景下词表太小会把常用汉字切得很碎浪费上下文长度词表太大又会让 embedding 矩阵占大量参数。比较常见的区间是 50k 到 100k。词表必须用目标语料训练不能用其他语言词表凑合否则中英混合场景下的训练效果会受到明显影响。2. 预训练阶段架构选型和训练稳定性的真实功课数据准备好之后接下来就是预算消耗最大的阶段预训练。这段时间里很多人最关心“loss 降到了多少”但真正考验工程能力的是“能不能稳定地、不浪费地跑完整个训练”。一次中途崩溃就可能浪费数天算力这类事故在真实项目中反复出现。预训练阶段要处理的问题可以拆成三块模型结构选型、超参数确定、分布式训练稳定性。这三块环环相扣任何一块出问题训练曲线都会很难看。2.1 模型结构选型底座尺寸和注意力机制基础结构是 decoder-only 的 Transformer这个基本没有争议。但具体参数配置里有不少选择要做隐藏维度、层数、FFN 比例、注意力头数量、位置编码方法、注意力变体。以常见的 7B 参数级别为参考一组实践中比较稳的配置是隐藏维度 4096层数 32 到 36 层FFN 维度约为隐藏维度的 3 倍激活函数使用 SwiGLU位置编码使用 RoPE注意力机制使用 GQA。为什么强调 GQA因为推理阶段 KV cache 是显存占用的大头GQA 能显著减少 cache 大小训练的时候也不会引入太复杂的并行约束。对算力有限的团队来说哪怕做一个 1B 级别的模型也建议直接选用 GQA 或 MQA而不是标准多头注意力这样后续部署会轻松不少。上下文长度不要一上来就追求超长。比较稳妥的路线是先用 4k 或 8k 训练底座把模型训稳定之后再用长文本数据做持续预训练逐步扩展到更长上下文。这样做的好处是训练成本可控而且不容易因为“一步到位”导致短文本能力退化。词表大小就是前面提到的数据工程问题。如果目标语料包含大量中文和代码建议词表规模选在 64k 到 80k 之间。词表过小的直接表现是中文字被切得支离破碎同样一段文本需要更多 token 才能表达实际上下文利用率下降训练成本反而更高。2.2 训练超参数和规模法则先小后大不要一步到位大模型训练不是“把所有资源和参数一次堆满”。合理的流程是先做小规模摸底再放大到目标规模。规模法则给了一条参考线7B 级别模型通常需要 1T 到 1.4T token 才能充分发挥能力1B 级别模型几十 B token 就能看到明显效果。因此在小规模模型上快速验证数据和代码成本要低得多。真正开训之前建议先做一个 0.1B 到 0.3B 的微型模型跑几百步观察 loss 曲线。如果连小模型都不能稳定下降说明数据、代码或超参数设置有问题不需要急着上大机器。常用超参数可以参照这套起点AdamW 的 beta1 设为 0.9beta2 设为 0.95epsilon 设为 1e-8权重衰减 0.1梯度裁剪 1.0峰值学习率在 7B 模型上通常从 3e-4 左右开始调。学习率调度采用 warmup 加余弦退火warmup 步数约占训练总步数的 1% 到 2%最终学习率衰减到峰值的 1/10。学习率与 batch size 之间要联动调整。从较小 batch 切换到较大 batch 时学习率通常要按比例放大但放大的倍数不能过于激进否则容易出现 loss spike。实际操作中我会先记录小 batch 下的曲线形态再逐步放大 batch并同时观察梯度范数的变化。梯度范数突然飙高往往是网络内部数值溢出的前兆。混合精度方面主流做法是使用 BF16。BF16 的指数位比 FP16 更宽能覆盖更大数值范围训练稳定性明显更好。即便如此仍然需要额外做 loss scaling 或梯度规约检查。对关键 checkpoint 不仅要保存权重还要保存优化器状态、学习率调度器状态、随机数状态和数据采样游标。如果只存权重重启训练之后数据顺序会重复学习率调度也会跟着错位后续 loss 曲线就很难解释到底发生了什么。2.3 分布式并行策略把卡用好比把卡堆好更重要说到分布式训练很多人第一反应是“卡越多越好”。但实际上并行策略的选择取决于卡数、显存、通信带宽和数据规模。只堆卡而不设计并行方式通信开销可能吞掉大部分算力收益。表三种并行策略的适用场景对比策略适用规模显存压力通信开销数据并行 梯度累积单机多卡较低低分布式优化器分片多人多卡显著降低中等张量并行单机多卡且单卡放不下模型高高一个比较实用的路线是8 卡以内主要用数据并行配合梯度累积来扩大 batch16 卡以上再引入分布式优化器分片。张量并行虽然能降低单卡显存但每一层都需要同步通信对带宽要求很高通常只在单卡实在放不下权重时才启用。流水线并行可以节省显存但容易出现“空转”和负载不均的问题需要多花精力做阶段划分。训练过程中的可观测性同样关键。除了 loss 之外建议持续记录梯度范数、学习率、层激活分布、吞吐量tokens/sec、显存占用这些指标。尤其不要只盯一个总 loss而是把验证集拆成多个子集分别观察通用文本、代码、数学这些领域的 loss。这样最早能发现某个领域能力突然退化而不是等整个模型训练完了才后悔。3. 后训练对齐从“会生成文字”到“按要求办事”预训练完成后模型本质上是一个“高水平的自动补全器”。它能续写出通顺的段落但用户问一句“帮我写个函数”它可能继续往下写一段无关的代码而不是直接给出回答。后训练对齐要解决的就是这个问题把“会说话”变成“懂规矩、能办事”。对齐通常分为两个步骤指令微调SFT和偏好优化常见的是 RLHF 或 DPO。很多团队在这一阶段最容易犯的错误是用大量数据把模型“喂吐”结果模型从“能力不够”变成了“很油滑但能力下降”。3.1 SFT 数据设计指令数据不等于问答堆料SFT 阶段不需要几百万条数据。更准确地说几万条高质量数据通常就能覆盖常用场景。关键在于数据质量和多样性开放问答、摘要、翻译、改写、编程、推理、安全拒答都要有覆盖。指令数据的设计有几个容易被忽略的地方。第一难度要有梯度。如果全是“什么是某某”这种简单问答模型只会形成浅层记忆。第二编程数据要同时给出问题和可运行代码最好包含执行结果和简单分析让模型学会“看结果说话”。第三多轮对话数据要覆盖“用户追问、澄清、修改要求”的场景而不是只有单轮问答。一个典型坑是模板过拟合。如果所有训练数据的格式都完全一致模型可能只会输出那一种结构换个格式就乱掉。补丁方式是数据里自然混入不同格式Markdown、JSON、表格、纯文本、代码块每种格式都要有。同一时刻数据去重也很重要。同一个问题如果有多个不同答案模型会学到“摇摆”输出结果不稳定。遇到这种样本要保留标注质量更高、更完整的一条把其余版本删掉。训练的时候要监控过拟合。如果 SFT 之后模型在验证集上几乎零 loss通常不是好事说明模型把训练数据背下来了而不是学会了泛化。应对方法是缩短训练步数、增加数据多样性或者在训练中引入少量 dropout。3.2 RLHF 与 DPO选择适合团队资源的方式完整 RLHF 链路需要一个奖励模型、一个策略模型、一个参考模型还可能加上 Critic 模型训练流程长、超参数多、调起来非常费时间。相比之下DPO 不需要显式训练奖励模型直接在偏好数据上优化策略模型工程实现更简单。表RLHF 与 DPO 的对比维度完整 RLHFDPO训练成本高多模型协同训练低无需奖励模型训练稳定性需要处理 PPO 多项超参相对直接但需防过拟合样本效率对偏好对的利用较间接能直接利用偏好对调试复杂度高探索和奖励噪声大较低适合快速迭代DPO 的核心思想是让模型更倾向于选择人类偏好的回答同时不要偏离参考模型太远。损失函数里通常有一个温度参数 beta控制对偏好的拟合强度beta 一般设置在 0.1 到 0.5 之间。DPO 的学习率要比 SFT 低很多我常用的是 1e-6 到 1e-7 这个区间不然很容易把模型训“飞”。实际项目中很多通用助手场景只需要“SFT 小步 DPO”就够了。只有在对攻击性、安全性要求很高的场景才需要上完整 RLHF 链路。而且 DPO 有个已知副作用在代码和数学能力上有时会发生退化。所以做偏好对齐之前要先把评估基线跑出来对齐后再跑同一套基线确认没有明显损伤才算安全。3.3 对齐税与过度拒绝问题对齐过程中有一个绕不开的现象叫“对齐税”——为了让模型更符合人类偏好模型可能在生成多样性、创造力和某些推理能力上有所损失。这个现象在安全类数据比重过大时尤其明显。另一个常见副作用是过度拒绝。如果训练数据里安全拒答样本太多模型会对“争议词”、“敏感词”过度敏感用户问一句稍微沾边的内容它直接拒绝。解决方式不是简单删掉安全数据而是调整安全数据的比例并且增加“修改、说明、替代回答”的样本类型让模型学会给出建设性回应而不是只会拒绝。偏好数据的质量也直接影响结果。有些团队为了快速制作数据生成大量“倾向性明显但答案本身很一般”的对比对模型学到的其实是“模仿一种更讨好的语气”而不是“做对任务”。这样反而降低了模型实际可用性。4. 评估、部署与持续迭代模型上线才算闭环一个模型能聊天、能通过测试并不代表可以上线。现实中常见的现象是团队把 90% 的时间和算力花在训练上最后用 10% 的时间匆匆跑一遍评测就发布结果上线后问题不断。评估、部署和持续迭代这三个环节本质上决定模型能不能真正产生价值。尤其对于程序员来说模型训练只是手段通过服务接口稳定地输出有用结果是目的。4.1 建立评估体系跑分高不代表任务表现好通用跑分自然会看但不能只看。训练语料里大概率包含这些测试集的相关内容分数很容易虚高。真正有用的评估体系应该包含三部分通用基准作为横向参考、内部自建任务集作为纵向回归、人工抽评作为最终把关。内部任务集要尽量贴近真实使用场景。比如产品是客服助手就要准备一批真实用户问题样本产品是代码助手就要准备各种语言和框架的编程任务。把真实场景的问题固定下来形成一份“回归集”每次模型迭代后都跑一遍能及时发现某个领域能力退化。评测过程还要注意解码稳定性。生成任务有随机性评估时把温度设为 0并对同一批样本跑多次取均值。分数波动在 1 到 2 个百分点以内通常算正常。如果某次迭代分数提升 0.5 分那可能是随机噪声不必过度反应。4.2 推理部署优化显存占用和输出延迟的平衡部署阶段最常见的问题是“模型能跑但延迟和成本都不可控”。生成式模型的最大显存压力其实来自 KV cache而不只是权重本身。上下文越长KV cache 越大。这也是我前面强调模型结构要选 GQA 的原因——推理阶段省下的显存非常可观。量化是另一个常用手段。把权重从 FP16 量化到 INT8 或 INT4通常能将显存需求压缩一半以上。但量化对逻辑类任务的损伤有时会更明显尤其数学和代码生成。所以量化的力度不要拍脑袋定而是先跑一套标准评测集对比不同量化精度下的分数再决定。如果当前推理延迟已经满足要求就不要激进地使用低比特量化。推理服务层面尽量使用支持“连续批处理”和前缀共享的框架。连续批处理可以把多个请求拼在一起复用注意力计算显著提升吞吐前缀共享对多轮对话和长提示词场景非常有效。部署架构可以按场景拆分通用问答用一个实例代码生成用一个实例并给不同实例设置不同的并发和量化等级这样成本控制会更灵活。4.3 数据回流与版本迭代上线只是第一步模型上线后还应该继续从真实使用中收集数据。真实请求是比任何人工构造数据都宝贵的样本来源。但要特别留意隐私和合规不能未经处理就把线上数据丢进训练集。筛选思路是找出“用户多次提问但模型回答质量不佳”的样本做人工标注形成新增 SFT 数据。每次迭代都通过自动评测回归确认整体能力不退化再上线。千万不要每来一批新数据就重新训练一次那样无法定位能力波动原因。保持单变量修改原则一次迭代只改变一个环节比如只增加数据或只调整训练超参这样排查问题才有效率。版本管理也不能只看权重文件。每个模型版本应该关联记录数据配比、清洗流程版本、训练超参、迭代步骤、评估结果、上线时间。这个记录可能听起来繁琐但等模型迭代到第五、第六版时它会是唯一能帮你捋清思路的资料。最后分享一点个人经验这几年接触大模型研发我越来越强烈的感受是最容易拖垮项目的不是模型结构本身而是数据清洗、评估体系、版本管理这些“看不见的环节”。很多团队热衷研究最新架构最后却被数据里的重复、部署时的 KV cache、评测集里的污染拖住手脚。如果让我给一个建议那就是先走通最小规模的完整链路拿一个 1B 左右的模型把数据准备、预训练、SFT、偏好优化、部署评估全流程跑一遍。流程跑通之后再去叠加参数和数据规模。这个顺序看起来慢实际上才是最快的路径——因为 LLM 项目真正复杂的地方从来不在单一环节而在环节之间的衔接。