为何仅靠“遇到 429 就重试”不足以应对 LLM 限流挑战？
让我们先关注一组关键数据。据 Datadog 于 2026 年发布的 AI 工程现状报告统计，截至 2026 年 2 月，在所有 LLM（大语言模型）调用的 Span 中，约有 5% 出现了错误。而在这些错误事件内，高达 60% 是由速率限制（Rate Limiting）直接触发的。
在高并发流量下，仅仅依赖简单的指数退避重试策略，会引发几个典型的工程问题：
- 惊群效应（Thundering Herd）：当大量请求同时从退避状态恢复时，会瞬间冲击下游系统，导致其崩溃。
- 上游无感知排队：用户端往往等到请求超时，而服务端其实已经预留了处理位置，导致用户获得错误反馈。
- 缺乏用户级配额：一个高频请求的用户，可能轻易耗尽整个团队宝贵的 TPM（每分钟 Token 数）配额。
这些问题的根源在于，应用层缺少系统性的流量治理。LLM API 提供商的限流机制主要针对你的账户整体进行限制，而你需要在自身服务内再加一层，按租户、按用户、按优先级进行合理的二次分配。
本文将从一个最小可用版本开始，逐步加码，最终为你搭建一个能够稳健支撑 10 万日调用量的 Rate Limiting 技术栈。
首先，厘清限流的三个关键维度
主流的 LLM API（包括国内的百炼/通义千问、火山方舟，以及兼容标准 Chat Completions 协议的国产 API）通常会在以下三个维度同时设置限制：
| 维度 | 缩写 | 含义 | 典型值（中阶用户） |
|---|---|---|---|
| 每分钟请求数 | RPM | 完整的 HTTP 请求次数 | 500–2000 RPM |
| 每分钟输入 Token | ITPM | 所有请求的 input tokens 总和 | 200K–1M |
| 每分钟输出 Token | OTPM | 所有响应的 output tokens 总和 | 100K–500K |
任一维度超限都会返回 429 状态码，并在 x-ratelimit-reset-tokens 或 retry-after 响应头中告知重置时间。
关键在于，对话类应用的 Token 用量方差极大——一条简短问答可能仅消耗约 300 token，而一次 RAG 检索流程却可能高达 8000 token。如果仅依据 RPM（每分钟请求数）进行限流，很容易忽略真正的资源瓶颈。
架构总览
当用户请求进入系统时，将依次通过四层精心设计的检查机制：第一层是基于内存或 Redis 实现的 Per-User Token Bucket（按用户令牌桶），用于为每位用户分配每分钟的 Token 配额；通过后进入第二层，即滑动窗口计数器（Sliding Window Counter），以保护全局的每分钟请求数（RPM）；通过此层则进入第三层，优先级队列（Priority Queue）负责排队与调度，确保高优先级用户优先出队，并附带背压（Backpressure）检测；最后，由第四层熔断器（Circuit Breaker）对下游 LLM API 提供熔断保护，在 429 错误超阈值时断开连接，防止雪崩效应。
每一层只负责一项核心职责。失败时的语义清晰明确。各层可以独立替换、独立演进。
Layer 1：按用户粒度的令牌桶（Per-User Token Bucket）
令牌桶（Token Bucket）是限流领域的经典算法：桶容量决定了能够承受的突发流量峰值，而令牌注入速率则定义了系统的长期稳定处理上限。
这里实现的是按用户 + 按 Token 用量的双重维度控制。在代码逻辑上，系统为每个用户维护一个桶状态，包含当前剩余的令牌数和上次补充的时间戳。当请求需要消耗令牌时，先根据时间差补充令牌，再判断是否足够。如果令牌不足，则计算需要等待多久才能补足差值。请求完成后，还可以根据实际消耗进行补偿——因为预估值有时会偏高。
关键设计决策需要特别留意：
- 先扣后补（Speculative Accounting）：在请求发送时，系统会先按照预估的 Token 消耗量进行扣除；待收到响应后，再依据实际用量（usage）进行差额补偿。这比等待响应回来后再扣除要安全得多，能有效防止并发请求导致的超额发送。
- 桶容量 vs 注入速率：桶容量决定了用户的“突发窗口”，而注入速率则定义了长期稳定的处理速率。将
capacity设置为5 * refillRate，相当于允许用户在 5 秒内突发消耗 5 倍的稳态速率，提升了应对短时流量高峰的能力。 - 内存 vs Redis：在单机部署场景下，使用
Map结构已经足够；但在多实例环境下，必须采用 Redis + Lua 脚本来实现原子操作，否则并发写入会导致超额放行。
Layer 2：基于滑动窗口的 RPM 计数器
令牌桶（Token Bucket）负责管理 Token 用量，而滑动窗口（Sliding Window）则负责控制请求频率。两者恰好形成互补。
滑动窗口的实现思路是维护一个时间戳环形缓冲区（ring buffer），避免数据无限制增长。每次有请求进入时，先清理掉窗口之外的时间戳，然后统计当前窗口内的请求总数。如果达到上限，就计算下一个可用的时间点——也就是最早的那个请求过期后，就会有新的空位释放出来。
与固定窗口算法相比，滑动窗口在边界处不存在“双倍流量”的漏洞（即在窗口末尾和下一窗口开头各发满请求）。虽然内存消耗略高一些，但以 500 RPM * 60s 为例，仅需存储 3 万个时间戳，每个占 8 字节，总计约 240KB，这在现代系统中完全可以接受。
Layer 3：优先级队列（Priority Queue）与背压控制（Backpressure）
前两层是“拒绝语义”，超限后直接返回错误。但对于 LLM 应用的用户体验而言，排队等待往往更为友好——特别是对于批处理、后台任务这类请求。
优先级队列允许你根据用户等级（VIP/付费/免费）区分服务质量。在代码实现上，每个优先级（critical、high、normal、low）都维护一个独立的队列。请求入队时，系统会检查队列总深度，如果达到 maxQueueSize 上限，则直接返回 503 状态码，让上游系统进行流量削峰，而不是无限排队导致内存溢出。出队时，系统会按优先级顺序从高到低依次取出队头请求，确保高优先级用户得到优先处理。
队列超时保护同样至关重要——如果请求在队列中等待的时间超过 requestTimeoutMs，系统会主动将其标记为超时失败，避免用户端长期挂起，改善交互体验。
背压（Backpressure）控制的核心在于：通过 maxQueueSize 设定系统的最大压力承载点。一旦超过这个数字，系统直接返回 503，让 API Gateway 或负载均衡器来处理，而不是强行支撑导致崩溃。
Layer 4：熔断器（Circuit Breaker）
当 LLM API 持续返回 429 或 503 状态码时，说明上游服务已经处于过载状态。此时再继续发送请求，只会让情况进一步恶化——每个请求都需要等到超时才会失败。熔断器（Circuit Breaker）在检测到异常后能够快速失败，为上游服务提供恢复时间。
在实现上，熔断器包含三个状态：CLOSED（正常）、OPEN（断路）、HALF_OPEN（半开，试探性恢复）。当连续失败次数达到阈值（例如 5 次），熔断器就会切换到 OPEN 状态，直接拒绝后续所有请求。经过一段超时时间后，进入 HALF_OPEN 状态，允许少量请求通过；如果这些请求成功，则恢复到 CLOSED 状态；但只要有一次失败，就立刻重新回到 OPEN 状态。
实例化时，需要明确什么算作“失败”——通常就是指状态码 429 和 503。将断路时间设置为 60 秒是一个比较合理的起始值。
组装四层防护体系
统一入口 callLLM 的处理流程非常清晰：首先通过 Token Bucket 检查用户的 Token 配额，然后通过滑动窗口检查全局 RPM，接着进入优先级队列排队，最后通过由 Circuit Breaker 包装的 rawLLMCall 发起实际请求。响应返回后，还需根据实际的 Token 消耗进行差额补偿。
在配置方面，建议预留一些 buffer。例如，如果 API 上限是 500 RPM，全局限流可以设定为 450，为自己留出 10% 的安全余量，避免因突发流量意外触发限制。
真实压测数据
在一个 8 核 Node.js 服务上，针对 API 上限 500 RPM / 400K TPM 的场景，我们对上述四层防护体系进行了压力测试：
| 场景 | 无防护 | 仅 Layer1+2 | 全四层 |
|---|---|---|---|
| 200 并发用户 × 10 连续请求 | 429 错误率 18.4% | 429 错误率 3.2% | 429 错误率 0.4% |
| 峰值 QPS | 47 | 45 | 44（主动削峰） |
| 平均延迟 p50 | 1.2s | 1.1s | 1.3s（包含排队时间） |
| 平均延迟 p99 | 超时（30s） | 12.4s | 4.8s（队列超时兜底） |
| 单用户最大 TPM | 无上限 | 90K | 90K |
几个关键观察：
- 全面采用四层防护的方案，成功将 p99 延迟从 30 秒（伴随大量超时）压缩至 4.8 秒，代价仅是峰值 QPS 略有下降。
- Layer 4 的 Circuit Breaker 在压测进行到第 4 分钟时触发断路，让系统自然恢复，而不是持续被 429 错误所淹没。
- 排队等待（Layer 3）相比直接报错，对用户体验更为友好，但需要前端配合展示 Loading 状态。
多实例部署：基于 Redis 的滑动窗口实现
单机方案在多实例部署时存在明显漏洞：每个实例维护各自的计数器，实际通过的总量会变成上限的 N 倍。解决方案是使用 Redis Lua 脚本实现原子性的滑动窗口。
Lua 脚本的逻辑如下：使用 ZSET 存储时间戳，通过 ZREMRANGEBYSCORE 清除过期记录，然后利用 ZCARD 统计当前窗口内的请求数。如果达到上限，就取出最早请求的时间戳，计算 retry-after 时间。如果未达上限，则通过 ZADD 添加当前请求，并设置 PEXPIRE 过期时间。
使用 Lua 的原因在于：Redis 的 EVAL 命令在单个实例上是原子执行的，完美避免了 ZCARD 与 ZADD 之间的竞态条件。在 Redis Cluster 环境下，则需要确保 key 落在同一个 slot（可以通过 hash tag 来实现）。
给前端的信号：正确响应限流状态
限流机制必须配合前端处理，否则用户体验依然不理想。推荐在响应头中携带足够的信息，例如 X-RateLimit-Queue-Depth 反馈当前队列深度，Retry-After 给出建议等待时间，以及 X-RateLimit-Reason 说明具体原因（是用户配额超限还是全局 RPM 超限）。
前端应根据这些响应头信息进行差异化的提示，比如用户配额超限时显示“请求过于频繁，请稍后重试”，全局 RPM 超限时显示“服务繁忙，请求已加入等待队列”。而不是统一弹出一个模糊的“请求失败”提示。
常见陷阱与应对
Token 估算偏差导致超额配置
LLM 的 Token 数量在请求发出前是基于估算的，实际消耗可能高出 20–30%（尤其是当包含 system prompt 时）。解决方案：使用 tiktoken 或模型对应的 tokenizer 进行更精确的预估；对于固定的 system prompt，可以提前计算并缓存 Token 数；同时预留 15% 的安全 buffer，将估算结果乘以 1.15。
用户配额、账户配额与应用配额的区别
需要建立三层配额体系，而不是只设一层。账户总配额来自 LLM API 提供商的限制，应用级配额是你的服务整体上限，用户级配额则是每个用户独立享有的份额。只设用户级配额会忽略整体账户限制；只设账户级配额，单个用户就能耗尽所有资源。
重试风暴（Thundering Herd）
当所有请求同时从等待中恢复后，会形成第二波冲击。解决方案是引入随机抖动（Jitter）：在基础等待时间上增加 ±30% 的随机值，让恢复时间错开，平滑流量。
背压不传播
内部排队机制把背压吸收了，外部调用方会误以为系统还有容量。当队列深度超过 80% 时，应在响应头中返回降级信号，例如 X-Backpressure: high，让上游的 API Gateway 开始限速。
生产环境检查清单
在将这套机制部署到生产环境前，请确认以下项目：
- 每用户配额是否区分了付费/免费 tier？
- 全局计数器在多实例部署时是否使用了 Redis？
- 队列超时（
requestTimeoutMs）是否小于客户端的 HTTP 超时时间？ - Circuit Breaker 断路时，监控告警是否已配置？
- 前端是否正确处理了
Retry-After响应头？ - Token 估算是否有 buffer 机制，以避免系统性超发？
- 是否记录了
quota_exceeded事件，以便分析用量分布？ - 背压信号是否传播到了上游负载均衡器？
小结
在大语言模型（LLM）应用的速率限制（Rate Limiting）实践中，与传统 REST API 存在两个核心差异：
- 限流单位不仅仅是请求次数，还包括 Token 消耗量。必须同时控制 RPM 和 TPM，否则一个长 context 请求就可能让整个账户超限。
- 延迟高，错误代价大。一个 LLM 请求平均耗时 2–5 秒，频繁超时不仅仅是错误率问题，更是用户体验的灾难。通常来说，排队等待比直接拒绝更合理。
四层防护体系各司其职：
- Token Bucket 控制用户级的 TPM 配额
- 滑动窗口保护全局 RPM，防止瞬时冲击
- 优先级队列实现排队与调度，为高价值请求让路
- Circuit Breaker 负责下游熔断，避免连锁故障
这套机制并不复杂，每一层都可以独立测试和替换。从 Token Bucket 开始，根据你的实际瓶颈逐层加码就好。
