1. 为什么我会从零训练一个小语言模型三条不得不走的路先交代背景。我做了几年NLP应用大多数时候都在微调别人开源的大模型。但是最近几个月我决定把“训练”这件事从头做一遍产出了一个我在文章里暂且叫它Xihe的小语言模型。训练一个只有1B参数左右的小模型在很多同行看来是“吃力不讨好”毕竟现在大家都在卷大参数量、卷长上下文、卷多模态。我反而觉得如果你真想搞懂语言模型是怎么工作的、想完全掌控部署链路、想花小成本获得一个能用的专业助手从零训练一个小模型这条路非走不可。促使我这么做的原因有三个第一我当时手头有一个继续预训练CPT的需求——希望模型在特定领域语料上有更强的理解能力但开源社区的通用模型在这个领域上要么没有覆盖要么连safety对齐的知识都混进来了第二我需要一个完全可控、权重干净、没有乱七八糟chat模板依赖的底座这让我能放心地做后面SFT监督微调和DPO直接偏好优化第三硬件条件不允许我动不动就跑几百块显卡的活儿一条单机多卡A100/A800的链路更现实。这篇文章不是论文复现也不是调参玄学而是把整个流水线完整捋一遍从语料清洗、预训练、CPT、SFT到PEFT参数高效微调、蒸馏最后用DPO做对齐。每一步我都会给出我实际使用的配置、观察到的现象以及踩过的坑。你如果也想在低成本预算下拥有一个“属于自己的模型”或者只是想弄明白各个训练阶段到底在干什么这篇文章应该能帮你省掉不少摸索时间。先给个流程总览方便你之后对照语料清洗 → tokenizer训练 → 基座预训练或者直接拿开源基座做CPT→ SFT → PEFT微调与SFT在部分场景下结合→ 蒸馏可选模型压缩→ DPO对齐 → 部署评估。这是一个完整闭环每一步之间是有依赖关系的前面偷懒后面全得加倍还回来。下面我按这个顺序拆开讲。2. 数据准备是第一道门槛语料清洗、去重与采样比例2.1 你要准备多少数据才敢开训网上很多教程会把预训练说得玄乎但落实到实际你首先要回答的问题就是我要多少数据我的经验是可以用一个粗略估算倒推假设你的模型参数量是N训练总token数是T一般建议T大约在N×20到N×100之间。1B参数量的模型如果要比较扎实地打底我建议至少准备20B token左右的语料。如果你只想做一个偏领域模型例如只覆盖某个行业文档、论文摘要、私有知识库文本那么数据量可以减少到5B到10B token但仍要保证一定的多样性否则模型会陷入严重过拟合和词表崩塌。数据只多不少这件事我体会挺深。最开始我准备了一版只有3B token的领域语料模型跑完表现很“笨”句子都能生成但只要一遇到没见过的表述就胡言乱语。后来加了通用语料和增强数据才把基础能力补回来。小模型不是不需要预训练数据而是它比大模型更需要靠多样数据来提升泛化。2.2 清洗、去重与格式统一不能跳过的一课很多人以为预训练是把一堆txt丢进去就行事实远不是这样。我的处理流程分四步转码与统一格式 → 规则清洗 → 语义去重 → 质量过滤。统一格式这一步很容易被忽略。教育、科研、政务类的原始文档经常混杂PDF提取残片、HTML标签、表格线、乱码甚至还有Base64图片数据混进文本里的情况。我会先用一个脚本把所有语料转成纯文本再统一换行符为\n统一标点。规则清洗用来干掉明显的垃圾内容比如连续重复的“啊啊啊啊”、广告模板、无意义的代码注释、异常URL。语义去重就上MinHashLSH对长文档抽取特征后做近重复检测把完全一样或者几乎一样的重复文档剔除。质量过滤我参考了开源社区的一些做法用一个简单的Heuristic分类器给每个文档打分把那些标点异常、词频失衡、乱码比例过高的低分文档筛掉。这里我特别想提一个容易忽略的细节领域语料里代码和表格怎么处理。如果你的模型要读财报、实验报告、日志这类数据最好别把表格简单转成CSV文本否则结构信息就丢了。我后来统一把表格转成“表头行内容描述”的自然语言模板模型在下游任务里的表现明显更好。这算是数据预处理里最占时间但最值回票价的部分。2.3 分词器训练不要直接拿Llama的tokenizer大部分教程会让你直接复用Llama或Qwen的tokenizer这在小模型实验里确实省事。但是如果你重点做领域数据强烈建议单独训一个分词器。原因很简单通用tokenizer可能没有覆盖你的领域术语同样的词被切得很碎导致序列长度暴涨、训练效率下降。我专门用SentencePiece训练了一个中文BPE词表vocab size取16K。这个量级对于1B模型和领域语料来说够用也不会因为词表太大导致embedding矩阵膨胀。训练前先统计领域语料的字符分布、常见子串再把通用中文语料和领域语料按7:3混合进行训练覆盖会更均衡。训练结束后我会重点检查领域专名比如一些技术名词、产品名是否被完整切成了一个token如果没有就调整语料增强它出现的次数重新训一次。3. 预训练与继续预训练CPT从随机初始化到领域通晓3.1 从零预训练一个1B模型硬件和时间到底要多少我喜欢把“预训练”分成两层理解一种是从随机权重开始完整训练另一种是在别人已经训练好的基座上继续训练也就是CPTContinue Pretraining。如果你有足够的领域语料和相关算力从零预训练能让你完全掌控模型的“知识底色”如果你只想快速取得领域能力直接拿开源基座做CPT会更高效。我在Xihe这个项目里两条路都走过下面先说从零预训练的感受。我采用的模型结构是标准的Decoder-only Transformer约1.02B参数embedding约0.1Btransformer层约0.85Blm head约0.07B12层、隐层维度2048、16个注意力头最大序列长度2048。训练配置上我用AdamW优化器初始学习率4e-4warmup比例1%权重衰减0.02batch size累计到约512个样本输出梯度裁剪1.0。训练数据就是第2节处理过的20B token语料在4张A800上跑单卡batch size 16每张卡大概5万多token配合梯度累积达到了512样本的等效batch。实际跑下来20B token在4卡A800上大约需要16天。这个数字听起来有点长但相比大模型的年級训练周期已经算是很可控了。训练过程中最值得关注的是loss曲线前1B token里loss应该快速下降3B token以后下降会变慢进入了“记忆更多知识”的阶段。如果你看到loss曲线突然反弹或者震荡得很厉害就要怀疑是不是学习率设置太高、数据混入了异常分布或者注意力层数值不稳定。3.2 CPT的三种策略以及我是怎么组合的如果你不打算从头训练CPT绝对是最值的road。它有三种常见策略增量预训练在通用基座上加入领域语料继续训练、混合预训练领域语料和通用语料按比例混合继续训练、渐进式比例提升通用语料占比逐渐下降领域语料逐渐上升。我最终采用了混合预训练领域语料和通用语料比例大概在5:5到6:4之间波动。为什么不用纯领域语料做CPT因为只喂领域语料会导致灾难性遗忘——模型对通用语言能力、常识知识、推理能力的保持会大幅下降。我试过一顿饭只喂某个专业领域的1B token之后模型写代码还行但解释同一个概念时反而语无伦次像是把通用语法规则给冲掉了。所以如果你做CPT建议领域语料占比不要超过70%最好保留一部分通用语料作为“润滑剂”。CPT阶段的学习率我额外调低到1e-4到2e-4因为基座已经有了基本的语言能力再用高学习率容易把已经学好的参数空间破坏掉。另外序列长度上我直接用2048如果你的任务是长文本理解也可以逐步从512扩展到2048但这种渐进式延长在中小模型上收益不明显反而增加调试成本。3.3 损失曲线的“健康标准”盯哪里不焦虑预训练过程中我通常会同时观察四组指标训练loss、验证loss、梯度的L2范数、学习率曲线。验证loss是判断是否过拟合的重要依据如果验证loss开始上升而训练loss还在下降大概率已经过拟合此时需要减少训练数据重复率或者增强数据增强。梯度的L2范数如果突然冲到1以上甚至几十说明数值不稳定先检查学习率和batch size其次是数据里是否存在极长序列或异常样本。说句实在话很多人把预训练想成全自动跑完就行但实际上前1%-2%的step里就能看出这次训练是否会跑偏。训练loss迟迟不降、梯度范数忽大忽小、验证集上生成出一堆重复词这些都是红灯。4. SFT监督微调是把模型“调教”成助手的关键一步4.1 指令数据的“质”比“量”重要得多到了SFT阶段核心目标已经从“学会知识”变成“学会与人对话”。很多人以为SFT就是给模型一堆问答对其实这里有个大坑如果你的数据只有问题和答案没有system、角色、多轮上下文之类的结构模型学到的只是“背题”而不是“交流”。我构造指令数据时会尽量保持多样化的任务类型包括开放问答、摘要、信息抽取、改写、翻译、代码解释、格式化输出比如JSON、表格、角色扮演、多轮对话。单轮和多轮的比例大概7:3这样模型既能快速学会单轮问答也具备多轮对话的上下文衔接能力。每条数据我按标准结构组织{ system: 你是Xihe一名通晓多个领域的智能助手…, user: …, assistant: … } 在训练时我会把system和user部分拼成promptmodel只对assistant部分计算loss。这个细节能不能做好直接影响模型是否会在回复里混入“prompt原文”或“指令解析文本”。4.2 数据格式、模板与batch内部的“注意力陷阱”SFT里最容易被忽略的是attention mask。你会把prompt和completion拼在一起塞进模型如果mask没有正确设置模型在预测assistant回复第一个token时还能被prompt里的未来token所影响这就泄漏了。所以一定要确保训练时每个样本的loss mask同时考虑了“只计算assistant部分”和“因果注意力下的左向掩码”。这两层都要弄对我见过太多新手代码在这里出问题训练曲线漂亮但推理时胡言乱语。batch内部还有另一个问题padding。不同样本的长度差别很大我默认在右侧padding并配合attention mask排除padding位置。当前主流做法有两种右侧padding适合与标准causal mask配合左侧padding则在某些推理场景更有用。SFT我推荐右侧padding简单且不容易出错。另外如果一条样本长度超过2048我会截断而不是硬套长序列因为我现在还在训练阶段没必要把高成本花在少数超长样本上。4.3 超参数选择学习率、batch size、epoch数量SFT的优化器我依然用AdamW但学习率要比预训练低很多。通常我设置2e-5到5e-5warmup比例大概3%然后使用余弦衰减。batch size不需要太大因为SFT数据量一般只有几十万条等效batch size在64到128样本之间就可以。学习率过高会在SFT早期就把预训练学到的分布打坏你会看到loss一路下降但评估时生成质量反而暴跌。epoch数量则要在“充分学习指令”和“避免过拟合”之间取平衡。我对于10万条以内的指令数据通常跑2到3个epoch如果数据超过20万条1个epoch往往就够了。判断是否过一个好epoch的指标是在验证集上做精确匹配、语义相似度和人工打分如果loss继续下降但验证分数不再提升就该停了。另外我会在SFT之后的模型上跑一组预设评测case比如“能否记住训练里出现的对话格式”“能否区分同一个问题的不同表达”。评测case要提前写不能临时编否则你很容易被几个个例带偏判断。5. PEFT用LoRA/QLoRA做参数高效微调的实际选择5.1 什么时候该用PEFT什么时候别用PEFT参数高效微调是一类方法的总称最常见的是LoRA。PEFT最大的价值在于显存占用小、训练速度快你不需要重新训练全部参数只训练一小部分附加的低秩矩阵。但PEFT不是银弹我的经验是如果你想深度改变模型在某个领域上的行为且训练数据量足够大全参数微调的上限通常比PEFT更高如果数据量只有几千条、训练卡显存有限PEFT的性价比非常高。在Xihe这个项目里我把PEFT用在两个地方一是用LoRA对SFT后的模型做domain adaptation也就是进一步强化对某一具体业务场景的适配二是在DPO之前用LoRA快速试探对齐数据的质量。我会在第一个场景里展开讲细节。5.2 LoRA关键的参数rank、alpha、target_modules和丢弃率LoRA实际使用时最需要关心的参数是rrank、alpha、target_modules、lora_dropout。r低秩矩阵的维度我一般在8到64之间选。小数据量选8或16大数据量或任务复杂选32或64。rank并非越大越好rank过大会带来过拟合rank太小表达力不足。alpha缩放系数决定低秩更新对原权重的影响强度。标准做法是alpha设为r的2倍比如r16则alpha32。如果你希望微调更加保守可以调到0.5r想更大胆改变行为调到2r甚至更高。target_modules决定在哪些模块上插入LoRA。Transformer里我通常选择q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj这些线性层。如果你不确定可以只选q/k/v/o能显著降显存如果任务需要更强适应能力我建议把MLP的三个proj也加上。lora_dropout一般设置0.05过大会让训练变慢过小则容易过拟合。下面是我在业务场景微调里常用的一组LoRA配置r: 32 alpha: 64 lora_dropout: 0.05 target_modules: - q_proj - k_proj - v_proj - o_proj - gate_proj - up_proj - down_proj训练时我只把LoRA参数加入优化器原模型参数全部冻结学习率可以比全参数微调大个2到3倍比如1e-4这里因为更新参数相对少更高的学习率不会破坏原模型的主干结构。5.3 融合模型LoRA训练完别忘了“炼”回权重LoRA训练结束后你会得到一堆独立的adapter权重。但在实际部署时我几乎都会把它们融合(fuse)回原始模型权重生成一个standalone的模型文件。这样推理时不需要额外加载adapter速度也更快也不会出现忘记加载adapter之类的低级错误。融合的过程本质上就是W_new W_orig (alpha / r) * B A。在HuggingFace生态里直接调用peft库的merge_and_unload就能完成最后保存成普通transformers模型。融合后的模型文件体积基本和原模型一样大不会额外增加太多存储。之后如果想做DPO别把SFT模型融合后再DDP更好的做法是在DPO代码里直接加载融合后的SFT模型再在其上训练LoRA或者DPO这样结构更清晰。6. 蒸馏用小模型学大模型的“解题思路”而不是照抄答案6.1 蒸馏为什么有效关键在“软标签”和概率分布知识蒸馏的核心思想是让小模型学习大模型的输出概率分布而不只是最后选出的那个token。大模型输出“Paris”这个词时实际上它同时给了“Lyon”和“Marseille”很高的概率这些**软标签soft labels**蕴含了丰富的语义关联。小模型如果只学硬标签就只学到了“最终答案”如果学软标签就能学到“答案之间的相似性”。我在Xihe项目里蒸馏的对象是一个7B左右的开源大模型我称呼它Teacher。学生模型就是1B的Xihe基座或者SFT后的1B模型。蒸馏时温度系数T很关键我一般设为2.0到4.0。T设置太低软标签太接近one-hot失去信息T设置太高概率分布过于平滑小模型会学不到重点。6.2 两种蒸馏做法概率蒸馏与序列蒸馏在生成任务里蒸馏可以分两种路径。第一种是概率蒸馏也叫token-level distillation。做法是把Teacher和Student同时过同一个promptTeacher在每一个token位置输出完整的词表概率分布Student的loss计算不再只用真实token的cross-entropy而是同时拟合Teacher的软标签分布。常见loss组合是总loss CE(学生输出, 真实标签) alpha * KL(学生logits, 教师logits / T) * T^2这里的alpha控制蒸馏损失的权重我一般设为0.5左右T^2 是为了保证温度缩放后的梯度幅度合理。第二种是序列蒸馏也叫生成蒸馏。Teacher先生成一系列候选回复做beam search或者采样多次然后把这些候选回复当成真实标签去训练学生。这种做法比概率蒸馏更实用因为不用同时维护Teacher在训练循环里逐token输出logits节省很多计算但缺点是丢失了一部分软标签信息训练结果更接近SFT。实际跑下来我建议先做一轮序列蒸馏再用概率蒸馏精调。这样步骤清晰也容易定位问题。序列蒸馏的时候要对Teacher的生成结果做一遍过滤去掉明显不合格的句子、重复句、内容不合格的样本否则小模型会连大模型的毛病一起学来。6.3 实测下来的时间与效果变化蒸馏1B模型时我用了一张A800Teacher是7B模型的16bit权重提前把所有Teacher生成结果缓存下来避免每个step重复前向传播。这样1B模型训练5000步左右大概多花不到一天的时间。效果上对比“直接SFT的小模型”与“先蒸馏再SFT的小模型”在通用知识问答上整体没拉开太大差距但在开放式生成、多轮对话的“自然度”上蒸馏模型的劣势明显减少比如句子更通顺、逻辑更连贯不再像SFT模型那样机械地堆叠要点。如果你想把这个做扎实我的建议是蒸馏只用在生成类任务上分类、抽取这类判别式任务收益不明显还会增加训练成本。另外蒸馏并不是唯一压缩模型的手段如果你要把1B模型部署到边缘设备后面还得叠加量化即把FP16权重转成INT8或INT4。蒸馏和量化可以叠加但蒸馏后的模型再用INT4量化往往比直接量化原始1B模型效果更稳。7. DPO直接偏好优化把“对齐”变成真正可以跑的实践7.1 从RLHF到DPO为什么我会选DPO传统上要让模型学会“人类偏好”通常走RLHF先训一个奖励模型再用PPO之类的方法去做强化学习。这套东西在工程上相当繁琐奖励模型可能不稳PPO训练对超参数和代码实现的要求也很高。DPODirect Preference Optimization是2023年那篇论文《Direct Preference Optimization: Your Language Model is Secretly a Reward Model》提出的方法思路非常优雅它不训练奖励模型而是直接用人类偏好对数据来优化策略模型本身在数学推导上等价于某种隐式的奖励最大化。对个人开发者和中小团队来说DPO最大的好处是稳定、好实现、显存占用可控。你只需要准备一堆“好回答/vs/坏回答”对然后策略模型去降低坏回答的概率、提高好回答的概率。我在 Xihe 项目里用 DPO 解决了模型“说车轱辘话”“长篇大论却信息密度低”“不愿意承认不知道”等SFT后经常出现的行为问题效果好到出乎意料。7.2 如何构造偏好对chosen和rejected从哪来DPO的数据格式是每条样本有一个prompt一个chosen回复一个rejected回复。chosen是更符合人类偏好的回答rejected是质量较差的回答。构造方式一般有三种。第一种是人工标注找几个人对同一prompt的不同回复排序挑中间最有代表性的两个作为pair。高质量但成本高。第二种是规则构造比如把正确答案作为chosen把模型故意生成的空泛回复、重复话、错误回复作为rejected。第三种是从大模型采样用Teacher生成多个候选回复让GPT-4或人工打分排序再取最高和最低组成pair。我最常用的是第二三种混合。具体做法是从SFT模型自己生成一批回复同时让Teacher也生成一批然后按规则过滤比如包含“我不知道但我想说一堆废话”的样本直接标记为rejected信息密度低、重复率高的样本也标记为rejected。尽量不要构造差异太小的pair不然DPO看不出方向梯度更新会无效。两个回复最好有明显的高下之分这样模型学起来更快。7.3 DPO训练里真正的核心beta、参考模型和灾难性遗忘DPO的损失函数里有两个关键角色策略模型和参考模型reference model。参考模型通常是DPO训练前的SFT模型训练时权重被冻结用来给每个rejected和chosen回复算初始概率。训练时策略模型要尽量让chosen的log概率相对参考模型提高让rejected的相对下降。超参数beta控制对偏好的响应强度。我默认设为0.1到0.3。beta太小模型对偏好数据敏感容易过拟合到偏好集beta太大模型懒得改变对齐效果弱。我第一次试DPO时直接用了beta0.5结果模型在偏好分布上改得非常激进回答变短但内容空洞。后来我改成beta0.15整体就协调多了。DPO最大的坑在于灾难性遗忘。因为偏好对通常只有几万条如果学习率太高、训练步数太长模型会忘掉SFT学到的通用能力。我一般会在DPO数据里混入一部分SFT数据比如按8:2混合即80%偏好对、20%普通指令对这样模型在尽量保持原有能力的同时又能优化偏好。学习率我用1e-6到5e-6远低于SFT阶段。训练轮数也不宜多常见的几万条偏好对数据跑1到2个epoch就够。训练时也要盯着SFT部分的loss如果它上涨说明你在牺牲基础能力。7.4 评估DPO效果不要只看“win rate”DPO之后怎么看效果网上一堆人只看“chosen vs rejected的胜率”这确实直观但还不够。我自己会加三组验证单轮对话质量让模型回答一批开放式问题从内容准确性、信息密度、冗余度三个维度人工打分对比DPO前后。多轮一致性连续问几个相关话题看模型是否还记得之前说的内容是否会在后续回答里自相矛盾。DPO之后模型倾向于更“收敛”的回复有时会把多轮一致性牺牲掉要重点观察。事实性幻觉构造一批需要承认“不知道”的问题看看模型是否还在硬编答案。DPO调得太激进可能会让模型变得更“自信”反而乱说。这个指标很容易被忽略但我发现它在实际业务里比胜率更重要。个人经验是DPO最适合用来调“语气”和“行为”比如让模型更简洁、更礼貌、更不啰嗦。如果你想让它“知道更多知识”那得靠预训练和CPTDPO帮不上什么忙。8. 整合与验证一些踩坑清单和容易忽略的工程细节8.1 评估集要一开始就建别等训完才开始这个建议我真是每次都想敲黑板强调在训练开始之前先建一个固定评估集里面包含预训练、SFT、DPO三个阶段的测试项。不要等到训完再临时网上搜几个题充当评估集。临时评估集的问题是会引入主观偏差而且你容易不自觉地选出“模型表现好”的题目来证明训练有效。我的评估集包含四类知识问答类从领域语料里抽200个问题、指令跟随类要求按特定格式输出的任务比如抽取JSON、改写成某种风格、开放生成类写一段短文、解释一个概念、偏好对比类从偏好数据里抽一部分成对样本。这四个维度分别对应CPT、SFT、生成质量和DPO效果。评估集里提前设定好自动打分脚本和人工评分标准训练过程中每隔一定步数就跑一遍。8.2 部署阶段量化、推理框架和显存优化训练完成后的模型最终还是要部署的。我知道很多人在这一步“翻车”最多。1B模型本身不大FP16权重约2GB跑推理的显存需求并不高但你一旦要用它处理长prompt或者并发请求显存和内存的占用就会成为瓶颈。建议至少做两件事。第一能量化就量化。把FP16权重转成INT8推理显存会降到1GB左右转成INT4更小但精度会有一定损失。我的做法是先量化到INT8在业务集上验证效果如果可接受再尝试INT4。不要一上来为了省显存上INT4如果效果崩了你都不知道该去调哪个环节。第二用支持KV Cache复用和Continuous Batching的推理框架部署。单独加载一个Transformer模型到Python里玩没问题但并发一上来每次都重新算历史KV会非常浪费。主流的推理框架都能做到动态batch和显存优化实测吞吐差距可能达到数倍这一步在工程上几乎必须做。8.3 整个链路最容易出问题的地方我列个黑名单数据泄漏预训练语料和评估集如果重叠指标会虚高。做MinHash去重时要把评估集也放进去。tokenizer不一致每一个阶段加载模型时都要保证tokenizer是同一个否则生成的答案不但在分词上不对劲还可能直接乱码。mask写错SFT阶段如果loss mask没有盖住prompt部分模型会出现“预测下一个词时会抄prompt原文”的现象尤其在长context下非常明显。pipeline串错DPO训练时的reference model必须是在DPO之前固定的模型如果你不小心加载了已经训练过的DPO模型作为reference损失会算出一个怪异的东西。过早融合LoRA如果在DPO之前就把LoRA融合掉再在融合模型上继续训练LoRA并试图再次融合可能会把不同训练的loRA权重在数学上弄混。尽量保持每一步权重来源清晰要么始终保留adapter要么融合后开新流程别交叉操作。我踩过最狠的一次坑就是在SFT阶段用了一个错误的attention mask模型训练loss非常低但所有生成结果都像复读机。后来我花了好几天排查最后发现居然只是mask没盖住prompt。所以这个东西真的值得提前在代码里做单元测试。写到这里差不多把从零训练一个小语言模型的全流程讲完了。Xihe这个项目带给我的最大感受是语言模型的训练不再是少数实验室的专利但每一步都有极其多的工程细节。你以为最花钱的是算力其实最花时间的往往是数据清洗、调参和定位诡异bug。如果你也在做类似的事情多留点时间给那些“看不见的环节”尤其是数据、mask和评估。模型最终效果如何很可能一半取决于预训练和SFT做得干不干净另一半取决于你的评估方法是否诚实、可复现。希望这篇文章能帮你少踩几个坑顺利产出属于自己的那个“小模型”。