AI 宕机的真相：模型本身很少坏，坏的是路由、数据库、网络和配置

一、引言：一个被反复误判的故障归因

2024 年以来，随着大模型服务大规模进入生产环境，AI 系统的可用性问题开始集中暴露。无论是公有云上的托管推理服务，还是企业自建的私有化部署，宕机事件都不再是新闻。但一个耐人寻味的现象是：在事故复盘的会议室里，"模型出问题了"往往是最先被提出、也最容易被接受的解释，却几乎总是被证明是错的。

这种归因偏差有其心理学根源。模型是 AI 系统中最"黑盒"、最不可解释的部分，人类在面对复杂系统故障时，倾向于把责任推给最不透明的那一环。但从工程角度看，模型恰恰是整个链路中最稳定、最可复现、最不容易"随机坏掉"的组件。一个已经训练完成、权重固定的模型，在相同输入下会给出确定性的输出（忽略采样随机性），它不会因为"今天心情不好"而宕机。

真正会"随机坏掉"的，是模型外面那套庞大、耦合、状态复杂的工程系统。请求要经过网关、负载均衡、路由层、鉴权、限流、缓存、向量检索、会话状态存储、推理调度、结果后处理，最后才回到客户端。这条链路上任何一环抖动，都会表现为"AI 服务不可用"。而用户和部分运维人员看到的只是最外层的 5xx，自然会把账算到模型头上。

本文评述：把 AI 宕机归因于模型，本质上是一种"可见性偏差"——最不透明的组件承担了最多的怀疑，而真正高频失效的外围系统因为"看起来很简单"而被忽视。本文要做的，就是把这条被忽视的故障链完整地摊开。

二、故障面拓扑：AI 系统失效的六层模型

为了系统性地分析 AI 系统失效，本文提出"故障面拓扑"这一分析框架。它把 AI 系统的运行链路抽象为六个相互叠加的故障面，每一面都有独立的失效模式、独立的观测指标和独立的加固手段。

2.1 六个故障面的定义

故障面	核心组件	典型失效模式	相对故障占比（估算）
路由面	网关、负载均衡、服务发现、模型路由	路由错误、实例摘除不及时、灰度串流	约 25%–30%
数据面	向量数据库、会话存储、缓存、元数据	连接池耗尽、索引损坏、慢查询、缓存击穿	约 20%–25%
网络面	DNS、TLS、长连接、跨区链路	超时、重试风暴、连接泄漏、DNS 解析失败	约 15%–20%
配置面	配置中心、环境变量、密钥、特性开关	配置漂移、密钥过期、开关误操作	约 10%–15%
调度面	K8s、推理调度器、GPU 池、限流器	冷启动、显存碎片、限流误伤、排队雪崩	约 10%–15%
模型面	权重、推理内核、Tokenizer、采样逻辑	数值溢出、OOM、内核崩溃	约 5% 以下

需要说明的是，上表中的占比是基于公开事故复盘报告、云厂商 SRE 分享以及笔者对多个生产环境故障工单的整合分析得出的估算区间，属于模拟整合数据，用于说明量级关系，而非精确统计。不同架构、不同规模的系统，各面占比会有显著差异。

笔者认为：这张表最重要的价值不在于具体数字，而在于它揭示了一个反直觉的事实——模型面是六个故障面中最"干净"的一个。模型一旦部署稳定，它的失效几乎都是确定性的、可复现的、有明确堆栈的；而外围系统的失效是概率性的、耦合的、难以复现的，这才是运维的真正噩梦。

2.2 为什么外围系统更容易坏

从系统论角度看，一个组件的失效率与其"状态空间大小"和"交互复杂度"正相关。模型权重是静态的，状态空间在部署后基本冻结；而路由、数据库、网络、配置这些组件是动态的、有状态的、与其他系统持续交互的，它们的状态空间随时间不断演化，失效概率自然更高。

更关键的是，AI 系统对外围组件提出了比传统 Web 服务更苛刻的要求。传统 Web 服务的请求通常是短小、无状态、可缓存的；而 AI 推理请求往往是大 payload、长耗时、有会话状态的。这种请求特征会把路由层、连接池、超时配置、状态存储的压力放大数倍，让原本"够用"的基础设施在 AI 场景下变得脆弱。

三、路由面：被低估的头号杀手

在 AI 系统的所有外围组件中，路由层是最容易被忽视、却最容易引发大面积故障的一环。原因很简单：路由层"看起来"只是转发请求，逻辑简单，但它承载了服务发现、健康检查、灰度发布、模型版本切换、多租户隔离等一系列复杂职责。

3.1 健康检查的"假阳性"陷阱

负载均衡器依赖健康检查来判断后端实例是否可用。但 AI 推理服务的健康检查存在一个天然难题：一个实例可能"进程活着、端口能连、健康检查通过"，但实际已经无法正常推理——比如 GPU 显存泄漏导致后续请求全部 OOM，或者推理队列已经积压到无法在超时前返回。

传统的 TCP 健康检查或简单的 HTTP 200 检查无法捕捉这种"亚健康"状态。结果是负载均衡器持续把流量打到一个实际上已经瘫痪的实例上，用户侧表现为间歇性超时或错误，而监控面板上该实例却显示"健康"。

本文评述：AI 推理服务的健康检查必须"深入业务语义"，不能停留在端口存活层面。一个可行的做法是让健康检查端点执行一次极轻量的真实推理（比如一个 1-token 的生成），并校验返回结构和延迟。这比任何端口探测都更能反映实例的真实可用性。

3.2 灰度发布与模型版本串流

AI 应用的迭代频率远高于传统服务，模型版本、Prompt 模板、推理参数都在快速变化。灰度发布是控制风险的标准手段，但路由层的灰度规则一旦配置不当，就会导致"版本串流"——同一用户的请求被随机路由到不同模型版本，输出风格、格式、甚至 API 兼容性都不一致。

更严重的情况是"灰度泄漏"：新版本实例因为某个 bug 大量报错，但路由层没有及时将其摘除，导致错误率持续攀升。这类故障在监控上表现为"错误率突增但无明确堆栈"，排查时极易被误判为模型问题。

3.3 可操作的加固路径

• 语义健康检查：健康端点执行轻量真实推理，校验输出与延迟。
• 会话粘性路由：对多轮对话场景，按 session_id 做一致性哈希，避免版本串流。
• 熔断与快速摘除：基于错误率和 P99 延迟的实时熔断，而非固定窗口的被动摘除。
• 路由决策可观测：在响应头中回传实际命中的实例 ID 和模型版本，便于事后追溯。

关于服务网格与流量治理的工程实践，可参考 Istio 官方文档中关于健康检查与熔断的章节：https://istio.io/latest/docs/tasks/traffic-management/，以及 Envoy 的 outlier detection 机制说明：https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier。

四、数据面：向量数据库与状态存储的暗礁

RAG（检索增强生成）架构的普及，让向量数据库成为 AI 系统的核心依赖。同时，多轮对话、Agent 记忆、工具调用状态等需求，又引入了大量会话状态存储。数据面因此成为仅次于路由面的第二大故障来源。

4.1 向量数据库的连接池与慢查询

向量检索的计算特性与传统数据库截然不同。一次 top-k 相似度检索可能扫描数百万向量，计算量随数据规模线性甚至超线性增长。当并发请求上升时，向量数据库的 CPU 和内存迅速饱和，查询延迟从毫秒级飙升到秒级，进而拖垮上游的推理服务。

更隐蔽的问题是连接池。许多向量数据库客户端默认连接池较小，在高并发下请求排队等待连接，表现为"数据库没挂但请求超时"。这类故障在监控上往往只显示为推理服务超时，根因却在数据库连接层。

笔者认为：向量数据库的容量规划不能沿用传统 OLTP 数据库的经验。它的瓶颈通常不在 QPS，而在"向量维度 × 数据规模 × 并发数"这个三维乘积。一个 1536 维、千万级向量的集合，单次检索的内存带宽消耗就足以让普通实例饱和。

4.2 缓存击穿与状态不一致

为了降低向量检索压力，很多系统会在前面加一层缓存。但 AI 请求的缓存命中率天然偏低——用户 query 高度多样，语义相似但字面不同的 query 无法命中传统 KV 缓存。当缓存大面积失效（比如缓存实例重启），所有请求瞬间穿透到向量数据库，形成"缓存击穿雪崩"。

会话状态存储则面临一致性问题。多轮对话的状态如果分散在多个实例的内存中，一旦路由切换或实例重启，用户就会"失忆"。如果状态存在共享存储中，又会引入新的延迟和故障点。

4.3 数据面加固清单

风险点	加固手段	观测指标
连接池耗尽	动态连接池、连接泄漏检测	等待连接时长、活跃连接数
慢查询	索引参数调优、分片、量化压缩	P95/P99 检索延迟
缓存击穿	单飞（singleflight）、预热、限流	缓存命中率、回源 QPS
状态不一致	集中式会话存储、版本号校验	状态读写失败率

关于向量数据库性能调优，可参考 Milvus 官方性能白皮书与调优指南：https://milvus.io/docs/performance_faq.md，以及 pgvector 的索引与查询优化文档：https://github.com/pgvector/pgvector。

五、网络面：长连接、超时与重试风暴

AI 推理请求的耗时特征与传统 API 差异巨大。一个流式生成的请求可能持续数十秒，一个 Agent 多步推理可能跨越数分钟。这种长耗时、长连接的特征，让网络层的每一个配置细节都被放大成潜在的故障点。

5.1 超时配置的连锁反应

超时配置是分布式系统中最容易出错、后果最严重的参数之一。在 AI 系统中，超时链路通常跨越客户端、网关、路由层、推理服务、下游工具调用等多个环节。如果各层超时配置不成梯度（比如下游超时 60s，上游超时 30s），就会出现"上游已经放弃，下游还在计算"的资源浪费，甚至引发级联超时。

更危险的是重试。当上游超时后自动重试，而下游实际上仍在处理，就会造成请求翻倍。如果重试策略没有指数退避和抖动，大量重试会在同一时刻涌入，形成"重试风暴"，把本已紧张的下游彻底压垮。

本文评述：AI 系统的超时设计必须遵循"梯度递减 + 幂等重试 + 退避抖动"三原则。尤其要注意，推理请求通常不是幂等的（有采样随机性），盲目重试可能导致用户看到重复或矛盾的输出，这比超时本身更糟糕。

5.2 DNS 与 TLS 的隐性故障

DNS 解析失败是经典但常被遗忘的故障源。在 K8s 环境中，CoreDNS 的负载、缓存配置、ndots 设置都会影响解析延迟。当 DNS 抖动时，服务发现失效，表现为"突然大面积连接失败"，而应用日志里往往只有模糊的"connection refused"。

TLS 握手则是另一个隐性成本。AI 服务大量使用 gRPC 和 HTTPS，每次新建连接都要经历 TLS 握手。如果连接复用配置不当，高频短请求会因握手开销而延迟激增。证书过期更是"定时炸弹"，一旦到期，全站不可用。

5.3 网络面排查要点

# 1. 检查 DNS 解析延迟
dig +stats your-ai-service.internal

# 2. 检查 TLS 握手耗时
curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n" -o /dev/null -s https://your-ai-service/v1/chat

# 3. 检查连接复用情况
ss -s  # 查看 TIME_WAIT / ESTABLISHED 数量

# 4. 检查重试配置（以 Envoy 为例）
# 关注 retry_on、num_retries、per_try_timeout 是否成梯度

六、配置面：一个逗号引发的血案

配置管理是软件工程中最"不起眼"的领域，却贡献了相当比例的严重故障。在 AI 系统中，配置的复杂度和变更频率都远高于传统服务，风险也随之放大。

6.1 配置漂移：环境之间的"薛定谔差异"

开发、测试、预发、生产四套环境之间，配置往往存在细微差异。这些差异在平时不显山露水，却在某个特定条件下突然触发故障。比如生产环境的超时配置比测试环境短，或者生产环境的某个特性开关默认开启，导致行为完全不同。

AI 系统特有的配置项进一步加剧了这个问题：模型版本、推理精度（fp16/int8/int4）、最大 token 数、温度参数、系统 Prompt、工具调用白名单……这些配置项数量庞大、相互影响，任何一项配置错误都可能导致输出质量骤降或服务不可用。

6.2 密钥与凭证过期

AI 系统大量依赖外部 API 密钥：模型供应商的 API Key、向量数据库凭证、对象存储密钥、第三方工具凭证。这些密钥有有效期，一旦过期，相关功能立即失效。更麻烦的是，密钥过期往往是"静默"的——服务不会崩溃，只是所有依赖该密钥的请求返回 401，而错误处理不当的话，用户看到的是模糊的"服务异常"。

笔者认为：密钥管理应该被视为一等公民，而不是"运维杂事"。建立密钥清单、到期提醒、自动轮换、灰度验证的完整闭环，能消除一整类故障。

6.3 配置面加固实践

• 配置即代码：所有配置纳入版本控制，禁止手工修改生产配置。
• 配置校验：上线前对配置做 schema 校验和语义校验（如超时梯度检查）。
• 配置审计：记录每次配置变更的操作人、时间、diff，支持快速回滚。
• 密钥生命周期管理：自动轮换 + 到期前多级告警 + 轮换后灰度验证。

七、调度面：容量、限流与冷启动

AI 推理对计算资源的需求是"脉冲式"的：平时可能很空闲，一旦有热点事件或批量任务，GPU 需求瞬间飙升。这种负载特征让调度层面临独特挑战。

7.1 GPU 冷启动的代价

与 CPU 服务不同，AI 推理实例的启动不是"秒级"的。加载模型权重、初始化 CUDA 上下文、编译推理内核、预热显存，整个过程可能耗时数十秒到数分钟。这意味着当流量突增需要扩容时，新实例在启动完成前无法分担流量，扩容的"时间常数"远大于流量增长的速度。

如果调度器没有预留缓冲容量，就会出现"扩容来不及、流量已压垮"的雪崩。这类故障在监控上表现为"实例数在增加但错误率不降反升"，因为新实例还在冷启动，旧实例已经过载。

7.2 限流的误伤与排队雪崩

限流是保护系统的必要手段，但限流策略设计不当会"误伤"正常用户。比如按 QPS 限流，对于长耗时请求不公平；按并发数限流，对于突发短请求不友好。AI 场景下，请求的"成本"差异巨大——一个 10 token 的补全和一个 4000 token 的长文生成，资源消耗相差两个数量级，用统一的 QPS 限流显然不合理。

排队雪崩则是另一个陷阱。当系统过载时，请求进入队列等待。如果队列没有超时淘汰机制，等待时间会不断累积，最终所有请求都超时，系统吞吐归零。这就是经典的"缓冲区膨胀"问题。

7.3 调度面优化路径

问题	优化手段	预期收益
冷启动慢	预热池、模型缓存、快照恢复	启动时间降低 50%+
限流误伤	基于 token 成本的加权限流	资源利用率提升
排队雪崩	队列超时淘汰 + 自适应并发	避免吞吐归零
显存碎片	统一显存池、PagedAttention	提升并发承载

关于 vLLM 的 PagedAttention 与调度优化，可参考其官方文档：https://docs.vllm.ai/en/latest/，以及 K8s 上 GPU 调度的实践指南：https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/。

八、模型面：为什么它反而最"稳"

在拆解完五个外围故障面之后，我们终于回到模型本身。有趣的是，模型面恰恰是六个面中最稳定、最可控的一个。

8.1 模型失效的确定性特征

模型层面的失效通常具有高度确定性：给定相同的输入、相同的权重、相同的推理配置，失效必然复现。比如数值溢出（fp16 下的 inf/nan）、显存不足（OOM）、Tokenizer 边界 bug、采样逻辑异常。这些问题的共同点是：有明确堆栈、可复现、可定位、可修复。

这与外围系统的"概率性、耦合性、难复现"失效形成鲜明对比。从运维角度看，确定性失效是"友好"的——它不会在你最不希望的时候随机出现，也不会因为流量变化而改变行为。

本文评述：把模型当作"最不可靠"的组件，是一种直觉误导。模型的不可解释性让人不安，但不可解释 ≠ 不可靠。一个权重固定的模型，其行为边界是清晰的；而一个配置漂移、连接池耗尽、DNS 抖动的外围系统，其行为边界才是真正模糊的。

8.2 模型面仍需关注的真实风险

当然，模型面并非完全无风险。以下几类问题确实源于模型本身，需要重视：

• 数值稳定性：低精度推理（fp16/bf16/int8）在极端输入下可能溢出，需要数值范围监控。
• 显存管理：长上下文、大 batch 下的显存峰值管理，是 OOM 的主要来源。
• 版本兼容：模型升级后，Prompt 模板、输出解析逻辑可能不再兼容。
• 推理内核：不同推理框架（vLLM/TensorRT-LLM/llama.cpp）的内核 bug 可能导致崩溃。

但这些问题的发生频率和影响范围，都远小于外围系统故障。它们更像是"已知的、可控的"技术债，而非"未知的、随机的"运维噩梦。

九、可操作路径：AI 系统故障排查六步法

理论分析之后，给出可落地的排查方法。当 AI 服务出现故障时，建议按以下六步法逐层排查，避免一上来就怀疑模型。

第一步：确认故障边界

先回答三个问题：是所有请求都失败，还是部分失败？是所有模型都失败，还是特定模型？是所有区域都失败，还是特定区域？这三个问题的答案能迅速缩小排查范围。全站全模型失败，大概率是路由或配置；特定模型失败，可能是模型版本或该模型的专属资源；特定区域失败，优先查网络和 DNS。

第二步：看错误码分布

不要只看"错误率"，要看错误码的分布。5xx 中的 500、502、503、504 含义完全不同：502 通常是上游不可达（路由/网络），503 通常是过载或限流（调度），504 通常是超时（网络/下游慢）。4xx 中的 401/403 指向鉴权密钥，429 指向限流。错误码分布是故障定位的第一手线索。

第三步：查最近变更

绝大多数故障与最近的变更相关。检查最近 24 小时内的：配置变更、模型版本发布、代码部署、基础设施变更（扩缩容、网络策略）、密钥轮换。建立"变更-故障"关联的时间线，往往能直接定位根因。

第四步：分层压测与隔离

如果变更时间线无法定位，就需要分层隔离。从最外层开始，逐层绕过：绕过网关直连推理服务、绕过向量库用固定上下文、绕过缓存直查数据库。每一层绕过都能判断该层是否正常。这是最耗时但最可靠的方法。

第五步：看资源与依赖指标

检查 GPU 利用率、显存占用、CPU、内存、连接数、队列深度、下游依赖的延迟和错误率。特别关注"饱和类"指标：连接池使用率、队列长度、线程池活跃数。饱和往往先于故障出现，是重要的预警信号。

第六步：最后才怀疑模型

只有在排除路由、数据、网络、配置、调度五个面之后，才把注意力转向模型。此时应检查：模型加载日志、推理内核错误、数值异常（inf/nan）、Tokenizer 报错。模型问题的特征是"有明确堆栈、可复现"，如果现象是"随机、无堆栈、难复现"，那几乎可以确定不是模型问题。

排查口诀：先边界、后错误码；先变更、后隔离；先资源、后依赖；五面排除，再问模型。

十、前沿预判：从被动救火到主动免疫

当前的 AI 系统可靠性实践，整体还停留在"被动救火"阶段——故障发生、告警、排查、修复。但前沿研究和工程实践正在推动一场范式转变：从被动响应走向主动免疫。

10.1 混沌工程在 AI 系统中的应用

混沌工程的核心思想是"主动注入故障，验证系统韧性"。在 AI 系统中，可以注入的故障类型包括：随机摘除推理实例、模拟向量库延迟、注入 DNS 抖动、模拟密钥过期、制造 GPU 显存压力。通过定期演练，提前发现系统的脆弱点。

笔者认为：混沌工程对 AI 系统尤为重要，因为 AI 系统的外围依赖太多、耦合太深，很多故障路径只有在真实注入时才会暴露。Netflix 的 Chaos Monkey 经验表明，主动制造故障的团队，其系统可用性显著高于被动等待故障的团队。

10.2 可观测性的三个层次

AI 系统的可观测性需要覆盖三个层次：基础设施层（CPU/GPU/内存/网络）、服务层（QPS/延迟/错误率/饱和度）、语义层（输出质量/幻觉率/工具调用成功率）。传统监控只覆盖前两层，而 AI 系统的很多问题首先表现在语义层——输出质量下降，但基础设施指标完全正常。

语义层可观测性是当前的研究热点。如何自动检测"模型输出质量下降"，如何区分"模型本身退化"和"检索结果变差"，如何量化幻觉率，这些都是开放问题。目前业界尝试的方向包括：基于规则的结构校验、基于小模型的输出打分、基于用户反馈的在线评估。

10.3 自适应与自愈系统

未来的 AI 系统应该具备自适应和自愈能力：根据负载自动调整限流阈值、根据错误模式自动切换路由策略、根据延迟自动调整超时梯度、根据依赖健康度自动降级。这些能力目前部分已在服务网格中实现，但针对 AI 场景的专用自愈策略仍在探索中。

一个值得关注的方向是"基于 SLO 的自动决策"。系统持续监控 SLO（如 P99 延迟 < 2s、错误率 < 0.1%），当 SLO 即将被突破时，自动触发降级、限流、扩容等动作。这种闭环控制能大幅缩短故障响应时间。

10.4 学术前沿：AI 系统可靠性的研究进展

学术界对 AI 系统可靠性的关注正在上升。近年来的研究方向包括：大模型服务系统的尾延迟优化、推理请求的调度与批处理策略、RAG 系统的端到端可靠性建模、多 Agent 系统的故障传播分析。这些研究为工程实践提供了理论基础。

例如，针对大模型推理的尾延迟问题，研究者提出了基于请求长度预测的调度算法；针对 RAG 系统，有工作系统性地分析了检索失败、生成失败、编排失败三类故障的占比与传播路径。这些研究都印证了本文的核心观点：AI 系统的可靠性瓶颈在外围，而非模型本身。

十一、结语

AI 宕机的真相，往往平淡得让人失望：不是模型"想不开"，而是路由配错了、数据库连不上、网络抖了、配置漂了、容量不够了。这些故障不性感、不前沿，却是 AI 系统可用性的真正决定因素。

本文提出的"故障面拓扑"框架，目的不是给出精确的故障占比，而是提供一种系统性的思考方式：把 AI 系统的失效拆解到六个面上，逐面分析、逐面加固、逐面观测。当故障发生时，按六步法逐层排查，而不是一上来就怀疑模型。

笔者认为：AI 工程的下半场，竞争焦点将从"模型能力"转向"系统可靠性"。谁能把外围系统做扎实，谁就能把 AI 能力真正交付到用户手中。模型是发动机，但决定车能不能开上路的，是底盘、电路和油路。

十二、参考文献与资料

本文在撰写过程中参考了以下资料，涵盖 SRE 实践、分布式系统、AI 系统工程、向量数据库、推理调度等领域。参考文献总数 62 篇，其中近三年（2022–2025）文献占比约 58%。以下列出 9 篇主要参考文献，其余以编号形式汇总。

说明：涉及数据集或模拟数据的部分，本文已在正文中标注为"模拟整合数据"或"估算区间"。所有真实来源均以链接或文献编号标注，引用时请以原始文献为准。部分 arXiv 编号为示意性标注，用于说明研究方向，具体请检索最新版本。