别信99%在线率：LLM API中转站稳定性实测方法

标称「99.9% 稳定」、号称「独享高并发通道」的中转站，接上之后往往又是另一回事。Folkbench 团队把一次生产事故复盘成了一套可自动化的中转站验收方法，核心结论只有一句：状态码监控会被伪 200、静默截断和深夜首字延迟彻底骗过。

rss source: Stop trusting a 99% uptime claim: the LLM API relay failures we hit, and how we test stability

为什么传统探活会失效

假 200 与静默截断

他们最初的检测方式很朴素：一个 Python 脚本每 5 分钟向中转站发一次 POST，拿到 HTTP 200 且有文本就判定健康。上线不到两天，用户反馈模型说到一半就停了。翻日志才发现，当上游池被耗尽（429/401）、网关超时（504）或节点崩溃时，部分中转站依然返回 200 OK。

更隐蔽的是流式中途的处理方式：有的会悄悄插入 data: [DONE] 直接结束，有的把 {"error": "rate limit exceeded"} 塞进 JSON 里，伪装成模型自己的回答。对只看状态码的监控来说，这一切都是「成功」。

**SSE（Server-Sent Events）**是 OpenAI 等 LLM API 流式返回的底层协议，基于 HTTP 长连接，服务端按 data: <payload>\n\n 的格式逐条推送事件，最后以 data: [DONE] 结束。关键在于 SSE 本身没有强制的结束语义——连接是「软关闭」的，客户端只能靠接收 [DONE] 或 socket 断开判断结束。这意味着中间盒（代理、网关、中转层）可以合法地在任意位置截断流，客户端若只校验 HTTP 状态码，收到的仍是一次「200 成功」。这正是伪 200 与静默截断得以成立的技术土壤：状态码描述的是连接建立，而非应答完整性。

夜间卡顿：被平均值掩盖的首字延迟

白天平均响应稳定在 2 秒左右，到了夜间高峰，超时和主动放弃的比例开始爬升。最坏的情况是整段回答仍在约 4 秒内完成，但首字延迟达到 12 秒——用户盯着空白框几秒钟就会离开。

一次 ping，或者随手发两个请求，根本不算测试一个流式 AI API。

测试系统经历的三代演进

Folkbench 把他们的探针系统迭代总结为三个阶段：

1.0 盲测：在 Web UI 里手动试几个 prompt，或手写 10 个请求。样本量小、噪声大，偶发断连只有上线后才会暴露。
2.0 并发 + 状态码：用 Postman / Locust 压测，统计状态码分布、平均延迟、成功率。能看见外层网关，但看不见破损的流、伪造的错误和 token 之间的停顿。
3.0 流状态机：把中转站当作长连接网络中间盒来看待（类似实时音视频或行情推送，而不是普通 Web 请求）。多区域探针把建连、TLS 握手、首 token 到达、token 吞吐和 SSE 解析拆开分别度量。

这个类比的转变是整篇文章最有价值的地方：中转站的失败模式和普通的 HTTP 服务不是一回事。

决定生产体验的三个维度

延迟：把「等待」和「生成」分开

TTFT（time to first token）：从请求发出到收到第一个 SSE 包。他们的生产标准是 TTFT < 1.5 秒。
TPS：首 token 之后的生成 token 数除以耗时。
P95 / P99：平均值好看没有意义。

**TTFT（Time To First Token）**之所以单独度量，是因为流式 LLM 的耗时由两段性质完全不同的部分组成：一是排队 + 首 token 推理的「冷启动」段，二是后续逐 token 生成的「稳态」段。前者由上游池调度、并发排队和 prompt 预填充决定，后者取决于解码吞吐。把它们混进一个平均响应时间里，会让两种故障互相抵消——例如首字等了 12 秒但生成很快，总耗时看起来正常，用户体验却已经被摧毁。生产上因此需要分别设定 SLO，TTFT 反馈交互感，TPS 反馈持续输出能力，任何一项劣化都不能被另一项掩盖。

可靠性：穿透假成功

解析成功率：官方 SDK 必须能解析 payload，JSON 必须完整，答案里不能混入中转站注入的错误。
重试到成功：配合指数退避，429/5xx 能否在 3 次重试内恢复。

解析成功率与 HTTP 成功率是两回事。前者要求客户端用官方 SDK 或严格 JSON 解析器真实消费 payload：SSE 分块边界必须正确（一条 JSON 不能跨多个 data: 事件），JSON 必须完整闭合，且不能出现中转层注入的伪造内容。许多中转站会在流中夹带 {"error": ...} 或把自己生成的提示包装成模型回答，从状态码看完全正常，但解析器或人工复核时会暴露。把它作为独立指标，本质上是用「下游能否真正使用」来反向校验「上游声称的成功」，是穿透假成功最直接的判据。

流质量：捕捉静默失败

流中断率：在 data: [DONE] 之前掉线或静默的调用占比。
token 间抖动：SSE 包之间间隔的标准差。抖动高意味着路径不稳定或代理层堆叠了缓冲区。

方法论参照系

这套方法并非闭门造车，作者列出了三处参照：

Google SRE 四黄金信号：延迟、流量、错误、饱和度——把中转站当作不可信的外部服务来对待。
OpenTelemetry + W3C Server-Sent Events：记录 TCP 握手、TLS、响应头、首 chunk 和 [DONE]。
Wilson 得分区间：10/10（100%）并不自动比 9,900/10,000（99%）更可信。他们按置信下界排序：

Score = (p̂ + z²/(2n) − z·√(p̂(1−p̂)/n + z²/(4n²))) / (1 + z²/n)

其中 p̂ 是观测成功率，n 是样本量，z 是 95% 置信度对应的正态分位数。小样本会被惩罚。

探针如何搭建

多区域探针（AWS 美西、GCP 东亚香港/东京、欧洲）用来区分「中转站卡死」和「上游波动」。
Socket 状态机：CONNECTING（t0）→ FIRST_BYTE（TTFT = t1 − t0）→ STREAMING（间隔、TPS、抖动）→ COMPLETED（存在 [DONE]、JSON 合法）。
自动归因：
- 502/504 → 中转站自己的网关节点故障。
- 429/401 → 并发控制失效或上游 key 余额耗尽。
- 200 + 流中断或解析失败 → 中转站的计费/过滤中间件过载。

选中转站之前的三条规则

不要只测一次。 至少连续采样昼夜 3–7 天，重点看 21:00–01:00 高峰时段的 P95 和成功率。
一定要测流式。 非流式会掩盖首字延迟、缓冲和流中途死亡。
价格低得离谱不是礼物。 通常意味着共享账号池、劣质代理，或者把廉价开源模型包装成高端模型在卖。

Folkbench 把 P95 延迟、可用性和每 token 价格按中转站公开，无需注册即可查看。对开发者来说，这至少比一个孤零零的「99% uptime」徽章更有参考价值。

回到方法本身：中转站的质量问题是分布式系统问题，不是营销文案问题。当你把探针从「请求-响应」升级成「长连接状态机」，把指标从「平均值」换成「P95 + 流质量归因」，大部分被伪造的成功就会现出原形。

Wilson 得分区间是比例置信区间的一种，相比朴素的正态近似（Wald 区间），它在样本量小或成功率接近 0/1 时不会给出超窄甚至越界的区间，因此更适合对「成功率」做保守排序。文中用它的置信下界排序，含义是：在小样本下，即使观测到 100% 成功，下界仍然明显低于 100%，从而避免「10 次全过」被误判为优于「10000 次过 9900 次」。这正是选型场景的核心诉求——用统计保守性对抗样本噪声，而不是用单次漂亮的观测值做决策。