昼夜延迟：为什么你的 AI 功能在东部时间上午 9 点最慢

在上个季度的某个时候，你团队的一名工程师在 Slack 上发了一个帖子，开头是“模型变慢了”。他们展示了一张图表：你的助手功能的 p95 延迟从早上 7 点开始稳步攀升，在东部时间上午 10 点左右达到顶峰，午餐期间处于平台期，并在下午 5 点后悄然恢复。这种形态在第二天、第三天不断重复。团队追溯了他们的部署记录，指责了分词器（tokenizer）的更改，接着是上下文长度的退化，最后发现没什么是特别确定的。修复方案从未落地，因为 Bug 根本不在你的代码里。

顶尖模型提供商运行着共享的推理集群。当你的用户醒来时，北美其他地区也醒了，再加上欧洲的下午，以及每一家购买了相同 API 的公司的每一个内部工具。提供商端的队列深度翻倍，GPU 竞争加剧，你的 p95 延迟也随之翻倍——而你的代码库没发生一行代码变更。这是你技术栈中最可预测的生产事故，但几乎没有团队会为此建立仪表板。

曲线的形态

公共延迟追踪器和提供商的事后分析都指向了同一种每日节奏。工作日期间，美国托管的主要端点峰值负载大致在东部时间上午 8 点到下午 2 点之间，在晚餐后当消费级聊天流量回升时会出现一个较小的次峰。非高峰时段——比如东部时间午夜到凌晨 6 点——在相同工作负载下的运行速度通常快 30% 到 40%，在长提示词（long prompts）情况下有时甚至更快，因为此时的首字时间（time-to-first-token）主要受预填充（prefill）调度的影响，而非解码吞吐量（decode throughput）。

这种波动不会以“停机”的形式表现出来。没有 5xx 错误，没有速率限制错误，提供商的状态页面也没有任何异常。请求仍然可以完成，只是耗时更长。凌晨 4 点只需 4 秒就能完成的工作负载，在上午 10 点可能需要 9 秒，而你的链路追踪工具会静默地将两者合并到同一个直方图中。如果你按天汇总，日平均值看起来很正常，日 p95 看起来就像是噪声。信号完全隐藏在你丢弃的时间维度中。

研究工作负载已经直接测量到了这一点。2025 年一篇关于系统论文发布的为期两个月的校园 ChatGPT 使用追踪显示，请求率在几分钟内波动高达 3 倍，同时遵循更广泛的昼夜模式，运营商被迫按峰值过度配置 GPU，仅仅为了在糟糕的时段维持其服务水平目标（SLO）。这种过度配置也是你的提供商所做的，但仅限于合同预算范围内——剩下的负载则以延迟的形式转嫁到了你身上。

为什么你的仪表板隐藏了它

大多数团队设置延迟监控的方式就像设置数据库延迟监控一样：在一个采样窗口内汇总直方图，在单张图表上显示 p50、p95 和 p99 线。对于负载由你控制的服务，这是正确的形态。但对于负载由他人的流量主导的服务，这就是错误的。

聚合隐藏了双峰性。如果 30% 的流量落在非高峰时段，70% 落在高峰时段，你的 p95 反映的是一种加权混合，没有任何单个用户会体验到这种数值。凌晨 2 点的批处理作业和上午 10 点的客户电话通过同一个客户端连接，并计入同一个桶中，尽管它们在延迟维度上处于完全不同的世界。仪表板读数显示为“尾部方差较高的稳定状态”，而事实是“两个稳定的状态，中间有一个确定性的切换”。

修复方法并不复杂：按小时进行分群（cohort by hour-of-day）。将同一个直方图切成 24 个子直方图，每小时一个，并以热力图的形式展示。昼夜模式会立即显现——通常是 UTC 时间 13:00 到 19:00 的一条“热带”，在周末会褪去。叠加分区域延迟，你可以看到欧洲的早晨在北美醒来之前就开始拉升曲线。一旦你拥有了这个视角，每一个模型端的延迟问题在寻找答案的路上都会多出一列：这个用户是在“糟糕时段”吗？

你实际能做些什么

加载中…