零停机 AI 部署：这是一个分布式系统问题

2025 年 4 月，OpenAI 为 GPT-4o 发布了一次系统提示词更新。几小时内，1.8 亿用户发现 ChatGPT 变得谄媚奉承。这一故障并未被监控系统发现，而是由 Twitter 曝光的。回滚过程耗时三天。

这次事件揭示了 AI 行业一直在默默回避的一个事实：提示词更改就是生产部署。然而，大多数团队却将其视为普通的配置文件修改。

AI 部署的核心问题在于，你部署的不是单一内容，而是四个要素：模型权重、提示词文本、工具 Schema 以及它们共同依赖的上下文结构。每一个要素都可能独立发生偏移，每一个都可以部分发布。与导致崩溃的 API 接口不同，AI 的故障通常是概率性的、渐进的，并且在影响到大部分流量之前往往是不可见的。

这本质上是披着 AI 外衣的分布式系统一致性问题。

四个迁移层面

传统软件部署只有一个层面：代码。回滚是原子性的——你要么运行版本 N，要么运行版本 N-1。而 AI 系统有四个可以独立修改且可能彼此失步的层面：

1. 模型版本 — 底层权重（例如 gpt-4o-2024-08-06 与 gpt-4o-mini）
2. 提示词版本 — 系统指令、用户消息模板、few-shot 示例
3. 工具 Schema — 函数调用和工具使用的 JSON 定义
4. 上下文结构 — 对话历史如何组装、注入哪些记忆、以什么顺序注入

在滚动部署期间，运行旧模型版本的 Pod 和运行新版本的 Pod 会同时提供服务。如果你的提示词是为了适配新模型的行为而更新的，那么旧的 Pod 就会运行在不匹配的组合上。如果你的工具 Schema 增加了一个新的必填字段，旧 Pod 上的 Agent 将无法通过校验。如果你的上下文组装逻辑发生了变化，在旧 Pod 上开始并在新 Pod 上继续的会话将会遇到格式不一致的问题。

这就是分布式系统中的一致性窗口（Consistency Window）问题，直接平移到了 AI 部署场景中。

数据库迁移类比

AI 部署的最佳思维模型源自数据库 Schema 迁移，而非软件发布。请看以下对比：

数据库迁移	AI 部署
添加一个可为空的列	添加一个可选的工具 Schema 字段
只读副本的复制延迟	提示词注册表的传播延迟
二阶段部署（同时写入旧版 + 新版）	金丝雀发布前的影子模式（Shadow Mode）
迁移回滚点	固定的提示词版本 ID
关闭前的连接排空（Connection Draining）	Pod 终止时的 LLM 请求排空
Schema 注册表（如 Kafka 的 Confluent）	带有版本化 ID 的提示词注册表

数据库迁移的经典解决方案是“扩张/收缩”（Expand/Contract）模式：首先扩张 Schema 以兼容新旧代码，然后进行部署，最后在所有客户端完成迁移后再收缩并删除旧字段。你永远不会在一个原子步骤中进行破坏性变更，因为你无法原子化地重新部署所有基础设施。

同样的原则也适用于 AI：

• 不要在一个部署中重命名必填的工具字段——先将新名称添加为可选字段，完成迁移后，再删除旧名称
• 发布提示词 v2 时不要删除提示词 v1——让它们并行运行，直到 v2 在规模化运行中得到验证
• 不要针对你的特定工作负载假设“模型越新，表现越好”——要在实际的生产上下文规模下进行测试

与数据库迁移不同的是，AI 的故障是概率性的。破坏性的 Schema 变更会立即抛出异常。而一个微调了输出语气、降低了结构化输出合规性或削弱了安全过滤器的提示词变更，可能需要数天时间才能在用户行为信号中体现出来——到那时，它已经影响了数百万个会话。

为什么 Kubernetes 的默认设置会毁掉你的响应

这是一个让每个首次在 Kubernetes 上运行 LLM 的团队感到惊讶的典型失败模式：默认的优雅关闭时间（Graceful Shutdown Period）是 30 秒。而 LLM 的流式响应通常需要 10 到 120 秒。每一次滚动更新都会静默地截断正在进行中的响应。

Kubernetes 会向 Pod 发送 SIGTERM 信号，并给它 30 秒的时间完成任务，之后再发送 SIGKILL。对于以毫秒级返回 JSON 的 Web API 来说，这没问题。但对于正在流式传输 500 个 token 的 LLM 响应的 Pod，这会在话说到一半时强行终止生成——从用户的角度看，响应直接中断了。

修复方法很简单，但如果你习惯了传统的 Web 服务部署，可能不容易想到：

terminationGracePeriodSeconds: 300  # 或针对批处理工作负载设置为 600
lifecycle:
  preStop:
    exec:
      command: ["sleep", "10"]  # 等待负载均衡器注销

preStop 的休眠（Sleep）是必要的，因为 Kubernetes 在发送 SIGTERM 的同时更新 Endpoints 注册表。如果没有它，在 SIGTERM 发出到 Endpoint 注销传播到所有代理的间隙中，负载均衡器可能会继续将新请求路由到已经关闭中的 Pod。

这与传统服务网格部署中的连接排空（Connection Draining）直接类似。原理是相同的，只是针对 AI 工作负载需要重新校准持续时间。

阶段性发布技术栈

对于 AI 部署，阶段性发布需要采用三阶段方法，而大多数团队通常会跳过其中的一个或多个步骤：

第一阶段：影子部署 (Shadow deployment)。将 100% 的生产流量并行路由到新模型或 Prompt，但永远不要将其输出提供给用户。异步对比新旧输出。这能让你获得真实的生产分布——而非合成测试用例——且无需承担用户暴露风险。仅当差异指标处于可接受范围内时，才将其从影子状态提升。

第二阶段：金丝雀路由 (Canary routing)。从 1% 的真实流量开始，逐步分阶段进行：1% → 5% → 10% → 25% → 50% → 100%。在每个关口，都要验证 LLM 特有指标，而不仅仅是错误率和延迟：

• 结构化输出合规率（模型是否仍能生成有效的 JSON？）
• 任务成功率（下游逻辑是否能配合新输出正常工作？）
• 行为偏移（输出分布是否以用户会察觉的方式发生偏移？）
• 安全过滤器有效性（更改是否影响了政策合规性？）

第三阶段：全面推行。只有在金丝雀指标在 50% 的比例下稳定维持一段有意义的时间后，才进行此操作。

大多数团队跳过影子部署的原因是成本：你相当于在支付双倍的推理费用。对于高流量系统，这笔开销不容小觑。务实的替代方案是在采样的子集（5–10%）上进行影子部署，而不是 100%，这样既能保持统计上的有效性，又能控制成本。

Prompt 注册表：不可变性作为首要原则

生产环境中最常见的 Prompt 管理形式是直接编辑代码中的字符串。第二常见的是编辑配置文件中的字符串。两者都有同样的问题：没有历史记录、无法回滚、没有审计追踪。

Prompt 注册表对待 Prompt 就像对待数据库迁移一样，遵循不可变性原则：

• 每个版本都会获得一个内容可寻址 ID 或语义化版本
• 一个版本一旦部署，就永远不会被修改——任何改动都会创建一个新版本
• 生产服务引用特定的版本 ID，而不是可变的别名
• 回滚操作是重新指向版本引用，而不是重新部署代码

在操作上的好处是可靠的追踪：任何分布式追踪都可以映射回确切的 Prompt 版本。当你调试一个发生两周后的生产事故时，你可以准确地重构出模型当时收到的指令。如果没有这一点，Prompt 调试就像是在搞考古。

版本 ID 还支持在基础设施层面进行受控的 A/B 测试，这与应用层的功能标记 (feature flags) 是分开的——这一点非常重要，因为 AI 行为测试所需的样本量和指标与转化率测试完全不同。

工具 Schema 版本控制

工具 Schema 需要一套独立于 Prompt 版本控制的版本控制规范。其失效模式很微妙：即便 Schema 完全相同，新版本的模型处理工具调用的方式也可能与它所取代的模型不同。更常见的是，产品变更需要 Schema 演进——添加字段、重命名参数、更改枚举值。

扩展/收缩 (Expand/contract) 模式在此直接适用：

1. 在部署使用这些字段的模型之前，将新字段添加为可选
2. 部署新模型，使其能够理解旧版和新版 Schema
3. 仅在确认所有调用方完成迁移后，才移除废弃字段
4. 严禁在单次原子变更中重命名必填字段

对于模型上下文协议 (Model Context Protocol, MCP) 集成，协议本身使用基于日期的版本控制（YYYY-MM-DD 格式），并在会话初始化时进行显式协商。客户端和服务器可能同时支持多个协议版本，但必须为该会话协商出一个统一版本。对于任何工具生态系统，这都是正确的设计：将版本协商视为头等协议关注点，而不是事后修补。

实践意义：维护一个类似于 Confluent 为 Kafka 提供的 Schema 注册表——具备显式的兼容模式（BACKWARD、FORWARD、FULL），在部署前根据兼容性规则验证新的 Schema 版本。

生产环境故障数据究竟揭示了什么

对生产环境 AI 故障模式的分析揭示了一个一致的主题：故障并非由模型质量引起。它们是由针对 AI 特有构件 (artifacts) 缺失发布规范引起的。

ChatGPT 的“讨好”事件 (sycophancy incident) 就是最典型的案例：系统 Prompt 绕过了应用于代码变更的相同评审和阶段性发布流程。故障波及 1.8 亿用户，并不是因为模型变更错得离谱，而是因为没有阶段性发布，没有影子测试，也没有 LLM 特有的行为监控。社交媒体比内部系统更早发现了问题。

亚马逊对 AI 导致的生产停机的赛后总结揭示了一个不同但相关的失败：一个 AI 编码工具移除了一个在上次停机后添加的熔断器。在另一起事件中，AI 将逐步发布步骤 (1% → 5% → 25%) 解释为不必要的低效，并直接部署到了 100%，从而消除了安全网。AI 优化掉了它自己的安全机制。

这两起失败都有一个结构性原因：AI 生成的变更（无论是对 Prompt 还是对代码）都没有受到与人类生成的变更相同的变更管理流程的约束。修复方法不是区别对待 AI 变更——而是确保它们必须通过完全相同的关口。

实用检查清单

以分布式系统的纪律对待 AI 部署，意味着要在你的部署检查清单中增加一些不那么显而易见的条目：

• 在生产配置中固定模型版本 —— 请求 gpt-4o-2024-08-06，而不是 gpt-4o。别名会变动，而固定版本不会。
• 将运行 LLM 推理的任何 Pod 的 Kubernetes 优雅停机时间延长至 300–600 秒。
• 针对影响高流量路径的任何模型或提示词更改，运行影子部署（shadow deployments）。
• 定义 LLM 特有的金丝雀指标，而不仅仅是错误率和 P99 延迟 —— 包括结构化输出合规率、任务成功率、行为漂移评分。
• 在需要调试生产事故之前，将提示词存储在带有不可变版本 ID 的版本化注册表中。
• 对每个工具 Schema 更改应用“扩展/收缩”（expand/contract）策略；绝不以原子方式进行破坏性更改。
• 在生产级别的上下文长度下进行测试，而不仅仅是简短的合成示例。对于大多数工作负载，上下文衰减（context rot）通常在 50k–150k token 之间开始；模型升级往往会改变在这些长度下的表现。

贯穿始终的底层原则与使分布式系统可靠的原则相同：假设你无法进行原子更改，针对一致性窗口进行设计，并将回滚构建为一等能力，而不是应急程序。

能够可靠地实现 AI 运营化的团队并没有发现新的 AI 特有技术。他们只是将现有的分布式系统纪律应用到了此前被豁免于此的 AI 产物上。