模型API稳定性对比避坑指南：评测指标、SLA条款与选型监控实战

我做应用接入和模型选型这些年，越来越不敢只看“接口能不能调通”。模型API稳定性对比这件事，表面看是测接口，落到业务里是测客服、内容生产、支付风控这些链路能不能持续扛住。我写过调用代码，也跟SRE一起盯过凌晨告警，还陪采购同事逐条抠过SLA条款。视角不同，对“稳定”两个字的理解差得很远。

这篇模型API稳定性对比先把评测地基说清楚。背景、价值、边界不讲透，后面拿一堆数字做排名容易跑偏。我会尽量用实际踩坑的口吻讲，不把实验室指标和业务可用性混成一锅。

1.1 大模型API稳定性的业务含义与典型风险

大模型API稳定性的业务含义，我的理解是“在约定时间、区域、配额和场景下，调用能以可接受的成功率和时延完成，故障后能恢复，重试不放大风险”。它不只看月度可用性。调用成功率、错误率、限流触发率、P95/P99延迟、超时率、恢复时间、流式输出中断率、长上下文成功率、输出一致性，都落在稳定性这个筐里。业务侧更直接：用户能不能稳定拿到结果，运营能不能扛住活动峰值，研发要不要半夜爬起来切流量。

典型风险我踩过几类。重试风暴最坑，客户端看见超时猛重试，服务端限流更狠，错误率反而上去。流式输出断在半句，前端以为成功，后端日志是断流。长上下文任务在高峰时段超时，摘要任务跑一半失败。区域故障和配额突降也会把业务打懵。还有一类是SLA口径差异，承诺的可用性不含某些错误，真实体验和纸面数字对不上。

我作为开发者会更关注错误码是否清晰、重试是否安全。运维同事盯的是告警是否及时、切换是否顺手。业务负责人只问一句：这个月API故障丢了多少单。三种视角合在一起，才能把模型API稳定性对比做得贴近业务。

1.2 对比范围与主流大模型API样本选择

对比范围我倾向“主流、可长期拿到、能复现”的公开API。国际样本会覆盖OpenAI、Anthropic、Google几家常用模型API，国内会看百度文心、阿里通义、腾讯混元、智谱GLM、DeepSeek、月之暗面Kimi、字节豆包这些主流服务。云厂商托管模型API也会纳入，比如Azure OpenAI、AWS Bedrock、阿里云百炼、火山方舟这类形态。样本不求全，求在我能稳定申请配额、能固定版本、能持续跑一段时间的范围里做对比。

样本选择有几个硬条件。模型版本要固定快照，不能今天测完明天换版本。API入口和区域要记录清楚，同一家厂商不同区域表现可能差很多。配额和限流策略要能查到，至少能拿到公开文档或控制台说明。计费方式也要记，重试成本算不算进稳定性评估，后面会单独说。我会把样本分成原生API和云厂商托管API两组，避免把托管层的稳定性算到模型厂商头上。

这里不说“谁家最强”，模型API稳定性对比的价值在于给出可解释的差异。样本覆盖国际和国内主流服务，覆盖文本生成、长上下文、流式和高并发常见场景。读者拿这套样本框架，可以按自己业务区域和预算做裁剪。

1.3 评测周期、区域、时段与场景设定

评测周期我一般拉到四周以上，包含两个完整工作周和两个周末。时段覆盖早高峰、午间、晚间和凌晨，工作日和周末分开看。区域上国内看华东、华北、华南，海外看美西、新加坡和欧洲。不同区域走不同接入点，DNS、网关、跨境链路都会影响结果。场景设定围绕短文本问答、长上下文摘要、流式输出、高并发请求和突发流量五类。固定prompt集和调用参数，采样频率按分钟级和小时级结合。

我会把“正常流量”和“突发流量”分开记录。正常流量看基线稳定性，突发流量看限流和恢复。高峰时段单独打标签，凌晨低峰也保留样本，方便看维护窗口和区域故障。流式场景记录首包时间、断流率、完整率。长上下文场景记录超时和截断。高并发场景看吞吐和错误率拐点。

评测不是一次压测定输赢。四周周期能覆盖版本小更新、区域抖动和计费策略调整。数据采集用固定脚本，调用日志保留请求ID、时间戳、区域、模型版本、错误码、重试次数。结果复现靠原始日志和统计口径，不靠截图。

1.4 稳定性对比与性能对比、成本对比的边界区分

稳定性对比和性能对比容易混。性能看延迟分布、吞吐、并发承载，稳定性看可用性、成功率、错误率、限流触发、超时、恢复时间和输出一致性。一个API延迟很低，高峰期限流一触发，业务照样不可用。一个API平均延迟一般，错误率低、恢复快、重试成功率高，生产上反而更稳。我评估时会先把指标分桶，不把P99延迟和可用性揉成一个分数。

成本对比也要切开。单价低不代表总成本低。重试多、超时多、流式中断多，token浪费和运维人力都会上去。缓存命中、批量调用、降级切换也会影响账单。稳定性对比只看故障和恢复，成本对比只看单价和用量结构，性能对比只看延迟和吞吐。三张表分开看，选型时才不会拿“便宜”掩盖“老坏”。

SLA条款和实测表现的偏差，我归到稳定性对比里。SLA覆盖范围、除外责任、统计口径、赔偿机制，都会影响真实稳定性判断。性能对比不替SLA背书，成本对比也不替故障买单。这一章把背景、样本、周期和边界说清，后面的模型API稳定性对比才有可比的底子。

指标体系这件事，我改过好几版。第一版拿着厂商文档里的可用性百分比就当结论，被运维同事一句话问住了：“上个月两次限流，你那个数字怎么没反映？”从那时候起我才明白，模型API稳定性评测不能只抄指标名，得把每个指标怎么来、怎么算、在什么条件下有效说清楚。这一章我把自用的指标体系和测试方法摊开讲，包括哪些指标互相打架、哪些数据看着漂亮其实是口径在帮忙。

2.1 可用性、成功率、错误率与限流触发率

可用性我按“时间窗口内有效调用成功比例”来算，不是简单拿厂商公告的月度值。有效调用的定义要提前写死：请求到达网关、拿到可解析响应、业务字段完整。少一个条件就算失败。我见过响应里带错误对象但HTTP状态200的情况，前端不识别，用户看到空白页。这类请求我归到失败里，不归到成功。

成功率再往下拆，分业务成功率和传输成功率。传输成功但内容截断、JSON解析失败、字段缺失，算业务失败。错误率按错误码分桶统计：认证类、配额类、超时类、服务端5xx、内容审核拦截。限流触发率单独拎出来，因为它常被算进“客户端错误”里一笔带过，实际上限流是服务端容量信号，对稳定性判断很关键。

我自己跑数据时会把限流触发率和429占比分开看。有些厂商用429表示限流，有些用自定义错误码。回退到监控面板，看的是每分钟触发次数和持续时长。短促的限流和持续几分钟的限流，对业务影响完全两码事。前者重试能救，后者重试就是往火里浇油。

2.2 延迟分布、超时率、吞吐与并发承载

延迟我不看平均值，平均值这玩意儿掩盖问题。我按P50、P90、P95、P99分桶，再单独看首包时间和完整响应时间。流式场景的首包时间对交互体验影响大，完整时间对批量任务影响大。两组数字分开记，不混着排名。

超时率的统计口径要先定超时阈值。我一般设三档：客户端软超时、业务硬超时、网关超时。软超时看体验劣化，硬超时看失败。同一批请求在三档下算出来的超时率能差出几个点。厂商文档里写的超时通常指网关层，业务侧感知的超时要早得多。

吞吐和并发承载我放在一起看。并发往上加，观察错误率和P99延迟的拐点。拐点出现前的并发数记为安全水位，拐点之后开始出现限流或超时。这个测试我会分时段重复，早高峰和凌晨跑出来的安全水位不一样。有次凌晨测出来的并发上限很好看，白天活动一上来直接打回原形。所以并发承载不能只测一次，得在真实流量结构下反复验证。

2.3 故障恢复时间、重试成功率与输出一致性

故障恢复时间我按“从首次错误到连续成功”来算。中间夹着一次成功不算恢复，得连续N次成功才记恢复点。N我一般取10，少了容易把抖动误判成恢复。恢复时间再按故障类型分：限流恢复、5xx恢复、区域链路恢复。三类恢复机制不同，混在一起看没意义。

重试成功率这块，我做了个对照实验。同一批失败请求，一组立即重试，一组加指数退避再重试。结果差距很明显。立即重试在限流场景下成功率惨淡，退避之后能救回不少。重试成功率还跟错误类型强相关，认证错误重试一百次也没用，超时错误重试价值高。我把重试成功率按错误码分组统计，选型建议里也按这个逻辑给。

输出一致性容易被忽略，但对稳定性判断很重要。同一个prompt、同一组参数，短时间内重复调用，输出结构和关键字段应该稳定。我遇到过同一接口偶尔返回不同JSON结构的情况，业务解析直接崩。一致性测试我跑固定样本集，记录结构差异率和字段缺失率。不一致率高的API，稳定性评分要打折。

2.4 长上下文、流式输出与高峰时段的专项测试

长上下文专项测试我按上下文长度分档：8K、32K、128K，有条件再往上加。每档测成功率、完整率、首包时间和超时率。长上下文场景在高峰时段特别容易翻车，我会把高峰标签单独加上。有厂商短文本稳如老狗，长上下文一到高峰期截断率明显上升，这种差异不专项测根本看不出来。

流式输出我盯三个数：首包时间、断流率、完整率。断流率按连接中断和内容未结束两种情况分开记。流式还有个坑是错误后前端感知不到，后端日志显示连接关闭，用户界面停在一半。我会在客户端加完整性校验，把“看似成功实则断流”的请求捞出来。

高峰时段专项测试放在工作日早十点和晚八点，周末另算。突发流量用阶梯加压和脉冲加压两种模式。阶梯看拐点，脉冲看瞬时抗压和恢复。脉冲测试最接近真实活动场景，几秒内流量翻几倍，看限流触发和恢复速度。这组数据我每次跑完都会跟运维对一遍，确认告警时间和业务感知时间对得上。

2.5 数据采集、统计口径与结果复现方法

数据采集我用固定脚本加代理层日志双通道。脚本侧记录请求参数、时间戳、区域、模型版本、响应状态、错误码、重试次数、耗时明细。代理层记录网络层错误和连接中断。两边对不上就以代理层为准，因为脚本可能把连接重置误判成超时。

统计口径我写成文档，每个指标附计算公式和数据来源。可用性按什么窗口算，错误率含不含限流，P99延迟取不取重试后的请求，这些都得白纸黑字写清楚。口径变了要标版本号，不然前后数据没法比。我吃过亏，换了个统计脚本，同样的API稳定性数字跳了一大截，查了半天是超时阈值改了。

结果复现靠原始日志和固定样本集。样本集包含prompt、参数、预期结构，每次评测跑同一套。日志保留至少一个季度，按请求ID能追溯到单次调用。有人拿我的数据做二次分析，我会把口径文档和样本集一起给出去。模型API稳定性对比的可信度，一半靠测，一半靠别人能照着复现。

这一章是我过去大半年持续跑测试攒下来的东西。同一个脚本、同一套口径，按周跑，按厂商归档。有些结果发到群里被质疑过，我后来把原始日志和样本集一起甩出去，争议才落下来。先说清楚一件事：下面提到的稳定性差异，是我在特定时段、特定区域、特定负载下测出来的，不代表厂商的全局水平。你拿去做选型参考可以，当成判决书就不合适了。

3.1 国际主流模型API稳定性表现对比

OpenAI的API我跑了一年多，整体可用性在几个国际厂商里排前头。它的错误码设计规整，限流触发后返回的头部信息足够做退避判断，这点对工程侧很友好。问题出在高峰时段，北美工作时间段跑P99延迟能比凌晨高出将近一倍，首包时间波动更明显。我印象最深的一次是某个周二上午连续三小时出现间歇性超时，间隔大概七八分钟一次，每次持续二十来秒，监控面板上的曲线像心电图。这种短促抖动对批量任务影响有限，对实时对话产品就是灾难。

Anthropic的API稳定性得分不低，但限流策略比OpenAI激进。同样的并发水位，在OpenAI那边还稳着，到Anthropic这边已经开始触发429。它的限流恢复时间也偏长，我测到的持续限流窗口平均比OpenAI多出半分钟左右。好处是它的5xx错误率很低，跑了几万次请求，服务端错误占比不到千分之一。坏处是配额政策变动频繁，有过两次在我评测周期中间调整了速率上限，前后数据没法直接比，得单独标注版本。

Google Gemini的API稳定性在区域间差异明显。我同时从新加坡和弗吉尼亚两个区域跑，新加坡节点的P95延迟比弗吉尼亚低三成左右，限流触发率也低。Gemini的长上下文场景在高峰期偶尔出现内容截断，短文本场景反而很稳。还有一个细节，Gemini的流式输出断流率在三个国际厂商里最高，我统计到约百分之一点几的连接中断，虽然大部分能靠客户端重试救回来，但前端体验会打折扣。

3.2 国内主流模型API稳定性表现对比

国内几家我测下来，通义千问的API稳定性属于第一梯队。它的可用性曲线平滑，限流触发率低，错误码分类清楚。我在工作日早高峰跑过一组两万次请求的压测，成功率保持在百分之九十九点五以上，P99延迟波动控制在合理区间。有个小问题是流式输出的首包时间在晚八点前后会出现一次明显抬升，幅度大概百分之四十，持续时间半小时左右。这个规律我连续观察了四周，每周都出现，像是定时任务或者资源调度导致的。

DeepSeek的API在稳定性上表现有点两极分化。文本生成场景的成功率很高，延迟也漂亮，成本还低，用起来很舒服。长上下文场景就没那么乐观了，我测128K上下文时成功率明显下滑，高峰期截断和超时比例上升较快。有一次跑长文档摘要任务，连续十几条请求返回内容不完整，日志显示连接正常关闭但响应体被截短。这类问题不专项测根本发现不了，短文本跑得再漂亮也掩盖不住。

豆包的API稳定性在突发流量下表现不错。我用脉冲加压模式测过，几秒内把QPS拉高三倍，它的限流触发比较有节制，恢复速度也快。文心一言的API在错误码规范性上还有提升空间，我遇到过同一类限流错误在不同接口返回不同错误码的情况，监控侧得做额外映射。智谱的API整体中规中矩，延迟分布比较集中，没有特别突出的短板，也没有特别亮眼的地方。

3.3 云厂商托管模型API与原生API稳定性对比

这块我专门做了一组对照测试。Azure OpenAI和OpenAI原生API跑同一批请求，Azure的P50延迟略高，多了一跳网络开销，大概多出几十毫秒。稳定性方面Azure反而更稳，限流触发率低一些，我猜是它前面有一层配额缓冲。原生API在配额用尽时直接拒绝，Azure侧会先给你一段降速窗口。这个差异对业务连续性影响不小，尤其是流量突增的时候，降速比直接拒绝友好得多。

AWS Bedrock托管Anthropic模型和Anthropic原生API对比，结论类似但不完全一样。Bedrock的错误码体系跟原生API不一致，重试逻辑得分开写。Bedrock的区域可用性做得不错，我在两个区域同时跑，单区域故障时另一区域接管顺畅。原生API在区域故障时没有这么平滑的切换体验，得业务侧自己做多区域路由。

阿里云百炼托管通义模型和通义原生API对比，托管层的稳定性略优。百炼在前面加了一层网关，限流策略更温和，错误码也做了统一封装。代价是延迟多了一点，流式场景的首包时间比原生API慢百分之十左右。腾讯云托管混元和其他模型的情况类似，托管层带来稳定性红利的同时，也带来一点性能损耗和配置复杂度。选托管还是原生，本质上是拿延迟换稳定性的取舍问题。

3.4 文本生成、长上下文、流式与高并发场景对比

文本生成场景是各家基本功，国际国内厂商在这个场景下的稳定性差距不大。成功率普遍在百分之九十九以上，延迟差异更多体现在P99尾部。我测下来文本生成场景最不容易翻车，选型时反而不该只看这个场景的数据。真正拉开差距的是长上下文和高并发。

长上下文场景是稳定性分水岭。128K上下文下，我测到的成功率从短文本的百分之九十九点几掉到百分之九十五到九十八之间，厂商之间差距明显。有的厂商长上下文成功率掉得少但延迟涨得多，有的延迟控制得好但截断率高。截断这个问题最隐蔽，响应看着完整，实际内容被砍了一截，业务侧不做完整性校验根本发现不了。我给每个厂商都加了截断检测，结果差异挺大。

流式输出场景我盯首包时间和断流率。首包时间国际厂商普遍快一些，国内厂商在追赶。断流率方面，原生API普遍优于托管API，我推测是托管层多了一跳连接管理。高并发场景下，安全水位差异很大，有的API在两百并发就开始限流，有的能扛到八百。安全水位跟时段强相关，白天测出来的数字比凌晨低三到四成，这个规律各家都一样。

3.5 分时段、分区域与突发流量下的稳定性差异

分时段测试我跑了一整月，结论很一致：工作日早十点和晚八点是两个稳定性低谷。早十点低谷更明显，延迟抬升和限流触发集中出现。周末的曲线平缓很多，说明工作日流量结构对稳定性影响很大。有些厂商的低谷出现在整点前后，我怀疑跟批处理任务调度有关。这个规律对排期有参考价值，非实时任务尽量避开这两个时段。

分区域测试我选了华东、华北、华南三个区域跑国内厂商，选了新加坡、弗吉尼亚、法兰克福跑国际厂商。国内厂商的区域差异不大，华南节点偶尔延迟略高。国际厂商的区域差异就明显了，新加坡节点整体表现最好，法兰克福节点在晚高峰时段稳定性下滑较快。跨区域调用还有个坑，DNS解析和链路抖动带来的失败容易被误判成API不稳定，我在代理层单独做了标记。

突发流量测试用脉冲加压，几秒内把流量翻几倍。这个场景最考验限流策略和恢复速度。有的API限流触发很快但恢复也快，脉冲过后十几秒就回到正常水位。有的API限流触发慢，错误率先飙一段才限流，恢复也慢，脉冲过后要一两分钟才缓过来。后者对业务影响更大，用户感知到的是一连串报错而不是短暂排队。突发流量下的表现，我认为比稳态数据更能说明一个API的工程成熟度。

SLA这东西，我一开始也看得比较粗，觉得厂商敢写99.9%就行。后来真出了两次事故去翻条款，才发现这里头门道挺多。有的SLA写得像法律文件，免责条款比承诺条款还长；有的写得简单直接，赔偿方案明明白白。这一章我把主流厂商的SLA文本挨个过了一遍，结合我自己的故障记录，聊聊纸面承诺和实际表现之间的那道缝。

4.1 主流大模型API的SLA条款、可用性承诺与赔偿机制

OpenAI的SLA承诺月度可用性99.9%，赔偿方式是服务抵扣券，申请流程要走支持工单。我仔细读过它的条款，赔偿触发条件写的是“持续超过一定时长的不可用”，这个“一定时长”在条款里给了具体分钟数。实际操作中，短促抖动基本不会触发赔偿，哪怕你业务被打断了好几次，只要单次持续时间不够长，就不在赔偿范围内。这个设计对大客户友好，对中小开发者就比较鸡肋。

Anthropic的SLA条款相对简洁，可用性承诺也是99.9%这个档位。它的赔偿机制我印象里是按不可用时长阶梯计算的，时间越长抵扣比例越高。有个细节值得注意，Anthropic把限流导致的拒绝请求明确写进了免责范围，也就是说429错误不算SLA违约。这个条款在业内挺普遍，但对高并发业务来说，限流造成的业务损失可能比服务宕机还大。

国内厂商的SLA我翻了几家。通义千问的SLA承诺可用性99.9%，赔偿条款写得比较细，区分了不同故障等级。DeepSeek的SLA相对简洁，赔偿方案以抵扣券为主。豆包和文心的SLA条款结构类似，都包含了可用性承诺、赔偿标准和免责声明三部分。整体看下来，国内厂商的SLA文本比国际厂商短一些，条款细节少一些，赔偿门槛的设置思路倒是一致的——小故障不赔，大故障才触发。

有个现象挺有意思。我对比了同一家厂商原生API和云托管版本的SLA，托管版本的可用性承诺往往比原生版本高半个档位。Azure OpenAI的SLA承诺比OpenAI原生API高了那么一点，阿里云百炼的承诺也比通义原生API略高。多出来的这半个档位，本质上是托管层用架构冗余换来的，代价就是前面说的那点延迟损耗。SLA数字好看是有成本的，不是白来的。

4.2 SLA覆盖范围、除外责任与统计口径差异

SLA的统计口径差异，是我觉得最容易被忽略的地方。有的厂商按月统计可用性，有的按天统计。按月统计意味着月初出一次大故障，只要后面二十九天稳住了，月度数字照样好看。按天统计就更严格，单日故障直接影响当天指标。我跟几个做SRE的朋友聊过这事，他们一致认为按天统计对业务方更友好，但厂商普遍倾向按月，理由也充分——单日偶发故障不能代表整体服务水平。

除外责任的写法各家差别很大。限流拒绝基本都在免责范围内，这个前面提过了。计划内维护窗口也是常见除外项，但维护窗口的提前通知时长各家不同，有的提前三天，有的提前一周。网络运营商故障、不可抗力这些标准免责条款大家都有，措辞大同小异。我见过最细的一家把“客户端代码缺陷导致的失败”也写进了免责，这个条款边界其实挺模糊的，真出问题时容易扯皮。

统计口径里还有个坑，可用性的计算公式。有的厂商用成功请求数除以总请求数，有的用可用时间除以总时间。前者对高频调用的小请求更敏感，后者对大请求更友好。这个差异在故障场景下会被放大，同样一次持续五分钟的故障，按请求数算可能影响面很大，按时间算就是五分钟除以当月总分钟数，数字上显得微不足道。我建议看SLA时一定把计算公式翻出来看，别只看百分比。

4.3 历史故障率、故障类型与典型故障事件复盘

我自己记录了一年多的故障事件，大大小小攒了三十多起。按类型分，占比最高的是限流触发，大概占到四成。这类严格说不算故障，是厂商主动的保护机制，但对业务侧来说体感就是请求失败。排第二的是超时，占三成左右。超时又分两种，一种是服务端处理慢导致的响应超时，一种是网络链路抖动导致的连接超时。后者更隐蔽，API侧可能根本没记录到这次失败。

5xx服务端错误占比不高，但影响面最大。我印象最深的一次是某国际厂商在北美区域的一次持续四十分钟的5xx故障，错误率峰值冲到百分之十几。我当时的业务正好在做实时对话，用户端直接炸了，客服工单瞬间涌进来。事后复盘，厂商那边给的原因是一次配置推送引发的级联失败。这类故障的特点是来得快去得也快，但留下的印象最深，因为业务侧完全无能为力，只能等。

国内厂商的故障类型有个特点，长上下文场景的截断和超时占比明显高于国际厂商。我前面章节提过这个现象，这里再补充一个观察：这类问题往往不触发5xx错误码，连接正常关闭，响应体被截短，监控侧如果只看HTTP状态码根本发现不了。我后来专门加了一层响应完整性校验，才发现这个问题比想象中普遍。这类“静默故障”对SLA统计来说是个盲区，厂商侧可能压根不把它算进故障率里。

4.4 限流配额、区域可用性与依赖链故障影响

限流配额这事，我的感受是政策透明度比配额大小更重要。有的厂商把配额政策写得清清楚楚，什么档位对应什么速率上限，升级路径也明确。有的厂商配额政策变动频繁，我有次评测跑到一半，某家厂商悄无声息把默认配额砍了三成，我的测试脚本直接大面积触发429。后来我养成了习惯，每次跑测试前先查一遍配额公告，没有公告就发工单确认。

区域可用性差异在SLA里通常不体现，条款一般承诺的是全局可用性或者区域可用性，但不会细化到每个区域单独承诺。实际用下来，区域差异是真实存在的。我测过同一家厂商三个区域的API，P99延迟能差出百分之五十，限流触发率能差一倍。SLA条款不会告诉你这些，得自己跑数据。如果你的业务对某个特定区域有强依赖，光看SLA数字是不够的，得看那个区域的实测数据。

依赖链故障是最难防的。API本身没问题，但它依赖的鉴权服务、计费服务、DNS解析出了故障，表现出来就是API不可用。这类故障在SLA统计里往往被归到“不可抗力”或者“第三方服务故障”，不在赔偿范围内。我有次遇到一整片区域请求全部超时，查了半天发现是DNS解析异常，跟API服务本身没关系。这类问题靠单点监控发现不了，得做端到端的链路监控才能定位。

4.5 SLA承诺与实际稳定性表现的偏差分析

把SLA承诺和我的实测数据放一起对比，偏差是普遍存在的，但方向不太一样。国际厂商的实测可用性通常略高于SLA承诺，我猜是它们把SLA定得偏保守，留了缓冲空间。国内厂商的实测数据跟承诺值差距不大，个别厂商在高峰时段会跌破承诺线，但整体偏差在可接受范围内。这个结论有个前提，我只统计了触发SLA定义里“不可用”条件的时段，那些没触发赔偿但实际影响业务的短促抖动没算进去。

偏差最大的地方在长上下文和高并发场景。SLA承诺的可用性通常基于标准文本生成场景测算，长上下文和高并发下的实际表现跟承诺值差得比较多。我测过某家厂商在标准场景下可用性99.95%，跑到128K上下文场景掉到99.7%左右，高并发脉冲场景再掉一点。这个偏差不算违约，因为SLA条款没承诺特定场景的可用性，但对业务选型来说，这个信息比全局SLA数字更有参考价值。

最后说个实在话。SLA是底线，不是目标。我见过太多团队把SLA当成绩效指标来追，觉得达到承诺值就万事大吉。实际业务体验是另一回事，用户感知到的稳定性跟SLA数字之间隔着好几层。我的建议是SLA照看，但别只看SLA，自己搭一套端到端监控，按业务场景定义可用性标准，比盯着厂商的承诺百分比管用得多。真出了事故要索赔，流程走起来也远没有想象中顺畅，时间成本、沟通成本都得算进去。把精力花在架构冗余和降级预案上，回报比研究赔偿条款高。

前面几章把评测数据和SLA条款翻了个底朝天，问题来了——数据摆在这儿，到底怎么选？我这段时间帮三个团队做过选型咨询，发现大家最纠结的不是看数据，而是不知道怎么把数据映射到自己的业务上。这章我就聊聊选型框架和落地实践，全是踩过坑之后攒下来的经验。

5.1 不同业务场景下的模型API稳定性选型矩阵

我习惯先把业务场景按两个维度切一刀：对延迟的敏感度，以及对中断的容忍度。实时对话、在线客服这类场景，延迟一抖用户立刻感知，中断三十秒就是事故。这类业务选型时我盯三个指标：P99延迟、限流触发率、超时率。成功率反而不是第一优先级，因为成功率通常都在高位，拉不开差距。

批处理场景完全是另一套逻辑。离线跑数据、生成内容库这类任务，单次请求慢个一两秒无所谓，但任务跑到一半厂商挂了就很要命。这时候我看的是长时段的可用性曲线，尤其是故障恢复时间。有个客户做夜间批量报告生成，我帮他们选了故障恢复快的厂商，哪怕平时延迟高一点，只要挂起来能迅速切走就行。

Agent工作流和多步推理场景是最麻烦的。一次任务串五六次API调用，中间任何一环断掉整条链路就崩了。这类场景我会额外关注输出一致性——同样输入跑两次结果差太多，下游逻辑没法接。我测过一家厂商在重试之后偶尔返回空响应，监控上看着是成功，实际业务侧直接报错。这种坑只有自己跑完整链路才能发现，单看API成功率数字完全看不出来。

5.2 多供应商冗余、重试退避与降级切换策略

多供应商冗余这事，我见过两种极端。一种是一个厂商用到死，出事了干瞪眼；另一种是接了五六家，结果每家都没调优好，整体稳定性反而更差。我的经验是接两家到三家足够了，主供应商承担七八成流量，备供应商跑灰度和小流量验证。关键是备供应商不能光挂着不跑，得持续有流量过，否则真切换的时候各种参数、鉴权、SDK版本问题全冒出来。

重试策略我踩过的坑最多。早期我写的重试就是简单循环三次，结果遇到限流场景越重试越糟，直接把配额打穿。后来学乖了，指数退避加随机抖动，重试次数压到两次以内，非幂等请求干脆不重试。还有个细节，重试要区分错误类型——429限流和5xx服务端错误可以重试，401鉴权失败和400参数错误重试一百次也没用。这个判断逻辑我写在了网关层，所有业务线共用。

降级切换的触发条件我调了好几版。一开始设的是连续五次失败切备，实际跑下来发现太敏感，网络抖一下就来回切。后来改成滑窗统计，三十秒内错误率超过阈值才触发，切过去之后观察五分钟再决定要不要切回来。切回来这个动作我单独加了人工确认选项，自动切回的风险太大，万一主供应商还在恢复中，来回震荡对业务伤害比一直用备更大。

5.3 监控告警、SLA验收与故障演练机制

监控这块我的建议是别只信厂商的仪表盘。厂商侧统计的一定是“服务端视角”，你这边用户感受到的延迟和失败，跟厂商后台看到的往往对不上。我搭了两层监控，一层在网关侧采API响应，一层在业务侧采端到端耗时。两层数据对不上的时候，问题通常出在网络链路或者SDK层，这个定位过程本身就很有价值。

告警阈值我设了三档。P99延迟超过基线百分之三十发通知，错误率超过百分之一发告警，连续两次心跳探测失败直接触发降级预案。阈值不是拍脑袋定的，我跑了四周基线数据，取P95作为正常波动上限。有次半夜被叫起来处理告警，查了半天发现是厂商在推新版本，延迟整体上浮了百分之二十但没出错误。这种事没法提前预知，只能把告警噪音控制在可接受范围。

SLA验收我建议做成月度对账。把自家监控统计的可用性跟厂商SLA报告放一起比，偏差超过零点一个百分点就去查原因。我做过半年对账，发现两家厂商的统计口径确实有差异，一家把限流拒绝算进了总请求数，另一家直接剔除。这个差异在故障月份会被放大，对账的时候能明显看出来。故障演练也别等真出事才做，我每个季度强制切一次流，把备供应商完整跑一遍业务链路，练手也练心。

5.4 稳定性、性能、成本与合规的权衡

稳定性不是免费的。多接一家供应商，运维成本、联调成本、监控改造成本全跟着涨。我算过一笔账，双供应商冗余带来的稳定性提升大概能把年度故障时长从几小时压到几十分钟，代价是百分之十五左右的额外调用成本加上半个人力。这个投入值不值，取决于业务中断一小时的损失有多大。金融、医疗这类场景闭着眼上冗余，内部工具类应用单供应商加好重试就够了。

性能和稳定性有时候是打架的。低延迟的接入点往往覆盖区域少，多区域部署能提升可用性但会牺牲一部分延迟表现。我做过一个实时语音转写的项目，为了压延迟选了单区域接入，结果那个区域一个月出了两次小故障。后来改成双区域加智能路由，延迟均值涨了三十毫秒，可用性从99.9%提到99.97%。用户侧感知不到那三十毫秒，但故障期间自动切区域救了好几次场。

合规这条线现在越来越硬。数据出境、等保、行业监管要求，这些不是技术选型能绕过去的。我帮一个做金融文档处理的团队选型，本来想推某国际厂商，模型能力确实强，但数据出境合规过不了，只能退回来选国内的托管方案。合规约束会把可选集合切掉一大块，选型第一轮就该把不合规的筛掉，别等测完了发现白干。

5.5 大模型API稳定性治理趋势与持续评测建议

我观察到一个趋势，厂商之间的稳定性差距在收窄。前两年国际厂商和国内厂商在故障恢复能力上差距明显，现在头部几家都做到了分钟级恢复，SLA条款也越来越趋同。真正的差异化在细分场景——长上下文、多模态输入、高并发脉冲，这些场景的稳定性表现各家差别还很大。选型的时候别被全局数字迷惑，把自己业务最吃紧的那个场景单独拉出来测。

托管层越来越厚也是个明显变化。云厂商把原生API包了一层，加上路由、缓存、监控、限流管理，稳定性的下限被抬高了。代价是灵活性和可控性下降，出问题时排查链路更长。我现在的做法是核心业务走托管层求稳，创新业务走原生API求快，两条腿走路。这个策略跑了大半年，故障次数比全走原生API少了一半。

最后给个实在建议：建立自己的持续评测体系，别指望看几篇评测文章就能做决策。我搭了一套轻量级探针，每小时对各家API跑一轮标准测试，数据落库每周看一次趋势。这套东西维护成本不高，一个脚本加一块看板，但它能告诉你厂商的稳定性是在变好还是变差。有家厂商我监测到连续三周P99延迟缓慢爬升，发工单问才知道是他们在做架构迁移。这种事官方公告不会写，只能靠自己盯着。