限流是按 key 算还是按模型算：一把聚合站 key 上到底哪一层在卡你

为什么"限流是按 key 还是按模型"这个问题问不出答案

因为它预设了只有一个限流器。在一把 key 通向多家厂商的聚合架构里，一次请求至少要穿过四个可能独立的限流器，任何一个先触发，你看到的都是同一个 HTTP 429。

所以正确的问法不是"按 key 还是按模型"，而是：这一次 429，是哪一层返回的？

一次请求穿过的四层

第一层：你的聚合站 key

这一层通常按 key 维度计数，常见口径有时间窗口内的请求数（RPM）和 token 数（TPM）。因为一把 key 能调所有模型，有些实现会再做一层"按 key × 模型"的细分桶，防止一个模型把整把 key 的额度吃光。

这一层的特征是：换模型可能有用，换 key 一定有用。

第二层：聚合站网关自身的保护

聚合站要防的是全局过载，而不是针对某个用户。这类限流往往按来源 IP、按账号、按全局并发数生效。

特征：换 key 也没用，过一会儿自己就好了。

第三层：上游厂商的账号/项目层

聚合站调上游用的是它自己的账号或项目。上游厂商给你（这里指给聚合站）的配额是共享的，别人跑得凶，你也会被连累。

这一层还可能细分：有的厂商按组织/项目限，有的按模型单独限，有的对特定模型（比如推理型、长上下文型）有更严的并发上限。

特征：同一时刻别人也在报错，或者只有某几个模型报错。

第四层：账号池的并发调度层

聚合站通常维护一个上游账号池，请求被分配到某个账号上。如果某个账号正在被占用、正在冷却、或刚被上游短暂拒绝，调度器可能直接返回一个 429，而不是排队。

特征：同样的请求，重试一次可能就过了。

判断 429 来自哪一层：五个可观察信号

1. 看响应头

上游厂商（尤其是 OpenAI 兼容风格的接口）常常在 429 里带上限流相关的头，例如剩余额度、重置时间、当前窗口的限额。如果这些头存在且看起来是厂商格式，多半是第三层。

如果响应头干净得像刚出厂，只有一个 Retry-After 或者什么都没有，更可能是聚合站自己生成的。

2. 看错误体结构

上游原样透传的错误体通常有固定的 JSON 结构：一个 error 对象，里面有 type、code、message。聚合站自己生成的错误体往往更简单，或者文案是中文大白话。

3. 看错误文案的措辞

• 提到 "organization"、"project"、"account" —— 第三层。
• 提到 "your API key"、"rate limit for this key" —— 第一层。
• 提到 "upstream"、"provider"、"渠道"、"上游" —— 第二或第四层。
• 提到并发数、排队、无可用通道 —— 第四层。

4. 做变量控制

这是最可靠的方法，一次只改一个变量：

• 换模型、不换 key：如果只有某个模型 429，是模型维度的桶（第一层的细分桶或第三层的模型级限额）。
• 换 key、不换模型：如果新 key 正常，是第一层。
• 等 30 秒再试同一个请求：如果必过，多半是窗口型限流；如果还是不过，可能是账号级冷却。
• 换个时间段试：如果高峰期报错、低谷期正常，偏向第二或第三层的共享容量问题。

5. 看复现范围

• 只有你报错 → 你这一层。
• 只有你在这个模型上报错 → 模型维度的桶。
• 社区/群里同时多人报错 → 上游或网关层。

遇到 429 的处理顺序

1. 先退避重试，用指数退避加随机抖动。很多 429 是瞬时的，重试就过。
2. 不要盲目并发重试。429 期间加并发只会把窗口填得更满，还可能触发更严格的惩罚。
3. 读 Retry-After。有就按它来，没有就用一个合理的默认退避序列。
4. 区分可重试和不可重试。配额耗尽型（需要等到窗口重置）和拥塞型（可以立刻重试）处理方式不同。
5. 分流关键请求。把非关键的批量任务挪到低峰期，给关键路径留出余量。
6. 多模型做降级。如果只有某个模型被限，切到同类模型；聚合站一把 key 打通多个模型的价值在这里体现得最明显。

设计上的几个提醒

不要把限流当成错误，要当成信号。 应用层应该能和限流共存：队列化、降级、异步化，而不是让用户看到报错。

按 key 的配额和按模型的配额要分开考虑。 如果你的业务同时跑对话和批处理，最好用不同的 key，避免批处理把交互式请求的额度吃掉。

记录每次 429 的元数据。 时间戳、模型、响应头、错误体、当时的并发数。没有这些数据，你永远只能靠猜哪一层在卡你。

理解聚合站的成本结构有助于理解它的限流。 用户按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1（优质渠道 ×1.2）返 USDC，这意味着平台在上游账号上是需要精打细算的，限流策略会倾向于保护整体可用性而不是单用户体验。这不是缺陷，是这类架构的自然结果。

小结

一把 key 通向六家厂商，中间夹着四层限流器。判断 429 归属的核心方法是一次只改一个变量，配合响应头、错误体文案和复现范围交叉验证。绝大多数时候，你不需要知道确切的限流参数，只需要知道"这是不是我能控制的"——能控制的（换 key、换模型、降并发、错峰）就动手，不能控制的就退避重试。