企业官网建设流程全解析

把“大模型开发”从基座模型一路推到可交付的推理服务，里面卡着微调、对齐、压缩、评估、安全这几道工序。以前这些工序分散在几个人的脚本里，训练环境偶尔冲突、数据格式全靠口头对齐，一个项目跑到后期，每个人都有一份“自己的版本”。CubeStudio 这类大模型平台的出现，把这条链路做成了任务模板：LLaMA-Factory 的 SFT、reward、PPO，再加上蒸馏、剪枝、量化、安全评估、OpenCompass 能力评测，在一个项目里串起来跑。这篇文章我按自己的实操记录，把每个模板在做什么、关键参数怎么配、哪些坑必须躲开，完整拆给你看。适合正在做大模型交付、刚接触 RLHF 和模型压缩、或者想给团队搭一套固定训练流程的算法同学。

1. 为什么需要“一站式”模板：大模型生产的完整链路拆解

1.1 从基座模型到可交付产品到底要过多少关

基座模型出厂时只具备“续写”能力，要真正变成可用产品，通常得经过这样一条链路：先在高质量指令数据上做 SFT，让模型学会“回答问题”；然后训练一个 Reward Model 来给回答打分；再用 PPO 或 DPO 做对齐，让模型的输出更符合人类偏好；接着为了控制部署成本和推理延迟，还要做蒸馏、剪枝、量化等压缩操作；最后用安全评估和 OpenCompass 跑一轮全面评测，确认模型能上线。

问题在于，这条链路的每一个节点都对应一套独立的开源工具和一套独立的环境依赖。SFT 用 transformers+peft+trl 的组合，量化又可能要装 GPTQ 或 AWQ 的库，评估脚本要拉 OpenCompass 的配置。如果每个步骤都手工搭环境、手工传数据，麻烦的是“状态一致性”：SFT 产出的 checkpoint 到 reward 训练时因为代码版本不一致而报错，reward 模型的输出格式又和 PPO 的 reward 计算对不上，这些情况在实际项目中太常见了。

1.2 模板化封装解决了团队协作里的三个核心问题

CubeStudio 的做法，是把 LLaMA-Factory 这类已经在社区里验证过的训练框架，封装成可视化任务模板。你不需要自己写训练脚本，端到端的流程也被拆成了块，配置哪个模型、用哪份数据、调哪些超参数，都像填表一样清晰。

这解决了我最头疼的三个问题。第一是复现性，模板把训练参数、依赖版本、启动命令全部固化，任何人跑同一个模板拿到的是同样的实验环境和同样的日志格式，不再出现“我本地能跑但你那边报错”。第二是状态追踪，SFT 的 checkpoint 自动登记到平台上的模型仓库，reward、PPO 直接从模型仓库拉取产物，链路中每个节点输入输出都有记录，实验对比时能清楚看到是哪一步导致的差异。第三是流水线编排，蒸馏、剪枝、量化这些操作可以挂到同一条流水线里顺序执行，前一步的结果自动成为下一步的输入，不需要人工来回搬运权重文件。

2. 核心任务逐个拆解：每个模板到底在做什么

2.1 SFT 监督微调模板：把“会聊天”变成“会干活”

SFT 是整条链路的起点。基座模型在预训练阶段学到的只是语言统计规律，给它一段指令，它更倾向于“接着往下写”而不是“认真回答问题”。SFT 的目的，就是拿一批精心整理的“指令-回答”对，用监督学习做一轮微调，让模型学会在给定指令时输出有用、格式正确的回答。

LLaMA-Factory 里的 SFT 模板支持全参微调和 LoRA/QLoRA。我的经验是，在 7B 级别以上的模型上，LoRA 是性价比最优的方案：显存占用小、训练速度快、效果和全参微调差距通常在一个点以内。LoRA 的核心是在冻结原模型权重的同时，注入低秩的旁路矩阵做训练。直观理解就是，原模型的大规模参数保持不变，只训练一对小矩阵来“增量修正”权重，训练完成后把这两个矩阵合并回原模型。

数据格式上，LLaMA-Factory 的 SFT 模板默认支持 Alpaca 格式，每条样本是一个 JSON，包含instruction、input、output三个字段：

{ "instruction": "请把下面这句话翻译成英文", "input": "今天的天气很好", "output": "The weather is nice today." }

实际项目中我还有两个补充建议。一条是样本里不要只放高质量回答，最好混合一些正常的拒绝语句，避免模型在 SFT 阶段就学会“什么都答应”。另一条是instruction和input的分工要明确，如果有额外上下文就放input，纯口语问答场景留空即可。数据不干净，后续 reward 和 PPO 都会跟着受影响，这一点怎么强调都不为过。

2.2 Reward Model 奖励模型模板：给模型一个“人类偏好标尺”

SFT 之后，模型已经会作答，但答得好不好未必符合人的主观偏好。Reward Model 就是训练一个打分器，输入 prompt 和模型回答，输出一个标量分数，分数越高代表这个回答越符合人类偏好。

LLaMA-Factory 的 reward model 模板用的是 Bradley-Terry 排序模型，训练数据是成对的chosen和rejected回答。模板界面里需要选两份数据，或者在同一份数据里按字段区分好回答和差回答：

{ "prompt": "如何快速学习一门新编程语言？", "chosen": "先确定目标，然后按官方文档搭建环境，做一个小项目驱动学习……", "rejected": "学语言嘛，背语法就行，多背几遍就自然会了。" }

训练时，模型同时看到两个回答，目标是让chosen的得分比rejected高。这个任务的难度在于数据标注质量。实际项目里标注员经常把“内容更全面”当作唯一标准，而忽略“表达简洁”“语气友好”等维度，这会让 RM 模型学到单一的判断逻辑。我们做中文客服场景时，专门定义了五个评价维度，让标注员逐项打分后再合成排序，reward 模型的准确率明显比直接“选一个更好的”要高。

2.3 PPO 任务模板：用强化学习让模型贴住“人类偏好”

有了 reward 模型，就可以把策略模型（也就是经过 SFT 的基座）和奖励信号对接起来，用强化学习进一步优化。PPO 是这里最经典的算法，如果你之前接触过 SAC、CQL、IQL 这类强化学习算法，理解 PPO 会很快：它在每一轮迭代里采样一些动作（生成回答），用 reward 模型评估这些动作的好坏，然后让策略往“高奖励”的方向更新。

在 LLM 场景下，PPO 的完整结构包含四个模型：Actor是被训练的生成模型，Ref Model是训练前冻结的参考模型，Reward Model负责打分，Critic负责估计状态价值。训练时，Actor 对同一个 prompt 生成回答，Reward Model 打分，Critic 估计基准值，两者相减得到 advantage；同时 Actor 的输出要和 Ref Model 的输出计算 KL 散度，把“偏离原始模型太远”作为惩罚项加进损失。这样做是为了防止模型在追求高奖励的过程中输出乱码、重复或脱离人类语言的“奖励黑客”内容。

LLaMA-Factory 的 PPO 模板支持经典 PPO 流程，关键参数有 KL 系数、奖励归一化开关、mini-batch 大小。我的经验是一开始 KL 系数不要调太大，0.01~0.1 之间通常都比较安全；reward 一定要做 whiten（标准化），否则 reward 数值尺度在不同训练阶段变化太大，advantage 会不稳定。观察到 reward 上升、KL 也在合理范围内就是健康的；如果 reward 忽高忽低、KL 快速飙升，说明系数过大或 reward 模型本身有噪声，先降 KL 系数，再检查 reward 数据。

一个经常被忽视的点是：PPO 是一种 on-policy 算法，每一轮迭代生成的样本只用一次就丢。这意味着同样的数据量下，PPO 比 SFT 慢得多，数据利用率也低。如果你的数据本身就包含大量偏好对，用 DPO 这类 off-policy 算法会更省资源。但如果目标是让模型在开放对话中的表现持续贴合用户反馈，且你有能力维护一个实时更新的 reward 模型，PPO 的上限通常更高。两者不是替代关系，而是取决于你手里有什么数据和多少算力。

2.4 蒸馏、剪枝、量化：把模型“做小做快”且不掉点

训练完的大模型体积动辄十几 GB 甚至上百 GB，直接部署不现实。压缩环节有三个模板，分别解决不同问题。

蒸馏的目标是把一个大模型（teacher）学到的能力迁移到一个小模型（student）上。常见做法有两种：一是软标签蒸馏，把 teacher 在任务上的概率输出当作软标签喂给 student 训练；二是特征蒸馏，让 student 模仿 teacher 中间层的表征。LLaMA-Factory 的蒸馏模板通常基于 logits 层面的 KL 散度损失。实操中要控制 teacher 和 student 的能力差距，如果差距太大，student 根本学不到像样的分布，loss 降了但下游任务效果提升有限。一个简单的冲量测试：先用相同数据把小模型单独做 SFT，如果任务分数离 teacher 很远，说明蒸馏之外还得补数据。

剪枝负责把模型结构里的冗余参数删掉。结构化剪枝会直接去掉某些注意力头或前馈网络层，推理时能真实降低显存和速度；非结构化剪枝则是把权重矩阵中接近 0 的元素置零，压缩率虽高但很难换来推理加速。LLaMA-Factory 的剪枝模板常用非结构化方法，类似 SparseGPT 或 Wanda 的思路，按重要性分数裁剪权重。在模板里需要指定稀疏度，我的建议是从 20%~30% 起步，剪完立刻接一小段蒸馏或 SFT 做恢复，否则精度会掉得很难看。

量化是把模型权重从高精度浮点数压到低比特整数。主流方案有 GPTQ、AWQ、bitsandbytes 等，4bit 量化在 7B 模型上可以把显存压到原来的四分之一左右。LLaMA-Factory 集成了这类模板，通常需要提供一小批校准数据（几百条就够了），让算法在压缩时参照真实数据分布来减小误差。注意：量化之后的模型最好跑一遍任务评测，不要只看 PPL（困惑度），因为 PPL 微小变化在推理任务上可能被放大。我们之前量化一个代码模型，PPL 只涨了 0.1，但 HumanEval 分数掉了 6 个点，这种误差都要通过评测数据来发现。

2.5 安全评估与 OpenCompass 评估：不能只跑通，还要知道“行不行”

模型压缩和训练都完成之后，至少要跑两类评测模板。

安全评估模板检查的是模型会不会输出有害内容、会不会被越狱提示词诱导、会不会泄露训练数据里的隐私信息。平台一般内置了红队测试提示词集，你需要配置评估维度，比如“拒绝有害请求的比例”“违规输出比例”等。实际操作中，通用安全基准只能作为底线，还是要准备跟业务场景强相关的安全测试集：电商客服领域要重点测“退款诈骗诱导”，教育领域要重点测“暴力内容伪装成文学创作”，这些长尾风险通用模板覆盖不到。

OpenCompass 能力评估模板则是用统一工具跑客观和主观评测。客观指标如 MMLU（通用知识）、C-Eval（中文能力）、GSM8K（数学推理）、HumanEval（代码生成）、BBH（复杂推理），主观指标则有基于规则或模型裁判的打分。评估时我强烈建议固定 baseline：同一个模型在模板里跑 SFT 之后，先做一轮 OpenCompass 评测，后续每次压缩或对齐后都带着同一组测试集复跑，这样才能看到每个操作是加分还是减分。

3. 纸上谈兵结束：CubeStudio 上一站式实操记录

3.1 创建实验：从任务模板开始而不是从空脚本开始

我在 CubeStudio 上的实操一般从“新建实验”开始。平台左侧是任务类型列表，能看到 SFT、Reward Model、PPO、蒸馏、剪枝、量化、安全评估、OpenCompass 等模板，每个模板都是一个独立可运行单元。

我以 Qwen2-7B 基座模型为例，先选择 SFT 模板，模板会弹出一组默认配置：基础模型名称、训练策略（LoRA/QLoRA/全参）、训练轮数、学习率、最大序列长度等。首批可以先用平台自带的样例数据跑一遍，确认整条链路能通，再替换成自己的业务数据。这个“先跑通再优化”的习惯能帮你省下大量排障时间。

配置数据时，很多平台模板支持直接从本地上传或挂载对象存储路径，也可以绑定平台预置的数据集。选择数据之后，模板会自动校验格式，比如 SFT 模板要求 JSON 中包含 instruction/output 字段，RM 模板要求包含 chosen/rejected 字段，格式不对模板会直接提示错误位置，比打开脚本调试 JSON 舒服太多。

3.2 SFT 训练的参数选择和防显存爆炸策略

以 7B 模型为例，如果 GPU 显存只有 24GB，直接全参微调很容易爆显存。我的标准配置是开 QLoRA：4bit 基础模型加 LoRA 适配器，训练时冻结原模型，只更新少量参数。核心参数放在下面：

• lora_rank：LoRA 矩阵的秩，常用 32~128。秩越大可学习的容量越大，但显存占用也随之上升，7B 模型从 64 起步比较稳。
• lora_alpha：一般取 rank 的 2 倍，128 对应 rank 64，保持放缩合理。
• learning_rate：LoRA 微调常用 2e-4 到 5e-4，QLoRA 因为基座被量化，学习率建议再低一点，1e-4 左右更安全。
• max_seq_len：2048 可以覆盖大多数指令任务，过长会显著增加显存。
• per_device_train_batch_size：先从 1 开始，配合gradient_accumulation_steps到达有效 batch size 16~32。
• num_train_epochs：领域数据充足就 2~3 轮，数据量少就 5 轮以上，核心看验证 loss 是否收敛。

训练过程中要关注两个点：一个是 loss 曲线是否稳定下降，前 100 步如果 loss 不降或震荡剧烈，先调低学习率；另一个是显存占用，日志里能看到out_of_memory的错误时，第一时间把 batch size 减半，而不是去系统层面硬扛。训练结束之后，模板会生成 checkpoint 列表，LoRA 权重可以按“合并回原模型”或“保留 adapter”两种方式导出。我习惯先保留 adapter，后续对比实验时少占一份磁盘空间。

3.3 从 SFT 到 reward、再到 PPO 的链路编排

SFT 完成后，在模型仓库里选中这个 checkpoint，直接作为 reward 模板的基础模型。reward 训练数据是偏好对，配置上我是先跑 1 个 epoch 看 reward accuracy 能不能上到 85% 以上，达不到就回查标注一致性。reward 模型训练完成后也要单独跑一遍验证集，统计chosen和rejected的得分差值分布，差值过小意味着 RM 区分度不够，后续 PPO 会学不到有效信号。

PPO 模板的配置页面会比 SFT 复杂一些，因为它要选择四个模型的来源：Actor（使用刚才的 SFT 模型）、Ref Model（Actor 的初始版本）、Reward Model（上一步产出的 RM）、Critic（平台会自动初始化一个价值网络）。核心训练参数如下：

• per_device_train_batch_size：影响每轮迭代生成的样本量，7B 模型建议 8 起步。
• mini_batch_size：PPO 在 batch 内部再分小批做更新，一般取 batch size 的四分之一。
• ppo_epochs：每个 batch 数据被重复更新的次数，1~2 就够了，太大会导致过拟合到当前 reward。
• learning_rate：Actor 的学习率要比 SFT 阶段低一个量级，1e-6 左右。
• kl_coef：KL 惩罚权重，比如 0.1，控制新策略和原策略的偏离程度。
• whiten_rewards：开启，对 reward 做标准化，稳定 advantage 计算。

我跑 PPO 时会实时盯三条曲线：reward 均值、KL 散度、actor loss。健康的状态是 reward 稳步上行，KL 增长但保持在可控范围；如果 reward 冲高但 KL 也飙升，说明模型正在快速偏离初始策略，试着把 kl_coef 调大一倍。PPO 需要的训练时间通常远超 SFT，一块 24GB 显卡跑 7B 模型的 PPO，一个 epoch 可能要好几个小时，建议先在 1~2 轮小数据上验证配置，再放开到全量。

跟 SFT 和 DPO 相比，PPO 对模板的依赖度更高，因为它的状态机复杂：采样、算分、更新、再采样，每一步日志格式都不一样。平台模板帮我自动完成了中间这些状态流转，并且把每个 epoch 的模型权重都存下来，方便回滚到表现最好的那一个 epoch。

3.4 量化、剪枝的落地操作与精度对冲

训练完成进入压缩阶段。在 CubeStudio 上选择量化模板，我一般先做 GPTQ 4bit 量化，因为它和 LLM 的矩阵乘结构结合紧密，推理加速明显。要在模板里指定校准数据集，没有高效原始数据时用训练集截取 128~256 条即可。量化完成后，模板会给出量化前后显存占用、推理吞吐的对比报告。通常 4bit 量化后模型体积缩到原来的三分之一左右，显存需求也会大幅下降，但这只是“理论收益”，部署前最好再用业务测试集冒烟一遍。

如果量化后精度掉得厉害，两条路走：一是切到 AWQ 重试，AWQ 对敏感权重做缩放保护，在某些模型上会比 GPTQ 更稳；二是回到训练侧，把量化精度损失当成一种扰动，在蒸馏模板里用原始模型作为 teacher，让量化后的小模型去拟合原始模型的输出，训练一两个 epoch 就能找回不少分数。

剪枝的操作顺序我在后面加了一行提醒：所有剪枝操作前一定要保存原始 checkpoint。非结构化剪枝后权重矩阵里有大量置零值，这时不能直接合并 LoRA 或继续 PPO，因为稀疏训练会让优化器没法正确累积梯度。正确顺序是：剪枝 → 蒸馏/轻量微调恢复 → 测试。稀疏度从 20% 开始，逐步往上试探，每提高 10% 就跑一遍下游任务，找到精度可接受的最大稀疏度。

3.5 用模板跑安全评估和能力评估：一张表看效果

压缩之后的最后一道工序是评估。安全评估模板可以直接套用平台预置的红队测试集，但我通常会再上传一份结合业务场景构造的离线数据。评估报告一般是表格形式，包含恶意请求总数、被拒绝数量、违规输出数量、拒绝率、违规率等指标。我的验收标准是有害请求拒绝率不低于 90%，违规输出率低于 1%。如果你的模型是客服场景，再把“退款纠纷”“投诉升级”这类业务安全样本放进测试集，单独列一栏看结果。

OpenCompass 能力评估模板覆盖的指标比较全，直接勾选要跑的评测集就能排队执行。比如我需要中文能力时勾 C-Eval，需要数学推理时勾 GSM8K，需要代码能力时勾 HumanEval，需要通用知识时勾 MMLU。评测集数量多的话耗时较长，可以先用子集验证配置再全量跑。评估完成后，平台自动出对比报告，把不同 checkpoint 的分数列在同一张表里。我这一周做的完整链路产出大概长这样：

这种“一张表看效果”的方式，比口头汇报准确太多。哪个步骤有效、哪个步骤损失可以接受，肉眼一眼分辨。

4. 常见问题与排查技巧实录

4.1 问题速查表

4.2 几条踩着坑总结出来的过硬经验

先说我踩得最深的坑：数据质量永远排在调参前面。SFT 阶段数据里如果混了思路混乱的“正确答案”，模型学到的就是混乱的逻辑。我后来在模板的验证环节加了“数据质量评分”这一步，先让模型对每条样本跑一次输出、人工复核一遍，再进训练。这个步骤虽然多花半天，但省下的返工时间通常是好几倍。

第二是 PPO 训练期间尽量别替换 reward 模型。有些人想让 RM 越训越准，于是边训练边更新 RM，结果 actor 的奖励分布一直在漂移，训练曲线彻底失去了参考性。正确做法是先冻结一个版本当基线，训练结束再重新评估 RM 精度，决定要不要重训。

第三是对压缩环节保持“警惕”。量化、剪枝后只看 PPL 远远不够。PPL 下降说明模型整体分布变化不大，但长尾能力可能已经悄悄崩了。我们内部定了规矩：任何压缩操作之后必须跑一次离线评测和一次线上小流量盲测，通过后再进部署流水线。

第四是善用平台模板里的“实验对比”能力。每次改动都新建一个实验版本，保留配置和日志，而不是在当前任务上反复覆盖。模型压缩这类操作尤其如此，训练、量化、剪枝的产物都存在模型仓库里，方便随时回溯到“效果最好的那个版本”。

最后想说，这套一站式模板的价值不只是省掉了写脚本的功夫。它真正帮助我的是把实验管理规范化了：输入数据、超参数、输出产物、评测报告全部留痕。大模型项目从微调到量化剪枝，中间十几个环节，任何一个节点出错都有迹可循。一个人推进项目时可能感觉不到，但团队协作时这种规范化带来的效率提升是决定性的。我自己现在接手新任务，第一件事就是先跑一遍模板默认参数，把基线和日志都留下，再开始调优——这个习惯建议你也可以试试。