微调模型回滚：部署策略

你在周一部署了重新训练的模型。评估套件通过了。延迟看起来正常。团队很有信心。

到了周三，支持工单翻了一倍。客户反馈 AI "不再理解"他们的请求。一个之前运行完美的分类任务现在有 30% 的误分类率。有人问：我们多快能回滚？

如果答案是"让我找到旧模型文件，然后想办法重新加载它「，你有一个部署问题。如果答案是」30秒，我翻转一下配置"，你有一个部署策略。

本文介绍三种部署策略，让回滚变得快速、安全且日常化。

为什么微调模型部署会失败

在讨论回滚之前，了解部署为何会出问题是有帮助的。微调模型在生产环境中失败有四个一致的原因：

对近期数据过拟合。你用上个月的数据重新训练。这些数据过度代表了某个模式。模型对该模式变得非常擅长，但对其他一切都变差了。你的评估套件没有发现，因为测试集有相同的分布偏差。

评估缺口。你的测试套件覆盖了 85% 的真实使用场景。另外 15% 包括边缘情况、罕见类别和新颖措辞，旧模型通过泛化能力来处理。新模型在微调过程中失去了这种泛化能力。评估说"通过"。生产环境却不这么认为。

分布漂移。你收集训练数据和部署之间，生产数据发生了变化。新产品功能、新客户群体、季节性模式。模型是为上一季度的现实训练的。

基础模型不兼容。你更新了基础模型（比如从 Llama 3.1 到 Llama 3.2）并应用了现有的 LoRA 适配器。适配器是为旧基础模型训练的。权重不对齐。输出以微妙、难以检测的方式退化。

这些故障各有不同的修复方法。但它们都有相同的紧急需求：尽快恢复旧模型到生产环境。

策略 1：Blue-Green 部署

Blue-green 部署是最简单的策略，也是你应该首先实施的。

工作原理

你维护两个模型槽位：blue 和 green。在任何时候，一个是"活跃的「（服务生产流量），一个是」待命的"（已加载并就绪但未服务）。

当你部署新模型时：

1. 将新模型加载到待命槽位
2. 用 10-20 个代表性提示对待命槽位运行冒烟测试
3. 将路由配置切换到新槽位
4. 旧模型保持在之前的槽位中已加载

当你需要回滚时：

1. 将路由配置切回旧槽位
2. 完成

回滚时间：不到 10 秒。 这是一个配置变更，不是模型重新加载。

实现方式

对于基于 Ollama 的部署，这意味着运行两个模型实例。你的应用程序根据配置标志路由到其中一个：

# Config: model_routing.yaml
active_slot: "green"
blue:
  model: "customer-support-v2.1"
  endpoint: "localhost:11434"
green:
  model: "customer-support-v2.2"
  endpoint: "localhost:11435"

回滚就是将 active_slot 从 "green「 改为 」blue" 并重新加载配置。无需模型加载。无需文件交换。无需停机。

权衡

代价是内存。你需要足够的 RAM 来同时保持两个模型加载。对于 Q4 量化的 7B 模型，大约需要 8-10 GB。对于大多数部署服务器来说，这是可以管理的。对于内存预算紧张的边缘部署，考虑后面描述的适配器回滚方法。

Blue-green 适合以下情况：你有足够的内存，你想要最快的回滚速度，部署频率不高，维护两个已加载的模型是实际可行的。

策略 2：Canary 部署

Canary 部署在问题影响所有用户之前捕获它。你不是一次性切换 100% 的流量，而是逐步增加。

工作原理

1. 在生产模型旁边部署新模型
2. 将 5% 的流量路由到新模型
3. 监控关键指标 2 小时
4. 如果指标稳定，增加到 25%
5. 再监控 4 小时
6. 如果指标仍然稳定，提升到 100%

重要的指标

在 canary 监控期间，跟踪这些指标及其阈值：

Canary 期间的回滚

Canary 期间的回滚很简单：将 canary 百分比设为 0%。所有流量返回生产模型。新模型可以卸载或保留用于调查。

不良部署的损害是有限的。在 5% 的流量下，如果新模型在某个特定类别上有 30% 的故障率，只有 1.5% 的该类别总请求受到影响。这就是"客户注意到了一些奇怪的事情「和」客户正在流失"之间的区别。

自动化 Canary 检查

不要依赖人工在 canary 窗口期间看仪表盘。自动化检查：

• 在 canary 期间每 15 分钟运行一次 canary 和生产指标的比较
• 如果任何指标超过阈值，自动停止 canary
• 如果所有指标在每个阶段结束时保持稳定，自动提升到下一个百分比
• 在每个阶段转换时发送摘要通知

整个 canary 过程可以无人值守运行。当模型完全提升或 canary 因指标违规而停止时，你会收到通知。

策略 3：Shadow 模式

Shadow 模式是最保守的策略。它让你在生产中评估新模型，而对用户没有任何风险。

工作原理

1. 在生产模型旁边部署新模型
2. 将所有生产请求路由到两个模型
3. 向用户提供生产模型的响应
4. 记录新模型的响应用于比较
5. 收集足够的数据后比较输出（通常 1,000-5,000 个请求）
6. 如果新模型更好，使用 blue-green 或 canary 提升它

用户永远看不到新模型的输出。对用户体验的风险为零。权衡是时间，因为你需要收集足够的并行响应来进行统计上有效的比较。

何时使用 Shadow 模式

Shadow 模式最适合：

• 高风险部署，其中不良响应有重大后果（医疗、法律、金融）
• 微调模型的首次部署，替代基于提示工程的基线
• 重大重新训练，其中训练数据或方法发生了显著变化
• 基础模型升级，你更改了底层模型，而不仅仅是适配器

Shadow 模式对于在增量更新数据上的常规月度重新训练来说是过度的。对于这些情况使用 canary。

比较 Shadow 结果

比较应该是结构化的，而不是逸闻式的。对于每个请求对：

1. 两个模型都产生了有效输出吗？（格式合规性）
2. 两个模型都产生了正确输出吗？（准确性，对于有真实答案的情况）
3. 新模型的输出是否更受偏好？（质量评分，自动化或抽样人工审查）
4. 是否存在新模型失败而旧模型没有的情况？（回归分析）

如果存在回归，对其进行分类。它们是在特定领域？特定输入模式？特定输出格式？这个分析告诉你在提升新模型之前需要修复什么。

适配器回滚：LoRA 的优势

如果你使用 LoRA 适配器进行微调（大多数用例你应该这样做），回滚变得更加简单。

一个 LoRA 适配器是一个小文件，7B 模型的适配器通常只有 50-200 MB。基础模型保持不变。交换适配器意味着：

1. 卸载当前适配器
2. 加载前一个适配器
3. 恢复服务

总回滚时间：不到 10 秒。 无需交换大型模型文件。无需漫长的加载时间。基础模型在内存中保持热状态。

这也意味着你可以将每个适配器版本保存在磁盘上。一年的月度重新训练产生 12 个适配器文件，总共 1-2 GB。这就是你完整的回滚历史，代价只是几个 GB 的存储。

用时间戳和训练元数据对你的适配器进行版本控制：

models/
  customer-support/
    base/
      llama-3.1-8b-q4_k_m.gguf
    adapters/
      v2.1-2026-01-15-1247examples.gguf
      v2.2-2026-02-12-1891examples.gguf
      v2.3-2026-02-26-2104examples.gguf   # current

回滚到任何之前的版本就是更改配置指向不同的适配器文件。

回滚决策框架

当部署后指标开始下滑时，你需要一个快速、清晰的决策流程。模糊导致延迟。延迟损失用户信任。

立即回滚（无需调查）：

• 任何被监控类别的准确率下降超过 5%
• 错误率或崩溃率增加
• 模型产生不安全、有毒或无意义的输出
• p95 延迟增加超过 50%

调查后决定（1-4 小时窗口）：

• 特定类别的准确率下降 2-5%
• 延迟增加 20-50%
• 输出风格或格式明显变化
• 用户反馈参差但不是一致负面

监控并保持（24 小时窗口）：

• 准确率持平，没有改善也没有回归
• 轻微延迟变化，低于 20%
• 无用户投诉但没有可衡量的改善

规则：有疑问时，回滚。回滚的代价是几分钟。有问题的模型服务生产流量的代价是需要数周才能重建的信任。

回滚后分析

回滚是紧急响应。回滚后分析是根本原因调查。不要跳过它。

在回滚后 24 小时内，回答这些问题：

1. 什么失败了？ 确定新模型表现不佳的具体输入、类别或模式。
2. 评估为什么没有发现？ 你的测试套件让这个模型通过了。什么缺口允许了故障通过？将失败案例添加到你的评估套件中。
3. 需要什么改变？ 是数据问题（需要更多示例）、训练问题（超参数调整）还是评估问题（缺少测试覆盖）？
4. 什么时候重试？ 设定一个具体的日期来进行下一次尝试，并应用修复。

每次回滚都应该让你的管道更加健壮。失败案例变成回归测试。评估缺口被填补。下一次部署比上一次更安全。

部署前检查清单

在每次部署之前，检查这十个项目：

1. 评估套件通过所有阻断门控
2. 回归测试 100% 通过
3. 延迟基准在可接受范围内
4. GGUF 文件经过验证且可加载
5. 已识别并可访问用于回滚的前一个模型版本
6. 回滚程序已实际测试过
7. 监控仪表盘已配置并报警
8. Canary 百分比和阶段持续时间已定义
9. 值班人员已确定（或已配置自动回滚）
10. 利益相关者已收到部署窗口通知

一个都不要跳过。你跳过的那一个就是会让你吃亏的那一个。

监控窗口

部署后监控分三个阶段进行：

第一个小时：每 5 分钟检查一次指标。这能捕获崩溃、重大准确率下降、格式违规等灾难性故障。如果某些东西从根本上坏了，这里就会显示出来。

前 24 小时：每 30 分钟检查一次指标。这能捕获特定类别的回归、负载下的延迟蠕变、在足够流量下出现的边缘案例故障等中等问题。

第一周：每天检查指标。这能捕获缓慢退化，例如只有大样本量才能发现的微妙质量变化、一天中的时间模式、你的训练数据可能没有覆盖的每周使用模式。

一周后如果指标干净，部署被认为是稳定的。旧模型可以从 blue-green 待命中卸载（但保留文件，以备日后需要）。

随时间建立信心

第一次部署是紧张的。你像盯着欠你钱的人一样盯着仪表盘。每个指标跳动都让你紧张。

到第五次部署时，你信任这个流程了。评估套件已经通过四轮回滚后改进进行了加固。Canary 流程已经验证。回滚程序已经测试过，甚至可能已经使用了一两次。

到第十次部署时，这是常规操作了。管道运行。Canary 提升。监控在看着。你一边喝咖啡一边读摘要邮件。

这就是目标：无聊的部署。无聊意味着可靠。可靠意味着你可以专注于让模型变得更好，而不是担心部署是否能撑过一晚。

延伸阅读

• Side-by-Side Model Comparison for Fine-Tuning：在部署之前比较模型
• A/B Testing Your Fine-Tuned Model vs GPT-4：结构化比较方法论
• The Fine-Tuned Model Ops Lifecycle：部署在更大图景中的位置