企业官网建设流程全解析

1. 大模型全链路任务平台化拆解

1.1 为什么要把微调、蒸馏、剪枝、量化塞进同一个平台

做过大模型落地的朋友应该都有体会：一个模型从“能跑”到“能上线”，中间要跨过的坑远比想象中多。最开始你可能只是在单机上用 LLaMA-Factory 跑一个 SFT，数据格式调半天，显存爆了改 batch size，好不容易训完，发现推理延迟高得离谱，又得去做量化；量化完了精度掉了，还得回头做蒸馏补偿；蒸馏完模型还是太大，又得上剪枝。每一步都换一套工具、换一套环境、换一套脚本，光是环境依赖就能耗掉一整天。

CubeStudio 这类平台的价值就在这里——它把SFT、PPO、Reward Model、蒸馏、剪枝、量化、安全评估这些环节做成标准化的任务模板，你不需要在每台机器上重新配环境，也不需要自己写调度脚本。任务之间的产物（checkpoint、数据集、评估报告）通过平台的数据流串起来，上一个任务的输出直接作为下一个任务的输入。说白了，就是把“手工作坊”变成“流水线”。

我自己的经验是，单机跑一次完整的“SFT → 量化 → 评估”流程，光是环境切换和数据搬运就要花掉 40% 的时间。平台化之后，这部分时间基本压缩到 10% 以内，剩下的时间可以真正花在调参和看效果上。

1.2 全链路各环节的定位与依赖关系

在动手之前，先把整条链路的逻辑理清楚，不然很容易做着做着就乱了。下面这张表是我总结的各环节定位：

依赖关系上，SFT 是一切的基础，PPO 和蒸馏都依赖一个已经对齐过的 SFT 模型；量化和剪枝通常在 SFT 或 PPO 之后做；安全评估放在最后，作为上线前的守门员。理解这个顺序，后面配置任务时就不会把依赖搞反。

1.3 平台化方案相比手工脚本的核心优势

手工脚本最大的问题是不可复现。你今天在 A 机器上跑通了，换到 B 机器上因为 CUDA 版本差一点就报错；你调好的参数写在某个 notebook 里，过两周自己都找不到。平台化解决的就是这三个问题：

• 环境一致性：每个任务模板对应一个固定镜像，CUDA、PyTorch、依赖库版本全部锁定，换机器不影响。
• 参数可追溯：每次任务的超参、数据版本、模型版本都记录在平台上，出问题能回溯。
• 资源可调度：大模型任务动辄需要多卡，平台能按需分配 GPU，任务排队、断点续训都有支持。

提示：如果你的团队还在用“共享一台机器 + 手动改脚本”的方式做大模型，强烈建议尽早迁移到平台化流程，越往后迁移成本越高。

2. 核心环节实操要点与参数解析

2.1 SFT 微调：数据格式与关键超参

SFT 是整条链路里最基础也最容易踩坑的一步。LLaMA-Factory 支持 alpaca、sharegpt 等多种数据格式，我一般推荐用sharegpt 格式，因为它对多轮对话的支持更自然。一个典型样本长这样：

{ "conversations": [ {"from": "human", "value": "帮我写一个快速排序"}, {"from": "gpt", "value": "好的，下面是 Python 实现..."} ] }

关键超参方面，我踩过的坑主要集中在三个地方：

• learning_rate：LoRA 微调建议 1e-4 到 2e-4，全量微调要降到 1e-5 到 2e-5。我见过有人用 1e-3 跑全量微调，loss 直接炸到 nan。
• cutoff_len：这个参数决定单条样本的最大长度，设太小会截断长样本，设太大会浪费显存。建议先统计你数据集的长度分布，取 95 分位数。
• batch_size + gradient_accumulation：显存不够时优先加 gradient_accumulation，而不是无脑降 batch_size，因为太小的 batch 会让训练不稳定。

LoRA 的 rank 和 alpha 也值得说一句。rank 一般取 8 到 64，alpha 通常取 rank 的 2 倍。我实测下来，rank=16、alpha=32 对大多数指令微调任务已经够用，再往上收益递减明显。

2.2 PPO 强化对齐：Reward Model 与训练稳定性

PPO 是整条链路里最“娇气”的一环。它需要四个模型同时在显存里：actor、critic、reward、reference。7B 模型做 PPO，至少需要 4 张 A100 80G，这个资源门槛要先有心理准备。

PPO 的核心参数里，KL 散度系数（kl_coef）是最需要调的。它控制 actor 偏离 reference 模型的程度，设太小模型会“放飞自我”输出乱码，设太大又学不到东西。我一般从 0.1 开始试，观察 KL 曲线，稳定在 5 到 15 之间比较健康。

Reward Model 的训练质量直接决定 PPO 的上限。RM 训练时要注意chosen 和 rejected 的分数差，如果两者分数太接近，说明 RM 区分能力不足，PPO 阶段会很难收敛。我通常会在 RM 训练完后，先在一个小验证集上看一下准确率，低于 70% 就别急着上 PPO。

注意：PPO 训练过程中如果出现 reward 突然飙升但输出质量下降，大概率是 reward hacking，这时候要加大 KL 惩罚或者检查 RM 是否有漏洞。

2.3 蒸馏与剪枝：小模型能力迁移的取舍

蒸馏的本质是让一个小模型（学生）去模仿大模型（教师）的输出分布。平台上的蒸馏模板一般支持logits 蒸馏和response 蒸馏两种。logits 蒸馏效果更好但需要教师模型的完整输出，response 蒸馏只需要文本，实现更简单。

温度参数 T 是蒸馏的关键。T 越大，软标签分布越平滑，学生能学到更多“暗知识”；T 太小就退化成硬标签。我一般取 T=2 到 4，配合 alpha=0.5 的软硬标签加权。

剪枝方面，结构化剪枝（按通道、按头剪）比非结构化剪枝（按单个权重剪）更适合实际部署，因为结构化剪枝后的模型不需要特殊硬件就能加速。剪枝率一般从 20% 开始试，超过 50% 通常需要重新微调才能恢复精度。

2.4 量化：INT8/INT4/GGUF 的选择逻辑

量化是降低推理成本最直接的手段。常见的几条路线：

选哪个取决于你的约束。如果显存够，优先 INT8；如果显存紧张又要保质量，选 AWQ；如果是本地 CPU 或混合推理，GGUF 的 Q4_K_M 是甜点。

量化过程中最容易出问题的是校准数据集。校准集要和实际推理场景的分布接近，否则量化后的模型在你的场景上会掉点严重。我一般从实际业务数据里抽 128 到 512 条做校准。

3. 平台实操全流程与关键配置

3.1 环境准备与镜像选择

在 CubeStudio 上创建任务前，先确认镜像。平台一般会提供预置的大模型镜像，里面已经装好了 LLaMA-Factory、transformers、peft、bitsandbytes 等依赖。如果你要用特定版本的 LLaMA-Factory，可以基于基础镜像自己构建。

镜像选择的核心原则是CUDA 版本和 PyTorch 版本匹配。比如你要用 FlashAttention-2，就需要 CUDA 11.8 以上 + PyTorch 2.1 以上。版本不匹配是新手最常见的报错来源。

资源申请上，SFT 7B 模型用 LoRA 单卡 A100 40G 够用；全量微调需要 4 卡以上；PPO 至少 4 卡 80G；量化任务单卡即可。申请资源时宁可多申请一点，任务排队比 OOM 重跑划算。

3.2 SFT 任务配置与启动

在平台上创建 SFT 任务，核心是填好这几个配置项：

model_name_or_path: /path/to/base_model stage: sft finetuning_type: lora dataset: my_dataset template: llama3 cutoff_len: 2048 learning_rate: 1.0e-4 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 lora_rank: 16 lora_alpha: 32 output_dir: /path/to/output

启动后重点盯三个指标：loss 曲线、学习率曲线、显存占用。loss 如果在第一个 epoch 内快速下降然后平稳，说明学习率合适；如果 loss 震荡剧烈，降学习率；如果 loss 几乎不动，检查数据格式是不是没被正确解析。

3.3 量化任务配置与产物验证

量化任务在平台上通常是一个独立模板，输入是 SFT 产出的 checkpoint，输出是量化后的模型。以 GPTQ 为例，关键配置：

model_name_or_path: /path/to/sft_model quantization_method: gptq bits: 4 group_size: 128 desc_act: true calibration_dataset: /path/to/calib_data num_calibration_samples: 256 output_dir: /path/to/quantized_model

量化完成后，必须做产物验证，不能直接上线。验证分两步：一是用同样的评估集对比量化前后的输出，看质量掉了多少；二是实测推理速度和显存占用，确认达到预期。我见过量化后模型输出全是重复 token 的情况，就是因为校准集和实际场景差太远。

3.4 安全评估任务与报告解读

安全评估模板一般会跑一组预设的测试集，覆盖有害内容、偏见、越狱提示等维度。评估报告会给出各维度的通过率和风险等级。

解读报告时不要只看总分，要看具体失败案例。有些失败是模型真的有问题，有些是测试集本身的提示词过于极端。我一般会把失败案例人工过一遍，区分“真问题”和“误报”，再决定是否需要重新对齐。

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

4.1 训练类问题速查

4.2 量化掉点严重怎么办

量化掉点是最常见的问题。我的排查顺序是：先换校准集，用更贴近实际场景的数据；再调 group_size，从 128 降到 64 通常能改善；还不行就换量化方案，GPTQ 换 AWQ；最后考虑混合精度，对敏感层保留 FP16。

4.3 平台任务调度与断点续训

平台任务被抢占或超时是常事，所以一定要开断点续训。LLaMA-Factory 支持从 checkpoint 恢复，配置里加上resume_from_checkpoint: true即可。另外建议把 checkpoint 保存间隔设小一点，比如每 500 步存一次，避免被抢占后丢失太多进度。

提示：平台上的任务日志一定要保留，出问题时日志是第一手排查资料。我习惯把每次任务的关键配置和结果记在一个表格里，时间长了就是自己的经验库。

4.4 我踩过的几个典型坑

第一个坑是数据格式的 template 不匹配。LLaMA-Factory 的 template 参数要和基座模型对应，用 llama3 的 template 去训 qwen 的模型，loss 会异常。第二个坑是量化时忘了合并 LoRA，直接量化 LoRA adapter 会导致输出错乱，必须先 merge 再量化。第三个坑是PPO 的 reference 模型没冻结，导致 KL 计算错误，训练直接崩掉。

这些坑单看都是小问题，但每一个都能让你耗掉半天。平台化之后，这些配置项都有默认值和校验，能帮你避开大部分低级错误，但理解背后的原理仍然重要——毕竟出了问题，还是得你自己排查。