从去年年中开始我带着一个七人小团队把一条完整的训练链路跑了三遍数据清洗、预训练、SFT、DPO、评估、部署。网上关于大模型的论文和课程多到看不完但真正能把手把手把“数据→预训练→SFT→DPO/RLHF→评估”全流程走通的人并不多。这活儿确实脏、确实累、也确实贵但一旦跑通一次你对大模型的理解会彻底不一样——以后再看任何训练相关的东西基本都有谱了。这里把整条路线的事情写透一点想把模型从零搞起的团队可以先照着做至少能绕开我们踩过的那些大坑。1. 先想清楚从零训练的适用场景与资源门槛很多团队一上来就问“我要从零训一个自己的模型”但这句话背后的动机差别很大。有的是为了私有化部署、数据不出域有的是觉得开源模型不够贴合自己的业务有的纯粹想锻炼团队能力。这三种诉求对应的方案完全不同。1.1 什么情况下值得从零训练作为过来人我的判断标准很简单你要解决的问题改开源模型性价比更高就不要自己从头训。比如给客服做个FAQ助手用Qwen或Llama微调就够了但如果你要的是“金融法规条文的精准问答”、“医疗病历结构化抽取”这类垂直场景开源通用模型在术语准确性、格式合规性上经常差一口气。再加上企业级数据不能出域的话从零预训练一个专属底座就变成了刚需。还有一个情况值得从零训练你需要一个可控的技术底座。开源模型用起来方便但你不知道它训练数据里有什么出问题不好排查将来想针对垂直场景做继续预训练也受到上游限制。自己训的模型从tokenizer到数据配比都清楚出任何质量问题都好溯源。1.2 资源估算先算账再动手从零训练一个大模型最大的门槛不是技术是钱。我给你一个可以套用的粗略估算方法。模型规模如果做垂直场景7B量级在这个阶段是性价比比较合适的点参数量再往下能力下降明显往上训练成本指数级上升。数据规模常见的做法是1T到2T token这基本是7B模型能力涌现的及格线。数据少到几百B的话模型也有用但比较“笨”。硬件估算以7B模型、1T token、序列长度2048为例按Llama架构的算力需求粗算6N×DN是参数量D是token数需要约 6×7B×1T ≈ 4.2e22 FLOPs。用一张A100 80GBF16算力约312TFLOPs考虑60%左右的MFU大概需要 4.2e22 / (312e12×0.6) ≈ 2.2e5 秒约62小时。也就是说大约24张A100跑3天多或者8张跑9天多。如果改用H100时间差不多减半。这个数字只是训练本身还没算调试失败、数据重构、评估测试的时间。所以务实建议是如果你只有一两张显卡不要碰从零预训练。先用LoRA微调做业务验证等业务模型的需求被验证清楚了再预算从零训练的性价比。如果预算在几十万到百万量级直接从零训练是可行的。1.3 少走弯路的起点判断不少人一开始就冲“从零”两个字其实可以“从中间出发”。目前主流平台还是有公开的开源底座比如Llama系列、Qwen系列、Mistral系列。这些模型经过完整训练底子扎实如果你的垂直场景数据量大完全可以做增量预训练continue pretraining比从随机权重训起节省至少一个数量级的成本。真实项目里做增量预训练比例更高。它保留通用能力注入垂直知识风险比随机初始化小很多。如果你非要随机初始化建议也先跑一个几百M或1B参数的小模型验证数据质量和训练流程再放大到7B。我们第一次直接上7B随机初始化结果训练到两万步发现数据有系统性污染全部推倒重来那个酸爽不说了。2. 数据工程语料清洗与配比很多人觉得训练大模型拼的是显卡但跑完一轮你会发现真正的瓶颈在数据。模型能力的天花板几乎完全由数据质量决定。尤其从零训练数据直接决定你后续所有环节的成败。2.1 预训练语料从哪里来、怎么洗开源可用的预训练语料主要包括RedPajama、SlimPajama、Falcon RefinedWeb中文场景还有WuDaoCorpora、SkyPile等。但直接拿来用是不行的必须做清洗。我们跑了几轮清洗后原始文本大约只剩三分之二其中不少是重复内容和无意义符号。我实际用到的清洗流水线按顺序大概是格式统一把所有语料转成统一UTF-8文本格式处理PDF抽出来的乱码、HTML里的广告导航残留。去重先做精确去重MD5再做模糊去重MinHash LSH。网上很多公开语料重复率高到离谱同一段新闻在不同网页出现几十次不去重模型会严重过拟合表现为生成内容大量重复。语言过滤按业务需要筛选语言用fastText或语种识别模型过滤掉无关语种。质量过滤用规则结合困惑度过滤。规则主要筛掉纯表格、纯URL、无换行的超长文本困惑度可以借助一个小的语言模型计算把那些困惑度过高、不像正常语言的文本剔除。隐私与安全过滤把身份证号、手机号、私钥这类信息用规则正则清洗。这五步不是可选项是必须项。我们第一版数据因为去重不够训练出来的模型在生成时经常出现大段重复文本这个事后修补成本极高建议一开始就做扎实。2.2 数据配比怎么搭才不出偏不同来源的数据不能简单堆在一起配比很重要。一个从零训出的中文模型一般英文知识类数据占大头中文占一部分代码和数学要有相当比例因为推理能力很多是从代码数据里学到的。注意代码和数学这类结构化数据占比低会让模型逻辑能力明显偏弱占比过高又会让模型语感变僵硬在写作和对话场景显得机械。需要按业务场景做平衡。我用的初始配比大致是英文百科/网页/书籍 50%中文百科/新闻/社区 25%代码 15%数学与推理 5%其他 5%。这不是标准答案但作为起点比随便堆效果好很多。配比调整有个技巧先做小模型实验。拿1B模型用不同配比训各10B token看下游任务表现差异能用小成本把数据配比调到较优再放大到7B省下的是几十万的训练费。2.3 Tokenizer训练基础一定要打牢Tokenizer很多时候被忽略但它直接影响压缩率和模型表现。中文场景下直接用Llama的tokenizer中文效率很低词表里中文token太少同一个词拆得更碎序列更长训练和推理都变慢效果也受影响。训练自己的tokenizer时我一般这么配置词表大小中文英文场景选50K到64K比较稳。太小了压缩率差太大了容易过拟合而且embedding层参数也变多。训练语料最好在正式预训练数据的同分布采样上进行混合比例跟你预训练数据一致。验证指标看**字节覆盖率byte coverage**和平均分片长度。一个好的中文tokenizer常见中文字符应该单个token能覆盖大半极少出现把一个常用词切成三四个token的情况。如果从头训练确实麻烦可以考虑用现有开源中文tokenizer做扩展但要注意embedding层是随机初始化的如果模型是增量预训练扩展词表后还需要做旧词表权重对齐的冷启动处理。这一块的细节不少人踩坑建议实操时留意。3. 预训练实操从模型配置到loss收敛数据就位之后下一步就是预训练。这部分看起来就是跑脚本实际训练过程中问题很多loss不降、NaN、OOM、节点掉线每个问题都能耗掉半天到一天时间。我把关键部分拆开讲。3.1 模型架构与配置选择如果你随机初始化架构可以直接参考LLaMA的设计标准decoder-only transformerPre-NormRMSNormSwiGLU激活函数RoPE旋转位置编码无偏置项。这套架构经过大量验证训练稳定性和效果都有保障不用特地去搞发明创造。关键配置参数可以考虑从如下数值起步参数7B量级建议值隐藏层维度3584~4096Transformer层数28~32注意力头数28~32序列长度2048起步稳定后可扩展到4096词表大小50K~64K学习率峰值3e-4配合Warmup全局Batch Size0.5M~1M tokens约256~512条序列优化器AdamWβ(0.9, 0.95)权重衰减0.1精度策略BF16混合精度一个容易忽略的点是全局batch size。大模型训练的batch size建议保持较大的tokens总量效果好且训练稳定但batch太大会导致单卡显存爆炸需要靠梯度累积实现。我们用的是512的micro-batch每条2048 token配合64步梯度累积等效全局batch 65536条样本约134M tokens。3.2 训练框架与并行策略怎么选训练7B模型单机多卡到多机多卡的情况都有。我的建议是这样分层级走单机8卡A100/H100直接用DeepSpeed ZeRO-3或PyTorch FSDP就够了。ZeRO-3把模型参数、梯度、优化器状态分片到各卡训练7B模型很轻松显存占用约60~70GB每卡。多机多卡≥16卡建议上张量并行TP ZeRO/FSDP组合或者直接用Megatron-LM。张量并行能减少跨机通信量训练效率高不少。有稳定集群且长期训练可以直接上Megatron-LM 流水线并行 数据并行全套但门槛较高需要专职的并行工程师维护。如果你只是想把流程跑通FSDP是上手比较快的方案。注意用BF16而不是FP16大模型梯度在FP16下很容易溢出变成NaNBF16虽然精度低一点但动态范围大训练更稳。我们第一次用FP16跑到几千步就NaN了换了BF16解决。3.3 训练监控不要只看loss曲线预训练阶段loss肯定是一路下降的但loss本身不够判断模型好坏。建议同步关注几个辅助指标验证集困惑度Perplexity固定一个和训练数据同分布的验证集每500步算一次困惑度。如果训练loss继续降、验证困惑度不再降甚至抬升说明对训练数据过拟合了。预训练阶段这事不多见但数据不足时会遇到。loss spike观察训练中偶尔出现loss突然跳高又回落通常是训练数据里混入了异常样本超长重复段、非UTF字符等。遇到loss spike不要急着调参数先去查那批数据的分布查不清就减小心学习率或者降低batch size。checkpoint策略建议每500到1000步保存一个checkpoint并且同时保存优化器状态。只存模型权重的话中途训练中断连优化器状态都要重建会浪费不少时间。我们有个习惯每2000步传一份完整checkpoint到独立存储避免节点故障导致整机数据丢失。预训练的目标不是loss越低越好而是保证后续SFT、DPO阶段还有足够的“学习空间”。一般训到loss区域平稳下降、困惑度符合预期就可以切到SFT了。如果从零训练到困惑度明显高于参考开源模型的水平大概率是数据量或数据质量没到位。4. SFT指令微调与对话能力塑造预训练模型只是一个“文本接龙高手”能续写但不会好好回答问题。SFT监督微调通过大量指令-回答对把模型的生成行为对齐到“问答”模式。这一步做得好不好直接影响用户感知到的模型智商和情商。4.1 指令数据怎么构造与清洗SFT数据现在公开资源不少Alpaca、ShareGPT、Dolly、BELLE、OpenAssistant等都能用但直接混合效果一般。SFT数据的核心要求是多样性高质量不是数量大。我们第一轮SFT用了30万条公开自建数据效果远不如后面精筛后的15万条因为公开数据里大量是重复模板和低质量问题。指令数据一般包含三类角色system系统提示、user用户指令、assistant助手回复。构造时要注意指令要多样同一意图换多种表达方式覆盖“请帮我……”、“……怎么做”、“解释一下……”等句式防止模型只会某一种句式。回答要有依据对于专业领域每条回答最好附带参考来源模型才能养成“有依据才答”的习惯少生成幻觉内容。包含拒绝样本用户问违规或超出能力范围的问题时要构造“我无法回答……”的回复否则模型会强行编答案。清洗PII信息自建SFT数据往往包含用户真实对话身份证、手机号、公司名必须过滤别让训练数据把你出卖了。4.2 全参微调还是LoRA很多新手一上来就问要不要上LoRA。我直接给结论如果GPU显存够如4卡A100且想追求模型最佳效果全参微调。SFT数据量不大几万到几十万条全参微调的收敛速度和效果上限都更高。如果想快速实验、显存不够单卡24GLoRA或QLoRA。LoRA只训练一小部分参数显存和训练时间都节省不少效果接近全参的80%~90%。训练细节上有几个容易被忽略的地方损失只计算回答部分标准做法是prompt部分的token不参与loss计算只算assistant回复的交叉熵否则模型会把“跟着问题念一遍”学进去。代码实现上一般通过labels矩阵把prompt位置设为-100忽略。学习率要比预训练低全参微调通常用1e-5到3e-5LoRA可以用稍高的1e-4到3e-4。太高了会破坏预训练学到的通用特征。epoch一般不用太多SFT数据规模不大通常1到3个epoch就够了。过拟合的判断标准是验证集loss回升或模型开始“背诵训练数据”而不是泛化。4.3 SFT常见翻车现场这一阶段翻车频率非常高列举几个我们真实遇到过的复读机模型反复重复同一句话尤其是长回答时。原因大概率是SFT数据里有大量包含重复句的回答或者是预训练阶段数据重复率过高没洗干净。回答格式乱模型自己造出一堆不存在的markdown语法、错误换行。这类问题需要在SFT数据里统一格式并在评估时重点检查格式一致性。混入system内容模型把system里的指令原样输出或者自己发明system内容。这通常是SFT数据没有严格按照chat template填导致模型没学会区分角色。注意在训练和推理时使用同一个chat template这是新手容易踩的隐坑。SFT完成后模型已经能“正确回答”了但“正确”和“符合人类偏好”是两码事。接着要上对齐阶段。5. DPO/RLHF偏好对齐让模型学会说人话SFT教会模型模仿数据里的回答方式但它不会判断两个回答哪个好。偏好对齐的目标是让模型学会输出“人类更偏好的回答”比如更安全、更有用、更简洁。这一步走完模型才能真正用在实际业务中。5.1 Reward Model、RLHF 和 DPO 的差异与选型RLHFReinforcement Learning from Human Feedback的经典流程是先训练一个Reward Model打分再用PPO等强化学习算法去优化策略模型让回答在RM得分高的同时不过度偏离SFT基线加KL惩罚。DPODirect Preference Optimization出现之后这个流程被大幅简化。它去掉了Reward Model和强化学习环境直接用偏好对数据微调策略模型让模型增大对chosen回答的概率、降低对rejected回答的概率。对比维度RLHFPPODPO组件复杂度需要RMPPO4个模型交互仅策略模型参考模型训练稳定性较难调稳超参多相对稳定实现简单效果上限理论上更高可以迭代优化依赖偏好数据质量资源消耗高需要大量显存和时间低和SFT差不多维护成本高适合大团队低中小团队首选考虑到大部分团队只有有限的GPU资源和工程人力第一次做对齐建议直接用DPO。RLHF那套流程复杂PPO的KL散度控制、优势估计裁剪、RM训练等环节有一环没调好就白费工夫。DPO在7B量级上的效果已经被大量验证过是性价比更高的起点。5.2 DPO数据构造与超参要点DPO的数据形式是偏好对同一个问题给出一个chosen人类更喜欢的回答和一个rejected人类不太喜欢的回答模型从中学会区分好坏。数据来源一般有两种人工标注让标注员对比SFT模型的多个回答选出好坏。成本高但质量可靠。模型自动构造用强模型如GPT-4对SFT模型的多个输出打分排序选出一好一坏。成本低但需注意作弊问题模型可能偏好它自己风格的答案。我们实际跑下来发现DPO效果好坏主要靠数据质量而非数量。5万对高质量偏好数据效果比20万对弱监督数据好得多。至少要保证chosen和rejected来自同一个场景、同一个长度范围不然模型容易走捷径比如学习到“长的就是好的”这类虚假特征。DPO训练时几个关键配置beta参数KL约束系数默认0.1到0.5之间。beta越大模型越不敢偏离参考模型越小模型更激进地偏好chosen。我们常用0.1稳定性和效果平衡较好。参考模型ref_model用SFT阶段的模型作为参考模型不要在DPO开始后又重训参考模型。两个模型同源是DPO收敛的保障。学习率DPO学习率一般比SFT低通常1e-6到1e-5。我们全参DPO用2e-6LoRA DPO用1e-5。混合SFT数据只训练DPO数据容易让模型学歪比如对话风格突变。实操中我们会把DPO数据和少量SFT数据混合训练比例大概31能保持基本问答能力不退化。5.3 对齐之后必然付出的代价对齐不是免费的。偏好对齐本质上是在压缩模型的输出空间模型会变得更“正确”但也可能变得更保守、更啰嗦、丢失一些创造力。我们对比过SFT模型能给出更有“灵性”的答案DPO之后更规范但有时显得模板化。所以对齐的目标要跟业务挂钩如果是客服、知识问答、审核这类场景宁保守勿出错DPO可以多跑几个epoch如果是创意写作、文案生成DPO收敛太快反而会损失多样性建议用较低beta、较少步数保留更多生成空间。6. 评估与落地没有评估就是盲人摸象很多人训完模型就急着部署问“效果怎么样”却说不上来。大模型评估是拿着放大镜看细节的活不做系统评估你根本不知道模型哪里好哪里坏上线了才知道问题就晚了。6.1 自动评测基准不是万能的业界常用的自动基准有MMLU、CEval、CMMLU、HumanEval、BBH、GSM8K等。跑一遍确实能看出大概水平但有几个前提要搞清楚数据污染问题开源基准数据很可能出现在你用的预训练或SFT数据里模型对这些“见过”的题有虚高表现。这非常常见我们有一次训练到CEval 80分但实际使用时逻辑推理和通用常识都明显拉胯。自动评估只能测上限不能测真实体验模型在选择题任务上能得分高但在自由生成格式的任务里可能一团糟比如回答冗长、格式乱、编造来源。建议做法自动基准只是门槛真正决定上不上线的是任务场景里的专业测试集。如果你是做法律问答就找法律题库和真实咨询记录构造评测集如果是代码生成就用业务相关的小型代码编写任务让资深工程师人工打分。6.2 人工评估的完整流程我们团队跑了两轮人工评估这里给出一个能复用的框架样本选择从真实业务场景中随机抽取200到500个问题覆盖常见场景、边界场景、安全场景。盲测对比让评估员同时看两个模型的输出但隐藏模型身份对“正确性、有用性、安全性、格式”四个维度分别打分。双人交叉评判同一批样本分配给两个评估员独立打分不一致的样本由组长讨论复核减少主观偏差。bad case分析凡是得分低的样本逐条分析原因归类整理后回填到训练迭代里。另外**红队测试red teaming**也建议认真做一次尝试用对抗性提示让模型输出有害内容、泄露隐私、绕过限制。这一步对模型上线后的安全性有实际作用尤其是面向外部用户的产品。6.3 部署与推理模型训完怎么用起来模型评估没问题后部署选型直接影响落地体验。目前比较成熟的方向有vLLM吞吐量高支持PagedAttention对并发请求场景合适是目前自建推理最主流的引擎。7B模型用单张A10G/A100就能跑得比较顺配合Tensor Parallel可以进一步降低延迟。Ollama本地单机场景很合适一条命令把模型跑起来适合个人电脑、小团队的内部试用。它的推理速度和灵活性不如vLLM但胜在省心。量化部署如果资源紧张可以考虑AWQ或GPTQ量化到INT4/INT8。7B模型INT4大概占4~5GB显存速度提升明显但要注意量化后效果会有一定损失建议用评测集测一轮再决定是否上线。我们在实际部署时发现推理时上下文长度和SFT阶段不一致会导致效果明显变差。如果你SFT用的是2048上下文部署时突然给模型塞6000字的长文档模型表现会非常不稳定。部署前最好把上下文长度对齐或者多测几组长度看看效果梯度。最后分享一点个人体会这条链路走下来我最大的感受是大模型训练不拼技巧拼的是工程耐心和数据洁癖。从零训练的时间分配数据工程占了一半以上训练本身反而不是最耗时的环节。任何偷工减料的数据处理方式都会在后面某个阶段加倍还回来。另一个体会是不要迷信某个单一环节的惊艳效果。SFT好不代表DPO好DPO好不代表业务表现好每一轮都要用评估说话bad case分析比benchmark分数重要得多。以后拿到一个新模型花一个下午做一轮针对自己业务的bad case分析比看十篇评测报告更有用。 
长河君 · 2026/10/2 4:05:26 · 阅读 1.2k 从零训练大模型全流程实战：数据清洗、预训练到DPO部署
从去年年中开始我带着一个七人小团队把一条完整的训练链路跑了三遍数据清洗、预训练、SFT、DPO、评估、部署。网上关于大模型的论文和课程多到看不完但真正能把手把手把“数据→预训练→SFT→DPO/RLHF→评估”全流程走通的人并不多。这活儿确实脏、确实累、也确实贵但一旦跑通一次你对大模型的理解会彻底不一样——以后再看任何训练相关的东西基本都有谱了。这里把整条路线的事情写透一点想把模型从零搞起的团队可以先照着做至少能绕开我们踩过的那些大坑。1. 先想清楚从零训练的适用场景与资源门槛很多团队一上来就问“我要从零训一个自己的模型”但这句话背后的动机差别很大。有的是为了私有化部署、数据不出域有的是觉得开源模型不够贴合自己的业务有的纯粹想锻炼团队能力。这三种诉求对应的方案完全不同。1.1 什么情况下值得从零训练作为过来人我的判断标准很简单你要解决的问题改开源模型性价比更高就不要自己从头训。比如给客服做个FAQ助手用Qwen或Llama微调就够了但如果你要的是“金融法规条文的精准问答”、“医疗病历结构化抽取”这类垂直场景开源通用模型在术语准确性、格式合规性上经常差一口气。再加上企业级数据不能出域的话从零预训练一个专属底座就变成了刚需。还有一个情况值得从零训练你需要一个可控的技术底座。开源模型用起来方便但你不知道它训练数据里有什么出问题不好排查将来想针对垂直场景做继续预训练也受到上游限制。自己训的模型从tokenizer到数据配比都清楚出任何质量问题都好溯源。1.2 资源估算先算账再动手从零训练一个大模型最大的门槛不是技术是钱。我给你一个可以套用的粗略估算方法。模型规模如果做垂直场景7B量级在这个阶段是性价比比较合适的点参数量再往下能力下降明显往上训练成本指数级上升。数据规模常见的做法是1T到2T token这基本是7B模型能力涌现的及格线。数据少到几百B的话模型也有用但比较“笨”。硬件估算以7B模型、1T token、序列长度2048为例按Llama架构的算力需求粗算6N×DN是参数量D是token数需要约 6×7B×1T ≈ 4.2e22 FLOPs。用一张A100 80GBF16算力约312TFLOPs考虑60%左右的MFU大概需要 4.2e22 / (312e12×0.6) ≈ 2.2e5 秒约62小时。也就是说大约24张A100跑3天多或者8张跑9天多。如果改用H100时间差不多减半。这个数字只是训练本身还没算调试失败、数据重构、评估测试的时间。所以务实建议是如果你只有一两张显卡不要碰从零预训练。先用LoRA微调做业务验证等业务模型的需求被验证清楚了再预算从零训练的性价比。如果预算在几十万到百万量级直接从零训练是可行的。1.3 少走弯路的起点判断不少人一开始就冲“从零”两个字其实可以“从中间出发”。目前主流平台还是有公开的开源底座比如Llama系列、Qwen系列、Mistral系列。这些模型经过完整训练底子扎实如果你的垂直场景数据量大完全可以做增量预训练continue pretraining比从随机权重训起节省至少一个数量级的成本。真实项目里做增量预训练比例更高。它保留通用能力注入垂直知识风险比随机初始化小很多。如果你非要随机初始化建议也先跑一个几百M或1B参数的小模型验证数据质量和训练流程再放大到7B。我们第一次直接上7B随机初始化结果训练到两万步发现数据有系统性污染全部推倒重来那个酸爽不说了。2. 数据工程语料清洗与配比很多人觉得训练大模型拼的是显卡但跑完一轮你会发现真正的瓶颈在数据。模型能力的天花板几乎完全由数据质量决定。尤其从零训练数据直接决定你后续所有环节的成败。2.1 预训练语料从哪里来、怎么洗开源可用的预训练语料主要包括RedPajama、SlimPajama、Falcon RefinedWeb中文场景还有WuDaoCorpora、SkyPile等。但直接拿来用是不行的必须做清洗。我们跑了几轮清洗后原始文本大约只剩三分之二其中不少是重复内容和无意义符号。我实际用到的清洗流水线按顺序大概是格式统一把所有语料转成统一UTF-8文本格式处理PDF抽出来的乱码、HTML里的广告导航残留。去重先做精确去重MD5再做模糊去重MinHash LSH。网上很多公开语料重复率高到离谱同一段新闻在不同网页出现几十次不去重模型会严重过拟合表现为生成内容大量重复。语言过滤按业务需要筛选语言用fastText或语种识别模型过滤掉无关语种。质量过滤用规则结合困惑度过滤。规则主要筛掉纯表格、纯URL、无换行的超长文本困惑度可以借助一个小的语言模型计算把那些困惑度过高、不像正常语言的文本剔除。隐私与安全过滤把身份证号、手机号、私钥这类信息用规则正则清洗。这五步不是可选项是必须项。我们第一版数据因为去重不够训练出来的模型在生成时经常出现大段重复文本这个事后修补成本极高建议一开始就做扎实。2.2 数据配比怎么搭才不出偏不同来源的数据不能简单堆在一起配比很重要。一个从零训出的中文模型一般英文知识类数据占大头中文占一部分代码和数学要有相当比例因为推理能力很多是从代码数据里学到的。注意代码和数学这类结构化数据占比低会让模型逻辑能力明显偏弱占比过高又会让模型语感变僵硬在写作和对话场景显得机械。需要按业务场景做平衡。我用的初始配比大致是英文百科/网页/书籍 50%中文百科/新闻/社区 25%代码 15%数学与推理 5%其他 5%。这不是标准答案但作为起点比随便堆效果好很多。配比调整有个技巧先做小模型实验。拿1B模型用不同配比训各10B token看下游任务表现差异能用小成本把数据配比调到较优再放大到7B省下的是几十万的训练费。2.3 Tokenizer训练基础一定要打牢Tokenizer很多时候被忽略但它直接影响压缩率和模型表现。中文场景下直接用Llama的tokenizer中文效率很低词表里中文token太少同一个词拆得更碎序列更长训练和推理都变慢效果也受影响。训练自己的tokenizer时我一般这么配置词表大小中文英文场景选50K到64K比较稳。太小了压缩率差太大了容易过拟合而且embedding层参数也变多。训练语料最好在正式预训练数据的同分布采样上进行混合比例跟你预训练数据一致。验证指标看**字节覆盖率byte coverage**和平均分片长度。一个好的中文tokenizer常见中文字符应该单个token能覆盖大半极少出现把一个常用词切成三四个token的情况。如果从头训练确实麻烦可以考虑用现有开源中文tokenizer做扩展但要注意embedding层是随机初始化的如果模型是增量预训练扩展词表后还需要做旧词表权重对齐的冷启动处理。这一块的细节不少人踩坑建议实操时留意。3. 预训练实操从模型配置到loss收敛数据就位之后下一步就是预训练。这部分看起来就是跑脚本实际训练过程中问题很多loss不降、NaN、OOM、节点掉线每个问题都能耗掉半天到一天时间。我把关键部分拆开讲。3.1 模型架构与配置选择如果你随机初始化架构可以直接参考LLaMA的设计标准decoder-only transformerPre-NormRMSNormSwiGLU激活函数RoPE旋转位置编码无偏置项。这套架构经过大量验证训练稳定性和效果都有保障不用特地去搞发明创造。关键配置参数可以考虑从如下数值起步参数7B量级建议值隐藏层维度3584~4096Transformer层数28~32注意力头数28~32序列长度2048起步稳定后可扩展到4096词表大小50K~64K学习率峰值3e-4配合Warmup全局Batch Size0.5M~1M tokens约256~512条序列优化器AdamWβ(0.9, 0.95)权重衰减0.1精度策略BF16混合精度一个容易忽略的点是全局batch size。大模型训练的batch size建议保持较大的tokens总量效果好且训练稳定但batch太大会导致单卡显存爆炸需要靠梯度累积实现。我们用的是512的micro-batch每条2048 token配合64步梯度累积等效全局batch 65536条样本约134M tokens。3.2 训练框架与并行策略怎么选训练7B模型单机多卡到多机多卡的情况都有。我的建议是这样分层级走单机8卡A100/H100直接用DeepSpeed ZeRO-3或PyTorch FSDP就够了。ZeRO-3把模型参数、梯度、优化器状态分片到各卡训练7B模型很轻松显存占用约60~70GB每卡。多机多卡≥16卡建议上张量并行TP ZeRO/FSDP组合或者直接用Megatron-LM。张量并行能减少跨机通信量训练效率高不少。有稳定集群且长期训练可以直接上Megatron-LM 流水线并行 数据并行全套但门槛较高需要专职的并行工程师维护。如果你只是想把流程跑通FSDP是上手比较快的方案。注意用BF16而不是FP16大模型梯度在FP16下很容易溢出变成NaNBF16虽然精度低一点但动态范围大训练更稳。我们第一次用FP16跑到几千步就NaN了换了BF16解决。3.3 训练监控不要只看loss曲线预训练阶段loss肯定是一路下降的但loss本身不够判断模型好坏。建议同步关注几个辅助指标验证集困惑度Perplexity固定一个和训练数据同分布的验证集每500步算一次困惑度。如果训练loss继续降、验证困惑度不再降甚至抬升说明对训练数据过拟合了。预训练阶段这事不多见但数据不足时会遇到。loss spike观察训练中偶尔出现loss突然跳高又回落通常是训练数据里混入了异常样本超长重复段、非UTF字符等。遇到loss spike不要急着调参数先去查那批数据的分布查不清就减小心学习率或者降低batch size。checkpoint策略建议每500到1000步保存一个checkpoint并且同时保存优化器状态。只存模型权重的话中途训练中断连优化器状态都要重建会浪费不少时间。我们有个习惯每2000步传一份完整checkpoint到独立存储避免节点故障导致整机数据丢失。预训练的目标不是loss越低越好而是保证后续SFT、DPO阶段还有足够的“学习空间”。一般训到loss区域平稳下降、困惑度符合预期就可以切到SFT了。如果从零训练到困惑度明显高于参考开源模型的水平大概率是数据量或数据质量没到位。4. SFT指令微调与对话能力塑造预训练模型只是一个“文本接龙高手”能续写但不会好好回答问题。SFT监督微调通过大量指令-回答对把模型的生成行为对齐到“问答”模式。这一步做得好不好直接影响用户感知到的模型智商和情商。4.1 指令数据怎么构造与清洗SFT数据现在公开资源不少Alpaca、ShareGPT、Dolly、BELLE、OpenAssistant等都能用但直接混合效果一般。SFT数据的核心要求是多样性高质量不是数量大。我们第一轮SFT用了30万条公开自建数据效果远不如后面精筛后的15万条因为公开数据里大量是重复模板和低质量问题。指令数据一般包含三类角色system系统提示、user用户指令、assistant助手回复。构造时要注意指令要多样同一意图换多种表达方式覆盖“请帮我……”、“……怎么做”、“解释一下……”等句式防止模型只会某一种句式。回答要有依据对于专业领域每条回答最好附带参考来源模型才能养成“有依据才答”的习惯少生成幻觉内容。包含拒绝样本用户问违规或超出能力范围的问题时要构造“我无法回答……”的回复否则模型会强行编答案。清洗PII信息自建SFT数据往往包含用户真实对话身份证、手机号、公司名必须过滤别让训练数据把你出卖了。4.2 全参微调还是LoRA很多新手一上来就问要不要上LoRA。我直接给结论如果GPU显存够如4卡A100且想追求模型最佳效果全参微调。SFT数据量不大几万到几十万条全参微调的收敛速度和效果上限都更高。如果想快速实验、显存不够单卡24GLoRA或QLoRA。LoRA只训练一小部分参数显存和训练时间都节省不少效果接近全参的80%~90%。训练细节上有几个容易被忽略的地方损失只计算回答部分标准做法是prompt部分的token不参与loss计算只算assistant回复的交叉熵否则模型会把“跟着问题念一遍”学进去。代码实现上一般通过labels矩阵把prompt位置设为-100忽略。学习率要比预训练低全参微调通常用1e-5到3e-5LoRA可以用稍高的1e-4到3e-4。太高了会破坏预训练学到的通用特征。epoch一般不用太多SFT数据规模不大通常1到3个epoch就够了。过拟合的判断标准是验证集loss回升或模型开始“背诵训练数据”而不是泛化。4.3 SFT常见翻车现场这一阶段翻车频率非常高列举几个我们真实遇到过的复读机模型反复重复同一句话尤其是长回答时。原因大概率是SFT数据里有大量包含重复句的回答或者是预训练阶段数据重复率过高没洗干净。回答格式乱模型自己造出一堆不存在的markdown语法、错误换行。这类问题需要在SFT数据里统一格式并在评估时重点检查格式一致性。混入system内容模型把system里的指令原样输出或者自己发明system内容。这通常是SFT数据没有严格按照chat template填导致模型没学会区分角色。注意在训练和推理时使用同一个chat template这是新手容易踩的隐坑。SFT完成后模型已经能“正确回答”了但“正确”和“符合人类偏好”是两码事。接着要上对齐阶段。5. DPO/RLHF偏好对齐让模型学会说人话SFT教会模型模仿数据里的回答方式但它不会判断两个回答哪个好。偏好对齐的目标是让模型学会输出“人类更偏好的回答”比如更安全、更有用、更简洁。这一步走完模型才能真正用在实际业务中。5.1 Reward Model、RLHF 和 DPO 的差异与选型RLHFReinforcement Learning from Human Feedback的经典流程是先训练一个Reward Model打分再用PPO等强化学习算法去优化策略模型让回答在RM得分高的同时不过度偏离SFT基线加KL惩罚。DPODirect Preference Optimization出现之后这个流程被大幅简化。它去掉了Reward Model和强化学习环境直接用偏好对数据微调策略模型让模型增大对chosen回答的概率、降低对rejected回答的概率。对比维度RLHFPPODPO组件复杂度需要RMPPO4个模型交互仅策略模型参考模型训练稳定性较难调稳超参多相对稳定实现简单效果上限理论上更高可以迭代优化依赖偏好数据质量资源消耗高需要大量显存和时间低和SFT差不多维护成本高适合大团队低中小团队首选考虑到大部分团队只有有限的GPU资源和工程人力第一次做对齐建议直接用DPO。RLHF那套流程复杂PPO的KL散度控制、优势估计裁剪、RM训练等环节有一环没调好就白费工夫。DPO在7B量级上的效果已经被大量验证过是性价比更高的起点。5.2 DPO数据构造与超参要点DPO的数据形式是偏好对同一个问题给出一个chosen人类更喜欢的回答和一个rejected人类不太喜欢的回答模型从中学会区分好坏。数据来源一般有两种人工标注让标注员对比SFT模型的多个回答选出好坏。成本高但质量可靠。模型自动构造用强模型如GPT-4对SFT模型的多个输出打分排序选出一好一坏。成本低但需注意作弊问题模型可能偏好它自己风格的答案。我们实际跑下来发现DPO效果好坏主要靠数据质量而非数量。5万对高质量偏好数据效果比20万对弱监督数据好得多。至少要保证chosen和rejected来自同一个场景、同一个长度范围不然模型容易走捷径比如学习到“长的就是好的”这类虚假特征。DPO训练时几个关键配置beta参数KL约束系数默认0.1到0.5之间。beta越大模型越不敢偏离参考模型越小模型更激进地偏好chosen。我们常用0.1稳定性和效果平衡较好。参考模型ref_model用SFT阶段的模型作为参考模型不要在DPO开始后又重训参考模型。两个模型同源是DPO收敛的保障。学习率DPO学习率一般比SFT低通常1e-6到1e-5。我们全参DPO用2e-6LoRA DPO用1e-5。混合SFT数据只训练DPO数据容易让模型学歪比如对话风格突变。实操中我们会把DPO数据和少量SFT数据混合训练比例大概31能保持基本问答能力不退化。5.3 对齐之后必然付出的代价对齐不是免费的。偏好对齐本质上是在压缩模型的输出空间模型会变得更“正确”但也可能变得更保守、更啰嗦、丢失一些创造力。我们对比过SFT模型能给出更有“灵性”的答案DPO之后更规范但有时显得模板化。所以对齐的目标要跟业务挂钩如果是客服、知识问答、审核这类场景宁保守勿出错DPO可以多跑几个epoch如果是创意写作、文案生成DPO收敛太快反而会损失多样性建议用较低beta、较少步数保留更多生成空间。6. 评估与落地没有评估就是盲人摸象很多人训完模型就急着部署问“效果怎么样”却说不上来。大模型评估是拿着放大镜看细节的活不做系统评估你根本不知道模型哪里好哪里坏上线了才知道问题就晚了。6.1 自动评测基准不是万能的业界常用的自动基准有MMLU、CEval、CMMLU、HumanEval、BBH、GSM8K等。跑一遍确实能看出大概水平但有几个前提要搞清楚数据污染问题开源基准数据很可能出现在你用的预训练或SFT数据里模型对这些“见过”的题有虚高表现。这非常常见我们有一次训练到CEval 80分但实际使用时逻辑推理和通用常识都明显拉胯。自动评估只能测上限不能测真实体验模型在选择题任务上能得分高但在自由生成格式的任务里可能一团糟比如回答冗长、格式乱、编造来源。建议做法自动基准只是门槛真正决定上不上线的是任务场景里的专业测试集。如果你是做法律问答就找法律题库和真实咨询记录构造评测集如果是代码生成就用业务相关的小型代码编写任务让资深工程师人工打分。6.2 人工评估的完整流程我们团队跑了两轮人工评估这里给出一个能复用的框架样本选择从真实业务场景中随机抽取200到500个问题覆盖常见场景、边界场景、安全场景。盲测对比让评估员同时看两个模型的输出但隐藏模型身份对“正确性、有用性、安全性、格式”四个维度分别打分。双人交叉评判同一批样本分配给两个评估员独立打分不一致的样本由组长讨论复核减少主观偏差。bad case分析凡是得分低的样本逐条分析原因归类整理后回填到训练迭代里。另外**红队测试red teaming**也建议认真做一次尝试用对抗性提示让模型输出有害内容、泄露隐私、绕过限制。这一步对模型上线后的安全性有实际作用尤其是面向外部用户的产品。6.3 部署与推理模型训完怎么用起来模型评估没问题后部署选型直接影响落地体验。目前比较成熟的方向有vLLM吞吐量高支持PagedAttention对并发请求场景合适是目前自建推理最主流的引擎。7B模型用单张A10G/A100就能跑得比较顺配合Tensor Parallel可以进一步降低延迟。Ollama本地单机场景很合适一条命令把模型跑起来适合个人电脑、小团队的内部试用。它的推理速度和灵活性不如vLLM但胜在省心。量化部署如果资源紧张可以考虑AWQ或GPTQ量化到INT4/INT8。7B模型INT4大概占4~5GB显存速度提升明显但要注意量化后效果会有一定损失建议用评测集测一轮再决定是否上线。我们在实际部署时发现推理时上下文长度和SFT阶段不一致会导致效果明显变差。如果你SFT用的是2048上下文部署时突然给模型塞6000字的长文档模型表现会非常不稳定。部署前最好把上下文长度对齐或者多测几组长度看看效果梯度。最后分享一点个人体会这条链路走下来我最大的感受是大模型训练不拼技巧拼的是工程耐心和数据洁癖。从零训练的时间分配数据工程占了一半以上训练本身反而不是最耗时的环节。任何偷工减料的数据处理方式都会在后面某个阶段加倍还回来。另一个体会是不要迷信某个单一环节的惊艳效果。SFT好不代表DPO好DPO好不代表业务表现好每一轮都要用评估说话bad case分析比benchmark分数重要得多。以后拿到一个新模型花一个下午做一轮针对自己业务的bad case分析比看十篇评测报告更有用。