API 中转稳定性实测方法与指标
选 API 中转服务不能只看宣传页的延迟数字。这篇给一套可自己动手的实测方法：固定测试条件、跑够样本量，用首字延迟、P95 总耗时、错误率、跨时段波动四个指标评估稳定性，附可直接运行的 Python 测速脚本。
选 API 网关或中转服务时，宣传页上的「低延迟」「99.9% 可用」没法直接当真——测试条件不同，数字毫无可比性。好消息是验证成本极低：一段几十行的脚本、不到一顿早饭的钱，就能拿到一份属于你自己的实测报告。这篇文章给出一套做法和指标口径，照着跑即可。
先说结论
- 只看平均延迟会被严重误导，看 P95：平均 2 秒、P95 15 秒的服务在生产里会频繁超时
- 核心指标四个：首字延迟（TTFT）、总耗时分布、错误率、跨时段波动
- 样本量至少 100 次连续请求，且必须覆盖高峰与低谷两个时段
- 用流式请求测，因为生产里绝大多数 LLM 应用都是流式，非流式测出来的数据参考价值有限
- 测试模型选最便宜的就行，比如 gpt-4o-mini，结论对其他模型同样有参考意义
四个指标的定义与参考值
| 指标 | 定义 | 经验参考（流式，短回答） |
|---|---|---|
| 首字延迟 TTFT | 发出请求到收到第一个流式 chunk 的时间 | P50 低于 1.5s，P95 低于 4s |
| 总耗时 P50/P95 | 完整回答结束的时间分布 | P95 超过 30s 需警惕 |
| 错误率 | 4xx/5xx/超时占总请求比例 | 连续 100 次应低于 2% |
| 时段波动 | 高峰时段与低谷时段指标差异 | P95 波动超过 3 倍说明容量紧张 |
其中时段波动最容易被忽略：很多中转白天稳定、晚上高峰期排队，而你的用户恰好都在晚上。只测一次等于没测。
测速脚本：可直接运行
以下脚本用 Python 官方 SDK 做流式请求，统计首字延迟和总耗时：
import os, time, statistics
from openai import OpenAI
client = OpenAI(
api_key=os.environ["ZAIMOD_API_KEY"],
base_url="https://api.zaimod.com/v1",
)
N = 100
ttft_list, total_list, errors = [], [], 0
for i in range(N):
start = time.perf_counter()
try:
stream = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "用 50 字左右介绍一个随机编程概念"}],
stream=True,
max_tokens=120,
)
first = None
for chunk in stream:
if first is None and chunk.choices and chunk.choices[0].delta.content:
first = time.perf_counter() - start
ttft_list.append(first)
total_list.append(time.perf_counter() - start)
except Exception:
errors += 1
time.sleep(0.5) # 避免触发限流，保持请求间隔
def pct(data, p):
data = sorted(x for x in data if x is not None)
return data[int(len(data) * p) - 1]
print(f"TTFT P50={pct(ttft_list, 0.5):.2f}s P95={pct(ttft_list, 0.95):.2f}s")
print(f"Total P50={pct(total_list, 0.5):.2f}s P95={pct(total_list, 0.95):.2f}s")
print(f"错误率: {errors}/{N}")跑一轮大约 2-3 分钟。分别在工作日上午和晚上 8-11 点各跑一次，两份数据对比就是时段波动。
测试成本估算
用 gpt-4o-mini 测（站内计费口径：输入 $0.156 / 输出 $0.624 每百万 tokens）：每次请求约消耗输入 20 tokens、输出 120 tokens，100 次合计约 $0.008，加上重试和两个时段，总成本低于 2 美分。测大模型会贵几十倍，没有额外收益。
拿到数据之后怎么判
对比官方直连基线。 有条件的话对同一模型跑一次官方 API 的相同脚本，两份 P95 差距在 30% 以内属正常聚合损耗；差距超过 2 倍，说明该中转的调度链路有明显瓶颈。
看错误类型而不是只看比例。 偶发 429 是限流设计，可接受；反复出现的 502/504 和连接重置是上游或网关不稳定，生产环境会直接变成用户看到的报错，属于一票否决项。错误码含义见 大模型 API 错误码速查。
结合经营面信号。 单纯的技术指标无法反映「服务会不会跑路」：账号余额能否随时导出、是否有多个备用模型、平台更新是否活跃，这些信号和实测数据一起看才有结论，参考 API 中转跑路前的预警信号 与 余额查询与用量核对方法。
常见问题
Q：多久复测一次？
接入选定后每月复测一次即可。如果你的应用做了多模型容灾（主模型异常自动切备用），日常由监控埋点持续采集 TTFT 和错误率，比手动复测更及时。
Q：要不要顺便测并发能力？
要，但分开测。先单线程测质量，再用 5/10/20 并发各跑 50 次看 P95 退化曲线。并发下 P95 恶化平缓说明网关有多渠道冗余，断崖式恶化说明背后只有一个渠道在硬扛。
Q：流式和非流式测出来的差异很大正常吗？
正常。非流式总耗时通常比流式首字延迟大得多，二者不可比。确定一种模式（建议流式，贴近生产）后，所有对比都在同一口径下进行。流式协议细节见 SSE 流式输出从 curl 到前端。