企业官网建设流程全解析

做开源大模型落地做了大半年，我最深的感受是：真正把模型效果做出来，往往不是某个算法有多新，而是怎么把一长串工具链串起来。你手上的模型要经历底座选择、数据准备、SFT 微调、reward model 训练、PPO 强化、蒸馏/剪枝/量化、安全评估、客观评测，每一步单独拿出来都有成熟方案，但把它们放进一个业务项目里，环境隔离、依赖版本、数据格式、模型产物流转，随便一环都能卡你两三天。

我最近在 CubeStudio 上把这条链路整体跑了一遍，LLaMA-Factory 的 SFT/PPO/reward 三个微调阶段、模型瘦身三件套、安全评估和 OpenCompass 评测都能通过平台任务模板串起来。这篇文章就把我的实操过程、参数设置和踩坑记录完整写出来，适合正在做领域模型微调、准备上线的算法工程师，也适合被一堆命令行和 CUDA 环境折腾到怀疑人生的同学参考。

1. 工具链碎片化之下，一站式任务模板到底解决的是什么

1.1 独立跑一遍大模型全流程要跨多少套环境

先说一个我自己经历过的场景。公司要做业务知识问答，算法同学负责用底座模型做领域微调。第一版流程是这样：微调用拉起来的 Python 环境装 transformers、peft、trl，阶段参数靠 LLaMA-Factory 的 shell 脚本控制；微调完想做 RLHF，必须再训练一个 reward model，数据格式和 SFT 又不一样；模型效果好一点了，要压缩体积上生产，于是再开一台机器装量化工具，装 awq、gptq 的依赖；剪枝又要另一套稀疏化环境；最后给测试看结果，还要部署一套 OpenCompass 评测环境。

这些环境之间经常打架。有一次因为 transformers 版本不一致，同样的 tokenizer 在微调环境里保存的模型文件，在量化环境里加载后词表长度对不上，报错之后我才发现两套环境版本差了好几个 minor。这种问题代码逻辑没错，纯粹是工具链碎片化造成的。

等上了 CubeStudio 之后，这些步骤变成了平台上的任务卡片。微调是任务，量化是任务，评估也是任务。后台的依赖、版本、GPU 资源调度被平台接管，我只管填参数、选数据、看产物。这个改变看起来不大，实际省掉的时间非常可观。

1.2 任务模板的本质：把“命令”变成“任务卡片”

CubeStudio 的“任务模板”不是黑盒，我更愿意把它理解成“命令行参数的图形化封装”。比如微调类模板，背后跑的其实还是 LLaMA-Factory 那套训练逻辑，只是你不需要自己拼llamafactory-cli train --stage sft ...这一长串命令，而是在模板里填模型路径、数据集、学习率、LoRA rank 这些字段。

平台上的任务大概分三类：

• 微调类任务：对应 LLaMA-Factory 的 SFT、reward model、PPO 三种 stage。
• 模型压缩类任务：知识蒸馏、结构化/非结构化剪枝、GPTQ/AWQ/FP8 量化。
• 评估类任务：安全评估专项和 OpenCompass 客观评测。

数据、基础模型、训练产物都会以“工件”的形式在任务之间流转。上游任务输出的模型目录，直接作为下游任务的输入。我一开始对“模型产物自动传递”这个设计没太在意，直到有一次我手动把量化任务的输入路径写错，模型文件少拷贝了一个 adapter 目录，才发现这种依赖管理确实能预防低级失误。

1.3 什么场景适合上平台，什么场景别硬上

平台不是银弹。我自己的判断是：如果你的工作流是“探索型训练”，比如要跑一个完全自定义的 Trainer、做超大 batch 的多机多卡实验，那直接在 GPU 开发环境里写代码更灵活；但如果你是“工程型交付”，模型要用多轮流程反复迭代，还要给团队其他人复用，那模板化是最稳的。

还有一个容易被忽视的好处：审计。业务模型上线前通常要说明训练数据、超参、评估结果。以前这些散落在各个人的笔记里，现在每个任务都有记录，跑过哪些阶段、用了哪个数据集、输出了哪个版本模型，一查便知。对要过合规评审的项目来说，这个价值可能比省时间还大。

2. LLaMA-Factory 模板实操：把 SFT、reward、PPO 串成一个闭环

2.1 先把数据格式对齐

在平台里创建微调任务之前，最重要的不是急着填模型名，而是把数据整理成训练脚本认识的格式。LLaMA-Factory 的 SFT 阶段默认支持 Alpaca 格式，一个样本长这样：

{ "instruction": "请根据以下商品信息回答用户问题。", "input": "商品：无线蓝牙耳机。问题：续航多久？", "output": "这款耳机单次充电可连续播放6小时，配合充电仓总续航达到24小时。" }

如果你要做多轮对话，可以换成 ShareGPT 格式，把对话历史放在conversations字段里。我的建议是：一开始就别用“单轮问答”的干净数据练手，直接在数据集里混入一部分多轮对话，否则微调出来的模型在真实聊天场景里上下文理解会明显偏弱。

数据集在 CubeStudio 里需要先注册成一个“数据集工件”，指定好格式类型。这一步其实就是以前在 Python 里dataset = load_dataset(...)做的事情，只是变成了界面操作。

2.2 SFT 微调任务：LoRA 配置是我改得最多的部分

进入 SFT 任务模板后，核心参数和 LLaMA-Factory 的命令行基本一一对应。我习惯先在模板里这样填：

stage=sft model_name_or_path=/models/qwen/Qwen2.5-7B-Instruct dataset=customer_service_v1 template=qwen lora_rank=64 learning_rate=2e-4 num_train_epochs=3 per_device_train_batch_size=4 gradient_accumulation_steps=8 lr_scheduler_type=cosine max_length=2048

参数背后有几个点值得展开。

第一，为什么用 LoRA 而不是全参数微调？7B 模型全参微调动辄要 80GB 以上显存，而 LoRA 只训练低秩适配器，显存占用能压到 40GB 以内，很多场景一张 A100 就能跑起来。更重要的是，LoRA 出来的 adapter 很小，方便做多版本并行验证。同一个底座模型，我挂不同的 adapter，就能对比不同数据集的效果，这是全参微调不方便做到的。

第二，gradient_accumulation_steps=8配合per_device_train_batch_size=4，等效 batch size 是 32。我试过直接调大单卡 batch size，结果 7B 模型在 24GB 显存里直接 OOM，而靠梯度累积能有效绕开显存瓶颈。群里经常有人说“显存不够就把 batch size 调小”，这句话对，但代价是训练不稳定，所以优先用梯度累积而不是暴力减小 batch。

第三，template参数必须和底座模型匹配。Qwen 系的模型填qwen，LLaMA 系就填llama。我见过有人在这块偷懒，结果训练不报错，但推理时 system prompt 格式错位，模型回答质量下降一大截。

2.3 reward model 训练：PPO 的“裁判”

PPO 不是一个能凭空开始的过程。它需要一个裁判来告诉策略模型“这次回答好不好”，这个裁判就是 reward model。

在 LLaMA-Factory 里，reward model 训练对应stage=rm，数据格式和 SFT 不同，是偏好对：

{ "prompt": "用户问到货时间，请生成客服回答。", "chosen": "您的订单预计3天内送达。", "rejected": "不知道，您自己查物流吧。" }

模型要学习给chosen打出比rejected更高的分数。我的经验是：偏好数据不需要像 SFT 数据那么多，但质量要求更高。 SFT 数据量少只是效果差，偏好数据如果正负样本区分不明显，reward model 学会的可能是“话术长短”而不是“回答好坏”，PPO 阶段很容易跑崩。

在 CubeStudio 里创建 reward 任务，跟 SFT 任务类似，只是把“任务类型”选成 reward model 训练，然后指定偏好数据集。输出是一个单独的 reward 模型工件，后续 PPO 任务会直接引用它。

2.4 PPO 强化微调任务：三个输入的依赖链

PPO 任务模板是我觉得最体现“一站式”价值的地方，因为这个阶段在本地手动配最容易出问题。一次完整的 PPO 训练要同时加载三个模型：策略模型（SFT 产出的 LoRA 或合并模型）、reward model、参考策略（通常是冻结的原始 SFT 模型，用于计算 KL 散度）。

在模板里，我需要分别指定：

stage=ppo model_name_or_path=/models/qwen/Qwen2.5-7B-Instruct reward_model=/models/output/reward_v1 sft_model=/models/output/sft_v1 dataset=ppo_prompt_dataset_v1 learning_rate=1e-5 kl_control=0.1 per_device_train_batch_size=4 gradient_accumulation_steps=4

PPO 的循环逻辑是：策略模型对 prompt 生成回答，reward model 给回答打分，然后和参考策略比较 KL 散度，二者合并成一个带约束的奖励信号，再用于更新策略。这个过程比 SFT 不稳定很多，学习率必须调低，KL 系数太大模型学不动，太小容易导致 reward hacking。

我实际跑下来，平台上的 PPO 任务比较省心的地方在于：三个模型的加载和显存分配不需要我手动控制。以前本地跑 PPO，因为显存规划不当，三个模型加载顺序稍有问题就 OOM，而平台任务会根据 GPU 卡数自动切分模型放置。

2.5 我实际踩过的坑

第一个坑是 stage 选择错误。LLaMA-Factory 的命令行里--stage可以填sft、rm、ppo，但平台模板是三个独立卡片。我一开始图省事，在 SFT 模板里填了stage=ppo，结果训练任务跑了一分钟就报“unrecognized stage”错误。后来才意识到，平台已经按模板锁定了 stage，参数里不需要再传。

第二个坑是 PPO 训练奖励崩了还浑然不觉。PPO 的训练日志里会打印 reward 均值，我第一版策略模型微调后，reward 快速冲到 4.8，我以为效果很好，结果人工看生成内容，模型开始用各种花哨话术讨好奖励模型，回答却变得空洞。后来加了更高的 KL 约束，reward 均值稳定在 1.2 附近，输出才恢复正常。

第三个坑是灾难性遗忘。SFT 中期开始，模型的专业问答能力提升，但通用对话能力明显退缩。我在最后两个 epoch 混入了一部分通用指令数据，情况才好转。想提醒大家：SFT 的训练数据不要 100% 是业务数据，留 5%~10% 给通用能力维持。

3. 模型瘦身三件套：蒸馏、剪枝、量化到底怎么选、怎么跑

3.1 选型逻辑：要看你上线卡和延迟预算

模型微调完，接下来就是让它在实际硬件上跑得动。很多人一开口就说“量化”，但量化不是唯一选项，甚至不一定是最优解。

我自己有个简单的选型思路：

• 目标是降低单卡显存占用，最简单直接的是量化，INT4 量化可以把 7B 模型的显存需求从 14GB 级别压到 5GB 级别。
• 目标是把模型体积和推理延迟整体降下来，除了继续变小模型，知识蒸馏更合适。比如用 7B 模型当教师，教一个 3B 的学生模型。
• 目标是压缩后保留更高精度、同时运行硬件支持稀疏加速，才考虑剪枝。剪枝后的模型在普通 GPU 上未必能获得线性加速，需要配套的稀疏算子支持。

这三者不是互斥的。我常用的一条组合是：先蒸馏一个更小的学生模型，再做 INT4 量化，进一步压显存；剪枝则更多用在一些对带宽功耗苛刻的边缘场景，常规云 GPU 上我用的比较少。

3.2 蒸馏任务模板实操

蒸馏的核心思想是让小模型同时学会大模型的“答案”和“答题风格”。在 CubeStudio 的蒸馏任务模板里，主要配置项是教师模型、学生模型、蒸馏温度和损失权重。

教师模型一般指向已经微调好的高精度模型，学生模型的初始权重可以从同系列小尺寸开源模型开始。我第一版用的教师是 7B，学生是 3B，训练数据用业务指令集。

蒸馏任务里的温度参数值得多说一句。温度越高，教师模型输出的软标签分布越平滑，小模型能学到的“暗知识”越多；但温度过高，类别之间的差异被抹平，学生反而学不清晰。我习惯从temperature=3.0起步，然后看验证集损失调整。

任务跑完后，平台输出的学生模型会作为新的模型工件。蒸馏阶段的收益我印象很深：7B 模型的领域知识保留了大半，但推理显存需求直接降了一个量级，这在初期 GPU 资源紧张时非常划算。

3.3 剪枝任务模板实操

剪枝不是简单的“把不重要的权重置零”。按粒度分，主要两类：

• 非结构化剪枝：逐个权重置零，模型变“稀疏”，但普通引擎不加速。
• 结构化剪枝：按行、按列、按注意力头整块移除，能配合专用内核加速。

在模板里，我先跑了一条结构化剪枝链路。参数大致是pruning_ratio=0.25，也就是剪掉约 25% 的注意力头和 FFN 单元。这个比例看着保守，剪完直接推理时效果掉得比我想象中快，困惑度上升明显。

后来我补了一步“剪枝后恢复训练”，用少量业务数据对裁剪后的模型做短时间微调，让它重新适应被剪掉的参数空间。这一步至关重要。模板里有两个输出选项：直接输出剪枝模型，或者输出“剪枝-恢复训练”后的模型。我的建议是恢复训练这步基本不要省，代价只是多一点训练时长，换来的是质量明显回升。

不过要泼一盆冷水：剪枝在地上的收益没有听起来那么美。GPU 推理时瓶颈通常在线性层矩阵乘，而常规 PyTorch 推理不会自动利用稀疏结构。除非你的部署环境明确支持稀疏算子，否则我建议先把量化做了，剪枝的排序往后放。

3.4 量化任务模板实操

量化是三个方案里我实际用得最多的。量化任务模板里一般让你选量化算法和校准数据集。

目前主流选项：

校准数据集是量化流程里最容易翻车的点。我之前拿了一批纯偏技术的数据做校准，量化完业务问答还行，一出通用问题就开始胡言乱语，因为校准数据没有覆盖到通用 token 分布。后来把校准集改成“业务数据 70% + 通用数据 30%，总共 500 条左右”，效果才恢复正常。

量化任务的输出是一个可以直接部署的模型工件。在平台上它会单独标记版本，我建议每次量化都在模型名里带上方案名，比如model_int4_awq_v1，避免后面多个量化产物混在一起搞不清哪个是哪个。

3.5 我实测的一组数据（仅供参考）

我用一个 7B 模型做过一轮压缩效果对比，大体是这样的（不同框架和硬件会有差异，请以实际测试为准）：

每个方案都有得有失。量化掉的点数最少，收益最直接；蒸馏换模型体积的代价是业务能力也有折扣；剪枝如果不是部署环境支持稀疏加速，性价比一般。

4. 安全评估与 OpenCompass：不是跑分热闹，而是能否交付

4.1 微调之后模型“变笨”和“变野”都可能发生

我见过不少团队把微调训练做完，业务指标涨了一截，就急着发布。结果上线没多久，模型对敏感问题乱答、对用户恶意输入配合度高，甚至生成内容明显偏向训练数据的错误认知。

原因也很简单：领域微调会改变模型原有的行为分布，SFT 阶段如果只灌业务数据，模型原本的安全对齐能力会被稀释；PPO 阶段如果奖励设置不当，模型也可能出现目标偏移。所以微调完做安全评估不是可选项，是发布前的底线检查。

标题里提到的 Open，我理解就是指 OpenCompass 这一整套开源评测体系。CubeStudio 把它和安全评估拆成了两类任务：一个偏安全合规，一个偏客观跑分，二者互补。

4.2 安全评估任务怎么配置

安全评估模板的输入是“待评估模型 + 安全测试集”。测试集一般覆盖越狱攻击、偏见歧视、有害指令、隐私泄露、色情暴力等几个维度。

配置时有两点很关键。

第一，用对比模式。不要只评估微调后的模型。我会把原始底座、SFT 后模型、PPO 后模型、量化后模型同时建多个评估任务，跑完后放在同一张报告里对比。这样才能看出来“哪一步改坏了什么”。

第二，注意安全评估的判定尺度。模板通常会输出每个测试用例的风险等级，以及模型是否拒绝回答。这里有个坑：模型过于安全就会变成“什么都拒绝”，连正常业务问题也不敢答。PPO 调过头很容易出现这种情况。安全评估报告里如果发现“拒绝率”异常高，也要回头调整训练策略。

安全评估输出的报告会标记高风险用例，并给出具体触发输入。我一般会先把这些 bad case 下载下来人工过一遍，确认是真风险还是误报，再决定是否让安全团队介入。

4.3 OpenCompass 客观评测模板

安全评估解决“能不能用”的问题，OpenCompass 解决“用得怎么样”的问题。

在 CubeStudio 里创建 OpenCompass 评测任务，需要指定模型路径和评测数据集。常见配置：

# 简化示意 models: - type: HuggingFaceModel path: /models/output/model_int4_awq_v1 abbr: qwen7b-int4-awq datasets: - name: ceval fewshot: 5 - name: gsm8k fewshot: 5 - name: humaneval fewshot: 0

评测集的选择要跟业务场景挂钩。做中文领域问答，C-Eval 是必跑的；数学推理看 GSM8K；代码模型看 HumanEval。不要一上来全量跑几十个数据集，既费 GPU 时间，报告也没人仔细看。

模型路径这里特别容易搞错。平台虽然会自动传模型工件，但如果你手动改过路径，要确认传进去的是“合并后的模型”而不是 LoRA adapter。OpenCompass 本身不负责加载 adapter，跑出来分数会莫名其妙低甚至直接报错。

评测完成后，平台会输出模型在各数据集上的得分。我建议把这一步作为每次微调迭代的固定动作，哪怕只是改了个学习率，也重新跑一次主要评测集，积累成一张趋势表，比单独一次高分更有判断价值。

4.4 怎么解读报告并决定能不能发布

看评估报告最容易犯的错误是单看总分。我自己的判断顺序是：

1. 先看安全评估报告。有没有高风险、不可擦除的坏例。有，先不发布。
2. 再看目标业务指标。领域测试集得分是否达标。
3. 最后看通用能力分数。与底座模型相比，下降幅度是否可接受。

我遇过一种情况：SFT 后业务分从 80 涨到 95，但通用能力从 85 掉到 70。对于只上线专用客服场景来说，这个交易可能值得做；但如果这个模型还要承接泛化问答，就必须在训练数据里补通用语料。

量化后的模型也要重新跑一遍评测。我见过有人直接把量化模型的分数默认等同于原模型，结果因为量化校准集分布偏差，业务得分差了 8 个点。宁可多花半小时跑评测，也不要带着未知上线。

5. 端到端任务链走一遍：从领域底座到可交付模型

5.1 我选的业务场景与整体任务清单

最后用一个完整场景把前面的所有内容串起来。假设要做一个电商售前售后知识问答模型，基础底座选用 Qwen2.5-7B-Instruct，业务数据大概两万条 SFT、五千条偏好对、三千条 PPO prompt。

整体任务链如下：

不建议第一次就把所有任务全建出来。我实际的做法是：先建 SFT 任务，用 200 条数据跑通；再建量化任务，确认模型产物能正常被下游引用；最后才把 reward、PPO 这些重任务挂进来。

5.2 在 CubeStudio 创建任务链的步骤

第一步，注册数据集。把 SFT 数据集、偏好数据集、PPO prompt 数据集、校准集、安全测试集分别按模板要求上传，平台会给每个数据集一个唯一标识。

第二步，创建 SFT 微调任务。在“微调”分类下选 SFT 模板，模型路径填底座模型，数据集选已注册的 SFT 数据集，LoRA 相关参数保持默认，训练 2~3 个 epoch。任务跑完会生成一个模型工件，可以在模型列表里看到。

第三步，创建 Reward Model 任务。模型仍填底座，数据集选偏好集。这一步输出奖励模型工件。

第四步，创建 PPO 任务。这里依赖三个输入：SFT 模型、奖励模型、prompt 数据集。平台会画出依赖关系，上游任务没完成时下游任务不能启动。我一开始对这点很满意，因为手动编排时最容易犯的错就是“模型还没生成就去拉数据”。

第五步，创建量化任务。输入选 PPO 产出的策略模型，量化算法选 AWQ，校准集选业务加通用混合数据。等待执行，输出量化版本。

第六步，创建评估任务。安全评估和 OpenCompass 可以并行跑。我通常把原始底座、SFT 版、PPO 版、量化版四个模型一起提交，得到一份对比报告。

在这一套流程里，我实际花时间最多的是数据整理，而不是任务编排。平台把训练环境、依赖、模型流转全都接住了，我只需要关注业务问题本身。

5.3 结果验证与我的判断

任务链跑完之后，我得到几个关键结论：

SFT 模型在业务测试集上表现很好，但安全评估里出现了一些不该有的配合行为。接着跑 PPO，安全分数回归，但业务提问的“拒绝率”也随之升高，部分正常问题被模型保守地挡了回去。

量化版本在 AWQ 方案下，业务得分只掉了 1.5 个点，通用能力掉了 2 个点左右，但显存占用和生成速度的改善立竿见影。最终上线方案敲定为“SFT + AWQ 量化”，PPO 继续调参作为后续迭代。

如果一开始不做评估，我大概率会直接拿 SFT 模型上线，安全风险要等出事故才能发现。这也验证了我在前面说的：微调完不评估，等于白做。

最后再分享一个我自己的习惯。第一次在 CubeStudio 上跑完整链路时，我没有直接上全量数据，而是用几百条数据、两个任务节点先走通一张最小闭环。确认模板参数、模型流转、评估报告都正确之后，再放开批量和 epoch。这个习惯帮我避免了很多次“训练跑了两天，最后发现数据集格式错了”的灾难。模板能帮你管好环境，但管不了数据质量，数据才是这个链路里真正决定上限的部分。