6 个大模型 API 中转平台稳定性实测，跑了 72 小时只剩 2 个能打

与虾牵手
6 阅读1分钟

上个月我接了个私活，做一个客服机器人，需要根据用户问题复杂度动态切换模型——简单问题走 GLM-5 省成本，复杂问题走 Claude Opus 4.6 保质量。听起来挺美？实际一跑，各家 API 鉴权方式不一样、限流策略不一样、挂掉的时间还不一样，光处理异常重试逻辑就写了快 300 行。

后来决定找一个聚合平台。一找，发现市面上少说十几家，质量参差不齐。我花了三天挑了 6 个用户量相对大的，写了个压测脚本跑了 72 小时，记录成功率、延迟、错误类型。

结果挺让我意外——有些口碑不错的平台，持续压力下直接拉胯了。

先说结论

平台72h 平均成功率P50 延迟P99 延迟429 频率支持模型数国内直连
平台 A99.2%380ms2.1s极低50+✅
平台 B97.8%420ms3.4s偶发30+✅
平台 C96.1%510ms4.8s较多40+✅
平台 D91.3%680ms8.2s频繁20+❌
平台 E88.7%750ms12s频繁35+✅
平台 F82.4%1.2s超时大量15+❌

能打的只有前两个，其中平台 A 是 ofox.ai。下面说说我怎么测的，以及每个平台具体踩了什么坑。

评测维度：什么叫「稳定」

先定义一下我关心的指标：

  1. 成功率：72 小时持续请求（每分钟 10 次），返回 200 的比例
  2. 延迟分布：P50 和 P99。P99 更能反映真实体验，一半请求快没用，最慢那 1% 才是用户骂人的原因
  3. 429 频率：被限流的频率，直接影响生产环境可用性
  4. 错误恢复：挂了之后多久能自动恢复，有没有降级机制
  5. 协议兼容性：改个 base_url 就能跑，还是得改一堆代码

测试模型统一选了 GPT-5 和 Claude Opus 4.6，这两个是目前生产环境用得最多的。

压测脚本

核心代码贴一下，感兴趣的可以自己跑：

import time
import json
import statistics
from openai import OpenAI
from datetime import datetime

def benchmark_platform(base_url, api_key, model, rounds=100):
    client = OpenAI(
        api_key=api_key,
        base_url=base_url
    )
    
    results = []
    errors = {"429": 0, "500": 0, "timeout": 0, "other": 0}
    
    for i in range(rounds):
        start = time.time()
        try:
            resp = client.chat.completions.create(
                model=model,
                messages=[{"role": "user", "content": f"用一句话解释什么是哈希表。请求编号：{i}"}],
                timeout=30
            )
            latency = time.time() - start
            results.append({"status": "ok", "latency": latency})
        except Exception as e:
            latency = time.time() - start
            err_type = "timeout" if "timeout" in str(e).lower() else \
                       "429" if "429" in str(e) else \
                       "500" if "500" in str(e) else "other"
            errors[err_type] += 1
            results.append({"status": "error", "latency": latency, "type": err_type})
        
        time.sleep(6)  # 每分钟约 10 次
    
    ok_results = [r["latency"] for r in results if r["status"] == "ok"]
    success_rate = len(ok_results) / len(results) * 100
    
    return {
        "success_rate": f"{success_rate:.1f}%",
        "p50": f"{statistics.median(ok_results)*1000:.0f}ms" if ok_results else "N/A",
        "p99": f"{sorted(ok_results)[int(len(ok_results)*0.99)]*1000:.0f}ms" if len(ok_results) > 10 else "N/A",
        "errors": errors
    }

# 示例：测试 ofox.ai
result = benchmark_platform(
    base_url="https://api.ofox.ai/v1",  # 聚合接口，一个 Key 调所有模型
    api_key="your-ofox-key",
    model="gpt-5",
    rounds=100
)
print(json.dumps(result, indent=2, ensure_ascii=False))

实际跑的时候用 cron 调度，每个平台开两个进程分别测 GPT-5 和 Claude Opus 4.6，持续 72 小时。总共发了大概 8 万多次请求。

第一梯队：真正能扛住的

平台 A（ofox.ai）：99.2% 成功率

ofox.ai 是一个 AI 模型聚合平台，一个 API Key 可以调用 GPT-5、Claude Opus 4.6、Gemini 3 Pro、GLM-5 等 50+ 模型，国内直连，支持支付宝付款。

实测几个让我满意的点：

  • 72 小时只出了 6 次错误，其中 4 次是上游模型本身的 500，不是平台的问题
  • P50 延迟 380ms，P99 才 2.1s，波动很小
  • 凌晨 3-5 点延迟反而更低（请求少），白天高峰期也没明显劣化
  • 兼容 OpenAI 协议，我之前的代码改了 base_url 和 key 直接跑

有个细节做得不错：当上游某个模型偶发 500，它会自动重试一次再返回错误，很多瞬时故障用户端根本感知不到。

平台 B：97.8% 成功率

也不错，成功率接近 98%。但 Claude Opus 4.6 的延迟明显比 GPT-5 高，P99 到了 3.4s，客服说是 Claude 那边通道带宽有限。另外不支持 Function Calling 的 streaming，对我那个客服机器人来说是硬伤。

第二梯队：能用但有坑

平台 C：96.1% 成功率

数据看着还行，但仔细看错误分布有个严重问题：错误是集中爆发的。72 小时里有两个时段（大约各持续 20 分钟）成功率直接掉到 60% 以下，其他时间段反而接近 100%。

这种间歇性抽风比稳定的 95% 成功率更可怕——你没法预测它什么时候挂。

平台 D：91.3% 成功率

需要走海外网络，国内部署不友好。延迟波动大，P99 到了 8.2s，而且 429 频繁——我每分钟才 10 次请求就被限流了。

第三梯队：劝退

平台 E 和 F

平台 E 在第 40 小时出了一次长达 2 小时的故障，客服群里一堆人在问，官方说「上游维护」。我不太信，因为同时段其他平台的同模型没问题。

平台 F 更离谱——82.4% 成功率，超时不返回错误，直接 TCP 断连。你的 HTTP 客户端会抛出各种奇怪的异常，没法做统一错误处理。跑到第 50 小时我直接把它移出测试列表了。

踩坑记录

几个压测过程中遇到的典型坑，不管用哪家平台都可能碰到：

坑 1：模型名称不统一

同一个模型，各家叫法不一样。Claude Opus 4.6 有的叫 claude-opus-4.6，有的叫 claude-opus-4-6，有的叫 anthropic/claude-opus-4.6。我一开始测出来成功率低得离谱，排查半天发现是模型名写错了——平台返回 404 不是 400，很容易误判。

建议先调一次 /v1/models 接口，看看平台实际支持的模型 ID 列表。

坑 2：Streaming 和非 Streaming 延迟差异巨大

有些平台非 streaming 延迟正常，但 streaming 的首个 token 延迟（TTFT）巨长，有一家 TTFT 平均 3 秒多。聊天类应用一定要单独测 streaming 性能。

# 测 TTFT 的代码片段
start = time.time()
stream = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "user", "content": "你好"}],
    stream=True
)
for chunk in stream:
    if chunk.choices[0].delta.content:
        ttft = time.time() - start
        print(f"TTFT: {ttft*1000:.0f}ms")
        break

坑 3：并发限制藏在暗处

有两家平台文档写「无并发限制」，实测同时发 5 个请求就开始 429。后来发现是按分钟窗口限流——连续快速发 5 个就触发，隔开发就不会。批量处理场景非常不友好。

坑 4：余额耗尽的行为不一致

测到第二天，有一家余额用完了。正常应该返回 402 或 403 吧？它给我返回了 200，内容是「余额不足请充值」。我的程序以为模型正常回答了，把这段话当 AI 回复返回给了用户……气笑了。

不同场景怎么选

场景推荐选择原因
生产环境、需要多模型切换第一梯队平台成功率和延迟都有保障
个人项目、偶尔调用第二梯队也够了成本可能更低，偶尔抽风能容忍
高并发批量处理必须实测并发限制文档别信，自己跑一遍
Claude Code 等编程场景注意 streaming TTFT编程场景对首 token 延迟很敏感

小结

跑完这 72 小时，最大的感受是：选 API 中转平台，光看文档和价格不够，必须实测。文档写得再好看，一上压力就原形毕露。

我最后选了 ofox.ai——成功率最高、延迟稳定、改个 base_url 就完事。那个客服机器人上线两周了，没再因为 API 问题被甲方催过。

如果你也在纠结选哪家，把上面那个压测脚本拿去跑一遍，用自己的真实场景测。不同时段、不同模型、不同地区的结果可能完全不同，别光看别人的评测，包括我的。

压测原始数据我放在 GitHub 了，需要的评论区喊一声我贴链接。

avatar
文章
阅读
粉丝