供应商配额在你的全球流量从未选中的时区重置

你的每月 Token 配额在 00:00 UTC 重置。你最大的客户在东京，他们在 21:00 UTC（即当地时间第二天早上 6:00）达到峰值负载。当重置时刻到来时，东京的工作日已经在配额耗尽的降级方案中消耗了该周期的最后六个小时。429 错误看起来只是“偶发”，因为你仪表板上的 UTC 日历轴将每日重置边界隐藏在了普通的时间戳之中。

这不是速率限制（rate limit）的 Bug。这是一个日历 Bug。供应商为了结算方便选择了一个重置时钟，而你流量的地理分布决定了哪些客户会分配到周期末尾的空窗期。那些将配额定价为统一资源的团队，正基于一个用户从未见过的日历来进行配额分配。

仪表板让情况变得更糟。大多数 LLM 使用情况仪表板会绘制一条平滑的单月消耗曲线，并在重置时出现整齐的垂直下降。这个下降发生在 00:00 UTC。而 00:00 UTC 的页面访问量大多是来自 SRE 团队查看仪表板的内部流量。没有人从另一个半球的客户角度来看待重置时刻——在那里，00:00 UTC 可能是旧金山睡眼惺忪的上午 9:00，或者是伦敦正吃着办公桌午餐的上午 8:00。重置发生在你的流量低谷期，这恰恰是让你误以为这个边界是良性的错误原因。

重置时钟是合同条款，而非物理常数

每个供应商都会选择一个重置时钟。OpenAI 的每月使用限制、GitHub Copilot 的计费周期、Azure OpenAI 的每日配额、Google 的每日配额，以及一大批小型供应商，都统一选择 00:00 UTC 或太平洋时间午夜。这个选择很少被公开宣传——它通常被埋在计费 FAQ 中，或者从使用情况 CSV 的时间戳中推断出来——但它具有约束力。

这种便利性是单向的。供应商在其财务团队工作的时区获得了一个整洁的午夜边界。而客户获得的配额，相对于峰值负载的消耗速度，与其流量在 UTC 以东的距离成正比。一个在 21:00 UTC 偏向东京的工作负载，与一个在 18:00 UTC 偏向旧金山的工作负载，对 00:00 UTC 每月配额的消耗方式是不同的，即使两者消耗的总 Token 数完全相同。消耗总量一致，但每个客户当地时间中配额耗尽窗口的位置却不同。

在单个请求层面，令牌桶（token-bucket）速率限制不存在这个问题。Anthropic 公布的模型会持续补充容量直至上限。令牌桶在设计上是时区无关的——没有重置，只有流速。但令牌桶外围更大的包络线——每月支出上限、Anthropic 在 2025 年中期引入的每周上限、OpenAI 各层级的每月使用限制——都是带有重置时钟的固定窗口配额。令牌桶平滑了秒级的视图，而日历窗口决定了谁先用完配额。

日历人为因素如何隐藏在 UTC 仪表板中

这种诊断模式是统一的。团队会看到带有 insufficient_quota 或类似计费上限错误代码的 429 错误，而不是可以恢复的 rate_limit_exceeded。发生的频率是“每隔几周，临近月底”。团队的第一个假设是流量突发或有 Bug 的重试循环。他们添加了断路器，调整了重试退避（backoff），事故有所减少但并未消失。

团队没有检查的是故障请求在整个周期内的地理分布。如果他们按客户时区和周期天数对 429 错误进行分桶，他们会看到一个楔形：故障集中在峰值负载落在 UTC 当天较晚时段的客户中，并在日历月的最后三分之一累积最为严重。此时配额最接近耗尽，且每个 UTC 日的配额耗尽窗口与其峰值负载重叠。

仪表板上的 UTC 轴掩盖了这一点。21:00 UTC 的峰值负载只是一个高柱状图；仪表板不会标注它是“东京工作日的第七个小时”。重置只是一个垂直下降；仪表板不会标注它是“供应商会计系统中的下个月开始，但对一半用户来说只是一个普通的周三”。可视化正确地呈现了底层数据，但没有呈现能让这种失效模式变得清晰的时区解释。

配额是时间资源，而非数字

加载中…