大模型API稳定性对比，先看错误率和恢复能力
先明确稳定性到底比什么
大模型API稳定性对比，比的不是某一次请求能不能返回，而是在一段可观察的时间内，接口持续给出可用结果的概率，以及出问题时恢复得快不快。
只看厂商页面上的可用率数字，很难判断你的业务在高峰期会不会被限流、超时或返回空内容。
判断稳定性至少要同时看三件事：有效成功率、错误类型分布、延迟尾部与恢复时间。
有效成功率指排除了重试后仍然失败、空响应、内容截断等情况的成功比例；
错误类型分布能区分是网络问题、限流还是服务端异常；
延迟尾部则反映高峰期最差体验。
对比的前提是条件一致：相同的输入长度、相同的并发数、相同的超时时间和重试次数、相近的网络出口。
条件不一致时，任何结论都不成立。
准备一套可复现的测试条件
开始对比前，先固定下面这些变量，否则数据无法横向比较。
- 输入样本：准备 30 到 50 条长度接近的提示词，避免长短混杂导致延迟差异。
- 采样参数：统一
temperature、max_tokens，并记录模型名称和调用时间。 - 超时与重试：例如单次请求超时设为 30 秒，最多重试 2 次，重试间隔 1 秒，所有接口用同一套规则。
- 并发与时长：例如 5 并发持续跑 20 分钟，覆盖至少一个业务高峰时段。
- 网络环境：从同一台服务器发起请求，记录出口 IP 和地区。
建议把每次请求的结果落成一行日志，字段包括：时间戳、接口名、状态码、耗时、是否重试、最终是否成功、错误信息、返回内容长度。
后续所有指标都从这份日志算出来。
统计指标和判断方法
有了日志，按下面顺序计算，比只看成功率更接近真实体验。
- 有效成功率：最终成功请求数 ÷ 总请求数。注意把空响应、明显截断的返回也计为失败。
- 错误类型占比：按状态码和错误信息归类，例如 429 限流、5xx 服务端错误、连接超时、DNS 失败。429 占比高说明配额或并发策略不匹配，不一定是服务不可用。
- P95 与 P99 延迟：把成功请求的耗时排序后取分位值。平均值容易被少量快请求拉低，尾部延迟更能反映高峰期体验。
- 恢复时间：记录连续失败开始到重新出现成功请求的间隔。同样是 99% 成功率，故障持续 10 秒和持续 5 分钟对业务影响完全不同。
举个判断例子：A 接口有效成功率 99.2%，但 429 占失败的 80%，说明限流是主要矛盾，需要调整配额或降低并发；
B 接口有效成功率 98.5%，失败集中在 5xx 且每次恢复约 3 分钟，说明服务端偶发不稳定，对实时业务风险更大。
两者谁更合适，取决于你的业务能否容忍短暂失败并重试。
常见误区与适用边界
只看厂商公布的可用率：公布口径、统计周期和是否包含限流通常不清楚，不能直接等同于你的调用成功率。
把重试后的成功当作一次成功：重试会拉高表面成功率，但会增加延迟和成本，统计时应单独记录重试次数。
用单次短测下结论：几分钟的测试很难覆盖高峰期抖动，至少跑一个完整业务时段。
忽略客户端因素：本地网络、DNS、连接池配置都会影响结果，对比时尽量固定客户端环境。
需要说明的是，这类对比反映的是特定时间、特定地区和特定调用方式下的表现，不能推广为所有场景的结论。
厂商策略、模型负载和网络线路都可能变化，重要业务应保留可切换的备用接口。
怎么验证结论是否可信
跑完一轮后，用两个动作复查：一是换一个时段再跑同一套样本，看指标是否大幅波动；
二是在日志里抽查失败请求，确认错误分类没有算错。
如果两次结果差异明显，说明稳定性受时段影响大，选型时应把峰值表现作为主要依据，而不是平均值。
最终的选型结论建议写成条件句：在什么并发、什么超时策略、什么业务容忍度下，选择哪个接口更合适。
这样的大模型API稳定性对比结果才可复核，也方便后续环境变化时重新评估。
