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权重或全量模型可以直接被后面的量化任务引用不需要自己复制路径。举例来说一个典型的项目流程是创建“数据准备”任务把原始JSON清洗成LLaMA-Factory要求的格式创建“LLaMA-Factory训练”任务配置SFT或PPO参数训练完成后在模型仓库中注册一个模型版本对该版本创建“模型压缩”任务选择蒸馏、剪枝或量化模板对压缩后的模型创建“安全评估”和“开放评测”任务。每个任务启动后平台会自动分配容器和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型号。经验配置参考如下模型规模微调方式最小算力要求推荐GPU1B ~ 3BLoRA16GB显存可跑RTX 4090 / A107B ~ 13BLoRA24GB显存起步A100 40G / 40907B全参数至少32GB显存A100 80G70B以上LoRA单卡基本跑不动多卡A100或分组并行存储方面平台会默认给你一块项目空间但要注意模型权重下载路径。我第一次把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就行不要一上来就拉高。很多教程说秩越大模型越灵活但对指令微调来说rank8通常足够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和rejectedbatch越大比较越准确但显存占用也越高。如果显存不够不要盲目减小batch可以尝试开启梯度累积。一般来说在24G显存上对7B模型做LoRA训练rewardbatch 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跑PPO24G显存非常紧张建议至少使用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权重大概14GBINT4大概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 建议的排列组合顺序做项目时不要把所有压缩手段一起上因为相互之间会有副作用。我的默认顺序是先做蒸馏把小模型提起来再做结构化剪枝精简部分通道最后做量化把权重压到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 量化后模型输出崩了怎么排查量化后模型出现乱码、重复输出或者完全答非所问这是最让人头大的问题。不要立刻归咎于量化本身先按下面的顺序排查确认基座模型版本和量化配置一致。不同版本的tokenizer和分词器可能导致解码结果错乱检查是否把chat模板用错了。量化本身不改变模型的chat模板如果你在推理时没有加载与基座模型一致的模板输出必然崩尝试降低量化组大小比如从128降到64看是否恢复用模型自带的“困惑度”测试工具评估如果困惑度异常高说明量化过程出现了数值异常需要重新量化。如果降低组大小后依然崩溃建议改用AWQ算法对比测试。有些模型对GPTQ的校准集非常敏感换一个校准集或者换一个量化算法往往会得到完全不同的结果。6.3 模板的默认参数大多数时候不是最优解平台模板为了兼容各种模型和场景默认参数会偏向“稳妥”而不是“最优”。比如LoRA秩默认4学习率默认2e-5这些参数在大部分场景下都能跑通但效果不一定好。我的做法是先按默认参数跑一个小规模实验比如只训练200条数据的子集快速看loss下降速度是否合理再根据结果放大训练规模。对于SFT我通常会把学习率调高到1e-4LoRA秩调到8或16对于PPO把KL系数从0.1调到0.12同时把PPO epoch数设为3。这些微调带来的是几个百分点的提升但影响长期迭代的稳定性。始终记录每次实验的超参方便回溯对比。6.4 一些好用的“偷懒”技巧最后分享几个能明显提高效率的操作习惯在数据准备阶段直接用平台提供的“数据去重”功能能自动过滤掉完全重复的样本。这招非常有用我处理一个数据集时发现约10%的样本是重复的去掉后训练收敛速度明显加快。在评估阶段先用一个小型评测集例如每个子集只抽50条快速跑通流程确认模型路径和评测框架都配置正确后再换成完整评测集。别直接跑完整集否则一旦配置错误浪费的时间和算力都不少。在做压缩实验时把“压缩前模型”和“压缩后模型”同时注册到模型仓库并在两个模型上都挂一次安全评估。之前就遇到过一个压缩后的模型通用能力评测没掉多少但安全评估通过率大幅下降。这种情况说明压缩过程破坏了模型的安全对齐必须回炉重做。