企业官网建设流程全解析

做这行三四年，处理过大大小小几十个微调项目后，我越来越体会到一件事：大模型落地的难点，早就不只是“跑通一个训练脚本”这么简单。真正磨人的是从数据准备、SFT微调、对齐、压缩到评估这一整条流水线。中间随便哪个环节断一下，前面几天的功夫可能全白费。最近团队在 CubeStudio 平台上把这条链路完整梳理了一遍，用它可以一站式跑完 LLaMA-Factory 的 SFT / Reward / PPO 微调，接着做蒸馏、剪枝、量化，最后还能直接做安全评估和效度评测。写这篇东西是想把我实际操作中的步骤、参数和踩过的坑都记录下来，给正准备上车的朋友一个能直接“抄作业”的参照。

这套模板尤其适合两类人：一类是公司里要落地私有模型的算法工程师，不想每次都在本地环境折腾依赖和GPU调度；另一类是对微调有一定了解、但还没系统做过“训练后压缩+评估”的进阶选手。接下来我按自己的真实操作顺序来拆，每一步都给出可复现的配置和关键参数，也把为什么这么做的逻辑讲清楚。

1. 内容整体设计与思路拆解

1.1 为什么要把微调和压缩评估放在一起

先说个亲身体会。以前做项目，微调通常在一批服务器上治理好环境跑完，量化剪枝又是另一套环境，评估还得再开一台机器装依赖。数据、配置、模型权重全部靠人肉搬，光版本对齐就能耗掉半天。更麻烦的是，微调后的模型往往带了训练框架的特殊标记（比如 LoRA adapter），如果后续压缩工具不认识这种模型格式，你又得先合权重再转格式，中间很容易出岔子。

CubeStudio 这类的平台化任务模板，核心思路就是把这些环节拆成一个个“任务卡片”，每个卡片对应一段固定流程，底层环境、依赖、脚本全部预置好。你要做的只是填参数、选数据、点运行。这样最大的好处是流程可复现，换个人来操作也是同样结果。团队协作的时候，别人看你的任务记录就知道你用了什么镜像、什么超参，不用再逐条截图解释。

另一个关键点是资源管理。训练和评估对 GPU 的需求不同，微调阶段要显存大，量化评估阶段要 CPU 和内存调优。如果全部手工管理，要么高峰期抢卡，要么非高峰期卡闲着。平台的任务模板能按阶段申请不同规格的资源，比如 SFT 阶段用 8 卡 A100，量化阶段用单张 4090，成本更可控。

1.2 模板里包含的完整闭环

我们这次跑通的流程，按顺序包含六个环节：

1. 数据准备与预处理：把原始数据集统一成模型训练需要的 JSON 格式，做 train / validation 切分。
2. 基座模型加载：从模型仓库拉取 Qwen、LLaMA 或 Llama 3 系列这类开源权重。
3. 三阶段对齐训练：先 SFT 做指令微调，再用 Reward 模型打分，最后 PPO 做强化学习对齐。
4. 模型压缩：训练完成后做蒸馏、剪枝或量化，让模型变小、变快，适合线上部署。
5. 安全与能力评估：通过 OpenCompass 等评测工具跑通用能力和安全指标，验证压缩后的模型没有明显能力劣化。
6. 产物导出：把最终的模型权重和 tokenizer 一起打包，供下游服务使用。

每个环节都对应 CubeStudio 里的一个模板。你不需要自己写胶水代码，模板之间可以串联，前一个环节的输出自动作为后一个环节的输入。这就是“一站式”的意义：不是把脚本堆在一起，而是把依赖关系和工作流固化了。

2. 环境准备与模板选型

2.1 工作台配置：镜像、数据和算力选择

第一次进 CubeStudio 工作台，别急着跑任务。先把三件事确认好。

第一个是镜像。平台一般会预置 PyTorch + CUDA 的基础镜像，但微调时最好直接用带 LLaMA-Factory 的镜像，省去安装依赖的时间。我们用的是cubestudio/llama-factory:latest，里面对 transformers、peft、deepspeed 的版本都做了验证，不会再出现ImportError: cannot import name 'AutoModel' from 'transformers'这种低级问题。如果自己装，建议锁版本：transformers>=4.36,<4.40、peft>=0.7.0、torch>=2.1.0，这几个版本组合在 LLaMA-Factory 里测试得最充分。

第二个是数据集。模板默认支持 json 和 jsonl 格式。指令微调的数据要先整理成统一字段：conversations，里面是{"from": "human" / "gpt", "value": "..."}的序列。如果是从 alpaca 格式转过来的，字段名一般是instruction、output，需要一次预处理换成conversations。平台的任务模板首页通常带“数据集预览”功能，能看到条数和前几条内容，这一步能做简单的文本格式检查，发现对话对不齐就直接改，不要等训练跑起来才报错。

第三个是算力。SFT 阶段我们用的 8 卡 A100（80G），batch size 每卡 4，总 batch 32。如果只是做 LoRA 微调一个 7B 模型，单卡 4090 也能跑，只是速度慢些。PPO 阶段因为要同时跑四个模型（Actor、Reward、Critic、Reference），显存开销比 SFT 大不少，建议至少 4 卡 A100，否则很容易 OOM。量化评估阶段用 CPU 也能跑，但推理速度会明显慢，还是建议留一块 GPU。

2.2 任务模板的创建和串联逻辑

在 CubeStudio 里，一个“项目”下面可以建多个“任务”。任务之间用“产物”关联。比如 SFT 任务的输出是模型 checkpoint，这个 checkpoint 会自动挂到产物列表里，后续的 Reward 任务新建时就能直接选它作为初始模型。

一个小技巧：命名要按阶段统一打前缀。我们习惯这样：

• 01-sft-7b-lora
• 02-reward-7b
• 03-ppo-7b-lora
• 04-distill-7b-to-3b
• 05-prune-30pct
• 06-quantize-int4
• 07-eval-safe

这样做的好处是任务列表里按名称排序就是完整流程，后面找日志、对产物都非常清楚。尤其是多人协作时，光看日志记录里的任务名就能快速定位问题出在哪一环。

模板里有几个默认参数要改掉，不能直接点“开始”就跑：

• model_name_or_path：要填具体的模型名，比如Qwen/Qwen2.5-7B-Instruct，默认可能是空占位符。
• dataset_dir：指向你的数据集路径。
• output_dir：建议填成./runs/{task_name}，后面找产物方便。
• finetuning_type：lora（我们常用）、full或freeze。满参数微调对显存要求极高，7B 全参微调没有 48G 以上的卡基本不要想。

2.3 不同模板的适用场景和选型标准

每个模板不是独立的玩具，它背后对应一种业界主流方案：

• SFT 模板：底层调llamafactory-cli train，指定stage: sft。适合快速把模型调成服从指令的风格。
• Reward 模板：训练一个打分模型，输入是“提示词+回答”，输出一个标量分数。这个分数用来指导 PPO。
• PPO 模板：基于 Actor、Reward、Critic 做强化学习，让模型在保留原有能力的同时，更倾向于输出高分回答。
• 蒸馏模板：一般用 KL 散度或特征对齐方式，利用大模型（Teacher）的 soft label 来训练小模型（Student）。
• 剪枝模板：按权重重要性或结构稀疏度去除不重要的通道，能显著降低推理显存。
• 量化模板：把 FP16 权重转成 INT8 或 INT4，配合 GPTQ / AWQ / GGUF。量化后体积减少一半以上，推理速度提升明显，但会有一定精度损失。

选型标准我一般这么掂量：如果时间紧、资源少，只做 SFT + 量化就够用；如果要做高质量对齐，就补上 Reward + PPO；如果追求极致推理性能，就上蒸馏 + 剪枝 + 量化三层组合。压缩手段不建议一上来全上，先单测量化，看精度下降能不能接受，再考虑要不要加蒸馏。

3. 核心实操：LLaMA-Factory 微调三件套 SFT / Reward / PPO

3.1 SFT 指令微调：参数配置和训练日志解读

我用的模板配置如下（关键项），以 7B LoRA 为例：

model_name_or_path: Qwen/Qwen2.5-7B-Instruct dataset_dir: ./data/sft_data.json stage: sft finetuning_type: lora lora_rank: 32 lora_alpha: 64 learning_rate: 2e-5 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 max_length: 2048

前三个 epoch 之后，我通常会再用 0.5 个 epoch 在 validation 集上跑一次，观察 loss 是否反弹。这里有件事值得特别留意：LoRA 的训练会冻结原始权重，只更新 adapter 部分。所以训练完的产物是 adapter 文件，不是完整模型。如果后面直接拿去量化，量化工具会一脸懵——它们只认识完整权重。因此 SFT 结束后必须先做一步“合并 adapter 到 base model”。在 LLaMA-Factory 里是这样的命令：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./runs/01-sft-lora \ --export_dir ./models/07b-sft-merged \ --export_size 5 \ --export_legacy_format false

这一步不要在训练模板里做，因为训练模板重活是训练，合并是轻量操作。CubeStudio 支持自定义命令，可以写一个 shell 脚本作为新任务。我建议单独建一个“sft-merge”任务，不然训练完成后临时又去改输入输出，很容易出错。

训练日志里重点看两个指标：loss 是否稳定下降，valid loss 是否早停。还有一个容易被忽略的点：gradient_accumulation_steps和per_device_train_batch_size的乘积决定了全局 batch size，这个值不要太大也不要太小，经验值在 32 到 64 之间比较稳妥。太大收敛慢，太小容易震荡。

3.2 Reward 模型训练：构建偏好数据的两个要点

Reward 模型本质是从人类偏好中学习“什么答案更好”。CubeStudio 的 Reward 模板底层用的是 LLaMA-Factory 的stage: rm。训练数据格式是：

{ "instruction": "如何缓解焦虑", "input": "", "output": ["答案A", "答案B"], "prefer": 1 }

这里prefer表示哪一个回答更好，注意下标从 0 开始，所以prefer: 1代表答案B更好。

训练时模板会自动把两个回答拼在一起，用同一个模型分别算出得分，用 pairwise loss 拉大好坏差距。实操中有两个坑：

第一，偏好数据里的“好”和“坏”要拉开差距。如果只是“一个比较详细”和“另一个稍微不够详细”，Reward 模型学不到东西。最好让坏回答像是“网上随便复制的一段话”，好回答是“结构清晰、有步骤、讲证据”。这样模型才能学到实质差异。

第二，Reward 模型不能和 SFT 模型用同一个 LoRA 权重初始化。因为训练目标完全不同，Reward 模型最后学到的分数分布和语言建模分布不是一回事。所以新建任务时，基座模型依然用Qwen/Qwen2.5-7B-Instruct，adapter 为空。

训练完成后，导出奖励模型也别忘了合并 LoRA。合并后可以写一个简单脚本验证：随便输入几个提示词，看看好回答、坏回答得分是否拉开。如果分数只差零点几，说明数据质量有问题，先回去清洗数据，而不是继续调参。

3.3 PPO 强化学习：稳定训练的七个实操建议

PPO 模板是三者中最“娇气”的。我踩过的坑如果能堆起来，相当于一个小型故障手册。这里的建议给到按优先级排列：

1. 训练步数不要贪多。建议先跑 1000 步观察，而不是一上来 10000 步。PPO 的 loss 波动天然比 SFT 大，如果 1000 步内 reward 均值持续下降，说明 reward 模型本身有问题，先回头看数据。
2. clip 参数不要乱动。ppo_max_token_len和clip_ratio保持默认即可。很多同学喜欢调大 clip 范围，结果策略更新太猛，模型直接崩掉。
3. 参考模型必须冻结。模板里默认 freeze reference model，一定不要把它设成可训练，否则 PPO 很快会失去目标。
4. 学习率调小。PPO 的 actor 学习率一般设在1e-6到3e-6之间，比 SFT 小一个数量级。调大容易产生奖励 hack，模型输出一些看似高分但语义不通的内容。
5. Critic 模型约束。有的模板里 Critic 和 Actor 共享参数，这样还不如分开。如果显存够，建议把 Critic 模型单独初始化，保证价值网络可以独立学习。
6. 监控 KL 散度。每一步更新后，actor 和 reference 输出的 KL 散度要在某个范围内。如果 KL 涨得过快，说明策略偏离初始模型太远，生成的文本容易退化。
7. 始终保留 SFT 的 checkpoint。PPO 训练意外中断时，最好是回到 SFT 的 merged 模型重新启动，不要从半路崩溃的 actor 继续，否则灾难已经种下，后面只是显性化。

一次稳定的 PPO 跑完后，对比 SFT 模型，你会看到同样的提示词下输出更“克制”了，不再长篇大论堆砌无意义内容，而且明显更符合人类偏好。这才是强化学习该有的样子。

3.4 三阶段之间的产物衔接

三阶段跑完之后，你会有三个关键产物：SFT merged 权重、Reward merged 权重、PPO actor merged 权重。这里有个实际选择：最终部署时到底用哪个？

绝大多数场景下，PPO 后的模型效果最好，但如果你的业务强调稳定性和可控性，SFT 模型往往更可靠。Reward 模型一般不直接参与对话，它只用于给回答排序或在 PPO 内作为信号源。所以最终部署一般选 PPO（如果有）或 SFT 模型。

产物衔接要特别注意路径一致性。CubeStudio 里新建任务时，输入模型下拉框里可能同时出现多个产物，选错一个后面全错。我们总结了命名规范后，这种情况少了很多，但还是会在启动前再核对一下任务描述里填的模型路径。

4. 模型瘦身实战：蒸馏、剪枝和量化

4.1 知识蒸馏：从 7B 压到 3B 的实操记录

我们遇到一个真实场景：模型要从 7B 压缩到 3B，以适配边缘推理卡。直接用 3B 基座做 SFT 效果一般，于是用了蒸馏方案——7B 的 PPO 模型当 Teacher，3B 基座当 Student，目标是最小化两者输出的 KL 散度。

CubeStudio 的蒸馏模板参数大概是这样：

teacher_model: ./models/07b-ppo-merged student_model: Qwen/Qwen2.5-3B temperature: 4 alpha: 0.5 loss_type: kl

温度参数temperature设 4，是做蒸馏时常用的软化概率分布设置。学生的学习目标包含两部分：一是硬标签（真实答案）的交叉熵，二是软标签（Teacher 输出的概率分布）的 KL 散度。alpha控制这两者的权重，我们试了 0.3 太小、0.7 太大，0.5 比较均衡。

蒸馏后的小模型在大部分测试集上能保留教师模型九成的能力。但有一点必须注意：如果 Teacher 本身有偏见，蒸馏会把偏见也复制到 Student 上。所以蒸馏之前，尽量确保 Teacher 通过安全评估，避免偏见被放大。

实操中还有个小技巧：蒸馏时不要用最高温度的 teacher 输出，因为温度太高会稀释太厉害。一般试 4 或 6，分别跑一个小样本实验，对比 Student 在验证集上的 loss 和指标，再选最优。

4.2 剪枝：结构化剪枝比非结构化更实用

剪枝模板解决的是“模型里很多参数其实权重很小、没什么用”的问题。我们用的是结构化剪枝，直接剪掉输出通道维度上不重要的部分。模板参数：

pruning_method: magnitude pruning_ratio: 0.3 target_module: all_linear

pruning_ratio表示剪掉百分之三十的通道。这个值建议从 0.2 开始试，每次加 0.1，然后跑评估看掉点速度。7B 模型剪 20% 通常掉点不大，剪 50% 就可能出现胡言乱语。

剪枝后必须接一个微调恢复阶段，俗称“蒸馏式恢复”。直接用剪枝模型在线推理，效果往往不太理想，因为权重稀疏度和数据分布发生了变化。我们之后会在一个小的指令数据集上再做 1 个 epoch 的 LoRA 微调，把能力拉回来一些。如果没有这个恢复步骤，剪枝收益会被精度损失抵消。

剪枝和量化的先后顺序也有讲究。我的建议是先剪枝再量化。剪枝会改变权重分布，而量化对这种分布变化很敏感。如果先量化再剪枝，量化误差和剪枝误差会叠加，效果更差。两人都以“先做影响小的操作”为原则，我们亲测结果是这个顺序比反着来精度平均高 3 到 5 个百分点。

4.3 量化：INT4 / INT8 的选择与精度评估

量化是压缩环节里最立竿见影的。一个 7B FP16 模型占 14GB 显存，量化成 INT8 占 7GB，INT4 占 4GB 左右。CubeStudio 的量化模板可以选 GPTQ、AWQ、GGUF 三种方案。

我的经验：

• GPTQ：适合 NVIDIA GPU 上的推理，精度损失在 INT4 下比较可控。它对校准数据比较依赖，校准集不要用训练集，用单独的样本。
• AWQ：它根据激活感知选出重要权重通道做高精度保留，所以 INT4 下效果往往比 GPTQ 更稳一点，尤其适合 7B 以下模型。
• GGUF：主要给 llama.cpp 这类 CPU 推理框架使用。如果你要部署到纯 CPU 环境或本地方便工具，选它。

量化命令模板（以 GPTQ INT4 为例）：

quant_method: gptq bits: 4 group_size: 128 desc_act: true calibration_dataset: ./data/calib_samples.jsonl

group_size是量化分组的大小，越小精度越高，但会带来更长的编码时间和更大的模型文件。desc_act表示按激活值排序来重排通道，对 INT4 精度有帮助，但会增加一点推理开销。

量化后的模型一定要跑一遍评估。很多同学看到“体积减少一半”直接上线，结果线上连续掉点，投诉不断。我建议量化评价至少包含三个测试集：通用指令集、领域任务集、安全测试集。这个组合能同时观察能力保留和安全性。

4.4 压缩组合拳的顺序

如果项目对模型体积和速度有极致要求，可以按“蒸馏 -> 剪枝 -> 量化的恢复微调 -> 最终量化”的顺序来。为什么这个顺序合理？蒸馏已经缩小了规模，剪枝再进一步去除冗余，最后量化进一步压体积。每一步都建立在上一步更干净的模型基础上。

还要注意一点：剪枝和量化后的模型如果要做安全评估，评估结果不能直接和原模型对比。因为压缩后模型的能力分布变了，安全评估的阈值要适当调整。我们的做法是优先保证安全指标不劣化超过 2%，若超过，回到量化校准集或剪枝比例上找原因。

5. 安全评估与上线检查

5.1 用 OpenCompass 跑通用能力评测

微调和压缩做完，不能直接拍脑袋说“效果不错”。要用标准评测集验证。CubeStudio 的评估模板集成了 OpenCompass，支持 MMLU、CMMLU、GSM8K、HumanEval 等主流基准。

我的操作流程分两层：

第一层，快速摸底。选三个有代表性的测试集：MMLU（综合知识）、GSM8K（数学推理）、HumanEval（代码）。跑一次大概二十分钟，作为压缩前后的横向对比。

eval_dataset: mmlu, gsm8k, humaneval eval_batch_size: 8

第二层，深度评估。对业务相关领域单独测试。比如做法律垂直模型，就跑法律问答集；做金融模型，就跑金融指令集。OpenCompass 模板里可以自定义eval_dataset路径，直接指向我们自己的测试 JSON 文件。

评测结果会输出每个测试集上的准确率、困惑度等指标。我最看重的是“压缩前后掉点幅度”。比如量化后 MMLU 从 72% 掉到 70%，这个是正常范围；如果从 72% 掉到 60%，说明量化参数需要调整，或者校准数据集和业务数据分布差异太大。

5.2 安全评估：不仅要看“违不违规”，更要看“边缘试探”

合规底线是所有模型上线前的硬检查。安全评估模板一般用规则 + 模型两种方式结合：规则匹配一些明显违规词和意图模式，模型则用一个安全判别模型对输出做分类。

实际操作中，光用“安全分类为安全/不安全”这种粗粒度不够。我们通常自定义几类风险提示词，比如：

• 诱导模型输出危险操作步骤
• 要求模型扮演某种不合适的角色
• 用反问语气诱导模型透露底层隐私信息

这些输入跑一遍，记录模型的响应是否被直接阻止，或是否给出合理拒绝。安全评估报告会生成一个“拒绝率”和“不安全命中率”。

一个容易被忽略的细节：安全评估不仅要测正常输入，还要测“对抗性输入”。比如把提示词用大小写混写、同音字替换、emoji 插入等方式变形，看模型是否还能正确拒绝。我们实测发现，很多模型在正常讨论时很安全，但提高编码度之后就开始松口。所以评估模板里我建议要加“jailbreak”测试集，哪怕只有二十条，也能暴露出不少问题。

5.3 上线前的最终检查清单

在把模型推到真实环境前，我会逐项核对：

• 模型完整性和版本号：从产物列表中确认是最终 PPO 模型还是 SFT 模型，别拿错版本。
• Tokenizer 一致性：微调阶段有没有加新词？新词必须在最终权重里保留。
• 上下文长度限制：训练最大长度是多少，线上输入如果超长，服务端要做好截断或提示。
• 温度参数：评估时用的温度和线上推理温度要一致，否则指标对不上。
• 量化校准集信息：如果量化有用校准集，这个数据集要留存，方便复现或调整。
• 评测结果存档：把评测配置、结果、日志一起归档到项目里，方便下次复盘。

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

6.1 任务启动即失败：先查三件事

当你点“运行”后几秒就失败，经验上九成是这三件事之一：

第一，模型路径不对。确认你选的model_name_or_path在平台里真的存在。不要在本地想当然写./models/qwen，要先在产列表中复制路径。

第二，数据集格式不符。模板检查到 JSON 格式缺失instruction或output字段时，会直接报错。用模板自带的数据预览功能，上传后先看前几条。

第三，GPU 资源超限。检查任务申请的资源是否超过套餐额度。有时候同一个项目里并发任务太多，导致 GPU 配额抢不到。看任务状态的错误信息，如果是CUDA out of memory，则是显存不足；如果是Quota exceeded，则是资源配额问题。

6.2 训练中断与断点恢复

训练中途断网或任务被中断，心态容易崩，但其实有救。CubeStudio 任务支持断点续训，前提是要开启save_strategy: steps和save_on_train_end: true。在 SFT 和 PPO 任务模板里都建议开。

如果模板没有自动检查点，也可以自己写任务命令：

deepspeed --include localhost:0,1,2,3 --master_port 9901 \ src/train_bash.py \ --stage sft \ --model_name_or_path ... \ --checkpoint_dir ./runs/01-sft-lora \ # 从断点继续 ...（其余参数不变）

这个重训逻辑很实用。不过要注意：PPO 任务的断点续训偶尔会出现 reward 跳变，我们遇到好几次从断点续跑后 reward 均值暴跌，最后方案就是从头跑。所以 PPO 任务如果中途断了超过 2 个小时，干脆直接从头开始更省心。

6.3 量化后模型效果跳水

量化后掉点太多，先不要怀疑模型，优先检查这几个方向：

• 校准数据太少。GPTQ 校准一般至少需要 128 条，太少会低估权重的分布。
• desc_act是否开启。INT4 下不开desc_act，有些矩阵精度会明显下降，尤其是一些特征范围特别大的层。
• 是否有模型结构兼容问题。量化后的模型加载时，要用对应的量化版片段。用普通的AutoModelForCausalLM直接加载 GGUF 是加载不了的，必须配合对应推理框架。

还有一个常用技巧：量化后进行“感知量化训练”。这里不是重新训练，而是在模型上跑一段 10 到 20 分钟的小学习率微调，来修复量化带来的分布漂移。模板里如果有post_quantize_ft选项，可以试试。

6.4 PPO 训练不收敛时的排查路径

PPO 不收敛，先画三张图：actor loss、critic loss、reward mean。判断依据：

• reward mean 一路向下，先怀疑 reward 模型质量，回去查偏好数据。
• reward mean 上升到某一值后突然崩溃，往往是 KL 惩罚太大导致策略剧烈变化，把kl_coef调小一点。
• critic loss 持续振荡且不下降，说明 critic 网络学习困难，检查学习率设置，或者把 Critic 模型换成更浅的层数。

另一个隐蔽问题是 reward 模型和 actor 之间出现了“奖励黑客”。比如 reward 模型对过短的回答给高分，PPO 就会诱导模型输出越来越短，最后变成“贪一个字”。所以监控输出长度的分布也很重要。

6.5 文件命名和路径的隐藏坑

模板默认会生成一堆日志和输出，命名里若带了空格、中文或特殊符号，在后续不同模板间传参时经常会出问题。我的建议是全程用英文小写下划线命令，比如qwen2.5_7b_sft_lora_r32_ep3。

常见的一个隐藏坑：合并 adapter 后的模型目录里还会包含原来的adapter_model.bin或adapter_config.json。如果把它直接交给量化模板，量化工具可能识别成了 LoRA 权重，导致后面的产物完全不对。解决办法是合并且导出后，就把旧 adapter 文件清掉，只保留 merged 版的config.json、tokenizer*和.bin文件。

7. 一点个人体会

现在团队的新项目默认都在 CubeStudio 上跑这个全链路流程。它确实把“想清楚再动手”变成了一种强制习惯，因为每一步的参数和产物都被记录，复盘时非常省事。如果一开始经验不够，建议每一步跑完后都把我上面提到的检查点过一遍，不要连着把六个环节一次全跑完，否则哪一步错了，排查成本会大到你怀疑人生。

最后再分享一个小技巧：所有模板里都允许自定义启动命令，不要怕修改参数。遇到模板没覆盖的场景，把它当成一个普通脚本容器，写自己的命令执行。比如我常在这里面跑llamafactory-cli export合并 LoRA，或是用 Python 脚本做自定义数据清洗，都不需要新开环境。

算下来，从零到获得一个经过微调、对齐、压缩并通过评估的模型，我们目前最快能做到两天内交付。省下来的时间，都用在打磨数据和思考业务要求上了——这才是做模型该花时间的地方。