微调管道的CI/CD：自动化训练-评估-部署

第一次微调是你手动做完的：亲手整理数据，手动启动训练，用肉眼看结果，转成 GGUF，加载进 Ollama，再自己测一遍。花了一天，也可能是两天。

这套做法跑一次没问题。等到手上有四个客户，每个都有月度重训周期，各自的评估标准又不一样，还都要求零停机，它就撑不住了。手动微调在第二个客户身上就开始崩。到第四个客户，你花在流程上的时间已经超过花在模型改进上的时间。

答案就是软件工程几十年前给出的那一个：CI/CD。把持续集成和持续部署搬到微调管道上来。下面是完整的搭建方法。

管道概览

一条微调 CI/CD 管道包含七个阶段：

1. 触发：某个事件启动管道
2. 数据验证：确认训练数据干净且数量足够
3. 微调：运行实际的训练作业
4. 评估：用测试套件跑一遍模型
5. 对比：与当前生产模型做基准比较
6. 部署：通过全部门控后晋升新模型
7. 监控：部署后持续观察生产指标

每个阶段都有明确的通过/失败判定。任一阶段失败，管道就停下来并向你告警。顺利路径上不需要任何人工介入。

选择触发方式

并非每次管道运行都要有人点一下“开始”。三类触发方式覆盖了大部分场景。

定时触发最适合稳定、可预测的工作负载。定一个月度节奏：管道在每月第一个星期二运行，用这期间积累的新数据重训，新模型更好就晋升。新模型没有变好，一切照旧。人工投入总计：读一封汇总邮件。

数据量触发在积累到足够多的新训练样本时启动。设一个阈值，比如 500 条通过验证的新样本，管道就自动开跑。这适合每天都有新数据进来的高流量应用。

质量阈值触发是被动式的。监控系统发现生产环境准确率跌破 85%，就把管道点起来。模型基于更新后的数据重训、评估，确认修复了回退就部署。这是你的安全网。

组合使用才是实际做法。多数团队以定时触发为基线，以质量阈值触发作安全网。月度定时重训应付缓慢的漂移，质量阈值触发抓的是突然的劣化，比如一次产品更新在一夜之间改变了数据分布。

数据量触发对高流量场景是额外的加分项。如果你每天处理一万次以上的请求，并且对每次请求都收集反馈，训练数据的积累速度足以支撑更高频的重训。

有一条规则很重要：触发器要设冷却期。质量阈值触发一旦启动了重训，接下来至少 48 小时内要抑制其他触发。否则一个有噪声的指标可能把重训拖进反复触发的循环里。

阶段一：数据验证

在把算力花在训练上之前，先验证数据。这一阶段拦下的问题，放过去就会白白浪费几个小时的微调时间。

数量检查：新样本够不够？如果按月重训却只攒到 12 条新样本，管道应该跳过这一轮。设一个最低阈值，100 条新样本是个合理的起点。

格式验证：每条样本都必须符合你的训练 schema。对话式微调要求 system/user/assistant 消息数组合法，补全类任务要求输入/输出成对且合法。格式有问题的样本要标记出来并隔离，而不是悄悄丢掉。

分布检查：把新数据的标签分布和既有训练集对比一下。如果新一批里有 90% 属于同一个类别，这个信号值得查一查。它可能是合理的（季节性变化），也可能说明数据采集出了 bug。

去重：删掉完全重复和近乎重复的样本。Jaccard 相似度在 0.95 以内的近重复项应当标记出来。重复的训练样本会让模型在那几个特定模式上过拟合。

质量打分：如果你对单条样本有质量指标（回复长度、格式合规性、人工评分），就把低于质量阈值的样本过滤掉。一条糟糕的训练样本，足以抵消十条好样本带来的收益。

验证失败时，管道停止并发出一份详细报告：多少条样本没通过、哪几项检查失败、以及失败样本的代表性示例。你把数据修好，再手动重新触发。这里要避免自动修复，数据质量的判断需要人来做。

阶段二：微调

数据验证通过后，管道调用 Ertas 微调 API。这一阶段很直接，因为最难的部分（超参数选择、基础模型选型）已经在你最初那次手动微调时做完了。

管道配置把训练参数固定下来：

• 基础模型：你手动验证过的那一个（例如 Llama 3.1 8B）
• LoRA rank：验证过的取值（通常 r=16 或 r=32）
• 学习率：验证过的取值（通常 2e-4）
• 训练轮数：固定轮数，或根据验证损失做早停
• 训练数据：既有样本与新验证样本的合并集

关键的一点是：超参数实验属于开发阶段，管道要做的是把已经验证过的配方跑在更新后的数据上。

训练时长取决于数据集规模和模型大小。8B 参数级别的模型配 2,000 到 5,000 条样本，大致需要 30 到 90 分钟。管道在此期间等待、轮询作业状态，完成后进入评估阶段。

所有东西都要有版本。每次训练都应产出一个带元数据的版本化产物：数据集哈希、基础模型版本、超参数、训练时间戳。半年之后你要排查一次回退时，一定会想知道每个模型版本究竟是用什么训出来的。

# Example artifact metadata
run_id: ft-2026-02-26-001
base_model: llama-3.1-8b
dataset_hash: sha256:a4f8e2...
dataset_size: 3,847 examples
lora_rank: 16
learning_rate: 2e-4
epochs: 3
training_duration: 47m
timestamp: 2026-02-26T04:00:00Z

阶段三：评估套件

这是多数团队投入不足的环节，也是管道理应拦下大部分故障的地方。评估套件需要覆盖四个维度。

准确率指标：用留出测试集跑新模型，测任务相关的指标：分类看 F1，生成看 ROUGE 或人类偏好评分，结构化抽取看精确匹配。你要的是一个数字，凭感觉不算数。

回归测试：一组 50 到 200 条、生产模型能正确处理的精选样本。这些是你的“绝不能坏”用例。新模型只要答错其中任何一条，就算一次回退，必须查清楚。

延迟基准：跑 100 次推理调用，测 p50、p95 和 p99 延迟。微调后的模型比基础模型慢的幅度应当控制在 10% 以内。超出这个范围，说明训练或量化环节出了问题。

安全检查：跑你的安全评估集，包括对抗性提示、边缘用例、敏感话题。新模型必须通过每一项安全检查，没有例外，也没有阈值可谈，只有二元的通过或失败。

所有评估结果都要作为产物存档。你会需要横向对比多次管道运行，从中看出趋势。

阶段四：晋升门控

评估产出的是数字，晋升门控把这些数字变成部署或不部署的决定。以下这些门控在实践中管用：

所有阻断性门控都必须通过。任何一项阻断性门控失败，管道就停止运行，记录失败原因并通知团队。该模型会被归档以供排查，部署则不会发生。

全部门控通过后，管道自动进入部署阶段，无需人工审批。门控本身就是你的审批流程。

阶段五：部署

本地模型的部署走一条固定路径：微调后的模型量化为 GGUF，注册为新版本，然后逐步放量。

GGUF 转换：把微调后的适配器或合并后的模型，按目标量化等级转成 GGUF 格式（Q4_K_M 是个稳妥的默认值）。确认文件有效且能正常加载。

金丝雀发布：一次性把 100% 的流量切过去是危险的，从 5% 起步：5% 的请求走新模型，95% 留在生产模型上，观察 2 小时。指标稳住就提到 25%，再观察 4 小时，然后放到 100%。

Ollama 集成：更新 Modelfile 指向新的 GGUF，在 Ollama 里重新加载模型，用一条冒烟测试提示词确认模型回复正常。

整个部署阶段除去金丝雀观察窗口，用时不到 5 分钟。金丝雀观察再额外加上 6 小时的自动值守。

每一个部署过的模型版本都要留档，存储很便宜。回滚目标应当覆盖任意一个历史版本，包括更早的那些：回退问题往往在部署几天甚至几周之后才暴露，那时这个能力的价值极高。

阶段六：部署后监控

管道到部署为止还没有结束。全量晋升之后，部署后监控要持续运行 24 小时：

• 第 1 小时：每 5 分钟检查一次错误率、延迟和基本输出质量
• 第 1 到 6 小时：每 15 分钟检查一次，与生产基线做对比
• 第 6 到 24 小时：每小时检查一次，留意缓慢的劣化

监控窗口内只要有任何指标比生产基线低了 5% 以上，管道就触发自动回滚。回滚的动作是：重新加载上一版 GGUF、还原 Modelfile、把 100% 流量切回旧模型。回滚总耗时：使用 LoRA 适配器时不到 30 秒，整模型替换时不到 2 分钟。

自动回滚是必备项，正是它让全自动部署变得可以接受。缺了它，每次部署都得有人盯着；有了它，管道可以在凌晨三点跑，而你一觉睡到天亮。

每次回滚都要连同完整上下文一起记录：是哪个指标触发的、触发时刻的具体数值、被回滚掉的模型版本、以及恢复到的模型版本。这份日志就是你日后排查的起点。

这套东西的成本

搭建时间：端到端把管道建起来需要 8 到 16 小时，其中包括编写评估套件（最耗时的一块）、配置触发器、搭好监控，以及测试回滚路径。

日常维护：每月 1 到 2 小时。看一遍管道运行汇总、更新评估样本、随应用演进调整阈值。

省下的时间：每月 10 到 20 小时的手动微调、评估和部署工作。对同时管理多个客户模型的服务商来说，还要再乘以客户数量。

第一个月就能回本。到第二个月，你的迭代节奏已经是手动流程追不上的了。

哪些暂时不要自动化

第一天就把所有环节都塞进管道是不合适的。

你的第一次微调永远应该手动做。你得先理解流程、数据、失败模式和评估标准，才谈得上把它们自动化。

评估标准的设计需要人的判断。哪些指标重要？阈值定在哪里？这些决定塑造了整条管道的形状。定错了，你自动化的就是错的东西。

新任务类型的数据整理仍然需要人眼把关。当你要扩展到新领域或者增加新能力时，训练数据进入管道之前应当由人审一遍。

边缘情况的处理也建议保持手动。模型遇到真正新颖的输入模式，既不属于现有类别，也不匹配现有流程时，应该由人来决定怎么处理、给样本打标，并把它们加进训练集。管道会在下一轮自动运行时把这些样本吸收进去。

把重复的执行工作自动化，战略性的判断留给人。

从哪里开始

七个阶段不必一次建完。先做三个：微调、评估、部署。接着补上数据验证，然后是触发器，最后是监控。每个阶段都能独立带来价值。

能把微调规模化做成的团队，都是把它当软件工程、而不是当科学实验来对待的团队。数据要有版本，模型要有测试，部署要自动化，生产要有监控。

管道是一笔在可重复性上的投资。每自动化掉一个手动步骤，就少了一个会被遗忘、被跳过或者被做走样的环节。这就是从一个微调模型走到五十个的路径。

我们合作过的一个团队，从每季度一次、每次耗时两天的手动重训，变成了每月一次、每次只需 15 分钟人工复核的自动重训。半年里他们的模型准确率提升了 12%，来源是更频繁地在更新鲜的数据上训练，训练技巧本身并没有变化。管道让这个频率成为可能，频率让提升成为必然。

延伸阅读

• 微调质量检查清单：为晋升门控提供依据的评估标准
• 交付前对微调模型做 QA：搭建管道所依赖的那套测试套件
• 微调模型的运维生命周期：CI/CD 在整体运维图景中的位置