这个题目我第一反应是想起前年冬天凌晨那次事故。当时监控大屏上一片飘红十几个AI服务接连告警API服务大面积超时大模型推理全部卡住连我们给内部客服做的Agent任务链也断了电话和群里全在问怎么了。那次事故持续了两个多小时最终定位到的是一个GPU节点的显存ECC错误引发连锁反应但排查过程远比这曲折。做AI基础设施这些年我越来越觉得AI服务集体故障跟以前做传统微服务故障完全是两码事不能用老思路去扛。这篇文章我想把AI服务故障这个话题彻底拆开聊聊——它为什么这么难搞、事前的架构和容量要怎么看、事中怎么快速止血、事后怎么复盘改进希望能给同样在做AI平台、大模型应用服务的同学一些可落地的参考。1. AI服务集体故障为什么这次和以前不一样1.1 传统故障和AI故障的底层差异先说个扎心的结论传统Web服务故障是开卷考试AI服务故障是闭卷考试。以前做电商后端一个接口变慢了链路追踪一拉哪个方法耗时高、哪条SQL没走索引十分钟内基本能定位。因为传统服务面对的是确定性的输入、确定性的状态问题复现率高报错信息也相对规范——连接池满了、内存溢出、磁盘写满这些都是水位到了就出事的模式监控起来非常直观。AI服务完全不是这样。同样的prompt在A实例上输出正常在B实例上可能就乱来同一个模型白天响应快晚上某个时段的P99能翻十倍传统服务性能瓶颈大多在CPU和内存AI服务的瓶颈可能出在显存带宽、KV Cache容量、GPU降频、NCCL通信超时甚至只是温度超过了85度导致显卡降频。而且AI服务的依赖链条特别长。一个在线推理服务底层依赖GPU驱动、CUDA版本、PyTorch框架、模型权重、tokenizer、向量数据库、特征服务上游还可能接了第三方大模型API。任何一个环节出问题表象都是服务超时返回异常但你从服务日志里根本看不出来是哪一层出了问题。我遇到过最离谱的一次查了半天最后发现是机柜里一台交换机的光模块因为灰尘太多丢包率升高触发了NCCL的通信超时整个分布式推理集群性能腰斩。还有一个容易忽略的点AI服务的环境漂移速度远快于传统服务。模型版本一两天一换推理框架经常升级GPU驱动要跟着补丁这些变化叠加在一起本身就容易制造故障。很多AI团队现在实行的还是快速试错模式模型和代码一样频繁变更但配套的稳定性保障却停留在传统微服务时代不出事才怪。1.2 AI服务故障的类型地图既然AI故障复杂第一件事是把故障分层归类。我习惯把AI服务故障分成五个层面这样复盘和排查时能快速缩小范围故障层面典型表现常见根因基础设施层节点NotReady、推理延迟飙升、训练中断GPU掉卡、显存ECC错误、光模块异常、供电散热问题平台编排层容器启动失败、调度卡住、Pod被驱逐K8s节点异常、GPU共享调度冲突、镜像仓库故障运行时框架层进程OOM、算子报错、推理结果NaNCUDA/OOM、框架版本不一致、显存泄漏、算子兼容问题服务逻辑层接口超时、返回乱码、Agent链路中断上下文窗口溢出、提示词引发无限循环、超时重试风暴数据与依赖层向量检索变慢、特征延迟、上游API故障向量库抖动、实时特征通道拥堵、第三方模型服务限流这五个层面不是孤立的一个底层故障往往会被上游放大成集体故障。比如GPU显存ECC错误导致一个推理节点异常负载均衡器把流量转发到其他节点其他节点扛不住压力集体超时此时客户端开始重试重试又加剧服务压力最终整个AI服务群雪崩。理解这个传导链条是应对AI服务故障的第一步。2. 故障发生前把防线往前移才是性价比之王2.1 高可用架构里AI服务最容易忽略的坑每次事故复盘后大家都会说要加强架构但AI服务的高可用架构和传统服务有个显著区别推理节点要尽量无状态。这句话听着简单做起来很多团队都栽了跟头。有状态的服务做故障转移是很痛苦的。比如你在推理服务进程里直接缓存了用户会话、把向量索引的副本放在本地磁盘、或者用进程内变量保存模型计数一旦节点宕机这些状态全部丢失即使K8s帮你把Pod重新调度到新节点服务也无法无缝恢复。正确的做法是推理节点只保留模型权重和运行环境所有的会话状态、业务状态放到外部的Redis或数据库里向量数据放到独立的向量数据库集群。这样节点挂掉后新节点拉起只需要加载模型权重流量重新路由过去就能继续服务。说到集群故障转移很多运维同学第一反应是拿来当噱头的软件功能但真正的故障转移背后是健康检查、脑裂处理、数据同步三个难题。以我们用的方式为例网关层用Consul做服务发现每个推理实例启动时注册然后每5秒上报一次健康状态网关发现连续3次健康检查失败就把节点从服务池摘除同时触发备用集群的扩容。这里的核心设计是摘除要快恢复要慢——发现异常的响应时间控制在15秒以内但恢复后重新接入流量要等节点预热完成否则一接入就打挂形成抖动循环。还有服务通信协议层的选择。AI服务内部之间的通信我强烈建议用gRPC而不是HTTP。gRPC的HTTP/2多路复用能力在大量并发推理请求下优势明显连接复用能显著降低时延。但要注意gRPC的连接管理也有坑比如连接池默认大小、跨可用区的长连接稳定性一旦连接池被占满新的请求会排队等待延迟飙升。我们曾因为连接池设置过大导致故障时单个网关到后端的连接数爆炸直接打满了后端的文件描述符。2.2 容量规划算一算你的显存到底够不够传统容量规划看QPS、CPU、内存AI服务容量规划的核心是显存和推理吞吐。别小看这一步很多集体故障其实都是容量不足引发的次生灾害——正常运行水位就有70%了一个节点挂掉流量分摊过来直接打满。这里分享一个七B模型需要大致算清楚的方法。假设你用FP16精度的7B模型权重那么加载权重约占14GB显存。如果用的是单卡A100 80G假设框架和运行时再占8GB剩余给KV Cache的显存大约是58GB。KV Cache大小和并发数直接相关典型7B模型如果没有使用GQA每个token大约需要0.5MB的缓存空间具体取决于层数、注意力头数和精度。如果一个请求的上下文和生成长度合计约2048个token那么这个请求大约要占1GB显存。粗略估算单卡能同时服务的并发约在58路左右如果使用GQA优化KV Cache可能降到原来的四分之一并发数可以到200路以上。从这个算例能看到几个结论性的经验AI推理服务的并发上限很多时候不是GPU利用率不够而是显存被KV Cache吃满继续接入请求就会触发OOM。容量要留出故障转移的冗余。我的建议是稳态水位不要超过总容量的60%这样至少能扛住一个节点故障后流量重新分配的压力。每个版本的模型发布前必须重新评估容量。好多团队模型一升级显存占用上升20%推上去第二天就集体故障原因就是没算这笔账。2.3 限流与降级把服务雪崩扼杀在萌芽期一句话你的AI服务必须有一键降级的开关而且这个开关要提前做好不能在故障发生时才写代码。降级方案要分梯队。第一梯队是模型降级主模型是大模型遇到故障时把流量切到小模型哪怕效果差点至少用户在几秒内能拿到结果而不是一直转圈。第二梯队是功能降级先停掉最耗费资源的特性比如流式输出、长文本生成、图片生成保留基础文本问答。第三梯队才是拒绝服务直接返回限流提示或走静态兜底答案保证系统不雪崩。限流这块我见过太多的假限流只做了单机限流没做全局限流。单机限流看着每个节点都正常但有一个节点故障时其他节点分配的流量瞬间增加单机限流为了保护自己开始拒绝请求用户看到的却是大量报错。正确做法是网关层做全局限流按用户维度、接口维度分别设置配额同时在服务端保留线程池隔离机制——不同的下游依赖用独立的线程池一个下游阻塞时不要拖垮其他链路。这和微服务架构里的舱壁设计一个道理只不过在AI场景下线程池隔离的对象变成了模型推理、向量检索、特征获取这些更粗粒度的资源。3. 事中处置AI服务应急响应的七个关键动作3.1 发现AI服务告警要盯哪几个指标告警不是越多越好告警太多等于没有告警。我见过一个AI平台的报警规则接近两百条结果真正出大事时关键告警被淹没在了一堆无关通知里。AI服务的监控指标通用的黄金四指标依然适用延迟、流量、错误、饱和度。但还需要补充AI场景特有的指标GPU利用率、显存利用率、显存ECC错误计数、GPU温度/功率推理时延的P50/P95/P99以及解码速度每秒生成的token数请求排队长度、Batch Size变化、KV Cache占用率NCCL通信错误次数、NVLink带宽降级模型侧指标Token重复率、超时率、输出截断率告警规则的设计要强调持续性和相对变化而不是绝对阈值。比如P99时延超过基线1.5倍持续5分钟才告警能滤掉大部分瞬时抖动。再比如GPU ECC错误偶发一两次可能是宇宙射线但如果5分钟内错误数增长了100倍这就是硬件即将坏掉的强烈信号。发现环节还有一个容易被忽视的机制错误日志的聚合与趋势分析。很多AI故障的早期信号是日志里出现零星的特殊报错比如某个算子的warning、某个驱动版本不兼容的提示。建议把服务日志接入ELK或者Loki对特定错误码做聚合计数设置5分钟内同类错误数量突增的告警。3.2 止血先说降级、熔断与隔离故障发生时第一原则是先恢复后排查但恢复之前要花几分钟保留现场。我的习惯是确认故障发生后的第一件事不是改代码、也不是重启服务而是立刻做三件事打快照保留当前监控大盘截图、GPU监控数据、关键日志段。拉时间线记录从第一个告警到现在的关键时间点。建立指挥群明确谁决策、谁执行、谁通报。做完这三件事立刻进入止血动作。具体按什么顺序操作取决于故障类型如果是单个实例异常直接摘除该实例把流量切走。如果是服务大面积超时优先执行降级策略把大模型流量切到小模型或兜底逻辑。如果是上游依赖故障比如向量数据库无响应启动熔断器快速失败而不是让请求长时间挂起等待。如果是多个服务同时故障先限流保护最核心的链路再考虑整体容量问题。这里要特别强调重试风暴的问题。AI服务超时后客户端和前端的重试机制会成倍放大流量。我见过一次大模型API故障客户端因为设置了5次重试直接把后端压垮了。最好在网关层做统一的重试策略并且开启重试退避比如首次重试等500ms、下次等1秒、再下次等2秒指数退避能有效避免重试风暴。3.3 排查快速定位与现场取证止血之后进入定位阶段。AI服务故障的排查我看过不少团队直接在服务台看代码这是效率最低的方式。正确的路径是从外向内、由整体到局部先看整体链路网关入口成功率是多少哪个接口失败最多用户流量是如何路由的再看服务依赖模型服务、向量库、特征服务各自的指标是否正常有没有慢依赖然后看实例状态所有推理节点都能正常响应吗有没有节点已经处于故障边缘最后才是深入到代码如果前面的检查都没有结论再去看具体的异常日志、调用链。现场取证的系统化程度直接决定复盘质量。我要求团队在故障期间必须保留以下数据故障时刻的GPU监控快照显存、功率、ECC计数、异常样本的请求日志和模型输出、完整调用链追踪、容器资源使用趋势。这些数据看似占据存储空间但后续根因分析完全依赖它们删除就意味着复盘只能靠猜。4. 高频故障场景排查思路实录4.1 案例一推理服务RT突刺这个案例经常被当成灵异事件处理。现象是QPS没有明显变化请求量稳定但P99时延从200ms突然涨到2秒持续半小时后自动恢复。团队一开始怀疑是代码问题把发布记录翻了个遍也没发现异常。排查过程是这样的先看GPU利用率发现利用率并不高排除了算力瓶颈再看请求参数分布发现平均上下文长度没有变化然后看网络层网关到推理服务的连接数正常。最后是通过GPU温度曲线定位到的——故障期间GPU温度从65度升到88度触发了显卡降频保护推理性能大幅下降。温度升高的原因是机房空调的冷冻水阀故障整个机柜的散热能力下降。经验总结AI服务的RT突刺首要排查方向不是代码而是硬件和资源水位。重点看三层GPU频率曲线、温度曲线、显存带宽。只要GPU频率出现陡降大概率是散热或供电问题。后来我们把GPU温度纳入了核心监控阈值设为85度连续超过1分钟就告警这个问题就再也没有造成过长时间故障。4.2 案例二API网关大面积超时另一个高频场景是API服务大面积超时现象非常吓人客户端502、504报错一堆但后端服务看负载并不高。排查链条是这样展开的先登录网关节点发现负载不高CPU正常但连接数异常达到文件描述符上限的90%。再看后端发现新增的推理节点因为镜像拉取失败一直没有注册成功可用节点变少了请求全部压到存量节点上。网关等待后端响应的时间变长导致网关连接被占满新请求无法建立连接于是超时报错。这个问题有代表性核心原因是编排层故障和服务层故障互相放大。后来我们做了两件事一是镜像仓库做了多区域冗余并且把镜像拉取改成增量拉取避免大镜像阻塞二是给网关的连接数监控加了告警同时设置了后端慢响应的快速失败阈值等待超过3秒直接返回超时而不是让请求无限期占着连接。4.3 案例三GPU节点假装健康这是最坑的硬件故障模式。节点在K8s里显示Readynvidia-smi也能看到GPU但推理任务全部卡住或者返回NaN。我们那次的实际情况是GPU发生了可纠正的ECC错误硬件还在正常工作但错误率越来越高最终触发了该卡的计算异常。由于K8s本身只检查进程是否存活它根本不知道GPU已经出了问题流量还在继续调度到这个节点故障被放大了。处理这种假装健康的节点靠人工看nvidia-smi根本不现实一定要做主动巡检。方案是用DCGM Exporter采集所有GPU节点的详细信息包括ECC错误计数、温度、功率、利用率并设置如下告警可纠正ECC错误计数5分钟内增长超过100触发警告准备迁移业务。出现Xid错误直接告警立即摘除节点。显存使用率持续100%超过10分钟告警人工确认是否存在泄漏。这套机制上线后我们基本能在硬件完全坏掉前把业务迁移走AI服务因为GPU问题导致的集体故障明显减少。4.4 常见故障速查表故障现象可能原因快速处置推理P99突刺GPU利用率不高GPU降频、温度过高、显存带宽瓶颈检查温度/频率曲线降低并发或开启风扇策略部分请求返回NaN或乱码显存ECC错误、驱动问题、模型权重文件损坏摘除异常节点校验模型权重hash分布式推理NCCL超时网络丢包、交换机故障、单节点性能差拖累集体检查NCCL通信日志隔离慢节点API网关大量504/499后端连接池占满、慢响应堆积、节点数不足限流快速失败人工扩容可用节点Pod反复重启镜像拉取失败镜像仓库故障、镜像过大、认证过期切备用镜像仓库加本地缓存向量检索时延升高向量库索引内存不足、并发过大、分片不均扩容副本临时降级为关键词检索Agent任务链中断上游模型超时、上下文超限、工具调用异常增加工具调用重试与超时降级新建服务容器启动卡在GPU驱动驱动与容器运行时版本不匹配回退驱动版本统一容器镜像基线5. 故障之后复盘、演练与持续改进5.1 复盘不是追责是建立故障档案很多团队的复盘会开成了责任认定会这完全走偏了。故障复盘的核心是还原事实、提炼改进项、建立防复发机制。我的复盘框架是四段式时间线从故障发生到恢复的完整时间线每个关键节点的操作和效果。影响范围哪些服务、多少用户、持续多长时间、经济损失多少。根因分析这里严格区分技术根因和管理根因。技术根因是直接触发故障的动作管理根因是为什么这个缺陷没有被发现。改进项列表明确到负责人和完成时间。复盘之后一定要把结论沉淀成一份故障档案或者知识库文档。我们内部有个故障案例库每次复盘完都强制要求团队把经验写进去。这样即使某个核心同学离职下一茬人也不至于两眼一抹黑。实际看下来很多团队第一次遇到某个故障很慌张但有了案例库之后第二次类似故障的定位时间能缩短一半。5.2 混沌工程与故障演练用演练换事故一说到故障演练很多同学第一反应是这太危险了万一真搞挂了怎么办。我的观点恰恰相反在可控环境下搞挂总比在生产环境突然挂掉好。但演练必须循序渐进不能一上来就暴力杀节点。建议的演练路径是从单点破坏开始先选择一个不重要的推理实例手动杀死它的Pod观察服务发现和负载均衡是否自动切换然后是更残酷的场景直接模拟某个可用区整体断网看跨可用区的failover是否生效再进一步模拟关键下游依赖变慢给向量数据库人为注入延迟看服务端的超时控制和降级策略是否触发。每次演练都是一次低成本的故障排查。我们有一次演练甚至发现了当初最引以为傲的自动扩缩容有一个致命缺陷扩容节点的冷启动需要10分钟而故障恢复窗口只有5分钟扩容还没来得及完成服务已经被打挂了。这个坑如果不演练真到生产事故时才暴露后果不敢想。演练之后要产出两个产物一是更新故障预案把本次演练发现的问题修复掉二是更新故障预案手册写成清晰的执行清单确保一个不熟悉系统的人也能照着执行止血操作。5.3 从救火到防火持续的战略改进最后说点长远的。应对AI服务集体故障不能永远停留在救火队员的层面要逐步建立一套预防体系。我在团队里要求每个AI服务都定义SLO核心就三个可用性、时延、准确率。可用性不用说了时延一般定P95小于多少准确率则需要建立线上的评测机制。有了SLO背后就有预算。比如一个服务的时延SLO是P95小于500ms那个月如果P95达到600ms就消费了20%的错误预算团队必须主动调整容量而不是等着用户来投诉。容量治理和压测也要常态固定化。每次大模型版本更新全链路压测必须同步进行。我见过很多团队只测推理单节点的能力忽略了网关、向量库、特征通道这些全链路的瓶颈。实际上AI服务很多故障恰恰出在依赖链路尤其是实时特征服务哪怕只有几十毫秒延迟波动在高并发场景下都可能被放大成超时。还有一件事很容易被忽视发布流程的安全性。AI服务的变更太多太杂模型权重、推理代码、量化策略、Prompt模板每个都是变量。我强烈建议为AI服务建立独立的发布门禁发布前自动跑回归测试、评测准确率指标、检查显存占用变化、对比时延基线。有一项不达标就不许上线。这个机制曾经在很长一段时间里帮我们挡住了好几个本来会引发集体故障的坏版本。最后分享一个我的真实体会应对AI服务集体故障没有什么银弹最可靠的永远是那些看起来最笨的准备工作——提前写好的降级脚本、反复演练过的故障切换、沉淀到文档里的案例库、以及团队里每个人都清楚的遇到大事先别慌按照流程一步步来的共识。这些年我最大的教训就是不要在故障发生的半夜三更指望自己灵光一现想出完美方案真正的完美方案一定是在白天写的。如果你只能从这篇文章里带走一个动作那就趁现在去给你的AI服务加一个一键降级的开关哪怕只是把大模型换成规则匹配的兜底逻辑都会让你在下一次故障到来时比以往任何一次都睡得着觉。