1. 大模型全链路任务平台化拆解大模型从预训练到最终上线中间要经过微调、对齐、蒸馏、剪枝、量化、安全评估等一长串环节。单独跑通其中任何一环都不算太难难的是把它们串成一条稳定、可复现、可交接的流水线。我见过太多团队微调脚本散落在几个人的本地目录里量化参数靠口口相传安全评估报告是上线前临时补的——这种状态下模型迭代一次就要重新踩一遍坑。CubeStudio 这类平台的价值就在于把这条链路收敛成任务模板每个环节是一个可配置的任务输入输出通过平台的数据集和模型仓库衔接参数以表单形式固化下来。LLaMA-Factory 作为微调与对齐的执行引擎负责 SFT、PPO、Reward Model 这些训练任务蒸馏、剪枝、量化、安全评估则各自作为独立任务挂在链路上。整套东西跑下来你得到的不只是一个模型文件而是一条能反复执行的产线。这篇文章面向的是已经跑通过单点微调、但被多环节拼接折磨过的工程师。如果你还在纠结 LoRA 的 rank 怎么设建议先把单任务跑顺再回来。下面我按整体设计—核心细节—实操流程—问题排查的顺序把这条链路拆开讲参数和踩坑点都会给到。2. 整体链路设计与方案选型考量2.1 为什么用任务模板而不是脚本堆叠脚本堆叠最直接的问题是不可复现。同一个人隔两周跑同一个脚本环境变量、依赖版本、数据路径稍有变化结果就可能对不上。任务模板把这层不确定性收掉了镜像固定、依赖固定、参数以结构化配置存储每次执行都是一次干净的容器启动。另一个考量是交接成本。大模型项目的人员流动很常见一个微调任务如果只有原作者能跑那它本质上是个黑盒。模板化之后新同事看到的是输入数据集 参数表单 输出路径不需要读懂几百行训练脚本就能接手。这一点在需要频繁做 A/B 实验的场景下尤其重要。从资源角度看模板还方便做队列管理。训练任务吃 GPU、量化任务可能只需要 CPU 或少量显存、安全评估往往是推理密集型把它们统一挂在平台上调度器能按资源需求排队避免有人占着八卡机器跑一个只需要单卡的评估任务。2.2 LLaMA-Factory 作为训练引擎的取舍选 LLaMA-Factory 而不是自己写训练循环核心原因是它把 SFT、PPO、DPO、Reward Model 这些对齐范式都封装好了且对主流模型结构的适配比较全。自己写的话光是 PPO 里的 rollout、advantage 计算、KL 惩罚这几块就够调一阵子而且很容易在细节上和论文实现产生偏差。LLaMA-Factory 的配置以 YAML 为主这带来一个好处平台的任务模板可以直接把 YAML 作为参数载体前端表单填完生成 YAML后端拉起训练。坏处是 YAML 字段多容易填错所以模板里通常会把常用字段做成下拉选项冷门字段才放开手填。需要提醒的是LLaMA-Factory 版本迭代较快不同版本间配置字段可能有增减。平台镜像里锁定的版本要和文档对应否则会出现照着文档填却报未知参数的情况。我一般会在模板里显式记录引擎版本号方便回溯。2.3 蒸馏、剪枝、量化的定位差异这三个环节经常被混为一谈其实目标完全不同。蒸馏是让小模型学大模型的输出分布改变的是模型结构和参数量剪枝是去掉冗余权重或结构也是在改结构量化是把浮点权重压成低比特表示结构基本不变变的是数值精度。顺序上常见做法是先蒸馏得到一个更小的模型再剪枝进一步压缩最后量化降低部署成本。但这不是铁律——如果目标只是部署加速直接对原模型做量化往往就够了没必要绕蒸馏和剪枝。反过来如果目标是极致压缩那蒸馏和剪枝的收益会比单纯量化大。量化这块要特别注意int8 量化相对成熟精度损失通常可控更低比特如 int4在部分模型上会出现明显的能力下降尤其是长文本推理和数学能力。所以量化后必须做评估不能只看文件大小。2.4 安全评估为什么不能省安全评估在很多团队里是上线前补一下的角色但从工程角度它应该是链路的一环。原因很简单微调和量化都可能改变模型的行为边界。微调数据里如果混入了不当内容模型可能学会新的不良输出模式量化带来的数值扰动有时会让原本被抑制的输出重新冒出来。把安全评估做成模板任务好处是每次模型产出后自动触发评估结果作为是否进入下一环节的门禁。评估集要覆盖几类典型风险场景指标上不只看拒答率还要看误拒率——一个什么都不敢答的模型安全是安全了但没用。3. 核心环节的细节与实操要点3.1 SFT 任务的关键参数SFT 是整条链路的起点它的质量直接决定后续对齐的天花板。数据格式上LLaMA-Factory 支持 alpaca 和 sharegpt 两种主流格式选哪种取决于你的数据来源。alpaca 格式是 instruction/input/output 三段式适合单轮指令sharegpt 是多轮对话的 messages 列表适合对话数据。关键参数里cutoff_len决定单条样本的最大长度设太小会截断长样本设太大浪费显存。我的经验是先统计数据集的长度分布取覆盖 95% 样本的那个长度值再往上留一点余量。learning_rate对 LoRA 微调通常在 1e-4 到 5e-5 之间全参微调要更低1e-5 量级。lora_rank常用 8 或 16rank 越大表达能力越强但显存占用也越高任务简单时 8 就够。注意SFT 阶段如果用了 packing把多条短样本拼成一条长样本要确认你的数据里没有需要严格隔离的样本否则拼接后可能引入跨样本的注意力污染。3.2 PPO 与 Reward Model 的配合PPO 是强化学习对齐里最经典也最难调的一环。它需要四个模型同时在显存里策略模型、参考模型、奖励模型、价值模型。显存压力大是常态实践中常用 LoRA 来降低策略模型和参考模型的开销奖励模型和价值模型则视规模决定是否量化。Reward Model 通常先用偏好数据单独训练训练目标和二分类类似输出一个标量分数。PPO 阶段用这个分数作为奖励信号同时用 KL 散度约束策略模型不要偏离参考模型太远。KL 系数设太小模型会为了刷分而输出奇怪内容设太大又学不动。常见起点是 0.01 到 0.1 之间需要根据实际训练曲线调。PPO 的 rollout 阶段很吃时间batch_size和mini_batch_size的配比会影响训练稳定性。我一般让 mini_batch 是 batch 的 1/4 到 1/8太小会导致梯度噪声大太大则失去 mini-batch 的意义。3.3 蒸馏任务的温度与损失设计蒸馏的核心是让学生模型模仿教师模型的输出分布。温度参数 T 控制分布的平滑程度T1 时就是原始 softmaxT 越大分布越平滑学生能学到更多暗知识比如非最大类之间的相对关系。常见取值 2 到 5太高会让分布过于均匀反而丢失信息。损失函数通常是硬标签损失和软标签损失的加权和权重系数 α 控制两者比例。实践中 α 取 0.5 到 0.9 之间偏向软标签。如果学生和教师规模差距很大软标签的权重可以适当调高因为学生更需要教师的指导。蒸馏对数据的要求和 SFT 不同它不一定需要标注用教师模型对无标注数据做推理得到软标签即可。这在大规模场景下能省不少标注成本。3.4 剪枝的粒度选择剪枝分非结构化剪枝和结构化剪枝。非结构化剪枝按单个权重置零压缩率高但需要专门的稀疏计算库才能加速通用硬件上收益有限。结构化剪枝按通道、注意力头等结构单元裁剪能直接减小模型尺寸并加速但精度损失通常更大。实践中如果部署环境支持稀疏计算非结构化剪枝可以考虑否则优先结构化剪枝。剪枝后一般要做一轮轻量微调来恢复精度这一步不能省否则精度掉得很难看。剪枝率的选择要结合评估结果迭代。我一般从 10% 到 20% 开始试观察评估指标下降幅度如果下降在可接受范围内再往上加。一次性剪太多再想恢复代价很高。3.5 量化的精度与显存权衡int8 量化是当前最稳妥的选择多数模型精度损失在 1% 以内显存占用约为 fp16 的一半。int4 能进一步压缩但需要更精细的量化方案如分组量化、GPTQ 类方法且对校准数据敏感。量化校准集的选择很关键。校准集应该和实际推理场景的输入分布接近用一堆无关文本做校准量化后的表现可能和预期差很远。校准样本量通常几百到上千条就够太多收益递减。注意量化后的模型在长上下文场景下更容易出现精度退化如果你的应用涉及长文档处理量化后务必用长文本样本单独测一轮。3.6 安全评估的指标设计安全评估不能只看一个总分。我通常拆成几类有害内容拒答率、越狱攻击抵抗率、误拒率、以及特定领域的合规性。拒答率高不代表好如果误拒率也高说明模型过于保守。评估方式上规则匹配适合快速筛查明显问题模型打分适合判断语义层面的风险人工抽检用于校准前两者的准确性。三者结合比单用一种可靠。评估结果要留档和模型版本绑定。这样当线上出现问题时能快速定位是哪个版本的模型、经过了哪些处理环节。4. 平台实操流程与关键步骤4.1 环境与镜像准备在 CubeStudio 上跑这条链路第一步是确认镜像。训练类任务需要包含 LLaMA-Factory 及其依赖的镜像量化任务需要包含量化工具链如相关量化库的镜像评估任务需要推理框架。平台通常提供基础镜像团队可以在此基础上构建自己的镜像并推送到镜像仓库。镜像构建时要注意 CUDA 版本和驱动版本的匹配。训练镜像里 PyTorch 的 CUDA 版本要和宿主机驱动兼容否则会出现能启动但一跑就报错的情况。我一般会在镜像里加一个自检脚本启动时打印 CUDA、PyTorch、驱动版本方便排查。数据集和模型仓库要提前在平台上配置好访问路径。训练数据建议按任务分目录存放避免不同实验互相覆盖。模型输出路径也要规划好通常按任务名/日期/版本的层级组织。4.2 SFT 任务配置与执行创建 SFT 任务时选择 LLaMA-Factory 模板填写基础模型路径、数据集路径、输出路径。参数区里训练轮数、学习率、batch size、cutoff_len、LoRA 配置逐项填好。如果平台支持 YAML 预览执行前看一眼生成的配置确认没有字段被错误覆盖。启动后关注几个信号loss 曲线是否平稳下降、显存占用是否稳定、吞吐是否正常。loss 突然飙升通常是学习率过大或数据里有异常样本显存缓慢增长可能是数据加载或缓存的问题。训练完成后产物是 LoRA 适配器或合并后的完整模型。如果后续要做 PPO通常保留适配器形式更灵活如果直接部署合并成完整模型更方便。4.3 Reward Model 与 PPO 任务串联Reward Model 训练任务和 SFT 类似区别在数据格式是偏好对chosen/rejected损失函数不同。训练完成后模型路径作为 PPO 任务的输入之一。PPO 任务配置里要指定四个模型策略模型从 SFT 产物初始化、参考模型通常就是 SFT 产物、奖励模型上一步产物、价值模型可从策略模型初始化。参数上重点调 KL 系数、学习率、rollout 的 batch 配置。PPO 训练不稳定是常态我一般会先跑一个很小的步数看曲线确认奖励在涨、KL 没有爆炸再放开跑完整流程。如果 KL 迅速增大说明约束太松调大 KL 系数如果奖励几乎不动可能是学习率太小或奖励信号太弱。4.4 蒸馏与剪枝任务的衔接蒸馏任务需要教师模型和学生模型两个输入。教师模型通常是上一步对齐好的大模型学生模型是目标结构的小模型。配置里指定温度、损失权重、训练轮数。蒸馏完成后得到学生模型接着可以进入剪枝任务。剪枝任务配置里选剪枝方法结构化/非结构化、剪枝率、是否做恢复微调。剪枝后的模型建议单独评估一次确认精度在可接受范围。这里有个衔接细节剪枝后的恢复微调用的数据最好和蒸馏阶段的数据分布一致否则恢复效果会打折扣。4.5 量化任务的参数与校准量化任务输入是待量化模型输出是量化后的模型文件。配置里选量化位宽int8/int4、量化方法、校准数据集路径、校准样本数。校准数据集建议从实际业务数据里采样覆盖主要输入类型。校准样本数几百条起步如果发现量化后精度波动大可以增加样本数或调整采样策略。量化完成后用同一套评估集对比量化前后的指标。如果下降超过阈值考虑换量化方法或调整校准集。4.6 安全评估任务的触发与门禁安全评估任务配置里指定待评估模型、评估数据集、评估指标。评估数据集按风险类别组织每类有若干样本。评估任务可以作为独立任务手动触发也可以配置成流水线的门禁量化任务完成后自动触发评估评估通过才允许发布。门禁阈值根据业务容忍度设定比如有害内容拒答率不低于某个值、误拒率不高于某个值。评估报告要结构化存储包含模型版本、评估时间、各项指标、失败样本示例。失败样本尤其重要它是后续优化的直接线索。5. 常见问题与排查技巧实录5.1 训练类问题速查现象可能原因排查方向loss 不下降学习率过小、数据格式错误检查数据解析日志调大学习率试跑loss 震荡剧烈学习率过大、batch 过小降低学习率增大 batch显存 OOMcutoff_len 过大、batch 过大减小序列长度或 batch启用梯度累积训练速度异常慢数据加载瓶颈、未启用混合精度检查 dataloader 配置确认 fp16/bf16 开启PPO 奖励不涨KL 系数过大、奖励模型质量差调小 KL单独验证奖励模型5.2 量化后精度下降的排查量化后精度下降是最常见的问题。第一步先确认下降幅度是否在预期内——int8 通常 1% 以内int4 可能到几个百分点。如果超出预期先检查校准集是否和实际场景匹配不匹配的话换校准集重跑。如果校准集没问题考虑换量化方法。不同方法对同一模型的友好度不同有的模型对分组量化更敏感有的对逐通道量化更敏感。可以小规模对比几种方法再定。还有一种情况是量化本身没问题但评估方式有偏差。比如评估集里有大量长文本而量化对长文本的影响更大这时看到的下降其实是场景特异的不一定是量化方法的问题。5.3 蒸馏效果不佳的处理蒸馏后学生模型表现差先看教师模型的输出质量。如果教师本身在某些任务上就不行学生自然也学不到。其次看温度设置温度太低学生学不到暗知识太高则信息模糊。数据量也是因素。蒸馏虽然不需要标注但需要足够的无标注数据覆盖目标分布。数据太少学生只能学到很窄的能力。如果以上都排查过还是不行考虑学生模型容量是否太小。容量差距过大时蒸馏的收益会受限这时可能需要换一个稍大的学生模型。5.4 剪枝后恢复微调的技巧剪枝后恢复微调学习率要比原始训练小通常低一个数量级。因为剪枝已经破坏了部分权重结构大学习率会让模型震荡。恢复微调的轮数不用太多一两轮往往就够。轮数太多反而可能过拟合到恢复数据上。如果恢复后精度仍不理想可以尝试分阶段剪枝先剪一小部分恢复再剪一部分再恢复。渐进式剪枝比一次性剪到位更容易保住精度。5.5 平台层面的常见坑任务间数据传递是最容易出问题的地方。上游任务的输出路径如果没正确传给下游下游会读到旧数据或报路径不存在。建议在模板里把输入输出路径做成显式参数执行前核对。镜像版本不一致也会导致问题。训练用的镜像和量化用的镜像如果依赖版本冲突中间产物可能无法正确加载。团队内最好统一镜像基线。资源排队方面长任务容易阻塞短任务。可以把评估类短任务单独放一个队列避免被训练任务堵住。6. 一些实操心得跑这条链路有段时间了有几个体会比较深。一是别追求一次跑通全链路先把 SFT 和量化这两个最常用的环节跑顺再逐步加蒸馏、剪枝、PPO。全链路一起调出问题很难定位是哪个环节的锅。二是评估要贯穿始终不能等到最后。每个环节产出后都做一次轻量评估问题早发现早处理比最后发现精度崩了再回头找原因省事得多。三是参数要留痕。每次实验的配置、数据版本、评估结果都记下来哪怕当时觉得用不上。模型迭代几轮之后回头看这些记录能省很多重复劳动。四是安全评估别当负担。把它做成自动触发的门禁反而比人工把关更省心也更不容易漏。这条链路本身还在演进量化方法、对齐范式都在更新。平台化的好处是底层方法换了只要模板接口不变上层流程不用大改。这大概是我最看重的一点。