企业官网建设流程全解析

1. 大模型全链路任务模板到底解决什么问题

第一次接触 CubeStudio 的大模型任务模板时，我正被一个很现实的问题卡住：团队里做微调、做偏好对齐、做量化部署的流程散落在三四个不同的脚本仓库里，每个人手里都有一套自己的环境配置，换个人接手就得重新踩一遍坑。LLaMA-Factory 本身已经把 SFT、PPO、DPO、Reward Model 这些训练范式封装得相当完整了，但真正落到工程上，从数据准备到训练、再到蒸馏剪枝量化、最后做安全评估和导出，中间要切换的工具链和目录结构还是太碎。

CubeStudio 的大模型任务模板做的事情，本质上是把这些环节串成一条可视化的流水线。你在平台上选一个模板，填几个参数，它帮你把 LLaMA-Factory 的训练任务、模型压缩任务、评估任务按依赖关系编排好，产物自动落到统一的存储路径里。对于中小团队来说，这比自建一套 MLflow + Airflow + 各种自定义镜像要省事得多，尤其是当你需要反复做“训练-压缩-评估”这种循环迭代的时候。

这篇文章我打算按实操顺序拆开讲：先讲清楚整体设计思路和为什么这么编排，再把 SFT、PPO、Reward Model 这几个训练模板的关键参数和踩坑点说透，然后是蒸馏、剪枝、量化这三类压缩任务在平台上怎么落地，最后聊安全评估和模型导出的注意事项。内容基于我自己的使用经验和对 LLaMA-Factory 的理解，涉及具体参数的地方我会说明计算逻辑，方便你按自己的硬件条件调整。

提示：CubeStudio 的模板会随版本更新，参数名称和默认值可能变化，实操时以你当前平台版本的界面为准，本文重点讲的是思路和参数背后的逻辑。

2. 整体编排思路与方案选型考量

2.1 为什么用任务模板而不是纯脚本

纯脚本方案的问题不在于能不能跑通，而在于可维护性和可复现性。我见过太多团队把训练命令写在 shell 脚本里，参数硬编码，换一个数据集就要改脚本，改完还不一定记得改了什么。CubeStudio 的任务模板把参数抽出来做成表单，每次运行生成一条任务记录，参数、日志、产物路径都绑定在一起，回溯的时候直接看任务详情就行。

另一个考量是资源调度。大模型训练和压缩对 GPU 的需求差异很大，SFT 可能需要多卡 A100，量化校准可能单卡就够了。平台的任务模板可以针对不同环节配置不同的资源规格，训练任务排队的时候压缩任务可以先用小资源跑起来，整体吞吐比串行脚本高不少。

从 LLaMA-Factory 的角度看，它本身支持通过 YAML 配置文件驱动训练，CubeStudio 的模板实际上是在帮你生成和管理这些 YAML，同时把模型权重、数据集、输出目录这些路径参数化。你如果熟悉 LLaMA-Factory 的配置项，上手模板会很快，因为大部分参数名是对应的。

2.2 全链路的阶段划分

我把整条链路分成四个阶段来理解，平台上的模板也基本是按这个逻辑组织的：

• 训练阶段：SFT 监督微调、Reward Model 训练、PPO 强化学习对齐，这三个是有先后依赖的。通常先做 SFT 得到基础指令模型，再基于它训练 Reward Model，最后用 PPO 做偏好优化。
• 压缩阶段：蒸馏、剪枝、量化。这三个可以独立作用于训练好的模型，也可以组合使用，比如先蒸馏再量化。
• 评估阶段：安全评估、能力评估。安全评估主要看模型对敏感输入的响应是否符合预期，能力评估看通用 benchmark 的表现。
• 导出阶段：把压缩后的模型导出成部署友好的格式，比如 ONNX 或者特定推理引擎的格式。

这个划分的好处是每个阶段可以独立重跑。比如你发现量化后精度掉得厉害，可以只重跑量化环节，不用把前面的训练再跑一遍。平台的任务依赖关系配置就是干这个的。

2.3 存储与路径规划

这里有个容易被忽略但很关键的细节：产物路径的规划。我建议在平台的对象存储或者共享存储里按项目名/模型名/阶段/时间戳这样的层级来组织。训练阶段的输出是压缩阶段的输入，如果路径乱了，后面找模型权重会很痛苦。

具体来说，SFT 的输出目录里会有checkpoint-xxx和最终的saved_model，Reward Model 的输出是单独的 reward 模型权重，PPO 的输出是策略模型。压缩阶段的输入要明确指向哪个阶段的哪个产物，这个在模板的参数里要填对。我一般会在项目根目录下建一个manifest文件记录每个产物的路径和对应的任务 ID，方便追溯。

注意：不同阶段的模型权重格式可能不一样，LLaMA-Factory 训练出来的是 HuggingFace 格式，量化工具可能要求特定的输入格式，导出前要确认格式兼容性。

3. 训练模板实操：SFT、Reward Model 与 PPO

3.1 SFT 监督微调的关键参数

SFT 是整个链路的地基，这一步没做好后面全白搭。在 CubeStudio 的 SFT 模板里，我重点关注这几个参数：

基座模型选择：模板里会让你填模型路径或者从模型库选。如果是 LLaMA 系，注意区分 base 和 chat 版本，做指令微调一般从 base 开始，chat 版本已经做过对齐，再 SFT 容易过拟合。我实测下来，7B 级别的模型在单卡 80G 显存上，用 LoRA 微调 batch size 可以开到 4 到 8，全量微调基本要 4 卡以上。

微调方式：LoRA、QLoRA、全量微调三选一。LoRA 的 rank 和 alpha 是核心参数，rank 一般取 8 到 64，alpha 通常是 rank 的两倍。QLoRA 在 LoRA 基础上做了 4bit 量化，显存占用能降到全量的三分之一左右，代价是训练速度慢一些。我的经验是，数据量在几万条以内、任务不算太复杂的话，LoRA rank 16 到 32 就够用。

学习率和调度：SFT 的学习率通常在 1e-5 到 5e-5 之间，LoRA 可以适当高一点。调度器用 cosine 比较稳，warmup 比例设 0.03 到 0.1。这里有个坑，如果 warmup 设得太短，前期 loss 会震荡得厉害，我一般至少设 100 步。

序列长度：这个直接决定显存占用。计算公式大致是显存 ≈ 参数量 × 精度字节数 + batch_size × seq_len × hidden_size × 层数 × 系数。实际调的时候，我一般从 1024 开始试，不够再往上加，同时配合 gradient checkpointing 省显存。

# LLaMA-Factory SFT 配置示例（平台模板会生成类似结构） model_name_or_path: /path/to/base_model stage: sft finetuning_type: lora lora_rank: 32 lora_alpha: 64 lora_target: all dataset: my_sft_data cutoff_len: 2048 learning_rate: 2.0e-5 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 lr_scheduler_type: cosine warmup_steps: 100

3.2 Reward Model 训练要点

Reward Model 是 PPO 的前置依赖，它的作用是给模型输出打分。训练数据是偏好对，格式是(prompt, chosen, rejected)。在平台上配置 Reward Model 任务时，要注意它和 SFT 的区别：

Reward Model 通常是在 SFT 模型基础上加一个 value head，输出一个标量分数。损失函数是 pairwise ranking loss，让 chosen 的分数高于 rejected。学习率要比 SFT 低一些，我一般用 1e-5 左右，因为 Reward Model 容易过拟合，训练 epoch 也不宜多，2 到 3 个 epoch 就够。

数据质量在这里比数量重要。我踩过的坑是用了大量噪声偏好数据，结果 Reward Model 学出来的分数分布很怪，PPO 阶段模型直接跑偏。后来改成人工筛选过的几千条高质量偏好对，效果反而好很多。

3.3 PPO 强化学习对齐的实操细节

PPO 是整条链路里最复杂也最容易出问题的一环。它同时涉及四个模型：策略模型（actor）、参考模型（reference）、奖励模型（reward）、价值模型（critic）。显存占用是 SFT 的好几倍，7B 模型做 PPO 基本要 4 卡 80G 起步。

关键参数里，KL 散度系数（kl_coef）控制策略模型偏离参考模型的程度，设太小模型不更新，设太大更新幅度受限。我一般从 0.1 开始调。裁剪范围（cliprange）通常设 0.2。PPO 的 batch size 和 mini-batch size 要配合好，mini-batch 一般是 batch 的四分之一到八分之一。

# PPO 配置关键项 stage: ppo ppo_epochs: 4 kl_coef: 0.1 cliprange: 0.2 cliprange_value: 0.2 gamma: 1.0 lam: 0.95

PPO 训练过程中要盯着几个指标：reward 均值是否上升、KL 散度是否稳定、策略模型的输出长度是否异常。我遇到过 reward 一直涨但模型输出变得又臭又长的情况，这是典型的 reward hacking，解决办法是在 reward 里加长度惩罚，或者用更好的 Reward Model。

实操心得：PPO 训练前先用小学习率跑几百步看看 reward 曲线，确认方向对了再放大规模。直接上大规模训练，一旦跑偏浪费的是几十个 GPU 小时。

4. 蒸馏、剪枝、量化三类压缩任务落地

4.1 知识蒸馏的模板配置

蒸馏是用一个大模型（teacher）指导一个小模型（student）训练。在平台上配置蒸馏任务时，核心是选好 teacher 和 student，以及蒸馏损失的温度参数。温度 T 一般取 2 到 5，T 越大软标签越平滑，student 学到的信息越多，但太小就退化成硬标签了。

蒸馏损失通常是软标签损失和硬标签损失的加权和，权重 alpha 一般设 0.5 到 0.9 偏向软标签。我实测下来，对于分类式任务，alpha 0.7、T 3 是个不错的起点。对于生成式任务，蒸馏要复杂一些，可能需要用 teacher 生成的序列作为 student 的训练目标，这时候更接近序列级蒸馏。

平台上的蒸馏模板一般会要求你指定 teacher 模型的路径和 student 的初始化方式。student 可以从头初始化，也可以从一个预训练小模型开始。从预训练小模型开始收敛更快，我一般选后者。

4.2 剪枝策略与参数选择

剪枝分结构化剪枝和非结构化剪枝。结构化剪枝直接去掉整个注意力头或者 FFN 的中间维度，剪完模型结构变小，推理速度有实际提升。非结构化剪枝是把个别权重置零，模型大小不变但稀疏化，需要特定硬件支持才能加速。

平台上常用的结构化剪枝参数是剪枝比例，比如剪掉 20% 的注意力头。剪枝后必须做微调恢复精度，这一步不能省。我试过剪枝 30% 不微调，模型直接不会说话了。微调的学习率要比原始训练低，1e-5 左右，跑个几百步就能恢复大部分能力。

剪枝的评估指标要看剪枝前后的 perplexity 变化和下游任务表现。如果 perplexity 涨了超过 15%，说明剪得太狠了，要降低比例重来。

4.3 量化方案对比与实操

量化是把模型权重从高精度（FP16/BF16）转成低精度（INT8/INT4）。平台模板里常见的量化方式有：

量化校准集的选择很关键，一般从训练数据里抽 128 到 512 条代表性样本。校准集分布要和实际推理分布接近，否则量化误差会偏大。我一般会抽不同任务类型的样本混合，避免校准集偏斜。

量化后的模型要做精度评估，对比量化前后的输出差异。如果某些关键任务的准确率掉超过 3 个百分点，就要考虑换量化方式或者调整量化配置。

# 量化校准数据准备的思路示例 from datasets import load_dataset # 从训练集抽样作为校准集 calib_dataset = load_dataset("json", data_files="train.json")["train"] calib_samples = calib_dataset.shuffle(seed=42).select(range(256)) # 保存为量化工具需要的格式 calib_samples.to_json("calib_data.json", orient="records", lines=True)

5. 安全评估与模型导出

5.1 安全评估模板的使用

安全评估这块，平台模板一般会内置一批测试用例，覆盖偏见、有害内容、隐私泄露等维度。评估方式是让模型对测试 prompt 生成回复，然后用规则或者评估模型打分。

我自己的做法是分两层：第一层用规则匹配，看模型输出里有没有明显的敏感词或者危险指令；第二层用评估模型打分，判断回复的整体安全性。规则层快但漏报多，模型层准但慢，两层结合比较平衡。

评估结果要留档，尤其是模型迭代过程中，每次评估的分数变化能反映压缩操作对安全性的影响。我观察到量化到 INT4 之后，模型的安全对齐能力有时会下降，可能是低精度下某些安全相关的权重被抹平了。这时候要么调整量化配置，要么在量化后补一轮安全微调。

5.2 模型导出的格式选择

导出格式取决于你的部署环境。如果是 HuggingFace 生态，直接导出 safetensors 就行。如果是 ONNX Runtime 或者 TensorRT，需要转成对应格式。转 ONNX 的时候注意 opset 版本，太新的版本可能某些推理引擎不支持，我一般用 opset 14 到 17。

导出后一定要做一次推理验证，确认输出和导出前一致。我遇到过导出 ONNX 后输出全变成乱码的情况，排查发现是 tokenizer 配置没一起导出。所以导出时要把 tokenizer 文件、配置文件一起打包。

注意：量化模型导出时，要确认目标推理引擎是否支持该量化格式。比如 GPTQ 量化模型在 vLLM 上支持较好，但在某些边缘设备推理框架上可能不支持。

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

6.1 训练阶段典型问题

问题一：SFT loss 不下降或者震荡。先检查学习率是不是太大，LoRA 的话试试降到 1e-5。再检查数据格式，LLaMA-Factory 对数据格式有要求，字段名不对会静默跳过样本。我遇到过一次数据里instruction字段写成了prompt，结果训练集实际为空，loss 一直不变。

问题二：PPO 训练 reward 不涨。先确认 Reward Model 本身打分是否合理，单独拿几条样本测一下。如果 Reward Model 没问题，检查 PPO 的 KL 系数是不是太大，策略模型被限制住了。还可以看看 advantage 的计算，如果 advantage 一直是负的，说明策略模型比参考模型差太多，可能需要先多做几轮 SFT。

问题三：显存溢出。按优先级排查：减小 batch size、减小序列长度、开启 gradient checkpointing、换 LoRA 或 QLoRA、减少 PPO 的 mini-batch 数量。我一般先动 batch size 和序列长度，这两个对显存影响最直接。

6.2 压缩阶段典型问题

问题四：量化后精度暴跌。检查校准集是否具有代表性，太少或者分布太偏都会导致量化误差大。试试换一种量化方式，比如从 INT4 换到 INT8。还可以对敏感层（比如第一层和最后一层）保持高精度，只量化中间层。

问题五：剪枝后模型输出重复。这是剪枝破坏了注意力机制的典型表现。降低剪枝比例，或者只剪 FFN 层不剪注意力层。剪枝后的微调要足够充分，我一般至少跑 500 步。

问题六：蒸馏 student 学不到 teacher 的能力。检查温度参数和损失权重，温度太低软标签信息不足，太高又太模糊。还可以试试中间层蒸馏，让 student 模仿 teacher 的隐藏状态，而不只是输出。

6.3 平台使用层面的坑

问题七：任务依赖配置错误导致产物找不到。平台上的任务依赖是通过路径传递的，如果上游任务的输出路径和下游任务的输入路径对不上，任务会失败。我建议在配置依赖时，直接用平台提供的路径变量，不要手写绝对路径。

问题八：资源规格选错导致任务排队很久。训练任务选了大规格 GPU，但压缩任务其实用小规格就行。合理分配资源规格能显著缩短整体流水线时间。我一般把 SFT 和 PPO 放在大规格队列，量化和评估放在小规格队列。

问题九：日志查看不方便。平台的任务日志一般按 stdout 和 stderr 分开，训练框架的进度条在 stderr 里。如果日志刷得太快，可以下载下来用 grep 过滤关键信息，比如 loss、reward、accuracy 这些指标。

6.4 我个人的几条经验

第一，任何压缩操作之前，先保存一份原始模型的评估基线，不然压缩后掉点了你都不知道掉了多少。第二，PPO 和蒸馏这类涉及多个模型的任务，显存规划要提前算好，别跑到一半 OOM。第三，平台模板虽然方便，但底层还是 LLaMA-Factory 那套东西，遇到问题去看 LLaMA-Factory 的文档和 issue，比在平台层面瞎试效率高。

还有一点，量化不是越激进越好。我见过为了省显存直接上 INT4 结果模型基本不可用的案例。实际部署时，INT8 往往是精度和显存的平衡点，INT4 适合对精度要求不那么极致的场景。选量化方案前，先明确你的精度底线在哪里。

最后分享一个小技巧：在平台上跑全链路之前，先用小模型（比如 1B 级别）和少量数据把整条流水线跑通一遍，确认各环节的输入输出路径、参数传递都没问题，再换成大模型和全量数据。这样能省下大量调试时间，也能提前发现依赖配置的问题。