LLM API 实测延迟数据集

探针在哪

🇭🇰 HK（中国香港）、🇺🇸 US-Central（美国芝加哥）。两个节点分开列，不做平均。 同一个端点在两地差出几倍是常事，平均出来的那个数谁都用不上。香港节点测的是国际/跨境链路，不等同于中国内地直连；美国节点调国产模型含跨太平洋链路。内地节点还没有，有了会单独标注。

多久测一次

TTFT 探测默认每 10 分钟一轮，输出速度探测默认每小时一轮。个别端点为省供应商配额放宽到 30 或 60 分钟一轮（Kimi K3、Claude Sonnet 5、Gemini 2.5 Flash 目前属此列），所以各行每小时的样本数 差得很远——别默认所有行都测得一样密，判断一个数字可不可信先看它那行的样本量。 结果每小时聚合成一行（每端点×每节点），这一页读的就是这些小时行。本站另有一条 跑标准任务、且刻意不关思考的成本探测线，口径不同，不进这份数据集。

思考模式一律关闭

所有请求都显式关掉了思考模式。思考型模型的思维链 token 会计进 completion_tokens 且不受 max_tokens 约束（实测某模型请求 256 实际生成 896），不关掉就等于拿「思考速度」 和「出答案速度」放在一起比。代价是这份数据覆盖不了强制思考的模型：Gemini 3.x 全系拒绝关闭思考，所以这里用的是 Gemini 2.5 Flash。越新的旗舰越倾向强制思考， 这个可比范围只会收窄。

窗口 p50 / p95 是二次聚合的近似值

逐次请求的原始记录只留 14 天，且不对外开放读取，所以窗口级分位数不是对窗口内每一次请求 重算出来的。口径如下，写清楚是为了让你知道该怎么用它：

• ttft_p50_ms = 窗口内各小时 p50 的成功样本加权中位数。
• ttft_p95_typical_ms = 各小时 p95 的成功样本加权中位数，读作「一个典型小时的尾延迟」。
• ttft_p95_worst_ms = 窗口内最差那一小时的 p95，尾延迟的上界。
• 真正的窗口 p95 落在这两个数之间。要精确值，得读原始逐次记录，那份数据不公开。
• 每小时只测到一两次的端点，它的「典型小时 p95」会退化成那一次测量本身，看起来会和 p50 一样甚至相等——这不代表它尾延迟平稳，只代表那一小时没有第二个样本 可比。用「样本」列的成功数除以覆盖小时数就能看出每小时有几次。
• tps_avg = 各小时平均输出速度的成功样本加权平均。
• error_rate 是精确值：窗口内失败请求数除以总请求数，不受上面的近似影响。

为什么要看 p95 而不是只看 p50

p50 是一半请求比它快、一半比它慢的那条线，它告诉你「顺手的时候什么感觉」。p95 是每 20 次请求里最慢的那一次，它决定用户什么时候开始觉得卡、你的超时该设多少、 重试逻辑会不会被触发。打个比方：两个端点 p50 都是 500 毫秒、一个 p95 是 800 毫秒另一个是 6 秒，对做实时对话的人来说是两个完全不同的东西。这一页把典型小时和最差小时的 p95 都列出来，就是因为「平时还行、偶尔抽风」是最常见的那种坏。

样本少的行怎么标

有效小时数不足窗口的 50%，或成功样本少于 100 次的，标「样本偏少」——数字照给，但它的波动会比别的行大。 窗口内每一小时都请求失败的，标「无有效样本」，延迟列留空不填 0。失败的小时不会从失败率的分母里摘掉：把调不通的时段扣掉，一个半数时间打不通的端点看起来会和一个稳定端点一样快。

这份数据的局限

两个节点的测量代表不了全球体验，也代表不了你自己机房到端点的链路。探针用的是固定的短提示词， 不等同于长上下文、高并发或带工具调用的真实负载。延迟只是选型的一个维度， 这一页不排「哪家最好」。要判断某个数字可不可信，先看它那行的样本量和覆盖小时数。