AI服务一日两度中断，基础设施可靠性再敲警钟

从“两次中断”看AI服务的可靠性真相

某AI服务提供商在一天之内遭遇两次服务中断：首次故障发生于下午，波及网页端与API服务，修复后短暂恢复；一个多小时后，同类故障再次出现，影响范围覆盖其主力模型版本的API调用与对话服务。这一事件看似是“偶发事故”，但如果将其放到大模型服务正从“可用”迈向“好用”的产业语境中审视，背后暴露的绝非一句“小概率事件”可以轻描淡写带过。

两次中断释放了哪些关键信号

“修复—复发”的短循环意味着根因未除

第一次中断后，官方执行了修复操作，服务短暂恢复。但不到一个半小时，同类故障卷土重来。这种“修复—复发”的周期特征，通常指向两类深层次矛盾：

• 根因未彻底消除：如果故障诱因是某个底层组件（如网关、权限服务、模型推理调度器）的不稳定状态，而修复只是对它进行了重启或流量切换，那么当负载回归或定时任务触发时，原故障极大概率复发。
• 修复动作引入新扰动：在紧追慢赶的应急状态下，快速上线的修复补丁或配置变更可能缺失全面的回归验证，反而改变了系统原有的负载均衡或超时控制行为，诱发新的不稳定。

无论上述哪种情况，都指向同一个结论：单次修复并不等于服务恢复的闭环。真正意义上的闭环，要求开发团队完成“故障定位—根因分析—修复实施—灰度验证—全量发布—观察确认”的完整链路，任何一个环节的缺失都会为下一次故障埋下伏笔。

API中断的外溢效应远超网页端

此次故障同时波及网页端对话服务和API接口，事实上，API部分的不可用才是最具杀伤力的环节。网页端用户遇到会话中断，充其量是刷新重试；而企业客户与开发者通过API调用构建的下游应用，则会立刻出现链路报错、任务积压、甚至核心业务停滞。一个API的抖动，可能让成百上千个业务系统同时感受“地震”。

这就要求AI服务提供商在架构设计上，必须将网页端与API视为同等级别的核心入口，甚至对API施以更严格的高可用保障，因为它的故障“外溢半径”远超单点用户体验。

应急能力不等于系统能力

该服务商在两次事件中均及时发布公告并积极修复，从危机沟通角度看，响应机制相对透明，这一点值得肯定。但专业视角更需冷静：快速修复只是应急能力，而不是系统能力。

真正的基础设施可靠性，体现在如下四个系统化设计中：

1. 故障预防：通过混沌工程在低峰期主动注入故障，验证系统对异常情况的感知和自愈能力，而非等到线上告警响起才被动应对。
2. 容量冗余：为关键服务预留足够的水位空间，确保流量突刺或单节点失效时，剩余资源仍能兜底承接业务。
3. 依赖隔离：模型推理、鉴权、计费、日志等模块具备独立的熔断与降级策略，某个非核心模块的抖动不能拖垮主链路。
4. 灰度回滚：变更发布支持精细的流量切分与秒级回滚，默认“变更即风险”，而非默认“变更即正确”。

拆解AI基础设施的可靠性支柱

架构冗余的“三层防御”

• 计算层：模型推理节点应采用多可用区部署，避免单一机房故障导致全面瘫痪。每个可用区内的算力资源需做到独立扩缩容，支持故障时跨区流量切换。
• 服务层：API网关、鉴权服务等无状态组件须支持多副本水平扩展，配合负载均衡实现会话级别的故障转移。会话粘连策略应设置合理的超时阈值，防止异常节点拖住整条请求链路。
• 数据层：缓存集群与向量数据库应设计主从切换机制，同时在内存与持久化存储之间建立稳定的异步或同步复制通道，确保数据不因节点切换而丢失。

依赖治理的“卡点”策略

大模型服务的调用链通常涉及多个外部依赖：文本审核服务、向量检索库、对象存储、消息队列、监控告警平台。任何一个外部依赖的毛刺都可能传导至用户端。有效的做法是引入超时、重试与熔断三件套：

• 超时：为每一次下游调用设置严格超时时间，防止线程长时间被占用。
• 重试：仅对幂等请求启用自动重试，且重试次数不超过两次，避免故障期间造成流量放大。
• 熔断：当下游依赖错误率达到阈值（如连续10次失败），快速打开熔断开关，直接返回降级响应，给下游自愈争取时间。

可观测性：从“感知故障”到“预判故障”

两次中断的核心问题之一是，第一次修复后未能及时发现潜在复发风险。这要求监控体系必须覆盖“指标—日志—链路追踪”三个维度：

• 指标：除了常见的QPS和延迟，还需关注ErrorBudget消耗速率、模型推理排队长度、GPU/CPU利用率变化趋势。
• 日志：统一日志格式并实现结构化存储，方便故障时快速检索同一请求ID在多个服务节点间的流转轨迹。
• 链路追踪：基于OpenTelemetry等通用标准，对每次模型调用进行全链路采样，准确识别慢节点或异常调用出现在哪一环。

更重要的是，告警不能只做阈值触发，必须配合预测性分析。例如，当模型推理队列长度超过历史P95水位并持续上升时，就应触发扩容预警，而非等到队列溢出导致请求超时再告警。

面向开发者与企业用户的三条实操建议

1. 为你的请求链路增加“容错层”

在调用大模型API的服务端代码中，建议加入本地兜底逻辑。以下是一个简化示意：

def call_llm_with_fallback(prompt, timeout=30):
    try:
        # 优先调用主服务
        return call_primary_provider(prompt, timeout=timeout)
    except TimeoutError:
        # 超时后尝试备用通道，若备用通道也不可用则降级
        return call_fallback_cache_or_rule_engine(prompt)

2. 提前制定降级预案并每周演练

包括：当模型API不可用时，是否可回退到轻量级检索式问答？当网页端故障时，是否可利用缓存的已生成内容进行会话恢复？所有降级方案应写入代码库而非停留在文档里，并定期进行“随机故障演练”。

3. 关注服务承诺，但更要关注自身架构的韧性

在选用任何大模型服务时，除了了解其可用性承诺，更需测压验证自己应用的断线重连、排队等待和超时控制是否健壮。优秀的应用架构应当能在供应商短暂“打盹”时，依然优雅地完成兜底处理。

结语

AI服务一日两度中断，看起来是“旧闻”式的运维事故，实则给整个产业提了个醒：大模型已不再是实验室里的“炫技品”，而是无数业务系统日夜依赖的水电煤。当服务不可用时，用户不会关心你是在修复日志还是调整参数，只会在意自己的业务是否停滞。

可靠性的建设没有尽头，它藏在一行行超时处理的代码里、一次次日复一日的混沌演练中、一次次对“根因未除”的较真里。这次故障是一面镜子，照见的不仅是一家服务商的短板，更是整个行业从“能用”迈向“好用”的必经之路。

技术水平不会因一次中断而被打倒，但敬畏之心必须在每一次中断中生长。