接口稳定性：看可用率和降级方案设计

接口稳定性平时看不见，出事时一次性结账。选大模型 API 只看能力和单价，上线后容易被超时和 429 拖住。所谓稳定，拆开是四件事：停机怎么算、错误怎么分、限流怎么排、故障怎么退。

先给一句判断：稳定性买不来，是设计出来的。供应商负责降低故障概率，你负责故障发生时服务不崩。

可用率先换算成停机时间

99.9% 听起来很高，按月算大约有 43 分钟不可用；99.95% 约 22 分钟；99.99% 约 4 分钟。三个数字摆在一起，才知道多花的钱买到了什么。

比数字更重要的是口径：按月还是按年统计、计划维护算不算、探测点是单地域还是多地域、赔付是服务抵扣还是现金、申请要不要举证。这些写在服务条款里，签之前读一遍，比看宣传页有用。

还有一层：可用率是统计值。它保证一年里的总时长，不保证你那一个小时。促销日、模型发版、区域性网络故障，都落在统计之外。

错误要按类型分开看

把所有失败都叫报错，就没法设计对策。至少分五类：参数错误、鉴权失败、限流、服务端错误、超时。前两类重试无用，改代码；后三类重试可能有效，但处理方式不同。

超时要再拆：连接超时是没连上，读超时是连上了没回。前者可以立刻重试，后者重试可能把已经排队的请求再压一遍。流式输出还有第三种：中途断开。已经吐出的内容不能重发，否则用户看到重复段落，计费也多算一次。

内容拦截要单独归一类。它属于策略命中，不属于故障。把它当故障重试，只会得到同样的拦截结果，还多花一次钱。正确做法是准备兜底话术，并记录拦截原因分布，用于改提示词。

限流与配额：问清四个数

每分钟请求数、每分钟 token 数、并发上限、突发额度。四个数缺一个，容量规划就做不准。很多团队只问了请求数，上线后发现长提示词把 token 配额打满，请求数远远没到。

还要问清三件事：超限是排队还是直接报错，不同付费档位的限制差多少，配额是按账号共享还是按 key 独立。按 key 独立的，可以拆 key 分摊；共享的，一个批处理任务就能把在线服务挤掉。

留余量是常识但常被忽略。按峰值的一点五倍到两倍申请，比按平均值申请稳；扩容审批要走几天，这个时间要算进容量计划。选接口和程序员选 AI 的思路类似：先定任务形态，再看工具参数。

降级：五层，从轻到重

最轻的一层是重试。指数退避加随机抖动，最多两到三次。没有抖动的重试会让所有客户端在同一秒再次打过去，把一次抖动变成一次拥堵。

再重一层是换通道。多 key、多区域、多接入点，前提是这些通道真的独立，不要都挂在同一个云厂商的同一地域。

再往上是降级模型。主模型不可用时切到更小更快的模型，提示词缩短，输出质量下降但服务不断。要提前测好降级后的效果，测法参照多方案对比的实测思路：同一批输入两家各跑一遍，只记可用率与返工率。

再往上是备用供应商。接口提前接好，格式转成统一的，切换只改配置。没演练过的备用方案等于没有。

最重的一层是关功能。自动摘要、智能推荐这类非关键功能先停，把配额留给主链路。这一层要产品经理提前同意，故障时再开会就晚了。

五层之外还有两个机制：熔断和超时预算。错误率超过阈值就停一段时间，避免持续打一个已经挂掉的服务；一次请求设总时长上限，超过就放弃，别让请求在队列里堆成一堵墙。

故障处理对照

这张表要变成值班手册的一页：看到什么信号、做什么动作、多久没恢复就升级。写清楚比背下来有用。

它做不到什么

多接一家不等于高可用。两家用同一个云、同一个区域，一起挂的概率不低。备用线路要独立到机房和运营商层面，成本会上去，值不值得看业务损失。

重试会放大故障。上游已经过载，客户端重试越多，恢复越慢。重试必须配熔断和总量上限，否则是帮着把服务打死。

流式输出没有事务。断了就是断了，已输出的内容收不回。要设计可恢复的交互，比如重新生成时带上已确认的部分。

可用率不承诺体验。接口全通但延迟翻三倍，用户一样会走。延迟要和可用率一起定标准。

接口稳定性速查

• 99.9% 约等于每月 43 分钟不可用
• 错误先分类，改代码、重试、降级是三套动作
• 限流问四个数：请求、token、并发、突发
• 重试必须配退避、抖动、熔断
• 没演练过的备用方案等于没有

上线前的三个问题

SLA 写了 99.9%，出事能赔多少？多数是按不可用时长折算服务抵扣，不是现金，还有赔付上限和申请时限。把它当补偿，不要当保险。

重试几次合适？两到三次，间隔递增并加随机。超过这个次数还失败，多半不是瞬时抖动，继续重试只会加重拥堵。

备用要接几层？一层就够，但必须覆盖主链路并演练过。真正要花的功夫不在接第二家，在把调用封成统一接口，切换时不用改业务代码，网页版与本地部署的体验差异里也提到，封装方式决定后续更换的成本。