中转 API 稳不稳定怎么测？可用率、延迟与限流测试方法

一次成功不等于稳定

中转 API 往往连接多个上游账号、区域和路由。你在下午三点发一次请求成功，只能证明那一刻某条链路可用。真正的稳定性需要回答：不同时间段成功率如何、慢请求有多少、错误集中在哪些模型、故障后多久恢复。

先定义指标

最少记录五个指标：请求成功率、首 token 延迟、总耗时、P95 延迟和错误分类。平均延迟很容易掩盖少量极慢请求；对交互式应用，P95 往往比平均值更接近用户体验。

成功也要有明确标准。HTTP 200 但正文为空、流式中途断开、工具参数无法解析，都不应该算完整成功。建议把结果分为成功、协议异常、超时、限流、鉴权失败和服务端错误。

设计一个低成本样本

选择一个短、确定、不会触发安全拒答的提示，固定模型、temperature 和最大输出。每 30 分钟请求一次，连续三到七天；早晚高峰都要覆盖。不要用大并发压测陌生中转，以免违反服务条款或消耗不必要额度。

如果要比较多家站点，所有站点使用相同参数和近似时间窗口。模型不一致时，延迟没有直接可比性。

记录首 token 与总耗时

非流式请求只能得到总耗时，无法区分“排队很久但生成很快”和“立即开始但生成很慢”。流式请求应记录连接完成、第一块有效内容和结束事件三个时间点。

首 token 延迟适合判断排队与网络；总耗时还受输出长度影响。比较总耗时时，要固定最大输出并记录实际输出 token 数。

正确计算可用率

假设一天计划采样 48 次，其中 42 次完整成功、2 次流式断开、3 次 429、1 次超时，则完整可用率是 87.5%，而不是把所有 HTTP 200 都算成功。

同时公布样本量。100%（1/1） 与 99%（990/1000） 的证据强度完全不同。小样本站点可以标记为“观察中”，不要与长期高样本直接比较。

分析错误分布

错误是否集中在固定时间，比错误总数更有价值。晚高峰大量 429 表明容量不足；只有某个旗舰模型出现“无可用渠道”，说明单模型路由薄弱；随机 502 可能是网关或上游网络波动。

把错误按日期、小时、模型和类型聚合，就能判断应该换套餐、换模型还是换供应商。

路由一致性也属于稳定性

中转可能在多个上游间轮询。即使请求都成功，响应结构、模型能力或计费字段突然改变，也会破坏生产稳定性。抽样时加入一个结构化输出或工具调用测试，观察协议行为是否跨时段一致。

如果同一个 Key 在不同时段出现明显不同的流结构和能力结果，应询问服务商是否存在多路由，并为业务增加兼容和降级策略。

不要把测速做成攻击

稳定性检测应遵守站点限额，使用低频、小输出、可停止的计划。不要并发轰炸，也不要用大量 Key 绕过限制。测试的目的是评估真实使用体验，不是制造故障。

如何阅读 CheckToken 排名

站点排名中的分数、可用性、模型覆盖和样本数应该一起看。样本少时，任何排名都只是暂时观察；样本增长后，趋势比单日名次更重要。延迟为空或样本不足时，不应推断站点一定快或慢。

对准备长期使用的中转，建议先用 CheckToken 做能力和真伪筛查，再用上述低频计划观察三到七天。前者回答“像不像目标模型”，后者回答“能不能稳定用于你的业务”。

最终决策表