企业官网建设流程全解析

1. 从"微调完就完事"到"全链路闭环"：大模型任务模板到底解决了什么

很多人做大模型项目，习惯把流程切成好几段：一段人负责跑SFT，另一段人负责搞量化，再有人单独做评估，中间靠共享盘和口头交接。项目小的时候还能凑合，一旦模型参数上到几十B、任务从SFT扩展到PPO再到蒸馏剪枝，这种"手工作坊"式的协作方式立刻崩盘——环境不一致、产物对不上、复现全靠运气。CubeStudio 的大模型任务模板，本质上就是把这套散装流程收进一个平台里，让"微调→对齐→蒸馏→剪枝→量化→安全评估→部署"变成一条可配置、可追溯、可复现的流水线。

我最早接触这类平台化方案，是因为一个很现实的痛点：同一个基座模型，团队里三个人跑出来的SFT结果loss曲线能差出一大截。排查了半天，发现是transformers版本、flash-attention编译参数、甚至CUDA驱动的小版本不一致导致的。这类问题在单机脚本时代几乎无解，因为你没法保证每个人的环境完全对齐。而任务模板的思路是——把环境、依赖、启动命令、超参配置全部固化进一个模板，谁跑都一样。这个价值听起来朴素，但在真实项目里能省掉的沟通成本是巨大的。

这篇文章面向的是已经跑通过至少一次大模型微调、但对"如何把整条链路串起来"还比较模糊的工程师。如果你还在纠结怎么装CUDA，那可能得先补一下基础；但如果你已经能跑通LLaMA-Factory的SFT，却不知道怎么接着做PPO、怎么做蒸馏剪枝量化、怎么在平台上把这些任务编排起来，那这篇就是写给你的。我会围绕CubeStudio的大模型任务模板，把LLaMA-Factory的SFT/PPO/reward、蒸馏、剪枝、量化、安全评估这几块的实际操作逻辑讲清楚，重点放在"为什么这么设计"和"实际跑的时候会踩什么坑"。

需要先说明一点：平台化不是银弹。它解决的是流程标准化和可复现问题，不解决"你的数据质量差"或者"你的算力不够"这类根本问题。所以别指望上了平台模型效果就变好，它只是让你把精力从环境折腾转移到真正重要的地方——数据、超参、评估策略。

2. LLaMA-Factory在平台上的SFT：模板配置里那些容易忽略的细节

2.1 为什么SFT阶段就要考虑后续链路

很多人做SFT的时候只盯着当前任务的loss，完全不考虑后面还要做PPO、蒸馏、量化。结果到了量化阶段发现模型结构里有大量不适合量化的算子，或者SFT时用的chat template和后面reward模型要求的格式对不上，返工成本极高。我的经验是：SFT阶段就要为下游任务预留接口。

具体来说，在CubeStudio的任务模板里配置LLaMA-Factory的SFT时，有几个参数需要提前想清楚。第一是template的选择，它决定了对话格式。如果你后面要用reward模型做打分，reward模型的训练数据格式必须和SFT输出的格式一致，否则reward模型给出的分数就是噪声。第二是finetuning_type，是走LoRA还是全量微调。LoRA省显存、迭代快，但量化时LoRA权重的合并方式会影响最终精度；全量微调效果好但资源消耗大。这个取舍在SFT阶段就得定，不能等到量化时再改。

平台模板的好处在这里体现得很明显：它把这些参数做成了表单化的配置项，并且会在任务提交前做基本的合法性校验。比如你选了LoRA但没指定lora_target，模板会直接报错而不是让你跑到一半才崩。这种"前置校验"看起来是小功能，但能避免大量无效等待。

2.2 数据集挂载与格式转换的实际操作

在平台上跑SFT，数据集通常通过挂载的方式注入容器。这里有个很容易踩的坑：平台挂载的路径和LLaMA-Factory默认读取的路径往往不一致。LLaMA-Factory默认从data/目录读dataset_info.json，但平台可能把数据挂到/mnt/dataset/下面。你需要么在模板里配置软链接，么在dataset_info.json里写绝对路径。

我一般推荐后者，因为软链接在容器重启后可能失效。具体做法是在dataset_info.json里把file_name写成挂载点的绝对路径，比如：

{ "my_sft_data": { "file_name": "/mnt/dataset/sft_train.json", "formatting": "sharegpt", "columns": { "messages": "conversations" } } }

另一个坑是数据格式。LLaMA-Factory支持alpaca和sharegpt两种格式，但很多人拿到的原始数据是自定义格式。这时候要么写转换脚本，要么在dataset_info.json里用columns字段做映射。我见过有人直接把自定义格式的数据丢进去，结果训练loss一直不降，排查半天才发现是字段名对不上，模型根本没读到有效内容。

提示：数据格式转换建议在平台外先做好，用一个小样本验证LLaMA-Factory能正确读取后再上传。平台内调试数据格式的效率很低，因为每次都要重新提交任务。

2.3 分布式训练配置与显存估算

CubeStudio的任务模板支持多机多卡配置，但分布式训练的坑比单机多得多。最典型的是per_device_train_batch_size和gradient_accumulation_steps的配合。很多人为了追求大batch，把per_device设得很大，结果OOM；或者设得很小但忘了调gradient_accumulation，导致等效batch太小、训练不稳定。

显存估算有个粗略公式：模型参数量×精度字节数×4（模型权重+梯度+优化器状态+激活值）。比如7B模型用fp16全量微调，大约需要7×2×4=56GB显存，单张80G卡勉强够，但加上激活值就悬了。这时候要么上LoRA，要么用梯度检查点（gradient checkpointing）。平台模板里通常有gradient_checkpointing的开关，打开后显存能降30%左右，代价是训练速度慢20%-30%。

分布式还有一个容易忽略的点：ddp_timeout。默认是1800秒，但如果你的数据加载慢或者网络存储IO抖动，很容易超时导致训练中断。我一般会调到3600秒，给自己留点余量。

3. PPO与Reward模型：对齐阶段的任务编排逻辑

3.1 Reward模型训练为什么不能和PPO混在一起

有些教程为了省事，把reward模型训练和PPO放在同一个脚本里跑。这在demo阶段没问题，但在平台化流程里是大忌。原因很简单：reward模型训练和PPO的资源配置完全不同。reward模型通常是一个较小的模型（比如7B），训练时batch可以开大；而PPO需要同时加载actor、critic、reward、reference四个模型，显存占用是reward训练的3-4倍。混在一起跑，要么reward训练时浪费资源，要么PPO时显存不够。

CubeStudio的任务模板把这两步拆成独立任务，通过产物传递衔接。reward模型训练完输出到指定路径，PPO任务从该路径加载。这样做的好处是每个任务可以独立配置资源、独立重跑。如果PPO效果不好，你可以只重跑PPO而不动reward模型；如果reward模型有问题，也只重跑reward。

3.2 PPO的四个模型与显存分配实战

PPO阶段是整条链路里最吃显存的。actor和critic通常是同一个基座模型的两个副本（或者critic用单独的小模型），reward和reference是另外两个。以7B模型为例，四个模型都用fp16加载，光权重就占7×2×4=56GB。再加上优化器状态、激活值、KV cache，单卡80G基本不够。

实际配置时，我一般用以下策略：

reward和reference因为不训练，可以用torch.no_grad()包起来，显存占用只有权重本身。actor和critic用LoRA后，可训练参数大幅减少，优化器状态也跟着降。这样一套下来，7B模型的PPO在单张80G卡上能跑起来，但batch size只能开到很小（比如per_device=1，gradient_accumulation=8）。

平台模板里通常会有ppo_batch_size、mini_batch_size这些参数。mini_batch_size决定了每次PPO更新用多少样本，设得太小梯度噪声大，设得太大显存扛不住。我的经验是mini_batch_size设为ppo_batch_size的1/4到1/8比较稳妥。

3.3 PPO训练不稳定的常见原因

PPO本身就以难调著称，在平台化环境里还多了一层变量：任务间的产物传递。我遇到过几次PPO loss突然爆炸的情况，排查下来发现是reward模型输出的分数范围不对。reward模型训练时如果没做归一化，输出的分数可能在[-10, 10]之间波动，而PPO的KL惩罚系数是按[0,1]量级设计的，两者一乘就失控了。

解决办法是在reward模型训练后加一步分数归一化，或者在PPO配置里调kl_coef。平台模板一般会暴露kl_coef这个参数，默认0.1左右。如果reward分数范围大，可以适当调小kl_coef，或者对reward输出做clip。

另一个常见问题是advantage的计算。PPO用GAE（广义优势估计）计算advantage，其中gamma和lambda两个参数影响很大。gamma接近1时看重长期回报，lambda接近1时偏差小但方差大。默认gamma=0.99、lambda=0.95对大多数任务够用，但如果你的reward信号很稀疏，可能需要调大gamma。

4. 蒸馏、剪枝、量化：模型压缩三件套的平台化实操

4.1 蒸馏：teacher模型的选择与中间层对齐

蒸馏的核心是用一个大模型（teacher）指导一个小模型（student）训练。在CubeStudio的任务模板里，蒸馏任务需要配置teacher模型路径、student模型结构、蒸馏损失函数和温度系数。

teacher模型的选择有个原则：teacher不一定要最强，但一定要和student的任务分布匹配。我见过有人用通用大模型蒸馏一个垂直领域的小模型，结果student学到的全是通用知识，领域效果反而下降。更好的做法是先用领域数据微调一个teacher，再用它蒸馏student。

温度系数temperature控制soft label的平滑程度。温度高时soft label分布更均匀，student能学到更多"暗知识"；温度低时接近hard label，蒸馏效果退化。一般设2-5之间，具体看任务。平台模板里通常有temperature和alpha两个参数，alpha控制soft loss和hard loss的权重，一般0.5-0.9之间。

中间层对齐是进阶玩法，需要teacher和student的隐层维度匹配或者加投影层。这块在平台模板里支持程度不一，有些模板只支持logits蒸馏，有些支持hidden states蒸馏。如果你的平台只支持logits蒸馏，那student结构可以自由一些；如果要hidden states蒸馏，student的层数和维度就得和teacher有对应关系。

4.2 剪枝：结构化vs非结构化的取舍

剪枝分结构化（structured）和非结构化（unstructured）两种。非结构化剪枝把单个权重置零，压缩率高但需要专门的稀疏计算库才能加速；结构化剪枝直接砍掉整个神经元或注意力头，压缩后是标准稠密模型，部署友好。

在平台化流程里，我一般推荐结构化剪枝，因为它的产物能直接进入后续的量化流程。非结构化剪枝后的稀疏模型，量化工具往往不支持，还得先做稀疏到稠密的转换，多一道工序。

剪枝的关键参数是剪枝率和剪枝粒度。剪枝率太高模型能力断崖式下降，太低没意义。我的经验是从10%-20%开始试，每剪一次做一次评估，找到效果和压缩率的平衡点。剪枝粒度可以是layer、head、neuron，粒度越细越灵活但实现越复杂。平台模板一般支持按head或neuron剪，配置里指定pruning_ratio和pruning_type即可。

剪枝后一定要做微调恢复（fine-tune recovery），否则精度损失很难接受。恢复训练用原训练数据的一小部分就行，学习率调小（比如原学习率的1/10），跑几个epoch。这一步在平台模板里通常作为剪枝任务的后置步骤自动触发。

4.3 量化：int8、int4与部署格式的对应关系

量化是把fp16/bf16的权重转成低比特表示，减少显存占用和推理延迟。常见的量化方案有：

量化在平台上的操作通常是：加载微调后的模型→校准数据集前向传播→计算量化参数→保存量化模型。校准数据集的选择很重要，它决定了量化参数的分布。一般从训练集里随机采样128-512条即可，太多没必要，太少统计不准。

量化后的模型格式要和部署框架匹配。比如vLLM支持GPTQ和AWQ，TensorRT-LLM有自己的量化格式，ONNX Runtime又不一样。平台模板一般会提供多种导出格式选项，选之前先确认你的推理框架支持哪种。

注意：量化不是无损的，int4量化后模型在某些任务上可能有明显退化。建议量化后跑一遍完整评估，对比量化前后的指标差异。如果退化超过可接受范围，要么换量化方案，要么对敏感层保持高精度。

5. 安全评估与OpenAPI封装：链路最后一公里的工程细节

5.1 安全评估该评什么、怎么评

安全评估不是跑一个脚本打个分就完事。它至少应该覆盖几个维度：有害内容生成率、偏见与歧视、隐私泄露风险、指令遵循的边界。在平台化流程里，安全评估通常作为一个独立任务，输入是微调量化后的模型，输出是一份评估报告。

评估数据集的选择很关键。公开的安全评估集（如toxicity、bias相关数据集）可以作为基线，但最好再构造一批领域相关的对抗样本。比如你的模型用于客服场景，就要测试它在面对诱导性提问时会不会输出不当内容。

评估指标方面，有害内容生成率是最直观的，但它的判定本身就需要一个分类器或人工标注。平台模板里一般会集成一个安全分类模型做自动判定，但自动判定的准确率有限，高风险场景还是得人工抽检。

5.2 OpenAPI封装：从模型到服务的最后一跳

模型量化完、评估通过后，最后一步是封装成API供业务调用。CubeStudio的任务模板通常支持一键部署，把模型加载到推理服务里，暴露OpenAI兼容的接口。这一步的坑主要在并发和显存管理上。

推理服务的显存占用和训练不一样，它主要吃KV cache。并发请求越多，KV cache越大。如果显存不够，要么限制并发数，要么用PagedAttention这类技术做显存分页。平台模板里一般有max_num_seqs和gpu_memory_utilization两个参数，前者控制最大并发序列数，后者控制显存使用上限。

另一个坑是模型加载时间。大模型从磁盘加载到显存可能要几分钟，如果服务重启频繁，这段时间业务就不可用。解决办法是用模型预热，服务启动后先跑几条请求把KV cache和CUDA kernel都初始化好，再接入流量。

6. 整条链路跑下来，我踩过的那些坑

第一个坑是产物路径不一致。SFT任务输出的模型在/output/sft_model，但PPO任务默认从/models/base加载。平台模板之间如果没有做好路径约定，每个任务都要手动改路径，很容易出错。我的做法是在平台的项目配置里定义一个全局的MODEL_OUTPUT_DIR变量，所有任务都引用这个变量，改一处全生效。

第二个坑是版本漂移。LLaMA-Factory更新很快，不同版本之间的参数名可能变化。比如早期版本用lora_rank，后来改成lora_r。如果平台模板锁定的版本和你本地测试的版本不一致，配置就会报错。建议在模板里明确锁定依赖版本，不要用latest。

第三个坑是评估指标不可比。SFT阶段用loss，PPO阶段用reward score，量化后用准确率，这些指标之间没有直接可比性。我见过有人拿SFT的loss和量化后的准确率对比，得出"量化后效果变差"的结论，其实两者根本不是一个维度。正确的做法是在每个阶段都跑同一套评估基准，用统一的指标追踪效果变化。

第四个坑是资源申请过大导致排队。平台上的GPU资源通常是共享的，如果你申请8卡但实际只用2卡，任务会一直排队等8卡空闲。建议先用小资源跑通流程，再根据实际需求调整。CubeStudio的模板一般支持资源规格选择，从单卡到多卡都有，按需选就行。

第五个坑是日志丢失。分布式训练时日志分散在多个节点，如果没做集中收集，排查问题很麻烦。平台模板一般会把日志汇总到统一路径，但要注意日志级别。默认INFO级别可能不够，调试时调到DEBUG，但DEBUG日志量很大，跑完记得调回来。

7. 一些让流程更顺的个人习惯

我在用CubeStudio跑大模型任务模板时，养成了几个习惯，分享出来供参考。

第一个习惯是先跑通再调优。不要一上来就配最优参数，先用小模型、小数据、少卡把整条链路跑通，确认每个环节的输入输出都对得上，再逐步放大。这样即使出问题，排查范围也小。

第二个习惯是每个任务都留checkpoint。SFT留、PPO留、蒸馏留、剪枝留、量化也留。平台存储便宜，但重跑一次任务的时间成本很高。留checkpoint意味着任何一步出问题都能从最近的节点恢复，而不是从头再来。

第三个习惯是评估脚本独立于训练脚本。训练脚本里带的评估往往只算loss，不够全面。我一般单独写一个评估脚本，加载模型后跑一套完整的测试集，输出准确率、召回率、F1、生成质量等指标。这个脚本在平台里作为独立任务，可以随时对任意阶段的模型跑。

第四个习惯是配置即代码。平台模板的配置项虽然可以在界面上填，但我习惯把配置导出成YAML文件，纳入版本管理。这样每次实验的配置都有记录，复现的时候直接加载YAML就行，不用回忆当时填了什么。

第五个习惯是关注数据质量而非模型大小。跑了这么多任务下来，最大的体会是：数据质量对最终效果的影响远大于模型大小和微调方法。同样的7B模型，清洗过的数据比脏数据的效果能高出20%以上。所以与其纠结用LoRA还是全量、用PPO还是DPO，不如先把数据清洗和格式对齐做好。

这套流程跑顺之后，从SFT到部署的周期能从原来的两三周压缩到几天。但前提是每个环节都理解透彻，而不是机械地填参数点提交。平台是工具，工具用得好不好，还是看用工具的人对背后原理的理解深度。