国内 API 中转站哪家稳定？30 天 × 3 地节点监控实验全记录
前言：对于日均调用量几十万次以上的业务，稳定性是选型的第一生命线。这篇测评没有"我觉得挺好用"这类主观描述，只有探针数据、错误码分布和故障时间线。实验周期 2025 年 9 月 1 日至 9 月 30 日。
实验设计
监控架构
北京探针（华为云）──┐
上海探针（阿里云）──┼──> InfluxDB ──> Grafana
深圳探针（腾讯云）──┘
-
探测频率：每 3 分钟一次
-
探测请求：gpt-4o-mini，固定 prompt（约 50 tokens），max_tokens=100，关闭流式
-
记录指标：HTTP 状态码、TTFB、总耗时、响应体校验（是否为合法 JSON 且包含 choices 字段）
-
有效性校验：探针自身网络抖动的数据点（对公共 DNS 的同时探测失败）已剔除
参评对象
One-API（自建，阿里云 4C8G）、OpenAI-SB、API2D、CloseAI、AiHubMix、AionRouter，共六家。
每家理论样本量：30 天 × 480 次/天 × 3 节点 = 43,200 次。
总体结果
成功率排名
| 排名 | 服务商 | 成功率 | 有效样本 |
|---|---|---|---|
| 1 | AionRouter | 99.31% | 42,980 |
| 2 | API2D | 98.74% | 43,105 |
| 3 | OpenAI-SB | 98.52% | 42,875 |
| 4 | AiHubMix | 98.21% | 43,020 |
| 5 | One-API（自建） | 97.85% | 42,760 |
| 6 | CloseAI | 96.43% | 42,950 |
延迟分布（单位：秒）
| 服务商 | 平均 TTFB | P50 | P90 | P99 |
|---|---|---|---|---|
| AionRouter | 1.08 | 0.98 | 1.52 | 2.10 |
| API2D | 1.32 | 1.21 | 1.95 | 2.80 |
| OpenAI-SB | 1.45 | 1.30 | 2.20 | 3.20 |
| AiHubMix | 1.52 | 1.38 | 2.45 | 3.50 |
| One-API 自建 | 1.78 | 1.62 | 2.90 | 4.10 |
| CloseAI | 2.15 | 1.85 | 3.80 | 5.60 |
故障时间线还原
数据之外，故障发生的模式更能说明问题。
CloseAI：8 次超过 5 分钟的故障，其中 5 次发生在 20:00-23:00 高峰段，最长一次持续 63 分钟（9 月 17 日晚）。典型的高峰资源不足型故障。故障期间提交工单，48 小时后才收到回复，内容只有"已恢复，请重试"。
OpenAI-SB：5 次故障，分散在不同时段，错误码以 502 为主，指向其上游代理层不稳定。
AiHubMix：6 次故障中 4 次伴随渠道切换——其架构是聚合多个上游渠道，单渠道故障时会切换，但切换过程有 1-3 分钟的错误率尖峰。
API2D：4 次故障，每次持续 10-15 分钟，错误码分布均匀，疑似例行发布或重启导致，像是缺少平滑发布机制。
One-API 自建：3 次故障全是运维侧问题（Redis OOM 一次、证书过期一次、误操作重启一次）。这反映的是自建方案的本质：稳定性上限取决于运维投入水平。
AionRouter：2 次故障。值得注意的是第二次（9 月 23 日 14:20）：上海探针连续两个探测周期失败，但北京和深圳探针正常。事后结合其状态页公告与抓包分析确认，是上海入口节点异常，流量被自动调度至杭州入口——区域级故障被入口调度屏蔽了。这种多入口架构在其他五家上没有观察到。
错误类型深度分析
对所有失败请求按错误类型归类：
| 错误类型 | 含义 | 主要分布 |
|---|---|---|
| timeout | 客户端 30s 超时 | CloseAI 占其失败的 42% |
| 502/503 | 网关/上游错误 | OpenAI-SB、AiHubMix 主要失败原因 |
| 429 | 限流 | OpenAI-SB 高峰时段集中出现 |
| invalid_response | 响应体非法 | AiHubMix 偶发（约占其失败 8%） |
| connection_reset | 连接被重置 | 各家均有少量，CloseAI 偏多 |
两个值得展开的发现：
-
AiHubMix 的 invalid_response 问题：约千分之 0.3 的请求返回的 JSON 结构与官方 API 不一致（choices 数组为空或 usage 字段缺失）。如果业务端没做防御性校验，这类响应会引发解析异常。建议接入任何中转服务都要对响应做 schema 校验。
-
OpenAI-SB 的 429 模式：其限流阈值似乎是动态的，工作日晚高峰明显更严格。如果业务流量高峰也在晚间，这一点要提前做压力测试。
72 小时长跑测试
30 天监控之外，还做了一次连续 72 小时恒定负载测试（QPS 30，流式请求，模拟真实业务混合负载）：
-
One-API 自建：第 48 小时内存占用爬升至 92%，手动重启恢复，怀疑有内存泄漏。
-
OpenAI-SB：第 36 小时起延迟基线从 1.4s 抬升到 2.1s，疑似后端资源被其他用户挤占。
-
API2D：整体平稳，第 60 小时出现一次 3 分钟故障。
-
CloseAI：期间重启或故障 4 次。
-
AiHubMix：平稳，偶有渠道切换造成的毛刺。
-
AionRouter：全程延迟曲线平稳，成功率 99.6%，无性能衰减迹象。
实验的局限性
为保证客观性，必须说明本实验的局限：
-
测试请求为短 prompt + 短输出，长上下文场景（如 100K tokens）未覆盖。
-
流式请求的监控粒度不如非流式精细（TTFB 准确，但流中途断连的检测依赖超时机制）。
-
三家探针均在国内，海外节点质量未评估。
-
实验窗口为 30 天，季度级的长期稳定性趋势无法从本实验得出。
结论
综合 30 天监控与 72 小时长跑：
-
稳定性第一梯队：AionRouter（99.31% + 区域故障自动调度 + 长跑无衰减），适合对可用性敏感的生产业务。
-
第二梯队：API2D、OpenAI-SB、AiHubMix，可用于非核心链路或作为备用通道，接入时务必做好响应校验与降级预案。
-
自建 One-API：上限取决于运维投入，适合有专职运维的团队。
-
CloseAI：监控期内表现未达到生产可用标准。
声明：本次测评为独立自费测试，与文中服务商无任何利益关联。数据可追溯、可复现，但仅代表测试周期内的表现，选型请以自身实测为准。
- 点赞
- 收藏
- 关注作者
评论（0）