晚高峰抖动：是上游、线路还是你的并发

先分清四种可能

「晚高峰变慢」有四个可能的原因层，它们的处置方式完全不同：

关键判断顺序：从最便宜、最可能有结论的一层开始。

第一步：用固定小请求测基线（2 分钟）

做法：发一个最小请求（max_tokens: 1），记录耗时。连续跑 10 次。

为什么用最小请求：它的耗时几乎完全由「网络 + 排队」决定，与生成内容的长度无关。这样测出来的是通道基线。

判据：

• 小请求快（< 2s）但你实际业务慢 → 问题不在通道，在生成阶段（上游负载高、或你的 prompt 太长、或输出太长）；
• 小请求也慢 → 问题在通道（排队 / 线路 / 你的并发）。

这一步就能把可能性从四种降到两种。

第二步：并发梯度测容量拐点（5 分钟）

做法：以 1、2、4、8、16 的并发梯度各发 10 个请求，记录每组的中位耗时与失败率。

并发 1  → 中位 1.2s   失败 0%
并发 2  → 中位 1.5s   失败 0%
并发 4  → 中位 2.8s   失败 0%
并发 8  → 中位 9.1s   失败 12%    ← 拐点
并发 16 → 中位 22s    失败 40%

判据：

• 有明显拐点（上面在 4→8 之间）→ 这是容量上限。原因可能是上游限流、中转站的队列，或者你自己的出口带宽。
• 没有拐点，各并发下延迟都随并发线性增长 → 说明请求在串行排队。这是典型的「上游/中转站排队」。
• 并发 1 就很慢 → 不是并发问题，是通道本身的问题。

关键：把拐点记下来，它就是你这条链路的实际并发上限。生产环境的并发应当设在这个值的 50%–70%。

注意：这一步会消耗一些额度，但用最小请求（max_tokens: 1）成本极低。

第三步：同城对照排除线路（3 分钟）

如果前两步都指向「通道问题」，需要区分是线路还是中转站。

做法：从两个不同的网络位置（比如你的本地机器 + 一台云服务器）同时探测同一个端点。

判据：

• 两个位置都慢 → 问题在中转站或上游；
• 只有你的位置慢 → 问题在你的网络出口（可能是运营商晚高峰拥塞，也可能是你的代理链路）。

这一步的价值：如果是你的线路问题，换中转站是白费功夫。

一个更省事的替代方法：如果你能访问该站的静态资源（首页、文档页），测一下它们的加载时间。

• 静态资源也慢 → 线路问题；
• 静态资源快、API 慢 → 中转站或上游的问题。

这个方法不需要第二台机器，非常实用。

四种原因对应的处置

上游模型服务

特征：所有走同一上游的站同时变慢；小请求也慢；从多个位置测都慢。

处置：换站（换到走不同上游的站），或错峰。没有别的办法 —— 这是上游的容量问题。

中间线路

特征：只有某些网络位置慢；静态资源也慢；延迟增加但成功率不变。

处置：换节点、换线路、或调整你的代理配置。

中转站自身

特征：并发拐点很低（比如超过 4 就大幅劣化）；同一站的不同模型表现一致地差；而别的站正常。

处置：降并发到拐点以下 + 加退避重试；或者换站。

你的并发

特征：抓包或日志显示你的请求在短时间内打出去很多；429 出现频率高。

处置：

1. 加并发上限（信号量控制）；
2. 加指数退避（失败后等待 2s、4s、8s…，而不是立刻重试）；
3. 加抖动（jitter），避免所有请求在同一时刻重试。

第 3 项最常被忽略：如果 10 个请求同时失败、同时重试，就会形成「重试风暴」，让本来只是轻微限流的情况变成完全失败。

一个容易忽略的因素：超时设置

晚高峰的延迟本来就更高。如果你把超时设得刚好贴近平时的延迟，晚高峰会大面积超时报错 —— 而请求本身可能已经成功（上游已经处理并计费），只是你没等到响应。

做法：超时按 p99 延迟 × 2 设置，而不是按平均值。宁可多等，也不要误判。

这一条的实际影响很大：很多「晚高峰故障」其实是超时设置不合理，而不是服务真的不可用。

一份十分钟诊断清单

□ 1) 最小请求 × 10，看通道基线是否正常
   · 快 → 问题在生成阶段（prompt/输出太长 或 上游负载）
   · 慢 → 继续第 2 步
□ 2) 并发梯度 1→16，找拐点
   · 有拐点 → 记下它，这就是你的并发上限
□ 3) 静态资源 vs API 对照
   · 静态也慢 → 线路问题
   · 静态正常 → 中转站/上游
□ 4) 检查你的超时设置是否 ≥ p99 × 2
□ 5) 检查是否有重试风暴（同时重试）

五步做完，原因基本就定位到具体一层了。整个过程不需要任何专业工具，curl + time 就够。

最后

本站监测页的「响应延迟」是首页可达性的测量，不等于生成首字延迟，也不反映晚高峰的排队情况 —— 它的口径写在《可用率是怎么测出来的》那篇里。

它的用途是横向比较（哪家整体更快），不是预测「今晚它会不会慢」。后者只能靠你自己的探针（见《自建探针》一篇）。