1. 从“后训练”这个词说起Halo 框架到底在解决什么问题第一次看到“White Circle 开源 Halo 后训练框架”这个标题很多人第一反应可能是Halo 不是那个博客系统吗怎么又变成后训练框架了这里得先把概念掰开。Halo 在这个语境下指的是 White Circle 团队推出的一个面向大模型后训练post-training阶段的开源框架跟那个建站系统没有半点关系。所谓后训练是相对于预训练pre-training而言的——预训练让模型学会“说话”后训练则让模型学会“听话”也就是把海量语料里学到的通用能力对齐到具体的指令遵循、偏好偏好、任务格式上。这一步做得好不好直接决定了一个模型在真实业务里能不能用。我接触过不少团队预训练阶段砸了重金结果后训练环节草草了事最后模型输出要么答非所问要么格式乱七八糟要么安全边界一塌糊涂。后训练看起来只是“微调一下”实际上涉及数据构造、损失设计、训练策略、评测闭环一整套工程。Halo 这个框架的价值就在于它把后训练里那些反复造轮子的部分——数据管线、训练循环、分布式调度、评测接口——做成了可复用的组件让团队能把精力放在真正有差异化的地方数据质量和算法策略。这篇文章适合三类人看一是正在做模型微调、想找一套靠谱后训练脚手架的算法工程师二是想理解后训练全流程、但被各种术语绕晕的入门者三是需要评估“要不要引入 Halo”的技术负责人。我会从框架定位、核心模块、环境搭建、数据管线、训练配置、评测闭环、踩坑经验几个角度展开尽量把每个设计决策背后的“为什么”讲清楚而不是只丢一堆命令让你照抄。提示后训练不是一个单一技术点而是一条链路。任何声称“一个脚本搞定后训练”的方案大概率在某个环节偷了懒。评估框架时先看它的数据管线和评测闭环是否完整再看训练本身。2. Halo 框架的定位它不做什么比它做什么更重要2.1 后训练框架和微调脚本的本质区别市面上大量所谓的“微调工具”本质是一个训练脚本加几个配置文件。你给它一个数据集它跑完 SFT 或者 DPO输出一个权重结束。这类工具在单任务、单数据集场景下够用但一旦你要做多阶段后训练——比如先做指令微调再做偏好对齐再做领域适配——脚本之间就开始互相打架数据格式不统一、checkpoint 管理混乱、评测指标各算各的。Halo 的定位是“框架”而非“脚本”核心差异体现在三个层面。第一是阶段编排它把后训练拆成可组合的阶段stage每个阶段有独立的输入输出契约阶段之间通过统一的中间格式衔接。第二是配置驱动训练超参、数据配比、评测任务都通过声明式配置管理而不是散落在代码里。第三是可观测性训练过程中的 loss、梯度范数、样本级指标都有标准化输出方便定位问题。我个人的判断标准很简单如果一个工具让你在换数据集时不得不改代码那它是脚本如果只改配置就能跑通新任务那才配叫框架。Halo 属于后者。2.2 为什么“后训练”需要独立框架有人会问预训练框架比如各种大规模训练库不能直接拿来后训练吗技术上可以但工程上别扭。预训练关注的是吞吐和稳定性数据是海量无标注文本目标是 next-token prediction。后训练关注的是对齐质量和任务指标数据是精心构造的指令-回复对或偏好对目标函数可能是 SFT loss、DPO loss、PPO 的 reward 组合。两者的数据管线、显存占用模式、评测方式完全不同。举个具体例子预训练时你几乎不关心单条样本长什么样只关心整体分布后训练时一条脏数据就可能让模型学会一个坏习惯你必须做样本级过滤和去重。Halo 把这类后训练特有的需求做进了框架层比如内置的样本质量打分、指令去重、格式校验钩子。这些在通用预训练框架里要么没有要么得自己写。2.3 开源策略背后的取舍White Circle 选择开源 Halo而不是做成闭源 SaaS这个决策本身值得说。后训练涉及大量业务数据很多团队根本不愿意把数据传到第三方平台。开源框架让团队可以在自己的集群里跑数据不出域这是刚需。同时开源也意味着社区可以贡献新的训练算法和评测任务框架的覆盖面会越来越广。但开源也有代价文档质量参差、版本迭代快、issue 响应看运气。我的经验是引入开源后训练框架时先锁定一个稳定版本把核心链路跑通再考虑跟进新特性。不要一上来就用 main 分支那是给自己找麻烦。3. 核心模块拆解数据、训练、评测三件套怎么协同3.1 数据管线后训练质量的第一道闸门后训练的数据管线通常包含采集、清洗、去重、格式化、配比、采样几个环节。Halo 把这条管线抽象成可插拔的 processor 链每个 processor 负责一个变换输入输出都是统一的数据记录结构。这样做的好处是你可以像搭积木一样组合处理逻辑也方便单独测试某个环节。我重点说三个容易被忽视的细节。第一是去重的粒度。指令微调数据里完全重复的样本好去但语义重复的样本换个说法问同一个问题很难去。Halo 提供了基于 embedding 相似度的近邻去重阈值需要根据你的数据分布调。阈值太低去不干净太高会误删有效样本。我的经验是先在验证集上人工看 100 组近邻对确定一个主观可接受的边界再反推阈值。第二是格式校验。后训练数据最常见的坑是格式不统一有的用 system/user/assistant 三段式有的只有 user/assistant有的把 system 内容塞进 user。Halo 的 format validator 会强制检查每条样本是否符合目标模板不符合的直接丢弃并记录原因。这个机制救过我很多次因为脏数据往往在训练跑了一半才暴露那时候排查成本极高。第三是配比采样。多任务后训练时不同任务的数据量差异可能上百倍。如果不做配比模型会被数据量大的任务主导。Halo 支持按任务权重采样权重可以按 epoch 动态调整。我一般会让模型在训练前期多接触通用指令数据后期逐步加大领域数据权重这样既保住通用能力又强化领域表现。3.2 训练循环SFT、DPO、PPO 的共存方式Halo 的训练模块支持多种后训练目标包括监督微调SFT、直接偏好优化DPO、以及基于奖励模型的强化学习PPO 类。不同目标的训练循环差异很大框架层要做的是统一接口、隔离差异。SFT 最简单就是标准的交叉熵损失但要注意 label masking——只对 assistant 回复部分计算 lossuser 输入部分要 mask 掉。这个细节很多脚本会漏导致模型学会“复述问题”。Halo 在数据模板里就标注了哪些 token 参与 loss 计算从源头避免这个问题。DPO 需要成对的偏好数据chosen/rejected损失函数同时涉及策略模型和参考模型。显存占用比 SFT 高因为要加载两份模型或者用 LoRA 加参考模型冻结的方式省显存。Halo 支持参考模型共享和梯度检查点实测在 7B 模型上单卡 80G 可以跑 DPO但 batch size 要压得很小。PPO 类训练最复杂涉及 actor、critic、reward、reference 四个模型。Halo 的做法是把 reward 模型和 reference 模型做成可选的远程服务actor 和 critic 在本地训练。这样显存压力小很多但引入了网络通信开销。我的建议是除非你有明确的在线反馈信号否则优先用 DPOPPO 的调参成本高得多收益不一定对得起投入。3.3 评测闭环没有评测的后训练等于盲飞后训练最容易失控的地方是你改了数据配比或损失权重模型在训练集上 loss 降了但真实能力是升是降完全不知道。Halo 内置了评测模块支持在训练过程中定期跑评测任务输出结构化指标。评测任务分两类通用能力评测如指令遵循、推理、代码和领域评测按业务定制的任务集。通用评测可以复用公开基准领域评测需要自己构造。我的做法是领域评测集至少包含 200 条人工标注样本覆盖主要任务类型和边界情况每次训练 checkpoint 都跑一遍画成曲线看趋势。这里有个反直觉的经验不要只看总分。总分上升可能掩盖某个子任务的退化。我遇到过整体指标涨了 3 个点但格式遵循率掉了 15 个点的情况原因是模型学会了更“自由”的表达牺牲了格式稳定性。所以评测报告必须分项展示任何一项明显下降都要警惕。4. 环境搭建与最小可跑通路径4.1 硬件与依赖的现实考量Halo 官方文档给的推荐配置通常是多卡 A100/H100 集群但大多数人手里只有单卡或双卡消费级显卡。我的实测经验是7B 模型做 LoRA 微调单卡 24G如 3090/4090可以跑但要把 batch size 降到 1-2开启梯度累积和梯度检查点。全量微调 7B 至少需要 4 卡 80G13B 以上建议 8 卡起步。依赖方面PyTorch 版本要和 CUDA 驱动匹配这个老生常谈但每次都能坑到人。Halo 对 transformers、accelerate、peft 这些库有版本要求建议用 conda 建独立环境不要和系统 Python 混用。我习惯用conda env export把环境锁死避免“昨天还能跑今天报错”的经典问题。4.2 从零到第一个 checkpoint 的完整步骤假设你已经装好环境手里有一份指令微调数据想跑通第一个 SFT checkpoint。步骤如下。第一步准备数据。Halo 期望的数据格式是 JSONL每行一条样本字段包括messages对话列表和可选的metadata。对话列表里每条消息有role和content。如果你的原始数据是其他格式写个转换脚本注意保留原始 ID 方便追溯。第二步写配置文件。Halo 的配置分数据、模型、训练、评测四块。数据块指定路径和 processor 链模型块指定基座模型路径和微调方式全量/LoRA训练块指定 batch size、学习率、epoch 数、优化器评测块指定评测任务和频率。第三步启动训练。用框架提供的 CLI 入口指定配置文件路径和输出目录。启动后先看日志里的数据加载统计确认样本数、token 数、过滤掉多少条。如果过滤比例超过 20%说明数据格式或质量有问题先停下来查。第四步观察训练曲线。前 100 步重点看 loss 是否平稳下降梯度范数是否爆炸。如果 loss 震荡剧烈先降学习率如果梯度范数持续很大检查数据里有没有超长样本。第五步跑评测。训练结束后用评测模块跑一遍验证集看各项指标。如果指标不达预期回到数据和超参调整不要盲目加 epoch。注意第一次跑通不要追求效果追求的是链路完整。哪怕指标很差只要数据进得去、模型出得来、评测有结果这条链路就是通的。后面所有优化都建立在这条链路之上。4.3 配置文件的字段陷阱Halo 的配置文件字段多有几个容易踩的坑。max_seq_length设得太小会截断长样本设得太大显存爆炸。我的做法是先统计训练数据的 token 长度分布取 95 分位数作为 max_seq_length超长样本单独处理或丢弃。learning_rate对 LoRA 和全量微调差异很大。LoRA 通常用 1e-4 到 3e-4全量微调用 1e-5 到 2e-5。用错量级会导致要么不收敛要么灾难性遗忘。gradient_accumulation_steps和batch_size的乘积决定有效 batch size。有效 batch size 太小训练不稳定太大收敛慢。我的经验是有效 batch size 控制在 64-128 之间比较稳具体看任务。5. 数据构造的实战心得好数据是后训练的天花板5.1 指令数据的三种来源与质量排序后训练指令数据无非三个来源人工标注、模型生成、真实业务日志。质量排序上人工标注最高但成本高真实日志最贴近分布但噪声大模型生成量大但同质化严重。我的实践是三者混合用真实日志做种子人工标注一批高质量样本作为“黄金集”再用强模型对种子做扩充生成最后用规则和模型双重过滤。黄金集不直接大量参与训练而是作为评测基准和 few-shot 示例。训练主力是过滤后的生成数据加真实日志。模型生成数据最大的问题是“模型味”——句式雷同、过度礼貌、缺乏具体细节。过滤时除了看格式还要看多样性指标比如回复长度的分布、开头词的分布。如果 80% 的回复都以“当然可以”开头这批数据就得重做。5.2 偏好数据的构造难点DPO 需要 chosen/rejected 对。构造偏好数据比构造指令数据难得多因为你要保证 rejected 是“合理但不够好”而不是“明显错误”。如果 rejected 太差模型学不到细粒度偏好如果 rejected 和 chosen 太接近标注一致性会很差。我的做法是让标注者先写 chosen再基于 chosen 做最小修改生成 rejected比如改一个事实、换一个语气、删一个关键步骤。这样两者的差异可控模型能学到具体的偏好维度。同时要记录 rejected 的修改类型方便分析模型到底在学什么。5.3 数据配比的动态调整策略多任务训练时配比不是一成不变的。我通常分三个阶段预热阶段前 10% 步数以通用指令为主让模型适应对话格式主体阶段按任务重要性配比重要任务权重高收尾阶段加大高质量黄金集权重做最后的能力巩固。Halo 支持按步数动态调整采样权重配置里可以写权重随训练进度的变化曲线。这个功能很实用但曲线不要设得太激进否则模型在不同分布间反复横跳反而不稳定。6. 训练过程中的典型故障与排查链路6.1 loss 不下降的四种可能原因loss 不下降是最常见的求助问题。排查顺序应该是先看数据再看配置再看代码最后看硬件。数据层面检查 label 是否正确对齐。如果 loss 计算包含了 user 部分模型会去拟合问题本身loss 可能下降但能力不涨。检查方法是打印几条样本的 input_ids 和 labels人工核对。配置层面检查学习率是否太小、优化器是否选错、warmup 是否过长。LoRA 场景下还要检查 target_modules 是否覆盖了关键层只调 bias 基本学不到东西。代码层面检查损失函数实现是否正确特别是自定义 loss 时容易出维度错误。硬件层面检查是否有 NaN 或 Inf通常是混合精度下的数值溢出可以尝试关掉 fp16 用 bf16。6.2 显存溢出的定位与缓解显存溢出OOM的定位方法是逐步缩小规模先把 batch size 降到 1如果还 OOM说明模型本身加载就超了如果能跑逐步加 batch size 找到边界。然后开启梯度检查点、优化器状态分片、LoRA 等省显存手段。我遇到过一个隐蔽的 OOM评测阶段加载了额外的模型导致显存不够。解决办法是把评测放到训练结束后单独跑或者用 CPU 做评测推理。Halo 的评测模块支持指定设备配置里写cpu就行慢但稳。6.3 模型输出退化的识别训练过程中模型输出退化表现为重复、格式混乱、拒绝回答。这通常是过拟合或数据污染的征兆。识别方法是定期用固定 prompt 集做生成测试人工看输出质量。如果发现退化先回退到上一个 checkpoint再检查最近加入的数据。有个经验训练 loss 持续下降但生成质量下降几乎可以断定是过拟合或数据问题。这时候不要继续训练停下来查数据。我见过太多人盯着 loss 曲线自我安慰最后得到一个“loss 很漂亮但没法用”的模型。7. 评测体系怎么搭才不流于形式7.1 自动指标和人工评估的分工自动指标如 BLEU、ROUGE、准确率适合快速筛选但不能替代人工评估。后训练的输出质量很多维度是自动指标测不出来的比如有用性、安全性、语气恰当性。我的分工是自动指标用于训练过程中的高频监控每 N 步跑一次看趋势人工评估用于关键 checkpoint 的深度检查每个阶段结束跑一次用固定评分表打分。评分表至少包含正确性、完整性、格式遵循、安全性四个维度每维度 1-5 分。7.2 评测集构造的注意事项评测集要满足三个条件覆盖主要任务类型、包含边界情况、和训练数据不重叠。第三点最容易被忽视。如果评测样本在训练集里出现过指标会虚高失去参考价值。构造方法上我建议从真实业务需求出发每个任务类型写 20-30 条边界情况单独列一类。评测集一旦定下来就冻结不要因为模型表现不好就改评测集那是自欺欺人。7.3 用评测结果反推训练策略评测结果的价值在于指导下一步动作。如果格式遵循差回去加强格式数据的配比和格式校验如果事实性错误多检查训练数据里的事实准确性如果拒绝回答过多检查安全对齐数据是否过度。我习惯把每次训练的配置和评测结果记在一个表格里形成实验台账。这样当你想复现某个好结果时有据可查当你想知道某个改动有没有用时有对比基准。8. 一些不那么显然的经验最后分享几个我在后训练实践中攒下的、文档里不会写的体会。第一小模型先验证流程。在 7B 上跑通全流程再上大模型能省下大量调试时间。大模型一次实验几小时小模型几十分钟迭代效率差一个数量级。第二checkpoint 管理要自动化。手动保存容易漏我一般配置成每 N 步自动保存同时保留最近 K 个和最佳指标对应的那个。磁盘空间要提前规划后训练 checkpoint 很占地方。第三不要迷信单一指标。任何单一指标都可以被“刷”多指标交叉验证才能反映真实能力。我见过模型在某个基准上涨了 10 个点但换个问法就露馅说明是过拟合基准而非真正提升。第四数据版本要可追溯。每次训练用的数据打上版本号记录来源、处理脚本、过滤规则。当模型出问题时能快速定位是哪批数据引入的。第五留出“什么都不做”的基线。基座模型不经过任何后训练在评测集上的表现是多少这个数字必须知道。否则你无法判断后训练到底带来了多少增益可能忙活半天还不如原模型。Halo 这个框架目前还在快速迭代接口和配置可能会变。我的建议是把它当成一个可参考的后训练工程实践理解它的设计思路比死记它的命令更有价值。后训练的核心竞争力永远在数据和对齐策略上框架只是帮你把这些想法落地的工具。工具会换思路不会。 Halo后训练框架实战：从数据管线到评测闭环的工程化指南
1. 从“后训练”这个词说起Halo 框架到底在解决什么问题第一次看到“White Circle 开源 Halo 后训练框架”这个标题很多人第一反应可能是Halo 不是那个博客系统吗怎么又变成后训练框架了这里得先把概念掰开。Halo 在这个语境下指的是 White Circle 团队推出的一个面向大模型后训练post-training阶段的开源框架跟那个建站系统没有半点关系。所谓后训练是相对于预训练pre-training而言的——预训练让模型学会“说话”后训练则让模型学会“听话”也就是把海量语料里学到的通用能力对齐到具体的指令遵循、偏好偏好、任务格式上。这一步做得好不好直接决定了一个模型在真实业务里能不能用。我接触过不少团队预训练阶段砸了重金结果后训练环节草草了事最后模型输出要么答非所问要么格式乱七八糟要么安全边界一塌糊涂。后训练看起来只是“微调一下”实际上涉及数据构造、损失设计、训练策略、评测闭环一整套工程。Halo 这个框架的价值就在于它把后训练里那些反复造轮子的部分——数据管线、训练循环、分布式调度、评测接口——做成了可复用的组件让团队能把精力放在真正有差异化的地方数据质量和算法策略。这篇文章适合三类人看一是正在做模型微调、想找一套靠谱后训练脚手架的算法工程师二是想理解后训练全流程、但被各种术语绕晕的入门者三是需要评估“要不要引入 Halo”的技术负责人。我会从框架定位、核心模块、环境搭建、数据管线、训练配置、评测闭环、踩坑经验几个角度展开尽量把每个设计决策背后的“为什么”讲清楚而不是只丢一堆命令让你照抄。提示后训练不是一个单一技术点而是一条链路。任何声称“一个脚本搞定后训练”的方案大概率在某个环节偷了懒。评估框架时先看它的数据管线和评测闭环是否完整再看训练本身。2. Halo 框架的定位它不做什么比它做什么更重要2.1 后训练框架和微调脚本的本质区别市面上大量所谓的“微调工具”本质是一个训练脚本加几个配置文件。你给它一个数据集它跑完 SFT 或者 DPO输出一个权重结束。这类工具在单任务、单数据集场景下够用但一旦你要做多阶段后训练——比如先做指令微调再做偏好对齐再做领域适配——脚本之间就开始互相打架数据格式不统一、checkpoint 管理混乱、评测指标各算各的。Halo 的定位是“框架”而非“脚本”核心差异体现在三个层面。第一是阶段编排它把后训练拆成可组合的阶段stage每个阶段有独立的输入输出契约阶段之间通过统一的中间格式衔接。第二是配置驱动训练超参、数据配比、评测任务都通过声明式配置管理而不是散落在代码里。第三是可观测性训练过程中的 loss、梯度范数、样本级指标都有标准化输出方便定位问题。我个人的判断标准很简单如果一个工具让你在换数据集时不得不改代码那它是脚本如果只改配置就能跑通新任务那才配叫框架。Halo 属于后者。2.2 为什么“后训练”需要独立框架有人会问预训练框架比如各种大规模训练库不能直接拿来后训练吗技术上可以但工程上别扭。预训练关注的是吞吐和稳定性数据是海量无标注文本目标是 next-token prediction。后训练关注的是对齐质量和任务指标数据是精心构造的指令-回复对或偏好对目标函数可能是 SFT loss、DPO loss、PPO 的 reward 组合。两者的数据管线、显存占用模式、评测方式完全不同。举个具体例子预训练时你几乎不关心单条样本长什么样只关心整体分布后训练时一条脏数据就可能让模型学会一个坏习惯你必须做样本级过滤和去重。Halo 把这类后训练特有的需求做进了框架层比如内置的样本质量打分、指令去重、格式校验钩子。这些在通用预训练框架里要么没有要么得自己写。2.3 开源策略背后的取舍White Circle 选择开源 Halo而不是做成闭源 SaaS这个决策本身值得说。后训练涉及大量业务数据很多团队根本不愿意把数据传到第三方平台。开源框架让团队可以在自己的集群里跑数据不出域这是刚需。同时开源也意味着社区可以贡献新的训练算法和评测任务框架的覆盖面会越来越广。但开源也有代价文档质量参差、版本迭代快、issue 响应看运气。我的经验是引入开源后训练框架时先锁定一个稳定版本把核心链路跑通再考虑跟进新特性。不要一上来就用 main 分支那是给自己找麻烦。3. 核心模块拆解数据、训练、评测三件套怎么协同3.1 数据管线后训练质量的第一道闸门后训练的数据管线通常包含采集、清洗、去重、格式化、配比、采样几个环节。Halo 把这条管线抽象成可插拔的 processor 链每个 processor 负责一个变换输入输出都是统一的数据记录结构。这样做的好处是你可以像搭积木一样组合处理逻辑也方便单独测试某个环节。我重点说三个容易被忽视的细节。第一是去重的粒度。指令微调数据里完全重复的样本好去但语义重复的样本换个说法问同一个问题很难去。Halo 提供了基于 embedding 相似度的近邻去重阈值需要根据你的数据分布调。阈值太低去不干净太高会误删有效样本。我的经验是先在验证集上人工看 100 组近邻对确定一个主观可接受的边界再反推阈值。第二是格式校验。后训练数据最常见的坑是格式不统一有的用 system/user/assistant 三段式有的只有 user/assistant有的把 system 内容塞进 user。Halo 的 format validator 会强制检查每条样本是否符合目标模板不符合的直接丢弃并记录原因。这个机制救过我很多次因为脏数据往往在训练跑了一半才暴露那时候排查成本极高。第三是配比采样。多任务后训练时不同任务的数据量差异可能上百倍。如果不做配比模型会被数据量大的任务主导。Halo 支持按任务权重采样权重可以按 epoch 动态调整。我一般会让模型在训练前期多接触通用指令数据后期逐步加大领域数据权重这样既保住通用能力又强化领域表现。3.2 训练循环SFT、DPO、PPO 的共存方式Halo 的训练模块支持多种后训练目标包括监督微调SFT、直接偏好优化DPO、以及基于奖励模型的强化学习PPO 类。不同目标的训练循环差异很大框架层要做的是统一接口、隔离差异。SFT 最简单就是标准的交叉熵损失但要注意 label masking——只对 assistant 回复部分计算 lossuser 输入部分要 mask 掉。这个细节很多脚本会漏导致模型学会“复述问题”。Halo 在数据模板里就标注了哪些 token 参与 loss 计算从源头避免这个问题。DPO 需要成对的偏好数据chosen/rejected损失函数同时涉及策略模型和参考模型。显存占用比 SFT 高因为要加载两份模型或者用 LoRA 加参考模型冻结的方式省显存。Halo 支持参考模型共享和梯度检查点实测在 7B 模型上单卡 80G 可以跑 DPO但 batch size 要压得很小。PPO 类训练最复杂涉及 actor、critic、reward、reference 四个模型。Halo 的做法是把 reward 模型和 reference 模型做成可选的远程服务actor 和 critic 在本地训练。这样显存压力小很多但引入了网络通信开销。我的建议是除非你有明确的在线反馈信号否则优先用 DPOPPO 的调参成本高得多收益不一定对得起投入。3.3 评测闭环没有评测的后训练等于盲飞后训练最容易失控的地方是你改了数据配比或损失权重模型在训练集上 loss 降了但真实能力是升是降完全不知道。Halo 内置了评测模块支持在训练过程中定期跑评测任务输出结构化指标。评测任务分两类通用能力评测如指令遵循、推理、代码和领域评测按业务定制的任务集。通用评测可以复用公开基准领域评测需要自己构造。我的做法是领域评测集至少包含 200 条人工标注样本覆盖主要任务类型和边界情况每次训练 checkpoint 都跑一遍画成曲线看趋势。这里有个反直觉的经验不要只看总分。总分上升可能掩盖某个子任务的退化。我遇到过整体指标涨了 3 个点但格式遵循率掉了 15 个点的情况原因是模型学会了更“自由”的表达牺牲了格式稳定性。所以评测报告必须分项展示任何一项明显下降都要警惕。4. 环境搭建与最小可跑通路径4.1 硬件与依赖的现实考量Halo 官方文档给的推荐配置通常是多卡 A100/H100 集群但大多数人手里只有单卡或双卡消费级显卡。我的实测经验是7B 模型做 LoRA 微调单卡 24G如 3090/4090可以跑但要把 batch size 降到 1-2开启梯度累积和梯度检查点。全量微调 7B 至少需要 4 卡 80G13B 以上建议 8 卡起步。依赖方面PyTorch 版本要和 CUDA 驱动匹配这个老生常谈但每次都能坑到人。Halo 对 transformers、accelerate、peft 这些库有版本要求建议用 conda 建独立环境不要和系统 Python 混用。我习惯用conda env export把环境锁死避免“昨天还能跑今天报错”的经典问题。4.2 从零到第一个 checkpoint 的完整步骤假设你已经装好环境手里有一份指令微调数据想跑通第一个 SFT checkpoint。步骤如下。第一步准备数据。Halo 期望的数据格式是 JSONL每行一条样本字段包括messages对话列表和可选的metadata。对话列表里每条消息有role和content。如果你的原始数据是其他格式写个转换脚本注意保留原始 ID 方便追溯。第二步写配置文件。Halo 的配置分数据、模型、训练、评测四块。数据块指定路径和 processor 链模型块指定基座模型路径和微调方式全量/LoRA训练块指定 batch size、学习率、epoch 数、优化器评测块指定评测任务和频率。第三步启动训练。用框架提供的 CLI 入口指定配置文件路径和输出目录。启动后先看日志里的数据加载统计确认样本数、token 数、过滤掉多少条。如果过滤比例超过 20%说明数据格式或质量有问题先停下来查。第四步观察训练曲线。前 100 步重点看 loss 是否平稳下降梯度范数是否爆炸。如果 loss 震荡剧烈先降学习率如果梯度范数持续很大检查数据里有没有超长样本。第五步跑评测。训练结束后用评测模块跑一遍验证集看各项指标。如果指标不达预期回到数据和超参调整不要盲目加 epoch。注意第一次跑通不要追求效果追求的是链路完整。哪怕指标很差只要数据进得去、模型出得来、评测有结果这条链路就是通的。后面所有优化都建立在这条链路之上。4.3 配置文件的字段陷阱Halo 的配置文件字段多有几个容易踩的坑。max_seq_length设得太小会截断长样本设得太大显存爆炸。我的做法是先统计训练数据的 token 长度分布取 95 分位数作为 max_seq_length超长样本单独处理或丢弃。learning_rate对 LoRA 和全量微调差异很大。LoRA 通常用 1e-4 到 3e-4全量微调用 1e-5 到 2e-5。用错量级会导致要么不收敛要么灾难性遗忘。gradient_accumulation_steps和batch_size的乘积决定有效 batch size。有效 batch size 太小训练不稳定太大收敛慢。我的经验是有效 batch size 控制在 64-128 之间比较稳具体看任务。5. 数据构造的实战心得好数据是后训练的天花板5.1 指令数据的三种来源与质量排序后训练指令数据无非三个来源人工标注、模型生成、真实业务日志。质量排序上人工标注最高但成本高真实日志最贴近分布但噪声大模型生成量大但同质化严重。我的实践是三者混合用真实日志做种子人工标注一批高质量样本作为“黄金集”再用强模型对种子做扩充生成最后用规则和模型双重过滤。黄金集不直接大量参与训练而是作为评测基准和 few-shot 示例。训练主力是过滤后的生成数据加真实日志。模型生成数据最大的问题是“模型味”——句式雷同、过度礼貌、缺乏具体细节。过滤时除了看格式还要看多样性指标比如回复长度的分布、开头词的分布。如果 80% 的回复都以“当然可以”开头这批数据就得重做。5.2 偏好数据的构造难点DPO 需要 chosen/rejected 对。构造偏好数据比构造指令数据难得多因为你要保证 rejected 是“合理但不够好”而不是“明显错误”。如果 rejected 太差模型学不到细粒度偏好如果 rejected 和 chosen 太接近标注一致性会很差。我的做法是让标注者先写 chosen再基于 chosen 做最小修改生成 rejected比如改一个事实、换一个语气、删一个关键步骤。这样两者的差异可控模型能学到具体的偏好维度。同时要记录 rejected 的修改类型方便分析模型到底在学什么。5.3 数据配比的动态调整策略多任务训练时配比不是一成不变的。我通常分三个阶段预热阶段前 10% 步数以通用指令为主让模型适应对话格式主体阶段按任务重要性配比重要任务权重高收尾阶段加大高质量黄金集权重做最后的能力巩固。Halo 支持按步数动态调整采样权重配置里可以写权重随训练进度的变化曲线。这个功能很实用但曲线不要设得太激进否则模型在不同分布间反复横跳反而不稳定。6. 训练过程中的典型故障与排查链路6.1 loss 不下降的四种可能原因loss 不下降是最常见的求助问题。排查顺序应该是先看数据再看配置再看代码最后看硬件。数据层面检查 label 是否正确对齐。如果 loss 计算包含了 user 部分模型会去拟合问题本身loss 可能下降但能力不涨。检查方法是打印几条样本的 input_ids 和 labels人工核对。配置层面检查学习率是否太小、优化器是否选错、warmup 是否过长。LoRA 场景下还要检查 target_modules 是否覆盖了关键层只调 bias 基本学不到东西。代码层面检查损失函数实现是否正确特别是自定义 loss 时容易出维度错误。硬件层面检查是否有 NaN 或 Inf通常是混合精度下的数值溢出可以尝试关掉 fp16 用 bf16。6.2 显存溢出的定位与缓解显存溢出OOM的定位方法是逐步缩小规模先把 batch size 降到 1如果还 OOM说明模型本身加载就超了如果能跑逐步加 batch size 找到边界。然后开启梯度检查点、优化器状态分片、LoRA 等省显存手段。我遇到过一个隐蔽的 OOM评测阶段加载了额外的模型导致显存不够。解决办法是把评测放到训练结束后单独跑或者用 CPU 做评测推理。Halo 的评测模块支持指定设备配置里写cpu就行慢但稳。6.3 模型输出退化的识别训练过程中模型输出退化表现为重复、格式混乱、拒绝回答。这通常是过拟合或数据污染的征兆。识别方法是定期用固定 prompt 集做生成测试人工看输出质量。如果发现退化先回退到上一个 checkpoint再检查最近加入的数据。有个经验训练 loss 持续下降但生成质量下降几乎可以断定是过拟合或数据问题。这时候不要继续训练停下来查数据。我见过太多人盯着 loss 曲线自我安慰最后得到一个“loss 很漂亮但没法用”的模型。7. 评测体系怎么搭才不流于形式7.1 自动指标和人工评估的分工自动指标如 BLEU、ROUGE、准确率适合快速筛选但不能替代人工评估。后训练的输出质量很多维度是自动指标测不出来的比如有用性、安全性、语气恰当性。我的分工是自动指标用于训练过程中的高频监控每 N 步跑一次看趋势人工评估用于关键 checkpoint 的深度检查每个阶段结束跑一次用固定评分表打分。评分表至少包含正确性、完整性、格式遵循、安全性四个维度每维度 1-5 分。7.2 评测集构造的注意事项评测集要满足三个条件覆盖主要任务类型、包含边界情况、和训练数据不重叠。第三点最容易被忽视。如果评测样本在训练集里出现过指标会虚高失去参考价值。构造方法上我建议从真实业务需求出发每个任务类型写 20-30 条边界情况单独列一类。评测集一旦定下来就冻结不要因为模型表现不好就改评测集那是自欺欺人。7.3 用评测结果反推训练策略评测结果的价值在于指导下一步动作。如果格式遵循差回去加强格式数据的配比和格式校验如果事实性错误多检查训练数据里的事实准确性如果拒绝回答过多检查安全对齐数据是否过度。我习惯把每次训练的配置和评测结果记在一个表格里形成实验台账。这样当你想复现某个好结果时有据可查当你想知道某个改动有没有用时有对比基准。8. 一些不那么显然的经验最后分享几个我在后训练实践中攒下的、文档里不会写的体会。第一小模型先验证流程。在 7B 上跑通全流程再上大模型能省下大量调试时间。大模型一次实验几小时小模型几十分钟迭代效率差一个数量级。第二checkpoint 管理要自动化。手动保存容易漏我一般配置成每 N 步自动保存同时保留最近 K 个和最佳指标对应的那个。磁盘空间要提前规划后训练 checkpoint 很占地方。第三不要迷信单一指标。任何单一指标都可以被“刷”多指标交叉验证才能反映真实能力。我见过模型在某个基准上涨了 10 个点但换个问法就露馅说明是过拟合基准而非真正提升。第四数据版本要可追溯。每次训练用的数据打上版本号记录来源、处理脚本、过滤规则。当模型出问题时能快速定位是哪批数据引入的。第五留出“什么都不做”的基线。基座模型不经过任何后训练在评测集上的表现是多少这个数字必须知道。否则你无法判断后训练到底带来了多少增益可能忙活半天还不如原模型。Halo 这个框架目前还在快速迭代接口和配置可能会变。我的建议是把它当成一个可参考的后训练工程实践理解它的设计思路比死记它的命令更有价值。后训练的核心竞争力永远在数据和对齐策略上框架只是帮你把这些想法落地的工具。工具会换思路不会。