大模型服务中断事件复盘与高可用架构设计

一、事件背景：一次“部分中断”的典型样本

某日，某大模型对话平台的网页端与接口服务出现部分不可用，用户在聊天界面看到“服务器繁忙，请稍后重试”的提示。根据该平台官方状态页“历史事件”记录，本次“网页/API 部分中断”从当日 16:58 持续至 18:48，累计约 1 小时 49 分钟，随后服务恢复，状态页显示“一切运行正常”。

这段描述虽然简短，却包含了一个非常典型的生产级故障样本：故障影响面是“部分”而非全量、故障可被状态页记录并对外披露、故障有明确的起止时间、恢复后状态回归正常。对于开发者与企业用户而言，比起追问“是哪家平台”，更有价值的是回答三个问题：

1. 大模型服务为什么会“部分中断”，而不是简单的“全挂”或“全好”？
2. 当依赖的模型服务出现波动时，上层应用如何把影响降到最低？
3. 如何通过架构设计与可观测性建设，让类似故障的发现更快、定位更准、恢复更短？

本文围绕这三个问题展开。

二、“部分中断”意味着什么：从单点故障到链路分段

“部分中断”通常不是单一原因造成的全局限流，而是服务链路中某个环节出现瓶颈或异常。一个典型的大模型对话服务链路可以抽象为以下几段：

• 接入层：负载均衡、网关、限流与鉴权；
• 会话与编排层：会话管理、上下文拼接、prompt 组装、路由调度；
• 推理层：模型推理集群、批处理调度、GPU/加速卡资源池；
• 依赖层：缓存、消息队列、日志与监控、存储等基础组件；
• 返回链路：流式输出的连接保持、超时控制、重试与降级。

当其中任一环节出现资源饱和、连接数打满、依赖超时或版本发布异常时，表现往往就是“部分用户可用、部分用户不可用”，或者“网页端异常但接口仍可用”“短请求成功、长上下文请求失败”。这也解释了为什么状态页会使用“部分中断”这一措辞——它描述的是影响范围，而非故障根因。

从工程视角看，“部分中断”比“全面中断”更难排查，因为它要求团队具备细粒度的分维度监控能力：按接口、按地域、按用户分群、按请求特征（上下文长度、是否流式）分别观察成功率与延迟。

三、故障发现与定位：可观测性是第一道防线

本次事件中，状态页记录了明确的起止时间，说明平台具备基本的事件记录与对外沟通机制。但对于依赖该服务的企业而言，更关键的是自己能否在平台状态页更新之前发现问题。

3.1 三层监控指标

建议在应用侧建立三层监控：

1. 可用性指标：请求成功率、错误码分布（限流、超时、鉴权失败需分开统计）、首字节延迟（TTFB）与整体时延分位数（P50/P95/P99）。
2. 容量与饱和度指标：并发连接数、队列积压长度、客户端侧重试次数、连接池占用率。
3. 业务语义指标：对话完成率、流式输出中断率、平均会话轮次、用户主动重试率。

其中“首字节延迟”和“流式输出中断率”是大模型场景下尤其值得关注的指标——大模型响应时间长，用户感知的“卡住”往往发生在首字节等待或流式传输中途，而非最终返回。

3.2 用代码建立最小可用的健康探测

以下示例展示一个带超时与分类重试的探测逻辑（示意性代码，非特定厂商接口）：

import time
import random
class ModelServiceProbe:
    def __init__(self, timeout_ms=3000, max_retries=2):
        self.timeout_ms = timeout_ms
        self.max_retries = max_retries
    def call(self, payload):
        # 真实实现中替换为对模型服务的调用
        # 这里仅示意超时与异常分类的处理结构
        raise NotImplementedError
    def probe(self, payload):
        last_err = None
        for attempt in range(self.max_retries + 1):
            start = time.time()
            try:
                result = self.call(payload)
                cost = (time.time() - start) * 1000
                return {"ok": True, "latency_ms": cost, "attempt": attempt}
            except TimeoutError as e:
                last_err = ("timeout", str(e))
            except ConnectionError as e:
                last_err = ("connection", str(e))
            except Exception as e:
                last_err = ("unknown", str(e))
            # 指数退避加抖动，避免重试风暴
            backoff = (2 ** attempt) * 0.1 + random.uniform(0, 0.05)
            time.sleep(backoff)
        return {"ok": False, "error": last_err}

这段代码的关键点不在语法，而在两个工程约定：错误必须分类（超时、连接失败、未知异常的处理策略不同），重试必须带退避与抖动（否则故障期间客户端重试会放大服务端压力，形成二次雪崩）。

四、应急恢复：从“等待恢复”到“可控降级”

本次事件中，服务在约 1 小时 49 分钟后恢复。对使用者而言，这段时间内的体验取决于应用是否具备降级能力。常见的降级策略包括：

• 多供应商/多实例冗余：同一能力接入多个服务端点，按健康检查结果动态切换；注意这不是简单的“主备切换”，而要处理不同端点输出格式与语义差异。
• 功能降级：在模型服务不可用时，关闭非核心能力（如长上下文、复杂推理），保留基础问答；或改为异步任务，先受理后处理。
• 排队与削峰：将突发请求写入消息队列，按服务端可用容量平滑消费，同时向前端返回明确的排队状态。
• 友好的失败语义：将“服务器繁忙”这类模糊提示替换为可操作提示（预计等待时间、是否已进入队列、是否可稍后重试），降低用户重复点击带来的额外压力。

需要强调的是，降级策略必须提前演练。很多团队写了降级开关，但从未在真实流量下验证过切换路径，故障发生时开关反而成为新的故障点。

五、高可用架构设计要点

结合大模型服务的特性，给出以下设计建议：

5.1 超时与重试的分层设定

客户端超时应小于网关超时，网关超时应小于服务端处理超时，形成“逐层收敛”的超时预算。对于流式输出，应分别设置“首字节超时”和“空闲超时”，避免长连接被误判为健康。

5.2 连接池与并发控制

对模型服务的调用应使用独立连接池，并与普通业务请求隔离，防止模型服务波动拖垮整个应用的连接资源。同时设置并发上限与排队上限，超出部分快速失败而非无限堆积。

5.3 状态页之外的“自建真相源”

平台状态页是重要参考，但存在更新延迟。建议应用侧维护自己的健康度视图：按分钟聚合成功率与延迟，设定告警阈值，并与平台状态页做交叉验证。当自建指标异常而平台状态页正常时，优先排查自身链路（如网络、鉴权、配额）。

5.4 容量规划与压测

大模型服务的容量受限于推理资源，具有明显的“非线性”特征：并发上升时延迟可能急剧恶化。应定期做阶梯压测，找到延迟拐点，并据此设定限流阈值，而不是简单按平均值估算。

六、复盘清单：把一次故障转化为长期能力

一次约 1 小时 49 分钟的中断事件，最有价值的产出是一份可执行的复盘清单：

1. 故障期间，应用侧的成功率、延迟、错误码分布曲线是否完整？
2. 告警是否在用户投诉之前触发？平均发现时间（MTTD）是多少？
3. 降级开关是否被使用？切换是否顺利？恢复时间（MTTR）由哪些环节构成？
4. 重试策略是否造成额外压力？是否需要调整退避参数？
5. 对外沟通是否清晰？用户是否知道“发生了什么、该怎么办”？
6. 是否有单点依赖？多端点冗余的切换逻辑是否经过演练？

结语

大模型服务的中断并不罕见，罕见的是从中提炼出可复用的工程能力。把“服务器繁忙”当作一次架构体检的契机：用分类监控替代笼统告警，用分层超时替代单点等待，用可演练的降级替代纸面预案。唯有如此，当下一次“部分中断”到来时，应用才能做到影响可控、恢复可预期、复盘有据可依。