在一把 key 上并发打 50 个调用：哪个后端先返 429、怎么排队绕开

为什么并发爆发时后端反应不同

LLM API 聚合站把同一把 key 的请求路由到不同厂商的后端（Claude、GPT、DeepSeek、Qwen、GLM、Kimi 等）。每个后端有各自的限流策略：有的按每分钟请求数（RPM）限制，有的按每分钟 token 数（TPM）限制，有的对突发并发更敏感，有的对长上下文请求单独设限。因此同时打出 50 个调用时，先返 429 的往往是那个当前配额最紧或对突发最敏感的后端，而不是聚合站本身。

聚合站的角色是转发和计费（按官方价 ×1.3 扣费），它不会替你抹平各后端的差异。所以“先返 429”既可能是聚合站层面的路由保护，也可能是某个后端直接拒绝。区分这两者，是设计客户端排队层的第一步。

如何摸清各后端的限流反应

不要靠猜，用受控的小规模实验观察 429 的分布。

• 单后端基线：固定一个模型，以递增并发（例如 1、2、5、10）发送短请求，记录出现 429 的并发阈值和响应头里可用于重试的提示（如 Retry-After、X-RateLimit-* 这类头，若存在）。
• 多后端对比：对同一批模型分别做同样实验，记录各自开始返 429 的并发点和恢复时间。你会发现不同后端差异明显，这决定了排队层要按后端分别配置。
• 观察错误结构：记录 429 的响应体与状态码来源。有些是后端直接返回，有些是聚合站网关返回，二者的重试语义可能不同。
• 注意长请求：长上下文或流式请求更容易触发 token 维度的限制，实验时要和短请求分开测。

实验时控制总量，避免用真实业务流量做压测。

客户端排队层的基本结构

目标是让客户端主动尊重每个后端自己的节流，而不是等 429 出现后再补救。核心是把“一把 key 打所有后端”拆成“每个后端一个队列”。

1. 按后端分桶：以模型或后端标识为键，维护独立的并发信号量和速率窗口。一个后端的限流不影响另一个后端的队列。
2. 两级闸门：先过并发闸门（同时最多 N 个在途请求），再过速率闸门（单位时间最多 M 个请求或 token）。两个阈值都从实验里得到，而不是拍脑袋。
3. 公平调度：当多个业务共享一把 key 时，用简单的轮询或加权轮询在各后端队列间取任务，避免某个业务把某个后端的配额吃光。
4. 可观测：为每个后端记录在途数、排队长度、429 计数和重试次数，方便后续调参。

遇到 429 怎么排队绕开

429 不是错误，是节流信号。正确的处理是退避重排，而不是立刻换后端硬打。

• 优先读 Retry-After：响应里给了等待时间就按它等；没给就用指数退避加随机抖动，避免同一时刻大量请求同时重试。
• 重试回到原队列：把请求放回对应后端的队列尾部，而不是插队，保持整体公平。
• 限制重试次数：超过阈值后向上层报错或降级到备用模型，避免无限重试放大压力。
• 区分可重试与不可重试：429 和部分 5xx 可重试，参数错误这类 4xx 不应重试。
• 跨后端绕行要谨慎：把一个后端的排队请求转到另一个后端，只在业务允许模型替换时使用，并且要计入目标后端的队列配额，否则只是把 429 转移了位置。

常见误区

• 用全局并发数管所有后端：各后端配额不同，全局阈值要么太保守浪费吞吐，要么太激进导致某个后端先崩。
• 把 429 当故障直接告警：节流是预期行为，应作为指标而非事故。
• 重试不带抖动：同步重试会形成新的并发尖峰，反而更容易再次 429。
• 忽略 token 维度：只按请求数排队，长请求仍可能触发 TPM 限制，需要对长请求单独限制并发。

小结

在一把 key 调多后端的场景里，限流是每个后端各自的属性。先用受控实验摸清各后端的 429 阈值和恢复行为，再在客户端按后端分桶、两级闸门、带抖动的退避重排，就能在尊重各后端节流的前提下稳定地打出并发。聚合站按官方价 ×1.3 计费，贡献 key 按 ×1.1（优质 ×1.2）返 USDC，这些计费规则与限流无关，排队层要解决的是吞吐与稳定性，而不是成本。