做AI系统最怕的不是模型效果差而是服务半夜挂了没人知道或者流量一上来就雪崩。我做了几年AI应用架构从最开始把模型接口直接甩给业务方调用到后来逐步沉淀出一套可用性设计方案中间踩过的坑真不少。这篇就把我实际在用的方案整理出来不绕弯子直接讲清楚AI系统的可用性到底怎么做哪些环节最容易出问题以及我最后用了什么手段去兜底。这套东西适合谁看如果你正在用大模型API做业务集成或者要自己部署模型服务再或者你是后端工程师、算法工程师需要和推理服务打交道那这篇里的思路和配置可以直接抄作业。我会把设计逻辑、关键参数、部署细节和踩坑实录都拆开讲照着做能把系统的可用性从“靠运气”提升到“可预期”。1. 为什么AI系统的可用性设计和普通后端不一样很多团队一开始把AI服务当作普通HTTP服务来管理结果发现完全不是一回事。普通接口超时重试一下基本能恢复但模型推理服务一旦出了问题重试往往会把雪崩放大。我见过一个真实案例某公司内部一个问答机器人模型服务因为显存溢出挂了网关层还在无脑重试结果每个重试请求都在排队等推理结果最后把整条业务链路全部拖垮。1.1 AI系统的三类故障模式要设计可用性方案先得搞清楚AI服务到底会出什么故障。我归纳下来就三类第一类是推理资源耗尽。GPU显存被打满、CPU算力被占死、显存碎片化导致新请求申请不到内存这类故障最典型也最容易引发连锁反应。普通后端超时只是浪费一点CPUAI服务超时会占着宝贵的GPU资源不放。第二类是模型行为异常。模型推理结果突然变成乱码、空内容、或者输出不稳定的结果。这类故障在传统后端里几乎不存在因为传统服务的输出是可确定的而AI模型的输出天然有随机性没法用简单的断言去判断“对不对”。第三类是依赖链路故障。比如调用外部模型API时对方限流或高延迟访问向量数据库超时依赖的特征服务挂了。AI应用的服务依赖树通常比普通应用深任何一个环节抖动都会放大到最终结果。1.2 可用性指标的重新定义传统后端的可用性指标是“请求成功率”但这套指标放在AI系统上不够用。我给团队定的核心指标有三个缺一不可可用性Availability 成功响应请求数 / 总请求数。这个是基础不用多说。有效响应率 语义有效响应数 / 成功响应数。很多请求虽然返回了200但内容是空、是报错信息、或者是胡言乱语这些都算无效响应。我要求这个指标必须做到99%以上。业务兜底率 降级路径成功处理数 / 触发降级请求数。AI服务终归有无法响应的极端情况这时必须保证能优雅降级而不是直接抛异常。这个指标能反映你的兜底设计做得够不够扎实。2. 可用性架构的整体设计思路整个方案我分成四层来做每一层解决不同的问题层层设防而不是把宝全押在一层上。2.1 四层防护架构第一层是接入层负责限流、熔断、鉴权和流量调度。这一层和普通网关差不多但限流策略要根据模型推理的特性调整不能简单地按QPS限。第二层是服务层负责请求编排、上下文管理、重试策略和降级判断。这一层是AI应用特有的一层承担着“理解请求、决定怎么调模型、失败了怎么办”的职责。第三层是模型层负责推理服务本身的可用性包括多副本部署、模型版本管理、显存监控、动态伸缩。这一层最容易被人忽略因为很多团队把它当作“一个黑盒API”来用。第四层是数据层负责向量库、缓存、特征库的高可用。AI应用对数据的依赖比传统应用更重向量库一挂整个检索增强生成链路就废了。2.2 关键设计决策同步调用还是异步处理AI应用架构里最先要定的一件事是模型调用走同步还是异步。很多团队默认选择同步因为实现简单但这恰恰是可用性设计的第一个隐患。同步调用的优点是逻辑直观用户体验好请求发出去就能等回结果。缺点是推理时间长大模型单次推理经常要几秒甚至几十秒同步调用会让连接长时间占用一旦慢请求堆积整个服务的线程池就耗尽了。异步调用的优点是削峰填谷请求先入队后台任务慢慢消费服务稳定性好还能做批量推理。缺点是需要额外引入消息队列还要处理回调或轮询客户端逻辑更复杂。我现在的建议是分场景混用对实时性要求高的场景比如在线客服、聊天对话走同步但严格控制超时时间对实时性要求不高的场景比如批量内容审核、离线分析走异步队列。这样既保证了用户体验又不至于让推理服务被瞬时流量冲垮。3. 接入层的限流与熔断实操接入层是防护的第一道门我总结的核心原则就一句话宁可拒绝新请求也不能让已有请求全部超时。3.1 限流参数怎么定普通接口的限流按QPS算就行AI接口必须按“并发中的推理请求数”来限。为什么因为GPU的显存是硬约束真正限制吞吐的不是请求频率而是同时能跑多少个推理任务。我通常用这个公式估算单副本最大并发最大并发数 显存总量 / 单请求峰值显存占用举个例子一张24GB显存的卡跑一个需要8GB显存的中型模型峰值并发最多3个。但实际我会留出30%的显存余量防止碎片化所以配置并发上限为2。超过这个值后面的请求就要排队等待。限流算法我用的是令牌桶但速率参数不是拍脑袋定的而是通过压测得来的。具体做法是先以低并发压测逐步增加并发数观察推理延迟的拐点。在拐点之前延迟基本平稳过了拐点延迟会指数级飙升。我把限流阈值设定在拐点的80%位置留出安全缓冲。3.2 熔断策略的踩坑记录熔断器我用的是经典的三种状态关闭、打开、半开。AI服务熔断和普通服务最大的不同在于AI请求成本很高失败一次浪费的资源远大于普通请求。所以我的熔断阈值设得很激进错误率超过10%就熔断而不是常见的50%。这里有一个血的教训。之前某次模型升级后推理错误率从1%涨到了15%熔断器没有触发因为阈值设的是50%大量坏结果直接返回给了用户。那之后我就把熔断阈值调成了10%同时增加了对无效响应的判定——只要结果长度为0、结果包含错误标志、结果置信度过低都算失败。熔断后的处理不应该是直接报错而是走降级链路。我的降级顺序是这样设计的先尝试用缓存结果兜底再用小模型替代大模型最后再返回预设的固定回复。每一级降级都要有监控告警否则降级链路什么时候触发的都不知道。4. 模型服务层的稳定性设计模型服务层是整个方案最核心的部分也是最难做好的。我把它拆成三个子问题多副本怎么调度、模型版本怎么管理、GPU资源怎么监控。4.1 多副本部署与请求路由单副本的模型服务再稳定也有单点风险多副本是必须的。但多副本不是简单复制几份就行还牵扯到请求路由策略。我用的是自定义路由规则而不是简单的轮询。具体配置逻辑是每个模型副本启动时上报自己的状态包括健康状态、当前负载、显存利用率。路由层根据这些信息做加权调度负载低的副本多分流量。副本的健康检查不是简单的“进程活着”而是做一次真实的推理探活——发一个很小的测试请求只有返回结果正常的副本才认为是健康的。每次探活之间至少间隔30秒避免探活请求本身消耗太多推理资源。这样做的效果是某台机器出现显存泄漏、推理卡死时路由层能很快感知并切走流量用户基本无感。4.2 模型版本管理与灰度发布AI服务的发版风险比普通服务高得多因为你没法预知新模型在真实流量上表现如何。我强烈建议做灰度发布不能直接全量切换。我目前的灰度流程是这样的新模型版本先部署一个副本流量按5%比例切过去观察两个核心指标——有效响应率和用户反馈。如果观察24小时没异常再把流量提高到30%再过48小时没问题才全量切换。灰度发布期间必须保证新旧版本的响应格式完全一致否则业务方要同时兼容两套格式出问题的概率陡增。我在实践中就踩过一回新版本模型按要求返回JSON格式但字段名改了一个灰度阶段没有业务方发现问题全量后第三天相关业务才暴露字段缺失排查了一整天才定位到是模型版本切换导致的。4.3 GPU资源监控的三个关键指标GPU问题不像CPU那样能直观看到但监控不到位的后果很严重。我现在固定监控三个指标显存利用率。超过85%就要预警超过95%必须立即处理因为显存碎片化会让实际可用显存远低于理论值。GPU利用率。这里要注意GPU利用率低不等于没问题。如果利用率低但请求排队严重说明推理瓶颈不在计算而在显存带宽或者数据加载。显存泄漏趋势。连续观察多天的显存使用曲线如果每天趋势都是“重启后很低、越跑越高”说明有泄漏要尽快定位是推理框架的问题还是某个模型版本的问题。我这边的监控告警还有个特殊设计模型输出的平均Token长度也监控。Token长度异常偏长或偏短往往意味着模型行为在变化这比看服务器指标更早发现问题。5. 依赖链路的可用性治理AI应用的依赖链路比传统应用长得不是一星半点。以检索增强生成为例一次请求可能要经过认证服务、意图识别模型、向量检索、重排序模型、大模型生成最后还要过内容审核。这条链上任何一环出问题整个请求就失败。5.1 三级缓存设计缓存是我最看重的可用性手段因为模型推理不可控但缓存是可控的。我做了三级缓存本地内存缓存响应时间微秒级适合高频率的完全相同请求比如热门问题的标准答案。内存缓存的空间有限我用LRU淘汰策略控制每台机器最多缓存最近5000条结果。分布式缓存响应时间毫秒级适合多实例共享的场景比如同一个热点问题在短时间内被大量用户问到。这个层的缓存时间我设置了动态TTL热点问题缓存10分钟普通问题缓存5分钟。降级缓存专门存放降级方案。当主链路不可用时直接用缓存里对应的历史结果或者预设文案返回。缓存设计里有一个特别注意点缓存不能缓存所有请求否则数据的时效性和准确性会出问题。我只对语义完全一致或高度相似的请求做缓存。判断方式也很简单——对请求文本计算向量向量相似度超过0.95的命中缓存。5.2 超时与重试的正确配置AI链路里每一环都必须有超时控制这是可用性的底线。我的默认超时分配方案是外部模型API调用3秒超时重试1次重试间隔500毫秒。向量数据库查询1秒超时不重试直接降级。特征服务调用800毫秒超时重试1次。总体链路超时5秒超过就返回降级结果。重试这里有个关键原则不是所有失败都适合重试。超时类错误可以重试业务类错误千万不能重试。我曾经犯过的错是参数错误导致的4xx响应还去重试白白浪费了模型调用次数还拖慢了响应速度。对于重试我还加了一个自适应重试策略当连续两次重试都失败了立即停止重试并熔断等30秒后慢慢放量恢复。这么做是防止“重试风暴”打垮下游服务。5.3 熔断和降级的联动逻辑熔断和降级一定要联动不能各自独立。我的设计逻辑是下游依赖挂了立即熔断该依赖同时启用降级路径。以向量库为例一旦熔断所有需要向量检索的请求自动改写为走关键词检索加全文匹配的降级路径。虽然效果差一点但至少请求有结果返回。降级路径本身也要有熔断保护。降级路径如果也不可用直接返回预设话术并记录一条日志用于后续分析。这样的设计保证了极端情况下系统依然有响应而不是让用户面对超时错误。6. 可观测性与告警体系搭建可用性方案做得再好如果观测不到位出了问题就是两眼一抹黑。我搭了三个维度的观测体系从基础设施到模型行为全覆盖。6.1 三个维度的观测指标基础设施维度看服务器CPU、内存、GPU、网络IO这些基础指标。这些指标用现有的监控工具就能采集关键是设置合理的告警阈值。服务维度看请求量、成功率、延迟分布、并发数这些标准服务指标。这里有个重点不要只看平均延迟要看P99延迟。有一次我们的P99延迟从2秒涨到了15秒平均延迟只从1.5秒涨到2秒如果只盯平均值根本发现不了问题。AI专项维度看模型响应长度、推理置信度、Token消耗量、无效响应率、用户反馈率这些AI特有的指标。这些指标是判断模型行为是否异常的关键。6.2 告警分级与处理流程告警不能一条信息发完就结束了必须分级、分人、有处理流程。我这边分四级紧急告警系统不可用或大面积超时立即推送电话和短信值班工程师必须在5分钟内响应。重要告警单机异常或某个模型版本错误率升高推送即时消息10分钟内确认处理。一般告警资源使用率偏高或延迟轻微劣化进值班群汇总30分钟内排查即可。提示信息日常状态变化记录归档不打扰人。值班处理流程也固定化收到告警后第一步先了解影响范围第二步按预案处理第三步同步状态第四步复盘。不要让工程师一边睡眼惺忪一边现想应对方案所有已知故障都要有预设的处理SOP。6.3 根因定位的实战方法AI系统的故障根因定位比常规系统难因为一条链路涉及太多环节。我常用的定位思路是逐层排除法。先判断是模型问题还是链路问题用同样的请求直接调用模型服务如果模型返回正常排除模型问题问题在链路其他环节。再判断是代码问题还是资源问题看服务器CPU和GPU指标如果资源没打满但延迟高大概率是代码锁竞争或下游阻塞。最后判断是偶发问题还是持续问题看趋势图如果偶发大概率是网络抖动或下游瞬时异常如果持续大概率是代码逻辑或配置问题。这套排除法说起来简单实际排查时需要有完整的日志链路追踪配合。我给每个请求都分配一个追踪ID全链路打点这样定位问题时才能把一次请求经过的所有环节串起来看。7. 一次真实故障的完整复盘理论讲再多不如看一次实战故障怎么处置的。下面这个案例发生在我们的线上环境我完整还原整个排查和处理过程你会发现可用性方案在真实场景里是怎么发挥作用的。7.1 故障现象描述某个周四下午运营反馈核心AI助手突然大面积回复超时。从监控看请求成功率从99%骤降到70%P99延迟从2秒飙升到了12秒同时模型服务所在节点的GPU利用率从60%暴涨到99%。第一反应是模型服务被打满了但检查后发现请求量并没有明显上涨流量和平时差不多。7.2 排查过程与关键判断我按排除法走了一遍第一步直接测试模型健康接口模型单个请求响应正常排除模型本身挂掉的可能。第二步检查依赖服务状态发现向量数据库集群的CPU偏高但还没到危险线。第三步看日志链路发现大量请求卡在向量检索环节平均耗时从原来的80毫秒涨到了4秒。问题指向了向量库。继续深挖向量库发现一个集合的索引出现了碎片化查询效率急剧下降。索引服务的单次查询从毫秒级变成了秒级但系统没有超时控制所有请求都卡住等待查询结果逐渐把线程池占满。线程池满了以后新请求又堵在队列里最终形成雪崩。7.3 应急处理与事后改进当时的应急动作分三步走第一步开会第一时间手动触发向量库的索引重建代码新建集合后导入全量数据耗时大概20分钟。这期间所有新请求暂时切换为关键词检索降级路径保证基本服务可用。第二步将向量库查询的超时时间从默认的30秒收紧到2秒超过即返回兜底结果防止单点故障拖垮整个链路。第三步扩容模型服务副本从3个扩到6个分担积压的请求队列。事后做了三个改进给向量库查询增加超时熔断机制增加索引碎片化程度的定时检测任务复盘会议确定所有外部依赖必须配置超时和降级路径不允许无限制等待。这次故障给我最大的触动是一个依赖服务的性能劣化就能拖垮整条AI链路。可用性设计不能只看主链路每一条依赖分支都要有兜底手段。8. 这套方案的落地清单和后续演进方案讲到这里我把核心要点再按实操顺序理一遍方便你直接对照落地。8.1 落地实施顺序建议建议按这个顺序推进因为依赖关系是这样第一周先搭可观测性体系。没有监控就谈不上可用性设计。先把基础设施指标、服务指标、AI专项指标的采集和告警配起来。第二周做接入层的限流和熔断。这是投入产出比最高的环节一个熔断器就能挡住很大一部分雪崩风险。第三周做依赖链路的超时和降级配置。把所有外部调用的超时时间、重试策略、降级路径全部补齐。第四周做模型服务层的多副本和灰度方案。这个环节涉及模型管理和发布流程需要和算法团队配合。最后持续做压测和故障演练。没有经过压测的限流阈值就是拍脑袋没有经过演练的应急预案就是纸上谈兵。8.2 推荐的选型参考工具选型取决于团队规模和技术栈我给出一些验证过靠谱的方向监控体系用主流开源时序数据库加报警组件配合链路追踪工具使用。消息队列选吞吐量高、生态成熟的那一类重点看是否支持延迟消息因为异步推理的场景需要定时回调。模型服务框架方面重点考察是否支持动态批处理、显存优化、多模型管理这三个能力直接影响推理服务的可用性和吞吐。动态批处理能把多个请求合并成一次推理显著提升GPU利用率这在并发高时非常关键。向量数据库方面重点看查询性能的稳定性、索引管理能力和水平扩展能力。就像上面案例里那样索引劣化的问题在向量数据库里比传统数据库更常见。8.3 方案还能怎么演进这套方案目前已经稳定运行了一年多但AI系统可用性设计还在快速演进我观察到的几个方向值得你持续关注弹性推理会是趋势。按流量动态调整GPU资源高峰扩容、低谷缩容能显著降低成本但对资源调度提出了更高要求。多模型路由值得探索。根据请求复杂度动态选择不同规模的模型简单的请求走小模型复杂请求才走大模型。既能保证效果又能大幅降低推理成本和故障面。模型输入输出的安全校验会越来越重要。不仅要检查格式合法性还要做内容安全性校验和敏感信息过滤这些都会纳入可用性设计的范畴。从我个人的实际经验来说AI系统可用性设计没有银弹就是一个不断暴露问题、修复问题、再补强监控的过程。最关键的一点是永远假设系统会挂然后提前想好挂了怎么办。把每一次故障都变成改进的机会这套方案就会越跑越稳。