中转站延迟怎么测才有意义

"这家快不快"这个问题，如果没有定义，答案没有意义。同一个站点，问"首 token 多久"和"一段 500 字回答总共多久"，得到的数字可能差十倍；上午十点和凌晨两点测，也可能差一倍。

一、先区分三个指标

首页或榜单如果只写"延迟 4.2 秒"而不说这是哪个指标、什么模型、多少输出，这个数字基本不可比。

二、让测量可重复的五个条件

1. 固定模型。不同模型的延迟差异比不同站点之间的差异还大。
2. 固定输出长度。要求输出约 200 token 的固定内容，或用 max_tokens 卡住上限。
3. 固定输入长度。输入 20 token 和输入 8000 token，TTFT 不在一个量级。
4. 固定并发。单并发和 20 并发的延迟是两回事，尤其对中转站。
5. 固定时段并多次采样。至少覆盖一次高峰（工作日下午）和一次低谷（凌晨）。

少任何一条，你测的是"某一次的感觉"，不是"这家站的水平"。

三、一个能直接用的测法

用 curl 测流式，记录首字节和总时长：

curl -sS -N "https://relay.example.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","stream":true,"max_tokens":200,
       "messages":[{"role":"user","content":"用恰好 200 字介绍 HTTP 协议"}]}' \
  -w '\nTTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n' -o /tmp/stream.txt

time_starttransfer 近似首字节时间。真正的 TTFT 要看第一个 data: 块到达的时间，两者差一个网络往返。

跑 10 次，去掉最高最低各一次，看剩下的中位数和离散度。只看平均值会被一次慢请求带偏。

四、中转站特有的三个干扰

1. 伪流式

有些站点不是边生成边返回，而是等上游全部生成完，再切成块发给你。表现是：TTFT 接近总时长，块与块之间没有间隔。

判断方法：记录每个 data: 块的时间戳。真流式的块间隔应该大致均匀（几十毫秒级），伪流式的块会在极短时间内全部到达。

2. 队列与分组

中转站常按"分组"限并发。你所在的组满了，请求会排队，排队时间算进 TTFT。这就是为什么同一家站在不同时间测出来的数字差很多。

这类延迟不是"网络慢"，换网络没用，只能换分组或换时段。

3. 上游重试

站点收到你的请求后，如果上游失败，它可能自己重试一次。你感知到的是一次很慢的请求，实际上是两次上游调用。这类请求的特征是偶发、极慢、且没有错误返回。

五、怎么读本站的延迟数据

本站榜单的延迟是探测请求的平均值，窗口是 7 天，模型和输入长度固定。它适合用来排序，不适合用来预测你的一次具体请求。

几个使用原则：

• 样本少于 200 的站点，延迟数字的置信度低。
• 延迟低但可用性差（例如 88%）的站点，说明它经常失败——失败很快，不计入平均。
• 跨窗口比较没有意义，只有同一窗口内的排序有意义。

六、给你的应用设一个预算

比起"哪家最快"，更有用的问题是"我的应用能容忍多慢"。

• 聊天类交互：TTFT 超过 2 秒，用户会感觉卡。
• 批量处理：总时长和单价比延迟重要。
• Agent 多步调用：每一步的延迟会累加，TTFT 1 秒 × 8 步 = 8 秒，用户会走。

先算出这个预算，再去选站，比追"最低延迟"实际得多。

七、一个记录表

填两周，你就有一份别人给不了的选站依据。