API 中转站测评：稳定性测试方法、指标与报告模板

做 API 中转站测评（稳定性测试）时，应在同一模型、输入、地区、时段、超时与重试口径下运行低强度样本，逐请求记录成功、TTFT、总耗时和流完成状态，再解释分位与错误分层。

先给结论：用五个指标量化稳定性

测评回答的是：同一负载在不同时段（或不同候选之间）稳不稳。量化结论用下面五个指标，并同时报告样本条件。

指标	定义	必须同时报告
成功率	满足解析、有效内容、正常完成的请求/总请求	总样本与错误分类
TTFT	发送到首个有效内容事件	流式模式与超时
P95 总耗时	同口径样本的第 95 百分位	分位算法、失败处理
流中断率	已开始但未正常完成的流/已开始流	取消、网络、网关、上游分类
429 比例	429 请求/总请求	并发、请求/Token 速率

不要发布没有原始行、时段和条件的数字。P95 不是“最慢值”，平均值也不能代替尾延迟。

运行 sequential 低强度 baseline kit v1

下载 API Relay Benchmark Kit v1。它是顺序、低强度的 baseline kit v1，不是负载测试器，也不能证明 SLA。解压后使用包内真实 CLI：

export OPENAI_API_KEY="your-test-key"
python3 benchmark.py   --base-url https://example.com/v1   --model example-model   --runs 10   --output results.csv

先运行 python3 benchmark.py --base-url https://example.com/v1 --model example-model --dry-run 检查配置。脚本顺序执行、默认不自动重试，并限制运行次数；它生成你自己的观测，不携带任何服务结果。

分时段测试与可比条件

1. 写下模型、提示词哈希、输入/输出目标、地区、网络出口、客户端版本。
2. 固定流式开关、连接/总超时、重试策略和请求间隔。
3. 在计划时段分别运行相同批次，不临时改变参数。
4. 原始 CSV 只追加，聚合结果写明方法版本。
5. 候选端点使用完全相同顺序，并标记维护或外部网络异常。

完整的协议前置检查见检测篇的校验清单；流式完成条件参考 OpenAI 与 Anthropic 的官方流式文档，而不是只检查状态 200。

结果校验清单

• CSV 行数等于计划尝试数，取消和失败没有被静默删除。
• 成功定义同时要求 HTTP、解析、有效内容和完成标记。
• TTFT 只在流式首个有效内容事件处停止计时。
• P50/P95 使用同一分位算法，报告样本数与失败数。
• 429、5xx、超时、客户端取消、流中断分开。
• 重跑相同批次并保留环境变化说明，不覆盖原记录。

测评结果异常：按客户端 → 网络 → 网关 → 上游排查

若所有端点同时变慢，先查本地 CPU、DNS、代理和出口；只有单一路由异常时再查网关队列、连接池与限流；已连接但 TTFT 异常可继续查路由和上游；流式开始后中断则保存最后事件、完成标记和请求 ID。错误语义用错误码分层表判断。单次请求报错时，按检测篇的故障定位路径逐层查。

若 SDK 自动重试，必须把一个 user_request 下的多次 upstream_attempt 分开。需要关联这些尝试时参考可观测性字段设计。

常见错误与误读

• 把 sequential baseline 当压力测试、容量上限或 SLA 证明。
• 只摘录成功行计算 P95，隐藏失败和流中断。
• 混用不同模型、提示词、地区、时段或重试设置。
• 用单次最快值宣布某服务“最快”或“最稳定”。
• 对 429 立即并发重试，反而放大限流。

故障恢复策略应在API 重试机制中单独验证。本文限制：只提供方法、字段和空白工具，不含任何供应商样本、得分、成功率或延迟结论。

逐请求记录、聚合与报告模板

每次运行创建独立目录，包含只读配置、方法版本、开始/结束时间、原始 CSV、stderr、环境摘要与聚合结果。配置中写 Base URL 主机但不写 key；环境摘要写网络出口类别而不收集个人标识。测试失败时保留该行和错误，禁止只重跑失败项再用新成功覆盖旧失败，因为那会系统性抬高成功率。

逐请求表应区分 user_request_id 与 attempt_id，即使 kit v1 默认不重试，也保留 retry_count 和 stream 状态列。计时使用同一单调时钟：发送前、响应头、首个有效内容事件、最后事件和完成。DNS、连接、TLS 若客户端能可靠拆分则单列；不能拆分时标为未采集，不用总耗时反推虚假的阶段数字。

聚合时先展示分母：计划请求、实际发送、完整成功、部分流、客户端取消、429、5xx 和超时。然后对明确集合计算 P50/P95，写清 nearest-rank 或其他算法，以及失败是否进入分位。TTFT 只对真正开始流的请求有定义；非流式请求不要填 0。流中断率的分母是已开始的流，而不是全部请求。

比较两个端点时使用同一工作负载，轮换运行顺序并记录间隔，减少时段和本地网络顺序偏差。若一方不支持某能力，应报告“不兼容”，不能悄悄换成更简单请求。图表同时显示失败数量和样本量；没有置信范围或重复批次时，趋势只写成“本次观察”。

审阅者抽查四类原始证据：一个完整成功、一个 HTTP 错误、一个超时/取消、一个开始后未完成的流。每类从汇总回溯到 CSV 和日志，再核对分类规则。若无法重现，应先修测试工具或补环境记录，而不是继续扩大次数。这样才能把稳定性基线用于回归，而不是制造看似精确的排行。

请求、响应、参数边界与计算复核

稳定性实验的请求边界包括同一 Base URL、模型、输入哈希、流式模式和无副作用负载；响应边界包括 HTTP 状态、错误类别、首个有效事件、完成事件、usage 与客户端取消。参数边界固定运行次数、请求间隔、单次超时、自动重试关闭、地区、网络出口和时间窗口；只有这些条件一致，两个批次或两个候选才可比较。

验证指标	计算方法	失败模式纳入方式	复核/回滚动作
成功率	完整成功请求数 / 已发起请求数	429、5xx、超时、解析失败、流中断都留在分母	逐行回放完成条件；口径错误则回滚聚合脚本
TTFT / P95 延迟	TTFT 从发出到首个有效内容事件；P95 对完成样本按既定分位规则计算	首事件前失败单列，不能伪装成极短延迟	核对单调时钟、事件时间戳和样本数
流式中断率	已开始但未正常完成的流 / 已开始的流	客户端取消与服务端中断分开	保存最后事件和取消原因，再从小批次恢复

“API 中转站压测和稳定性测试区别”在于本页套件是 sequential 低强度基线，不寻找容量极限；“如何比较两个 API 中转站延迟”则要求相同模型、负载、时段和失败口径。API 中转站测评不能只报 P95：还要并列 API 成功率、流完成率、429 与样本条件。发现脚本时钟异常、自动重试未关闭或请求参数漂移时立即停止，保留原始 CSV，回滚配置后创建新批次。

一手资料

• RFC 9110 §15：HTTP 状态码
• OpenAI：Streaming responses
• Anthropic：Streaming Messages

停止、回滚与恢复步骤

达到预设运行次数、测试费用、连续失败或 429 停止阈值时立即停止；kit v1 不是负载测试器，不通过增加并发“找极限”。用 Ctrl+C 停止后保留已写 CSV 和 stderr，撤销测试 key，不把半批数据与完整批次混算。若配置误改，回滚到只读配置快照与上一个方法版本；恢复前先执行 --dry-run，再运行一条短请求并核对 CSV 字段，最后从新批次编号恢复低强度顺序测试。失败批次保留为证据。

执行问题与参数边界

以下回答用于定位常见执行问题。实际判断仍需结合本文的参数、失败模式和验证指标，不应仅凭一项现象推断服务能力。

API 中转站稳定性怎么测试

先固定工作负载，再运行低强度 API 稳定性测试。

AI API 成功率和 P95 延迟怎么统计

API 成功率与 P95 延迟必须带分母、失败和算法。

流式 API TTFT 怎么测

TTFT 从发送到首个有效内容事件，不能用总耗时代替。

API 中转高峰期稳定性测试

高峰与平峰分别建批次，不能混成一个 API 延迟测试结果。

API 流式响应中断率怎么计算

流式中断数除以已开始的流，并按原因分类。

API 429 限流对稳定性的影响

429 单列，并记录请求/Token 速率和 API 限流测试条件。

常见问题

API 中转站稳定性怎么测试？

固定模型、请求、地区、时段、超时和重试，低强度重复运行并逐请求记录成功、TTFT、总耗时、流完成和错误类型，再在相同条件下比较。

P95 延迟怎么统计？

对同一口径的逐请求样本排序并采用明确的分位算法，同时报告样本数、失败数和是否排除失败；不能只给一个脱离条件的 P95。

流式 API 中断率怎么计算？

将已经返回有效内容但没有正常完成事件的请求数，除以全部已开始的流式请求数，并区分客户端取消、网络、网关和上游错误。

baseline kit v1 能证明 SLA 吗？

不能。它是 sequential 低强度基线工具，不是负载测试器；结果只代表运行时写明的模型、网络、时段、参数和样本。