1. 为什么最终都得回到“一站式流程”上1.1 做交付时遇到的第一堵墙碎我把一段完整的大模型交付拆开看通常会有这么几件事选底座模型、准备数据、跑 SFT、做 reward model、再上 PPO/DPO模型效果不达标就回头补数据达标后又发现部署资源不够于是要蒸馏、剪枝、量化最后还要过安全评估看有没有泄露、偏见、幻觉和毒性内容。每一步单拎出来都有现成开源工具能跑比如买 LLaMA-Factory 做微调用 Transformers 加载模型用 perplexity 脚本或 OpenCompass 做评测。但把这些串起来问题就来了环境依赖冲突、权重产物格式不统一、训练服务和评估服务之间传数据靠拷贝、参数没有版本记录。大多数人第一次完整跑通一个“能上线的小模型”不是死在训练上而是死在无聊的搬家问题上。1.2 模板化解决的不只是“少点几下”一站式模板真正的价值是把所有不变量固定住。模型路径、tokenizer、对话模板、训练阶段、评估基准、量化校准集这些在普通脚本里都是散着写的Excel说明。换个人就跑不出来。平台模板则把整条链做成一张固定图你只需要改有限几个变量比如数据集、基础模型、训练轮数、量化比特数。这带来的三个能力是普通脚本没有的一是可复现同一个模板参数跑两次结果基本一致二是可回退跑完几个阶段后如果发现 reward model 崩了可以直接切到上一次成功产出的 checkpoint三是可灰度不同参数分支可以并行跑成多条线而不是靠本地 Git 分支手动管理。1.3 CubeStudio 的大模型任务模板到底长什么样CubeStudio 这类 AI 平台里大模型任务模板一般会按“数据入站 - 训练 - 后处理 - 评估 - 部署产物”来做节点。以 LLaMA-Factory 模板为例你在界面上看到的几乎就是一条流水线数据节点指向一个我们上传的 JSONL 文件训练节点选择 stage也就是 SFT、reward、PPO训练完的 LoRA adapter 会有一个合并导出节点把 adapter 合回完整权重合并之后可以接蒸馏、剪枝、量化节点也可以直接接评估。通常每个节点可以单选跳过。这个设计思路跟 CI/CD 很像。一个模板不是“把命令包进去就完事”而是一个带状态的执行环境上一节点的输出路径自动变成下一节点的输入路径中间产物全部被平台登记在模型仓库里。你可以随时从仓库拉出某个阶段的模型去验证这是手工脚本最难做到的。2. 用 LLaMA-Factory 模板跑通 SFT、reward、PPO2.1 模板里到底内置了哪些训练能力LLaMA-Factory 最有价值的一点是不只支持 SFT还覆盖了大部分主流对齐技术pre-training、SFT、reward modeling、DPO、PPO、KTO、ORPO。放到 CubeStudio 里它就是做对齐阶段的主力。模板界面中一般会有一个 stage 下拉框选择不同 stage 时参数面板会变化。数据格式也跟着变。比如说阶段选sft数据格式走 Alpaca 或 ShareGPT 风格阶段选rm数据格式就需要 chosen / rejected阶段选ppo需要同时配置 reward model、reference model 和 actor 三套模型路径。这种设计非常符合实际工作流因为很多人不是只会 SFT。跑完 SFT 觉得指令遵循上来了但模型会变得“嘴碎”这时最好补偏好对齐。模板把这条路铺好而不是让你去另一套工具里重新配环境。2.2 SFT 不是丢进去训练那么简单我第一次用模板跑 SFT 时以为参数照着 demo 填就行结果训练曲线看着正常模型一开口就是胡话。后来发现是对话模板没对上模型类型选的是 base但我用的数据是 instruction 风格。这类问题在平台模板里同样存在只是它把template参数做成了可见项会提醒你选qwen、llama、chatglm等对应值。建议跑 SFT 前先抽一条训练样本用模板的推断功能看 tokenizer 到底还原成了什么。SFT 参数上我固定用这样一组底子基座Qwen2.5-7B-Instruct训练方式LoRArank 32alpha 64dropout 0.05learning rate2e-5per-device batch size8梯度累计 8max length2048epoch3batch size 和 max length 是显存占用的大头。如果 OOM优先把 per-device batch size 降到 4而不是去调低 max length因为长度影响模型对长上下文的感知能力。模板里通常也有显存预估但你心里要有数7B 模型用 LoRA一张 24G 卡跑 batch 8 比较紧32G 卡才舒服。训练完别直接拿去部署先看 eval loss 和生成样例。平台模板一般支持一个小样本采样推理这一步要多用因为它比指标更快告诉你模型歪没歪。2.3 reward model数据设计比模型架构更重要reward model 在模板里通常表现为“偏好数据格式 reward 训练参数”。这里有个常见误区把 reward model 当作普通分类模型给两个答案各标一个分。实际推荐是用 pair 数据做对比式学习输入是同一个 prompt 下的两个回答模型要学习哪个更符合预期。数据格式基本长这样{ prompt: 写一段产品介绍, chosen: 我们这款产品..., rejected: 这个嘛...产品还行 }选择越明显模型学得越快。如果 chosen/rejected 质量差别很小reward model 会学出一堆噪声。常用损失包括 pairwise ranking loss 和 policy-based 的 preference loss。在 LLaMA-Factory 模板里我习惯把 lr 调低到 1e-5max_length 保持 2048epoch 控制在 2-3 之间。reward model 很容易过拟合一旦 loss 降得很快但验证集连续性很差就要停。模板里可以配置 early stop 的 patience 参数这不是为了省时间是为了保住泛化能力。2.4 PPO 难调但模板让每一步都可回滚PPO 是 Stitch 里最敏感的一个阶段因为它不是单模型训练而是 actor、reference、reward、critic/advantage 一起转。很多人失败在 reward 信号不稳定前期 reward 值一路涨后期突然崩策略网络也跟着炸。模板的价值在于它把 reference model 和 reward model 作为独立节点锁住你可以先冻结它们只让 actor 更新这样出现问题就能定位是哪一侧出了问题。推荐参数范围rl_learning_rate5e-6 起千万别直接用 SFT 的 2e-5kl_penaltyfullkl 系数 scale_coeff0.05ppo epochs内层 2外层 1batch size512 条 trajectory 起步显存不够就靠模板的 accumulate 机制撑另外如果你的迭代节奏比较紧建议直接用 DPO 阶段替代 PPODPO 不需要单独的 reward model训练稳定度要高不少。模板里这两个 stage 都有选型成本很低。3. 蒸馏、剪枝、量化之间是组合关系不是互斥3.1 压缩阶段的顺序怎么定很多人把蒸馏、剪枝、量化当成等价方案其实它们的目的是完全不同的蒸馏降参数量级。把 30B 教师压缩到 7B 学生是“换一个更小的学生”。剪枝结构稀疏化。把 7B 里冗余 head、通道删除但概率结构可能变稀疏。量化降精度。把 FP16 权重变成 INT8/INT4压缩显存占用和推理带宽。如果目标是极致压缩标准顺序是先蒸馏出一个学生模型再做剪枝最后做量化。剪枝之后一般还要快速微调恢复一下所以模板里通常会把“pruning - sft_resume”设计成一对节点。量化永远放最后因为量化会引入噪声先量化再微调会让所有参数的误差分布偏离后患无穷。3.2 蒸馏怎么挑学生模型和散失函数在 CubeStudio 模板里选择蒸馏节点其实就是在设置一个“教师到学生”的对齐过程。学生模型通常选同生态的中小尺寸底座比如教师是 Qwen2.5-14B学生选 Qwen2.5-7B 或者 1.5B。蒸馏的 loss 不能只看学生跑得对不对要看它对教师 logits 的分布拟合程度。训练用的核心参数是温度 t 和蒸馏损失权重 alphat 越大教师概率分布越平滑学生能学到类别间关系而不是纯硬标签一般从 3 到 8 试我常用 6。alpha 控制在 0.5 到 0.7 之间过小等于没有蒸馏过大则学生容易被教师的软标签牵着走反而忽略真实答案。还有一个容易被忽略的点教师模型跟学生模型的解码器要兼容否则 tokenizer 都不统一logits 位置根本对不上。模板会在选择节点时做 tokenizer 匹配校验但自建流程里我踩过太多次坑还是提醒一句别只看模型家族相同就以为 tokenizer 一致。3.3 剪枝结构化与非结构化在工程上是两回事模板里会分structured pruning和unstructured pruning。我强烈建议生产环境选结构化剪枝因为它才能真正减少矩阵维度提高推理速度。非结构化剪枝虽然能保住更多精度但稀疏权重在 GPU 上需要特殊算子普通框架加载后不仅不变快甚至更慢。剪枝比率我先从 20% 试起然后在评估节点对比困惑度和下游 benchmark 的差异。如果掉点很大就回退到 10%。这里我想强调剪枝节点和定量评估的交互剪完以后不是结束了要接一个评估节点至少要跑 perplexity 和一个 core task。平台模板一般会内置几个任务你要是只用 loss 判断效果会漏掉模型在特定能力上的局部崩坏。3.4 量化INT8、INT4 和校准集的真实经验量化是大家最熟的词也是翻车率最高的节点。模板里通常会提供 GPTQ、AWQ、round-to-nearest 和 FP8 动态量化几种算法。我先讲参数上最关键的校准集。很多人直接拿训练集抽样去校准这是错的。校准数据应来自部署回流或者至少是相似的、含真实分布的数据。我习惯采集 128 到 256 条样本覆盖系统提示、多轮、代码、数学、安全敏感指令跑 10-30 分钟完成校准。然后说精度选择INT8 对推理显存压缩有限但精度损失很小适合快速验证链路是否通。INT4 能压到约四分之一适合最终部署但要非常小心。如果模板支持 AWQ我会优先选 AWQ因为它对激活值异常值做了保护性缩放比直接 round-to-nearest 稳得多。量化和训练一样要跑“前评估 - 后评估”指标对比不能只看生成对不对还要监控 token 概率分布变化。有一个平台模板通常不会提醒你的事量化的计算结果与 GPU 架构相关。同一个 INT4 模型在 A100 和 L40S 上的推理延迟差距很大量化节点完成后记下目标设备的计算版本不然换卡后又得重新量化一遍。4. 从零到上线一次完整的模板实操路径4.1 初始准备数据、基座、资源配置假设我要做一个客服助手兼内容安全助手基座选 Qwen2.5-7B-Instruct。准备三批数据SFT 数据约 10 万条单轮指令含业务场景、客服问答、拒绝无效请求。偏好数据约 1 万条 chosen/rejected重点覆盖安全话题和置信度表达。校准数据约 256 条真实对话头用于后续量化。基座模型上传到平台模型仓库后在模板里把它设为初始模型。资源配置建议SFT 和 RM 阶段用 2 张 32G 卡PPO 阶段用 4 张 32G 卡。平台模板会按阶段拆分资源需求这个拆分不是摆设不同阶段模型体积、优化器状态、RL buffer 占用差别很大匀着用反而浪费。4.2 创建 SFT 任务参数化配置表参考配置如下参数值备注stagesftmodel_name_or_pathQwen2.5-7B-Instruct平台选择datasetcustom_sft:100k平台内数据对象templateqwen与基座匹配finetuning_typeloralora_rank32lora_alpha64learning_rate2e-5num_train_epochs3per_device_train_batch_size8gradient_accumulation_steps8max_length2048任务跑完模板会在导出节点把 LoRA 合回完整权重。合并完记得做一次烟测跑 10 个测试 prompt检查 tokenizer 是否正常、输出是否包含对话模板残留。这一步在模板里虽然可以跳过但我建议把这条烟测作为固定动作因为 adapter 合并失败的案例我见得太多了。4.3 从 SFT 往前推进reward 和 PPO如果 SFT 模型基本不胡说但风格不稳可以直接跑 reward model 训练。RM 参数我固定一下stage: rm model_name_or_path: SFT导出路径 pref_beta: 0.1 learning_rate: 1e-5 max_length: 2048 num_train_epochs: 2RM 训练完成后再接 PPOstage: ppo actor: SFT导出路径 reward_model: RM训练输出 ref_model: 原始基座模型 rl_learning_rate: 5e-6 kl_penalty: full scale_coeff: 0.05 num_train_epochs: 1这里最关键的是 actor 初始权重。我习惯用 SFT 后导出模型而不是继续用 LoRA checkpoint避免 PPO 过程在低秩空间里被 adapter 结构限制住。每个 PPO 阶段结束时模板会自动保存 actor 和 critic 两份权重如果 reward 曲线出现下滑直接对比 actor 0 和 actor N 的生成结果看是 reward hacking 还是分布漂移。4.4 把蒸馏、剪枝和量化串起来跑效果稳定后进入压缩链路蒸馏节点教师选调优后的 Qwen2.5-7B-Instruct学生选 Qwen2.5-1.5B-Instruct温度 6alpha 0.7。剪枝节点对学生 1.5B 做结构化剪枝剪枝率 20%剪完接一个少量数据的恢复训练lr 1e-5500 步。量化节点对剪枝后模型做 AWQ INT4校准集放之前留的 256 条真实对话数据。为什么不把大模型直接量化成 INT4 交付因为如果目标是降低服务成本7B 降到 INT4 依然比 1.5B FP16 重。只有先让模型本身变“小”量化才有意义。模板允许我把蒸馏、剪枝、量化三个节点分别开关这样我能在同一条链上对比“7B INT4”和“1.5B INT4”两套产物直接看服务成本差距。4.5 评估与安全评估最后一个节点不是走形式平台模板的评估节点通常接 OpenCompass 或内置评估器。我要跑两类一类是常规能力比如通用问答、代码生成、数学推理另一类是安全相关包括 prompt 注入、偏见表达、人格分裂、权威诱导。安全评估里我最看重“拒答率”和“和谐率”该答不答、明显迎合有害提问这两种模型都不能上线。安全评估的数据集不直接塞进训练模板因为它是评估专用格式和训练样本有本质区别。模板里会有独立安全评估任务输出结果一般带分层报告给出风险类别和样本示例。这块在自建脚本里做起来很零碎放在平台上有审核记录方便后续追溯。5. 常见问题与排查实录5.1 问题速查表现象可能原因实操处理训练到一半显存 OOMbatch 太大或 KV cache 占用过高调降 batch或把 max_length 减到 1536优先保 batchSFT 生成带模板标记template 参数选错用模板的 sample 推理还原 tokenizer 文本确认特殊 tokenRM 训练 loss 下降快但蓝到不举偏好数据质量不足筛选 chosen/rejected 看阈值明显性删除模糊对PPO reward 后半程崩KL 惩罚太弱scale_coeff 从 0.05 升到 0.1剪枝后回答变短剪枝率过高降 20% 到 10%并接恢复训练量化后生成明显退化校准集和真实数据偏移重新采集校准样本替换成线上真实对话合并 adapter 后输出乱base model 路径不对确认 merge 时用的 base model 必须是训练前的原版权重模型评估整体分低模板里评估配置用了默认题集换与业务场景匹配的任务集再做分层对比5.2 量化后指标下降别急着归因到量化我在实际使用中经常遇到一个情况量化后模型指标掉量化不是主因而是一个前面的错误被放大了。比如剪枝已让模型表达力受损失再量化一次误差叠加崩得特别明显。处理思路是把压缩链路拆开单独验证先量化不剪枝跑一遍如果掉点更小那问题就在剪枝恢复阶段。模板的节点开关非常适合做这种“控制变量”实验。我建议每个人都养一个习惯每个节点的产物都登记在模型仓库里评估结果对应到产物 ID后续复盘时一眼就能看到哪一步丢的分最多。5.3 模板不是黑盒参数要学会“反推”很多人把模板当作黑盒填完参数就等结果这样就失去了模板最大的价值。模板真正好用的是它的状态记录每个节点跑的日志、超参数、数据版本都可追溯。反推逻辑应该是先定目标指标比如推理延迟 30ms、显存占用小于 8G再反推需要多大模型、需要多少压缩最后反向配置蒸馏和量化参数。不是先在模板里调一堆参数看效果而是先设目标。这样你的模板配置不再是一堆数字而是有明确含义的工程决策。5.4 一点个人提醒我刚开始用这类一站式模板时生怕配置不够先进总想着把蒸馏、剪枝、量化一口气全上。后来踩过几次坑发现最稳的路线是先只跑“SFT INT4 量化”把整条生产链路跑通再逐步加入蒸馏和剪枝。因为全链路压缩一旦出问题你不知道是该调蒸馏温度还是该调剪枝比例排查成本很高。先把最基础的产品闭环走完后面的优化每次只动一个变量所有实验才能拿到干净结论。这也是模板设计成可分支、可回滚的原因。模型上线之后这条模板链不会用完就删它变成了一种资产。下次再接新任务时你只需要改数据集和基座其他流程原样复用。整个过程最省时间的其实不是少写那几个脚本而是你不用在每一个环节都重新试错一遍。