做AI应用架构这几年我最大的感受是很多团队把大模型接进来就以为完事了结果上线第一个月就被可用性设计搞得焦头烂额。模型接口一抖用户就骂上游供应商一限流业务就瘫重试机制没想清楚账单先爆了。这些问题的根源在于我们还在用传统分布式系统的可用性思路做AI系统但AI系统的失败模式、延迟特征、成本模型完全不一样。今天这篇东西就是想把我在一线反复踩坑总结出来的AI系统可用性设计经验一次性讲透适合正在做AI应用落地、AI Agent搭建、或者想把已有系统接大模型的架构师和开发同学参考。先说清楚一个容易混淆的点标题里的“可用性设计”在AI应用这个语境下有两大层含义。第一层是传统的Availability也就是服务动不动得了、接口挂不挂、SLA够不够这是老生常谈的高可用话题。第二层是AI系统独有的“可用性体验”比如模型回复够不够快、降级策略切过去之后用户还买不买账、并发一高会不会连环超时。这两层必须同时设计缺一个都会出事。我见过太多团队只做了第一层结果服务没挂但用户体验像在拨号上网也见过团队一味堆缓存和降级结果核心场景全在降级态产品价值直接归零。所以这篇文章要解决的核心问题只有一个怎么让你的AI应用在模型层不稳定的前提下对外仍然稳定、快速、可解释。1. 先搞清楚AI系统的“可用性”到底在可用什么1.1 可用性不是单纯的“服务不挂”很多人一听可用性设计第一反应就是多副本、负载均衡、故障转移这套东西在传统架构里确实是标准答案。但在AI应用里“服务不挂”只是及格线。你要回答的问题是模型服务通不通、业务链路通不通、用户体感通不通。我习惯把AI系统的可用性拆成四层每一层都有不同的故障特征和应对手段。第一层是基础设施可用性也就是K8s集群、容器、网络这些底座这块和传统架构没有本质区别该做的监控告警照做就行。第二层是模型服务可用性这是AI系统最特殊的部分因为你依赖的大模型可能是自研的也可能是第三方API。第三方API的可用性你是完全不可控的人家限流、升级、故障你只能被动接受。第三层是应用编排可用性也就是你的Agent、提示词模板、业务编排逻辑本身能不能稳定跑通。这一层的故障很隐蔽比如模型返回正常但解析失败或者Agent的上下文太长导致调用直接报错。第四层是体验兜底可用性指的是当上面所有层都出问题时用户端能不能得到一个合理的反馈而不是一个圈圈转到底或者直接报错。这里有个很核心的观点四层要一起设计。只在基础设施层做高可用但对模型服务层没有熔断和降级那模型一崩你的多副本全在请求一个坏掉的上游最后所有实例一起超时。这在业界有个专门的说法叫“雪崩”但AI场景的雪崩来得更快因为单次调用延迟是秒级甚至分钟级传统架构里几十毫秒的超时放大效应相对可控AI系统里一个慢调用就能快速占满所有工作线程。1.2 大模型接入让传统可用性设计失效的几个地方为什么说直接用老一套来设计AI系统一定会翻车我总结了一下至少四个维度发生了根本性变化。第一个是延迟量级。传统接口的P99一般在几十到几百毫秒这决定了你可以用短超时、快速失败、大并发扛量。但大模型接口的延迟是秒级起步复杂推理场景十几秒几十秒都有流式返回的还可能持续几分钟。这意味着你原来设计的线程池大小、超时配置、重试策略全部要推翻重来。第二个是失败模式。传统接口失败无非连接超时、500、网络抖动但模型接口的失败多了很多奇怪的花样限流返回429、内容审核拒绝返回特殊状态码、上下文超长直接报错、生成中途断开、返回了JSON但格式不符、甚至模型“一本正经地胡说八道”。这些失败里有些是显式的有些是隐式的隐式失败最危险因为你的程序以为成功了但用户拿到的是一堆没用的废话。第三个是幂等性的改变。传统的读接口可以放心重试因为重试不改变状态。但大模型调用通常是带成本、带副作用的——每次调用都要花钱生成类任务重复调用可能产生重复内容Agent场景重试可能导致重复执行外部动作。这就是为什么AI系统的重试策略不能闭着眼睛写。第四个是成本与可用性的强绑定。传统系统里可用性设计主要考虑CPU、内存、带宽这些资源多花钱就能多买资源。但AI系统的成本取决于token消耗一次失败的请求也可能产生大量token一次不合理的重试可能让成本直接翻倍。我见过一个团队在模型接口超时后设置了5次重试结果一次用户请求烧出了6次调用量账单直接炸了。理解了这些差异你再看市面上的AI可用性设计手段思路就清晰了。下面我先把基础的四件套讲清楚再讲我认为真正有价值的几个“奇招”。2. 基础四件套超时、重试、熔断、限流在AI场景下的正确打开方式2.1 超时和重试先分清“能不能重试”超时和重试是一对孪生兄弟但在AI场景里这两兄弟如果配合不好就是事故放大器。先说超时最关键的一点是要区分连接超时和读超时。连接超时就是TCP建连阶段这个必须设得短我一般设3到5秒因为连不上再等也没意义。读超时是你发出请求后等待模型返回的时间这个要按业务区分非流式场景下简单问答给30秒到60秒复杂推理或长文本生成给到120秒以上流式场景下判断标准不是总时长而是“首字节时间”也就是用户看到第一个字的时间这个通常要求5到10秒内必须出字如果长时间没有第一帧说明上游大概率卡死了。再说重试这是AI系统里最容易出问题的地方。第一原则是看错误码再决定要不要重试。429限流可以重试因为过一会儿配额就释放了5xx服务端错误可以谨慎重试但400参数错误绝不能重试重试一百遍结果都一样。第二原则是生成类任务重试前要想清楚幂等性。如果你用一个全局任务ID传给模型端做幂等控制那可以重试否则一次重试等于多一次计费、多一次可能的重复副作用。第三原则是用指数退避加抖动而不是固定间隔。我第一次重试退避1秒第二次翻倍到2秒第三次4秒再叠加随机抖动防止所有实例的请求同时打向上游形成重试风暴。重试次数控制在2到3次以内再多就是赌徒心理了。实操中我还会做一层“成本止损”校验。每次调用前记录一下当前累计失败率如果失败率已经很高就不要再往里填请求了直接走降级。这比盲目重试更能保护你的可用性和钱包。2.2 熔断和限流要从“接口维度”细化到“模型维度”传统系统里熔断器按接口或者服务维度配置就行但在AI系统里我强烈建议你把熔断维度细到模型层和供应商层。什么意思假设你同时接了模型A和模型B模型A是主力模型B是备胎。如果模型A连续报错触发熔断你的请求应该自动切到模型B而不是整个服务降级。如果你用的API网关支持多级熔断那就把熔断维度配置成“供应商模型业务场景”这样能最大程度保留可用性。熔断器的状态机还是老三样闭合、打开、半开。闭合状态正常放行错误率达到阈值就切换到打开状态直接快速失败一段时间然后进入半开状态放少量试探流量试探成功后恢复闭合。关键在于阈值怎么定。传统系统的错误率阈值我一般设20%到30%但AI系统我建议设50%上下因为模型接口的偶发超时比较常见阈值太灵敏容易导致熔断器频繁开关反而影响可用性。另一个容易被忽视的指标是“慢调用率”。模型接口往往不是直接报错而是慢到脱层皮。我见过供应商接口P99到了40秒但错误率是0你的熔断器完全不会触发但用户体验已经崩了。所以必须加一项规则连续N次调用耗时超过预设阈值视为故障同样触发熔断。限流这边传统系统习惯按QPS算但AI系统一定要按RPM和TPM来算。RPM是每分钟请求数TPM是每分钟token数。为什么因为大模型的成本大头在token一个请求可能只消耗100个token另一个请求可能消耗5000个token单纯按QPS限流会让大请求把配额打爆。我见过比较规范的做法是在模型网关层同时监控RPM和TPM两个维度各自配置上限任意一个超了就排队或者拒绝。排队策略对AI场景更友好因为卡片式聊天操作本来就有等待感排个几秒用户是能接受的但直接拒绝就会流失用户。还要注意限流一定不要只做单机限流要做分布式限流不然扩容之后每个节点配额翻倍上游照样把你们熔断。3. 真正的奇招AI系统可用性设计的进阶打法3.1 模型降级矩阵大模型不行就上小模型小模型不行就上规则我所谓“奇招”不是说有什么黑魔法而是一些经过实战验证、但多数团队没有系统化落地的思路。第一个要说的是模型降级矩阵。大多数人做降级脑子里只有“模型挂了就走缓存”这太粗暴了。更好的做法是建立一个分级降级矩阵把降级路径分成好几级从上到下越级执行。我举个真实的例子。之前在做一个智能客服项目主链路是GPT级大模型做语义理解和生成。降级矩阵我设计成了这样的结构第一级降级是切到同量级但更快的小模型比如从旗舰模型切换到轻量模型保留完整语义生成能力延迟降一半成本降一个量级。第二级降级是模板化规则应答也就是基于关键词匹配和FAQ知识库的检索式问答这一级已经脱离了生成式模型但有兜底答案总比没有好。第三级降级是固定话术加联系方式告诉用户“当前咨询量较大请留言或致电”至少让用户知道系统还在运行。这里最容易被忽视的是第一级降级。很多团队没有做“大模型到小模型”的切换是因为觉得效果差异大会影响用户体验。但你想一下当主模型延迟超标或者连续报错时用户感受到的是“卡死”和“报错”这时候切到小模型虽然回答质量略降但响应快、不中断用户感知反而更好。这个权衡很多产品经理想不明白但我实测下来用户对“慢了但答得还行”的容忍度远高于“转圈之后直接失败”。降级矩阵要可配置这是另一个容易被忽视的点。不要硬编码在代码里而是放到配置中心运营和架构师可以实时调整阈值和策略。因为不同时间段的流量特征不一样比如白天峰值时段可能需要更快触发降级深夜低谷就可以更激进地尝试主模型。这些经验值不经过一段时间的线上数据积累是很难一开始就拍准的。3.2 语义缓存让重复请求直接命中省额度也降延迟传统缓存是基于精确匹配的同一个key就命中。但在AI应用里用户的问题是千人千面的自然语言同一个意思有无数种问法“怎么退货”和“我要退款怎么办”本质上是一回事但精确匹配肯定命中不了。这就是语义缓存存在的意义用向量化加相似度匹配来判断两个问题语义是否相同如果足够相似就直接返回之前的结果不再调用大模型。具体做法是把用户输入用Embedding模型转成向量在向量数据库里做相似度检索如果找到相似度超过阈值的历史问题就直接复用它的回答。我用下来阈值在0.92到0.95之间比较合适太低了会把不相关的问题也误命中太高了命中率又上不去。这个阈值要按业务调FAQ类业务可以放宽开放闲聊要收紧。这套机制的收益非常直接。我做过一个数据统计在常见客服问答场景下语义缓存的命中率能做到30%到45%意味着接近一半的重复咨询根本不走大模型。这直接降低了延迟和成本——缓存命中的响应是几十毫秒大模型调用是几秒一个天一个地。同时因为大模型的调用量降了熔断和限流的压力也小了等于间接提升了整体可用性。但有几个坑我必须提醒你。第一动态数据别缓存。比如有人问“今天天气怎么样”你缓存了昨天的答案就是事故。我的做法是只对静态知识类问题开启语义缓存涉及实时数据、个性化推荐的一律跳过。第二缓存要设置合理的TTL知识库内容更新后要能主动失效。第三一个容易被忽略的坑如果你中途换了Embedding模型向量空间会变化之前缓存的向量可能全都查不准了这时候要记得做一次全量重建索引或者至少容忍一段时间的低命中率。3.3 流式响应与体验降级用户感知不到的“假死”才是真故障在大模型应用里延迟是个极其影响可用性感知的指标。传统的可用性设计关心P99延迟是多少但在生成式AI场景用户在乎的不是“总耗时”而是“第一个字什么时候出来”。同样一个回答俩模型都是10秒出完整结果但A模型2秒出第一个字然后流式输出B模型8秒没动静然后一次性吐出来用户会明显觉得A更快、更可用。这就是流式响应对感知可用性的价值。在架构上流式响应要关注两件事。第一是首字节时间TTFT的监控和告警这个指标比总耗时更敏感地反映上游健康状态。第二是流式传输过程中的心跳机制。大模型生成到一半可能卡住如果客户端只在结束时确认那用户卡了30秒你都不知道。我的做法是前端和后端之间用心跳或者数据块进度上报比如每收到一定数量的token就上报一次进度超过N秒没有进度数据就判定为流式中断触发客户端重连或者降级提示。体验降级是另一个容易忽略的点。我见过很多AI产品的错误页就是简单的“网络异常请重试”这本质上没有做体验层可用性设计。真正的体验降级应该是有选择性的比如图片生成服务的模型挂了你可以先给用户一张占位图加“重新生成”按钮而不是让用户面对一个空白区域再比如搜索类AI没有命中知识库答案你可以降级到普通的搜索结果列表而不是干巴巴说“找不到”。我的经验是在降级方案设计时想清楚“用户当前最不能接受的是什么”大部分场景里用户最不能接受的是“我做的操作白做了”。所以一切降级策略的核心都是尽量保住用户的操作结果哪怕质量差一点。3.4 Agent类应用的任务编排与恢复能力接下来重点聊聊现在最火的AI Agent场景。Agent应用和多AI协作场景下可用性设计难度又上了一个台阶因为一次用户请求会拆成多个子任务子任务之间还有依赖关系。按当前业界主流做法Agent任务通常是动态编排的也就是模型自己决定下一步调用什么工具这就带来了非常大的不确定性——你无法提前预知一个任务会走多少步、调多少个模型、花多长时间。这个场景下有三个设计要点全是我认为在Agent项目里必须考虑的。第一是子任务状态必须持久化。我见过很多Agent框架在内存里维护任务状态进程一重启所有任务进度全部丢失。正确的做法是把每个子任务的状态写到数据库或KV存储里每个子任务有独立的ID和状态字段这样即使Agent进程挂了重启后可以从断点继续而不是让用户重新来一遍。第二是给子任务加幂等键。Agent执行外部操作发消息、建工单、下订单时如果模型调用超时导致重试必须保证同一个操作不会被执行两次。这个幂等键可以基于任务ID加步骤序号生成在调用外部系统时传过去。第三是并行度控制。多AI协作听起来很美好但一个用户请求拆成8个并发子任务每个子任务都去调大模型瞬间就吃掉了一大堆TPM配额。而且多个子任务同时失败时错误处理会变得非常复杂。我的经验是给Agent的并行度设一个上限比如最多同时执行3到4个子任务剩下的排队。这虽然牺牲了一点速度但对系统的稳定性和成本控制至关重要。最后Agent的场景里一定要给用户一个人工介入的通道。模型编排不可能永远正确一旦Agent陷入死循环或者连续失败你得有机制让用户终止任务并转人工处理。这在可用性设计里叫“逃生舱”必要的时候能让用户安全着陆。4. 落地实操一个可复用的AI应用高可用参考架构4.1 整体架构分层前面讲的都是方法论这一节我给一个可以直接抄作业的架构蓝图。我这里描述的是当前业界比较主流的AI应用分层架构也是我在多个项目里验证过的模式核心思想是把“模型调用”作为一个独立的网关层来治理。架构从上到下分四层。最上层是接入层负责鉴权、限流面向用户维度、防刷这层用的是普通API网关就能搞定。第二层是业务编排层也就是你的Agent或业务流程代码这层不直接碰模型而是把用户请求转化成模型调用需求统一发给下一层。第三层是模型网关层这是整套架构的核心承担所有AI可用性设计的落地模型路由、重试、熔断、降级、语义缓存、配额管理、调用审计都必须在这一层实现。为什么要单独做一层因为AI系统里最大的不确定性来自上游模型服务把这个不确定性隔离在一个专门的层里上层业务代码就不需要关心“现在有没有降级”这类问题整个系统的认知负担会小很多。第四层是模型供应层也就是你接的所有模型服务包括自部署的开源模型和第三方API。业务编排层和模型网关层之间一定要用标准接口协议比如统一的Chat Completion格式。这样你的业务代码只认这一种接口底层接的是GPT还是开源模型对上层完全透明。这也是你能实现“大模型切小模型”降级的前提——接口一致切起来才没有成本。4.2 关键参数配置参考下面给一套我在生产环境里常用的参数基线你根据自己的业务体量调整。这套配置的适用场景是常规的聊天助手类应用主模型走第三方APIRPM上限在中小规模。我建议你把它作为基线再结合自己的压测数据做迭代不要照抄就完事。配置项建议值说明连接超时3s建连失败直接放弃不等待读超时非流式60s简单问答够用复杂生成另调读超时流式首字10s超过10s不出字视为故障重试次数最多2次第1次退避1s第2次退避2s抖动重试条件仅限429/5xx/网络异常4xx参数错误一律不重试熔断错误率阈值50%连续10s窗口内错误率超50%则打开熔断慢调用阈值单次超过30s计入错误率统计熔断半开试探流量10%半开状态下放10%流量试探恢复限流维度每分钟请求数每分钟token数双维度并行限流语义缓存相似度阈值0.93按业务场景调整降级触发条件熔断打开或错误率连续超阈值自动切换至降级矩阵下一级这里有一个关键原则参数不要怕调错怕的是没有参数意识和压测数据。AI系统的每个参数背后都有业务权衡比如超时设短一点故障恢复更快但误判概率更高设长一点对偶发慢请求更宽容但极端故障下的拖尾更长。我的做法是每次变更参数都记录在案配合线上监控指标观察效果形成自己的参数调优经验库。4.3 压测与故障演练怎么做很多团队上线AI应用前不做压测理由是“大模型接口的延迟不受我们控制压测没意义”。这话大错特错。我们压测的目的不是检验模型有多快而是检验在模型延迟波动的前提下我们自己的降级、重试、熔断机制能不能按预期兜底。所以压测的焦点不是“能扛多少QPS”而是“在多少种故障模式下系统仍然可用”。故障演练我强烈建议用混沌工程的手段。具体做法是在预发环境里人为给模型网关注入故障比如模拟模型服务延迟增加10秒、模拟50%的请求返回500、模拟供应商限流。然后观察你的系统表现超时设置是否触发重试是否按退避策略执行熔断器是否在预期时间内打开降级矩阵是否切换到了正确的层级语义缓存是否还在正常命中这些验证完了才能真正说你对自己的系统有信心。这里分享一个我常用的演练流程。第一步录制线上真实流量因为真实流量的比例和场景远比构造的压测脚本要真实。第二步按比例注入故障从1%的流量开始逐步加大观察系统的自动响应是否平顺。第三步验证恢复路径不能只验证故障发生时的降级还要验证故障结束后系统能不能自动恢复——很多团队的熔断器能打开但半开状态的恢复参数调不好结果故障结束之后系统还在降级态白白损失用户体验。第四步故障演练要有事后复盘模板包括故障发现时间、系统自动响应动作、人工介入的必要性、参数是否需要调整。没有复盘的演练等于白练。5. 常见问题排查实录5.1 “模型接口偶发超时”怎么排查我在实际项目里遇到过太多“偶发超时”的问题。想告诉你一个排查思路不要一上来就调超时时间那是治标不治本。正确做法是分层排查。第一步确认超时发生在哪个环节。你的请求链路通常是业务服务→模型网关→供应商API。在模型网关里给每一跳加上耗时日志和分段监控看关键字在哪个段。如果耗时集中在供应商API本身那说明是上游问题如果耗时在业务服务和网关之间的队列堆积那可能是你的线程池或者连接池配置不合理也可能是下游慢调用占满了连接。我见过的情况里至少有一半“偶发超时”其实是自己服务内部问题跟模型接口没关系。第二步看超时是否集中在某个时间窗。如果是高峰期超时变多那大概率是RPM或TPM触到了供应商配额上限你需要优化限流策略而不是超时参数。第三步看超时是否伴随错误码。如果超时同时出现429或503那就是明确的限流信号应该把你的流量降下来或者切降级而不是傻等。5.2 “语义缓存命中率上不去”怎么排查缓存命中率上不去最烦人的是查来查去找不到原因。我总结过三个高频原因。第一个原因是阈值设置不合理。0.95的相似度阈值太严格大多数用户问题在语义上相似但字面上千差万别很难超过这个线。第二个原因是输入没有归一化。比如用户输入“怎么退货”和“我要怎么申请退货”它们的向量距离其实不远但如果你在Embedding前没有做基础的文本清洗比如全半角转换、大小写统一、去标点向量表达会不稳定直接影响相似度计算。第三个原因是Embedding模型不稳定。如果换了Embedding模型没有重建索引历史缓存的向量空间和新向量根本不在一个坐标系里命中率断崖式下跌。排查的时候先把命中日志打开看没命中的请求和目标候选之间的相似度分数分布一般就能快速定位是阈值问题还是向量质量问题。5.3 “Agent任务一半就断了”怎么办Agent任务中断是我见过最隐蔽的问题之一因为它往往不是“显式报错”而是“任务无声消失”。要排查这个问题先检查你的子任务状态有没有持久化到数据库。如果状态在内存里服务一重启任务自然就断了而且断得悄无声息。解决方式是引入任务状态表把每个子任务的状态字段pending、running、succeeded、failed、retrying更新到数据库同时配合一个定时扫描的恢复触发器发现running超时的任务就重新入队或者标记失败。第二个要检查的是模型上下文长度。Agent场景下多轮工具调用会让上下文越来越长一旦突破模型的上下文窗口调用直接报错而且这个报错往往不在你预设的重试条件里。我的方案是引入上下文压缩机制在上下文长度接近上限时自动把历史消息做摘要压缩而不是直接截断这样既保住关键信息又不至于报错。第三个要检查的是Webhook回调。很多Agent框架通过回调通知业务系统任务完成如果回调地址不稳定或者公网访问不通任务结果就丢了。这里建议把回退机制加上如果回调失败主动查询任务状态来补拉结果不要假设回调一定会送达。最后分享一个实际操作中的体会聊了这么多方法论和架构经验最后想讲一个我自己的习惯。我现在每上线一个AI应用都会逼自己做一次最坏情况推演把供应商API直接禁掉看系统会退化成什么模样。很多团队不愿意做这件事觉得概率低但AI应用的第三方依赖是最大的不确定性来源如果核心模型挂了系统就全线瘫痪那这个可用性设计基本是不过关的。我在最开始做AI应用时也犯过这个毛病觉得“供应商是大厂不会挂的”结果真遇到一次上游故障整个产品原地消失了大半天那之后我才真正把降级矩阵和模型网关当回事。设计AI系统的可用性本质上就是在设计系统面对不确定时的体面程度。你能接受的最坏情况是什么你的系统就应该被设计成在那一刻仍然能给出一个合理的交代。这一点想清楚了架构上的取舍会自然浮现。希望这篇实战总结能帮你在AI架构这条路上少踩几个坑。