1. 先从痛点说起：一套流程从微调到量化剪枝到底卡在哪

我自己做项目的时候，最烦的不是某个单点技术学不会，而是链路太长、工具太散。今天用LLaMA-Factory把SFT跑通了，明天要换另一个框架做PPO，后天又要写脚本做量化，再后来还要搞安全评测。每一步单独看都有开源方案，但串在一起就得自己写一堆胶水代码，中间还要处理不同工具的版本冲突、权重格式不兼容、评测口径不统一的问题。一个7B模型折腾下来，真正花在算法上的时间可能不到三分之一。

CubeStudio这类平台解决的就是这个“胶水”问题。它把LLaMA-Factory、蒸馏剪枝量化工具、安全评估和开放评测模板都挂到了同一个项目空间里，相当于把你从“自己拼乐高”变成“用别人拼好的模块搭房子”。它的核心思路是：用任务模板把特定场景下的最佳实践固定下来，你只需要准备数据和参数，剩下的环境依赖、数据流转、结果归档都交给平台处理。对你来说，从微调开始，到量化剪枝，再到安全评估，全程只在一个项目里操作，每一步的产物都能被下一步直接消费。

这篇内容我尽量按实操流程讲，不堆理论公式。前提是你已经对大模型微调和LLaMA-Factory有基础概念，至少知道SFT是监督微调、PPO是强化学习对齐、INT8/INT4是量化精度。如果你完全没接触过这些，建议先拿一个7B模型在本地跑一次SFT，再回来看平台上的流程会清晰很多。下面我会把我在CubeStudio上从零搭出来并跑通一整套SFT、reward、PPO、蒸馏、剪枝、量化、安全评估的完整过程拆开讲，包括界面里每个关键参数怎么填、哪个按钮容易点错、以及我实际踩过的坑。

2. 上手前准备：CubeStudio环境与任务模板视图

在真正点“训练”按钮之前，最好先理解CubeStudio的项目组织方式。我第一次用的时候直接新建了一个空白任务，结果发现很多模板入口没找到，白白浪费时间。其实这个平台对“模型开发”和“普通代码开发”的思路不太一样：它默认你把“一个项目”理解为“围绕一个模型版本的完整生命周期”，而不是单纯放代码的仓库。

2.1 一个项目对应一个模型版本：空间和任务如何组织

CubeStudio里的基本单位是“项目”，项目下可以挂多个“任务”。任务类型包括数据预处理、模型训练、模型评估、模型转换等。每个任务会产生独立的输出，输出会注册到项目的产物列表里。这样做的最大好处是：你在微调任务里产出的LoRA权重或全量模型，可以直接被后面的量化任务引用，不需要自己复制路径。

举例来说，一个典型的项目流程是：

1. 创建“数据准备”任务，把原始JSON清洗成LLaMA-Factory要求的格式；
2. 创建“LLaMA-Factory训练”任务，配置SFT或PPO参数；
3. 训练完成后，在模型仓库中注册一个模型版本；
4. 对该版本创建“模型压缩”任务，选择蒸馏、剪枝或量化模板；
5. 对压缩后的模型创建“安全评估”和“开放评测”任务。

每个任务启动后，平台会自动分配容器和GPU资源，并把日志、指标、输出模型统一存放在指定路径。你把项目当成一个流水线车间，每个任务就是车间里的一台机器，机器之间用“产物”这个传送带连接。

2.2 选模板其实就是选训练框架：LLaMA-Factory模板踩进来

CubeStudio的任务中心里，模型训练模板默认带了LLaMA-Factory的入口。这里要注意，模板不是只给你一个启动脚本，而是把LLaMA-Factory的WebUI参数和底层环境都封装好了。你进入模板后，会看到一个类似WebUI的配置界面，但它比本地版多了一些平台相关的选项，比如“启用任务依赖”、“输出模型注册到仓库”等。

我建议直接用模板里的“LLaMA-Factory 全参数/LoRA训练”模板，不要自己从零写Shell命令。因为平台已经帮你处理好了CUDA版本、PyTorch版本、transformers版本之间的兼容问题。你自己指定版本反而容易出现镜像不匹配的问题。

模板里最需要关心的几个区域：

• 模型来源：填Hugging Face模型ID或手动上传的本地路径；
• 训练阶段：支持SFT、RM、PPO、DPO等多种模式；
• 数据集：从数据管理模块选择已经处理好的数据；
• 训练参数：包括学习率、批次大小、序列长度、LoRA秩等；
• 平台专属开关：是否将训练产物注册为模型版本。

如果你之前用过LLaMA-Factory的WebUI，会发现界面很亲切。除了缺少某些实时图表（它会把指标全量写入日志，需要你自己在日志页面查看），其他使用逻辑几乎一致。

2.3 算力配置与数据存储：别在第一步就白烧钱

这是我最想强调的部分。很多人在本地养成了“先开个最大模型再调参数”的习惯，但在CubeStudio上算力是按时间计费的，随便把一个70B模型加载到24G显卡上，还没开始训练就OOM，费用照样扣。我的建议是：先明确你的实验目标，再选GPU型号。

经验配置参考如下：

存储方面，平台会默认给你一块项目空间，但要注意模型权重下载路径。我第一次把Qwen模型的ckpt下载到项目空间里，占了几十个G，后来又清理缓存，发现空间不够用了。正确做法是：把模型文件放在平台内置的模型缓存目录里，尽量别放到自己的数据盘。数据盘只放训练数据、脚本和最终产出的权重。

3. 微调阶段实操：用LLaMA-Factory在CubeStudio里跑SFT/PPO/reward

这块是重头戏，我把SFT、reward和PPO拆成三部分讲，它们虽然在同一个模板里，但逻辑上是一环扣一环的。很多人在训练reward和PPO时失败，是因为数据格式没对齐，或者超参数设置违背了强化学习的基本约束。

3.1 数据准备：从JSON到“角色/指令/回答”三段式

LLaMA-Factory支持的标准指令微调数据格式是对话式，最常用的是“instruction + input + output”的三段式。在CubeStudio里做数据准备时，你可以上传CSV、JSON或JSONL，平台会自动做schema识别。但如果字段名不标准，它会直接报错，所以最好一开始就规范好。

我常用的示例格式如下：

[ { "instruction": "将下面的句子翻译成英文。", "input": "今天天气很好。", "output": "The weather is nice today." } ]

如果做多轮对话，则需要按messages格式组织：

[ { "messages": [ {"role": "user", "content": "介绍一下量子计算。"}, {"role": "assistant", "content": "量子计算是一种利用量子比特进行计算的技术。"} ] } ]

在CubeStudio的数据管理模块中，你可以在“数据集标签”里指定训练集和验证集的比例。建议把验证集比例至少设置为5%，不要省。没有验证集的话，你很难判断模型是过拟合还是欠拟合。我自己习惯用10%做验证集，小数据量时宁可少跑几步也要把验证曲线留出来。

另外，如果是训练reward模型，数据格式会不太一样。LLaMA-Factory的reward模型训练需要“chosen”和“rejected”两个回答字段，用来告诉模型哪个回答更好。注意：同一个问题必须同时出现好与坏两个回答，不能只给一个打分。数据格式如下：

{ "instruction": "谁是你最喜欢的导演？", "input": "", "chosen": "我很喜欢诺兰，他对叙事结构的掌控很吸引我。", "rejected": "我没什么喜欢的导演。" }

3.2 SFT指令微调的界面配置和启动

进入LLaMA-Factory训练任务的SFT阶段后，首先要选基座模型。CubeStudio模板默认拉取Hugging Face上的模型，比如Qwen2.5-7B-Instruct、Llama-3-8B-Instruct。选Instruct版本有个好处：它的chat模板已经定义好了，不需要自己为每条数据拼system提示词。

在训练参数区域，我建议第一次跑先把Glora关掉、直接用LoRA。LoRA的秩（r）和缩放系数（alpha）保持默认的8和16就行，不要一上来就拉高。很多教程说秩越大模型越灵活，但对指令微调来说，rank=8通常足够，rank过大反而容易过拟合。

学习率方面，LoRA微调常见值是1e-4到2e-4，全参数微调则降到1e-5到2e-5。使用LLaMA-Factory默认的cosine学习率调度器即可。如果数据集比较小（比如几千条），可以把epoch设为3，太大反而会让模型记忆训练集，在验证集上崩掉。

启动训练前确认两个平台相关的选项：一是“输出模型注册到模型仓库”，二是“保存训练日志到项目空间”。如果不勾选这两个，你训练完可能拿不到产物路径，后续任务没法继续。我第一次就因为没勾选，导致量化任务找不到模型路径，白跑了一个小时。

启动后训练日志会实时滚动，重点关注loss曲线。SFT训练正常的现象是训练loss平滑下降，验证loss也在下降或趋于平缓。如果验证loss突然上升，大概率是过拟合，可以立刻停止并把学习率调低或减少epoch。

3.3 reward模型与PPO对齐：先训打分器再接强化学习

PPO训练之前的reward模型其实是个二分类任务：模型要学会把“chosen”回答的分数推高，把“rejected”回答的分数压低。LLaMA-Factory提供了reward模型训练模式，只需要把数据按chosen/rejected格式准备好，它会在基座模型上接一个线性层输出分值。

我在CubeStudio上训练reward模型时，遇到最典型的错误是batch size过大。reward模型对batch很敏感，因为它在同一个batch内比较chosen和rejected，batch越大，比较越准确，但显存占用也越高。如果显存不够，不要盲目减小batch，可以尝试开启梯度累积。一般来说，在24G显存上对7B模型做LoRA训练reward，batch size设2、梯度累积设8，跑起来比较稳。

完成reward模型训练后，PPO阶段需要同时加载四个模型：actor模型、reward模型、critic模型和参考模型。这里有一个平台上的隐藏逻辑：PPO任务模板会自动从模型仓库寻找你训练的reward模型，你需要在配置页面的“reward模型路径”里指定，而不是重新上传一份。如果找不到，初始化肯定会失败。

PPO的另一个关键参数是KL系数（kl_coef），默认0.1。这个值控制与原始策略的偏离程度。如果KL系数太小，模型会变得激进，输出内容可能偏离基座模型太多；太大则PPO效果不明显。我的经验是：先把KL系数设为0.1跑一轮，看平均reward是否上升。如果reward在提升但生成质量变怪，就把KL系数调到0.15重新跑。

PPO训练时的显存消耗通常是SFT的2到3倍。在我的实际测试里，7B模型用LoRA跑PPO，24G显存非常紧张，建议至少使用40G以上的卡，或者利用平台的多卡并行能力。别在单卡上硬跑，否则很容易被OOM中断。

3.4 实测过程中的坑：显存、过拟合、loss异常

这里整理几个最容易出现的问题：

显存OOM不一定是真的不够，有时是代码里同时加载了多个模型副本而没有释放。PPO任务尤其如此，如果发现显存被占满，先检查是否还有上一轮训练的后台进程没关。CubeStudio的任务列表可以看到活动任务，如果平台上没有清理机制，建议每次训练结束后手动把进程结束，或者使用强制重启节点功能。

训练loss为NaN是一个高频问题。我排查下来，原因多半是学习率过高，或数据集中存在超出分词器词表的非法token。你可以先尝试把学习率降到原来的十分之一，如果还NaN，再检查数据清洗流程中是否把换行符或特殊符号留在了文本里，因为某些特殊字符进入BPE分词后会变成未登录token。

过拟合时，语言模型的表现非常典型：训练loss很低但生成内容千篇一律，甚至把你训练集中的固定说法反复输出。这种情况下不要继续加epoch，而是应该直接减小LoRA秩，或者增加数据量来稀释重复模式。

4. 模型压缩一步到位：蒸馏、剪枝、量化在平台上的落地

压缩环节往往是大家最迷茫的部分，因为在学术界剪枝和量化是两套体系，但工业落地经常把它们混着用。CubeStudio把压缩任务单独做成了一个“模型压缩”模板，里面可以选蒸馏、剪枝、量化三个子入口。下面我按实际操作顺序讲。

4.1 剪枝：结构化稀疏怎么选参数

剪枝的核心是去掉权重矩阵中不重要的连接或通道，让模型更稀疏。LLaMA-Factory本身没有内置剪枝算法，但CubeStudio的模板内部封装了常见库，比如nn_pruning和SparseGPT。你在模板中主要判断两个参数：目标稀疏度（保留比例）和剪枝粒度。

剪枝粒度分为非结构化（细粒度）和结构化（通道级）两种。非结构化剪枝能保留更多模型能力，但缺点是在常规GPU上难以加速，因为它产生的是稀疏矩阵，需要特定硬件支持才能提速。结构化剪枝可以直接减少通道，推理速度提升明显，但精度掉得也更厉害。

我在CubeStudio上对7B模型做过结构化剪枝，推荐把目标稀疏度设置在10%到20%之间，不要一上来就干掉50%的权重。比如模型本来有128层，剪掉20%的通道后，实测推理速度提升约15%，但MMLU分数下降2到3个点。如果追求不损失精度，建议选择非结构化剪枝，并将稀疏度控制在30%以内。

有一个排序问题：剪枝应该在量化之前做还是之后做？我的经验是：先剪枝，再量化。先剪枝可以减少后续量化时的数值误差累积。如果先量化，再剪枝，量化的低比特误差会被剪枝放大，导致模型输出变得更不稳定。

4.2 量化：从FP16到INT8/INT4的取舍

量化是压缩环节里最常用也最容易出问题的。CubeStudio的量化模板支持GPTQ、AWQ、Int8量化等主流方案。对7B模型来说，我最常用的是GPTQ做4bit量化，因为它在显存占用和推理速度之间最平衡，而且部署在vLLM上非常方便。

参数选择上，量化有两个关键指标：group size（组大小）和desc_act（是否按列激活顺序量化）。group size常用128，再小一点比如64可以提升精度，但会加大模型体积。desc_act建议开启，它能让量化后的模型更接近原始输出，不过会增加部分计算量。

这里要说一个很多人不知道的点：量化不仅要测困惑度，还要测实际生成质量。因为困惑度低不代表对话连贯性就好。我遇到过一个模型，量化后perplexity只涨了0.1，但回答变得颠三倒四。后来发现是量化过程里某些层被错误合并了，必须重新跑一遍量化任务并检查模型输出的长度分布。在CubeStudio里，你可以在压缩任务完成后直接发起一个“文本生成测试”任务，快速看几个样本的输出，不要等着全量评估。

INT4模型能带来多大的收益？还是以7B模型为例，FP16权重大概14GB，INT4大概4GB，显存占用能下降60%以上。如果你手里的GPU只有24G，原来只能勉强跑FP16 7B模型推理，量化后可以跑更大尺寸的模型，或者给同一模型留出更大的并发请求空间。

4.3 蒸馏：用教师模型带学生模型，不是简单拿logits

蒸馏模板的使用逻辑是：选择一个性能更强的教师模型，一个参数量更少的学生模型，让学生模型去拟合教师模型的输出。CubeStudio里可以设置教师模型路径和学生模型路径，二者可以是同一个家族的模型，也可以完全无关。

我最开始以为蒸馏就是让软标签对齐，直接跑MSE loss。实际跑完才发现，光对齐logits会让学生模型学到过于平滑的分布，导致生成内容没有锐度。更好的做法是在蒸馏loss里混合硬标签和软标签，加上温度系数控制。平台模板里有“温度”参数，我一般设为2.0到4.0之间。

实践中比较有效的蒸馏方案是：教师模型用Qwen2.5-14B-Instruct，学生模型用Qwen2.5-7B或更小的3B模型，数据集可以是通用指令集加上领域数据。训练几个epoch后，学生模型在目标任务上的效果可以达到教师模型的85%到90%，而推理速度能提升接近一半。

蒸馏后的模型还需要继续做量化吗？看情况。如果蒸馏后的学生模型已经是3B级别，再做4bit量化，内存占用会非常低，适合端侧部署。如果学生模型是7B，量化的意义主要是降低部署成本。两者可以叠加，建议顺序为蒸馏、剪枝、量化。

4.4 建议的排列组合顺序

做项目时不要把所有压缩手段一起上，因为相互之间会有副作用。我的默认顺序是：

1. 先做蒸馏，把小模型提起来；
2. 再做结构化剪枝，精简部分通道；
3. 最后做量化，把权重压到INT4。

如果你做的是推理吞吐优化，可以先量化再根据实际profiling决定要不要剪枝。但如果你追求精度优先，就一定按上述顺序来，每一步都记录评估指标，方便回溯。

在这个顺序下，我实测一个7B模型压缩到4bit并剪枝20%后，显存占用从14GB降到4.5GB，推理速度提升约1.8倍，模型的指令跟随能力会有轻微下降，但核心对话能力保持得还不错。这是一个“还能用”的平衡点。如果你把剪枝比例拉到40%，再叠加INT4量化，模型可能就变成傻子了。

5. 安全评估与开放评测：模型不能光看分数

很多项目做到“能对话”就交付了，但我一直认为，没有安全评估和开放评测的模型是不能进生产环境的。CubeStudio把评估环节分成两个主要模板：安全评估和开放评测。前者主要测有害性和偏见，后者测通用能力。二者互补，缺一不可。

5.1 安全评估模板都测什么：越狱、有害内容、偏见

我在CubeStudio上点开安全评估模板，发现它内置了几大类评估集。最基础的是“越狱测试”，用一些对抗性提示词尝试诱导模型突破安全规则，输出不当内容。“有害内容检测”则直接评测模型在特定话题上是否会产生伤害性表述。“偏见测试”看模型在不同性别、地域等维度上是否有刻板印象。

这里要注意，安全评估的结果并不只是一个百分比，平台会给出每条测试样例的通过或拒绝情况。如果发现模型在某些提示词下输出异常，可以把具体样本导出，加入下一轮训练的“拒绝回答”数据里。我第一次跑安全评估时，模型通过率只有60%，后来专门收集了失败样例并做了一轮SFT，把通过率提到了85%以上。

安全评估和通用能力评测经常是矛盾的：安全规则过强，模型会频繁说“我无法回答这个问题”，导致通用能力分数下降。所以你在安全评估上看到高分时，先别急着高兴，要同时盯一下下一个章节的通用评测分数。好的模型是在两者之间找平衡。

5.2 挂上OpenCompass做通用能力评测

开放评测模板通常集成OpenCompass这类框架，它会自动从公开评测集（比如MMLU、C-Eval、GSM8K、BBH）中抽取题目，对模型进行批量测试。CubeStudio上你只需要选择要跑的评测集合，设置并发数量，剩下的评测过程会自动执行。

评测模板有几点要注意。首先是并发度不要开太高。我试过把并发调到8，结果因为GPU显存不够，任务直接崩了。一般7B模型在24G显卡上评估，并发设为2到4即可，同时启用batch推理模式减少显存峰值。其次是数据集选择要跟任务场景匹配。如果你做的是中文对话模型，至少要跑C-Eval和CMMLU；如果是英文场景，MMLU和GSM8K更重要。

每次评测完，平台会把结果以表格形式展示，包含每个子集的准确率。这里我最关心的不是总分，而是分项差异。比如某个模型MMLU分数很高，但BBH却远低于平均水平，说明它的推理链能力偏弱，这种问题在通用对话中不容易暴露，但在复杂任务中会很明显。

5.3 如何把评估结果回灌到训练闭环

评估结果的价值不只是写报告，更重要的是做下一轮迭代的“路标”。CubeStudio允许你在评估任务完成后，把结果导出到项目空间，并与训练任务产生关联。你可以创建一个“迭代清单”，标记哪些数据集表现差，然后回到数据准备流程，补充类似场景的训练数据。

举个例子，我在一次评估中发现模型在代码生成任务上的准确率只有50%，原因是训练数据里缺少多语言代码片段。后来我在数据管理模块中追加了一批Python和SQL样例，重新跑了一遍SFT，代码生成能力提升到了70%。这个循环在平台里非常顺畅，因为你不需要把模型下载到本地再重新上传，直接在项目里选择新的数据集版本和上一轮的模型版本就能继续训练。

安全评估的失败样本同样可以回灌。对于越狱测试中失败的样本，我手动编写对应的安全回答并加入训练集，然后重新SFT。经过两三轮迭代后，模型在安全评估集上的通过率明显提升，而且没有出现普遍的“过度拒绝”现象。

6. 常见问题速查与我的避坑清单

最后这部分完全来自我的实际操作经验，每个问题都是我或身边同事在CubeStudio上真实遇到过的。你可以把这里当成一份速查表，碰到类似情况直接按对策处理。

6.1 训练到一半OOM不是加显存那么简单

OOM是使用大模型平台时最高频的错误之一。很多人第一反应是换更大显存的GPU，但很多时候加显存并不能解决问题。因为OOM的根源可能有三个：模型加载本身太大、训练过程中产生了大量中间激活值、或者旧的进程没有释放显存。

我遇到过一个很典型的情况：同样的7B模型LoRA训练，在24G卡上第一次跑没问题，第二次在同一节点的另一块卡上跑就OOM了。后来排查发现，第一次训练结束后，平台的CUDA context没有被完全释放，导致第二块卡可用的显存变少。这种情况下重启节点比加大显存更有效。

如果确实需要压缩激活值显存，可以尝试开启梯度检查点（gradient checkpointing），这能减少约一半的激活显存，代价是训练速度会下降20%到30%。在CubeStudio的LLaMA-Factory模板里，这个开关叫“activation_checkpointing”，记得勾上。

6.2 量化后模型输出崩了怎么排查

量化后模型出现乱码、重复输出或者完全答非所问，这是最让人头大的问题。不要立刻归咎于量化本身，先按下面的顺序排查：

1. 确认基座模型版本和量化配置一致。不同版本的tokenizer和分词器可能导致解码结果错乱；
2. 检查是否把chat模板用错了。量化本身不改变模型的chat模板，如果你在推理时没有加载与基座模型一致的模板，输出必然崩；
3. 尝试降低量化组大小，比如从128降到64，看是否恢复；
4. 用模型自带的“困惑度”测试工具评估，如果困惑度异常高，说明量化过程出现了数值异常，需要重新量化。

如果降低组大小后依然崩溃，建议改用AWQ算法对比测试。有些模型对GPTQ的校准集非常敏感，换一个校准集或者换一个量化算法往往会得到完全不同的结果。

6.3 模板的默认参数大多数时候不是最优解

平台模板为了兼容各种模型和场景，默认参数会偏向“稳妥”，而不是“最优”。比如LoRA秩默认4，学习率默认2e-5，这些参数在大部分场景下都能跑通，但效果不一定好。我的做法是：先按默认参数跑一个小规模实验（比如只训练200条数据的子集），快速看loss下降速度是否合理，再根据结果放大训练规模。

对于SFT，我通常会把学习率调高到1e-4，LoRA秩调到8或16；对于PPO，把KL系数从0.1调到0.12，同时把PPO epoch数设为3。这些微调带来的是几个百分点的提升，但影响长期迭代的稳定性。始终记录每次实验的超参，方便回溯对比。

6.4 一些好用的“偷懒”技巧

最后分享几个能明显提高效率的操作习惯：

在数据准备阶段，直接用平台提供的“数据去重”功能，能自动过滤掉完全重复的样本。这招非常有用，我处理一个数据集时发现约10%的样本是重复的，去掉后训练收敛速度明显加快。

在评估阶段，先用一个小型评测集（例如每个子集只抽50条）快速跑通流程，确认模型路径和评测框架都配置正确后，再换成完整评测集。别直接跑完整集，否则一旦配置错误，浪费的时间和算力都不少。

在做压缩实验时，把“压缩前模型”和“压缩后模型”同时注册到模型仓库，并在两个模型上都挂一次安全评估。之前就遇到过一个压缩后的模型，通用能力评测没掉多少，但安全评估通过率大幅下降。这种情况说明压缩过程破坏了模型的安全对齐，必须回炉重做。