OpenAI、Anthropic与Gemini的LLM速率限制对比解析

生产环境调用大模型API时，HTTP 429错误几乎是每个工程师都会遇到的「老朋友」。当请求量或Token吞吐超过供应商设定的并发阈值，API就会拒绝服务。单轮聊天脚本很少触发限制，但多Agent流水线、并行提取任务和实时用户流量常常会瞬间打满默认配额。

本文基于Dev.to技术博客的深度分析，系统梳理OpenAI、Anthropic和Google Gemini三大 provider 在速率限制机制上的差异，并探讨如何从客户端和服务端两个层面构建一套「零429」的LLM调用架构。

LLM Rate Limits Across OpenAI, Anthropic, and Gemini

现代LLM速率限制的工作原理

大模型的速率限制是多维度的吞吐量约束，在项目或组织层面强制执行。与传统REST API仅按每秒请求数计算配额不同，LLM provider会同时从多个维度评估消耗：

RPM（每分钟请求数）：滚动60秒窗口内的HTTP调用总数。
TPM（每分钟Token数）：该窗口内所有并发请求处理的输入和输出Token总量。
RPD（每日请求数）：每日操作总量的宏观上限，通常在UTC或太平洋时间午夜重置。
TPD或消费限额：固定间隔（如滚动10分钟）内的货币或用量上限，防止账单失控。

只要任一维度触顶，请求就会被拒绝并返回HTTP 429状态码——即使其他维度还有大量余量。例如，向允许200,000 TPM的端点发送一个150,000 Token的提示可以成功，但两秒后第二个60,000 Token的并发请求就会立即触发429，哪怕应用只消耗了500 RPM中的2个。

更关键的是，provider不会把每分钟限制当作硬性批量计数器。它们执行的是带短期速率平滑的令牌桶或漏桶算法。一个60 RPM的账户大致相当于每秒1个请求，如果在1秒内发出15个并发调用，令牌桶的突发容量会立即耗尽，即使前59秒的总量为零。

令牌桶与漏桶算法是理解速率限制突发行为的关键。令牌桶维护一个容量为 C 的桶，以恒定速率 r 向桶内添加令牌，每个请求消耗一定数量的令牌；当桶满时新令牌溢出丢弃。桶中积累的令牌数即为允许的瞬时突发量——这正是 60 RPM 账户能在 1 秒内打出 15 个并发请求的原因：前 59 秒的空闲让桶积满了突发配额。漏桶算法则相反，请求先进入队列，以固定速率流出，对突发流量有平滑作用但不允许突发。主流云厂商和 LLM provider 多采用令牌桶或其变体（如带速率平滑的令牌桶），因为它们既保证长期平均速率，又容忍合理的瞬时突发。理解这一机制后，客户端在建模本地配额时也必须模拟桶的容量与补充速率，而非简单地按每分钟请求数均摊。

滚动窗口是另一个容易被误解的概念。与固定窗口（每分钟 0 秒清空计数器）不同，滚动 60 秒窗口意味着任意时刻的配额判断都回看过去整整 60 秒。固定窗口在窗口边界处允许高达两倍的突发流量（前一窗口末尾加后一窗口开头），而滚动窗口消除了这一漏洞，但也使客户端的本地预测更为复杂，需要维护请求时间戳队列而非简单计数器。这解释了为何客户端令牌桶校准必须依赖 provider 返回的剩余量和重置时间，而不能仅靠本地计数推断。

三大Provider速率限制机制对比

理解上游provider的机械差异，是编写客户端拦截器或配置网关路由策略的前提。每家provider通过非标准响应头报告容量指标，资源耗尽的评估方式也各不相同。

OpenAI：合并Token计量

OpenAI API按模型系列衡量RPM和合并TPM。发送请求时，OpenAI会检查估算的提示Token加上请求的max_tokens是否在剩余TPM池内。在补全请求中设置过高的max_tokens会提前预留预算，导致生成内容很短时也触发429。

OpenAI在每次HTTP 200和429响应中都会返回诊断头，包括x-ratelimit-remaining-requests（当前窗口剩余请求整数）、x-ratelimit-remaining-tokens（限流前剩余Token数）、以及x-ratelimit-reset-requests和x-ratelimit-reset-tokens（重置剩余时间，格式为20ms或6m0s这样的时长字符串）。429时还会附带retry-after头，指定客户端必须暂停的秒数。

Anthropic：输入输出Token分离

Anthropic Messages API将Token追踪拆分为输入Token每分钟（ITPM）和输出Token每分钟（OTPM），外加标准RPM。这种区分反映了LLM生成的不对称计算成本：自回归生成Token远比摄入输入上下文更耗算力。

Anthropic按模型系列隔离限制：Claude 3.5 Sonnet的请求与Haiku或Opus使用不同的桶。更关键的是，Anthropic的提示缓存机制中，缓存读取Token不计入ITPM配额。对于长对话Agent，建立稳定的缓存前缀能显著降低速率限制压力。

其响应头格式也不同：anthropic-ratelimit-input-tokens-remaining报告输入Token余量，重置头使用RFC 3339时间戳（如2026-10-15T10:05:00Z），而非时长字符串。

提示缓存（Prompt Caching） 是 Anthropic 和 Google Gemini 都支持的一项优化机制，对速率限制有直接缓解作用。其原理是：当多个请求共享相同的前缀（如固定的系统指令、少样本示例、长文档上下文）时，provider 将这些前缀的 KV 缓存持久化，后续请求命中缓存后无需重新计算该部分，从而大幅降低计算成本和延迟。Anthropic 明确规定缓存读取 Token 不计入 ITPM 配额，这意味着一个长对话 Agent 只要保持稳定的缓存前缀，其每轮实际消耗的输入配额可能远低于原始上下文长度。要命中缓存，提示必须满足最小可缓存长度（Anthropic 通常为 1024 Token），且前缀必须逐字节一致——任何微小的措辞变化都会导致缓存失效。因此在构造 Agent 提示时，应将稳定的系统指令和静态知识放在最前，将动态内容（用户输入、检索结果）放在最后，以最大化缓存命中率。

需要区分的是，这里的 ITPM（输入 Token 每分钟）和 OTPM（输出 Token 每分钟） 是独立配额，而非合并计量。自回归生成每个输出 Token 都需要一次前向传播，计算成本远高于并行处理的输入 Token，因此 provider 将两者分开限制。这意味着即使你的输入配额充足，大量生成长文本仍可能触顶 OTPM 而被限流。客户端在建模时需要对输入和输出分别维护令牌桶，并特别注意 max_tokens 参数会预留输出配额。

Google Gemini：项目级共享配额

Google Gemini API的速率限制严格在Google Cloud项目层面运作，而非按单个API密钥划分。这意味着所有后台任务、本地开发环境和生产微服务共用同一个配额桶。

Gemini强制执行RPM、TPM和每日RPD配额，付费层还有滚动10分钟消费限额。当配额耗尽时，API不会在成功调用上返回自定义头套件，而是抛出包装在HTTP 429响应中的gRPC风格RESOURCE_EXHAUSTED错误。客户端必须检查错误响应负载或提取标准retry-afterHTTP头来确定退避时长。

为什么朴素指数退避在生产环境中失效

客户端SDK文档的标准建议是用带抖动的指数退避循环包装请求：遇到429后，睡眠$t = \min(t_{\max}, 2^{\text{attempt}} \times \text{base}) + \text{jitter}$，最多重试三到四次。这种方式能防止单线程命令行脚本崩溃，但在持续生产负载下会因三个数学原因失效。

1. 羊群效应与并发放大

当高并发集群（如50个微服务Pod或Celery工作节点）撞上共享TPM上限时，所有50个worker同时收到429。即使引入随机全抖动，集群仍保持步调一致。抖动窗口一过，50次重试在令牌桶部分补充的瞬间同时涌向上游provider，立即耗尽新补充的Token，产生另一波429，并使总请求队列翻倍。

2. 尾部延迟爆炸与上游超时

指数退避通过将配额赤字转化为客户端等待时间来吸收速率限制。如果上游provider需要30秒退避来补充400,000 Token的提示配额，下游HTTP客户端、API网关或边缘负载均衡器（如Cloudflare或AWS ALB）会在重试成功之前就因504 Gateway Timeout断开连接。

3. 缺乏Token感知的盲目执行

标准重试算法不计算Token成本。如果应用试图处理60,000 Token的上下文文档，而上游provider滚动桶中只剩10,000 Token，那么三秒后重试在数学上注定失败。客户端需要的是主动流控，而非被动道歉。

羊群效应（Thundering Herd） 是一个经典的分布式系统问题，最初用于描述大量进程在同一时刻争抢同一资源的现象。在速率限制场景中，它的触发链条是：所有客户端因共享配额同时失败 → 同时进入退避 → 因使用相似或相同的退避公式而在相近时刻同时重试 → 同时再次打满刚补充的配额 → 再次同时失败。加入随机抖动（jitter）只能缓解而不能根除这一问题，因为当并发客户端数量足够大时，即使抖动窗口内均匀分布，单位时间内到达的请求数仍可能超过配额补充速率。真正的解法是让重试决策基于全局共享的配额状态而非各自独立计时，这正是集中式网关存在的意义。

尾部延迟（Tail Latency） 指请求延迟分布中高分位（如 P99、P99.9）的延迟值。在调用链中，上游的偶发慢请求会沿着调用链逐层放大：一个底层服务的 P99 延迟经过多层聚合后，可能变成整体请求的 P50 延迟。速率限制场景下的尾部延迟问题在于，指数退避把本应在上游快速解决的配额不足问题，转化为客户端的长时间挂起。当退避时间接近或超过中间层（网关、负载均衡器）的超时阈值时，连接会被中间层提前切断，导致重试永远无法完成，客户端陷入「重试-超时-再重试」的死循环，同时继续占用并发连接资源。

主动式流控（Proactive Flow Control） 与被动重试的根本区别在于控制流的方向。被动模式是「先发请求，失败了再退避」；主动模式是「发送前先确认本地配额充足，不足则排队等待」。主动模式需要三个能力：准确的请求成本预估（本地分词）、实时的配额状态（本地令牌桶 + provider 响应头校准）、以及请求调度器（优先级队列和精确定时器）。这实际上是经典网络拥塞控制在应用层的移植。

设计客户端速率限制引擎

要让应用客户端永不生成HTTP 429状态码，工程团队必须反转控制流：在网络包发出之前，速率限制必须在本地被追踪、预算和调度。

分层令牌桶算法

核心引擎依赖线程安全的本地令牌桶算法，同时追踪请求和Token。令牌桶最大容量为$C$，以每秒$r$个Token的速率持续补充。在出站请求发出前：

客户端使用本地tokenizer（如OpenAI模型的tiktoken）计算精确的提示Token数。
客户端同时检查请求桶（$C_{\text{rpm}}, r_{\text{rpm}}$）和Token桶（$C_{\text{tpm}}, r_{\text{tpm}}$）。
如果Token不足，线程不被派发，而是停放在优先FIFO队列中，带有精确的唤醒定时器：$\Delta t = \frac{\text{Tokens Required} - \text{Tokens Available}}{r}$。
收到API响应后，客户端解析返回的速率限制头，用provider服务端状态校准本地时钟。

相比被动等待429后重试，这种主动式客户端治理器能在请求发出前就知道「现在能不能发」，从根本上消除429错误。

基础设施层的集中式限流方案

客户端令牌桶包装器对独立进程很有效，但跨多个应用容器的分布式架构会破坏孤立的客户端治理器。如果Kubernetes中运行10个容器实例，每个维护自己的令牌桶而没有进程间协调，整个集群会经常耗尽上游provider配额。

将速率限制执行移到集中式基础设施层可以解决这个问题。开源AI网关Bifrost作为统一入口拦截LLM调用，在多个密钥和provider之间仲裁速率限制，并暴露OpenAI兼容API作为即插即用替代方案，应用只需更改一个base URL。据其公开基准测试，Bifrost在每秒5,000请求的持续负载下仅增加11微秒开销。

Bifrost的核心能力包括：

虚拟密钥与预算执行：将上游供应商API凭证与内部应用消费者解耦，通过sk-bf-*虚拟密钥实施分层预算控制（客户→团队→虚拟密钥→上游provider配置），每层可独立设置RPM和TPM阈值。
多密钥负载均衡：自动在API密钥之间加权路由。如果密钥A返回的响应头显示剩余Token低于10%，Bifrost会在亚微秒内将后续调用路由到密钥B。
跨provider回退：当上游provider返回429或5xx错误时，Bifrost将请求重试到预配置的二级模型或provider。例如，路由到claude-3-5-sonnet的提示在Anthropic主账户受限时，会被转换为OpenAI兼容格式并派发到Azure OpenAI或AWS Bedrock上的gpt-4o。
语义缓存：存储先前请求的提示和补全结果，当后续请求具有高语义相似度时直接从缓存返回，同时消除请求数和Token消耗。

虚拟密钥（Virtual Key） 是企业级 AI 网关的核心抽象。传统做法是每个应用直接持有上游 provider 的真实 API 密钥，这带来三个问题：密钥泄露风险、无法细粒度审计、配额无法跨应用协调。虚拟密钥用网关签发的内部密钥（如 Bifrost 的 sk-bf-* 格式）替代真实密钥，应用只与网关通信，由网关在出口侧注入真实凭证。这使得网关可以在同一次请求路径上执行多项治理：按虚拟密钥追踪用量、实施分层预算（客户→团队→虚拟密钥）、在多个上游密钥间轮换以规避单密钥限额、以及记录完整的审计日志。当某个虚拟密钥超限时，只需在网关侧限流或降级，无需触碰应用代码。

多密钥负载均衡与跨 provider 回退 共同构成了配额对冲策略。由于每个 API 密钥（或每个 GCP 项目）拥有独立配额，池化多个密钥等价于把总配额相加。网关通过解析每个密钥响应头中的剩余量，动态调整路由权重——剩余量低的密钥被降权，剩余量高的密钥承接更多流量。当所有密钥或整个 provider 都返回 429 时，回退机制将请求转换格式后转发到备用 provider（如从 Anthropic 切到 Azure OpenAI）。这种回退需要处理不同 provider 的 API schema 差异、Token 计量差异和内容策略差异，是自建方案的主要复杂度来源，也是成熟网关的核心价值。

语义缓存 超越了传统精确匹配缓存。它基于嵌入向量计算请求语义相似度，当新请求与历史请求相似度超过阈值时直接返回缓存结果。这对速率限制的意义是双重的：既减少了 RPM 计数，又消除了 TPM 消耗。但语义缓存需谨慎应用——对事实性问答可能返回过时或近似错误的答案，通常只适用于高频重复查询、模板化任务或对精度要求不高的场景。

零429架构检查清单

要在高吞吐企业部署中实现零429错误，团队应实施以下架构检查清单：

传输前计算Token：运行本地BPE分词来预算Token分配，而非基于字符数猜测。
绝不发送无界max_tokens：始终将max_tokens限制在现实的生成边界内，防止provider过度预留TPM容量。
解析provider速率限制头：在每次成功的HTTP 200响应上摄入剩余请求和Token计数，动态校准本地桶填充率。
部署集中式AI网关：将多密钥池化、跨provider回退和共享Token追踪卸载到基础设施层。
实施提示前缀缓存：用稳定的系统指令构造Agent提示，确保缓存命中绕过ITPM配额。
解耦交互式和后台任务：将批处理任务（数据提取、评估流水线、离线嵌入）隔离到专用API密钥或严格低优先级的虚拟密钥上。

常见问题

LLM API中的HTTP 429状态码是什么？

HTTP 429表示应用在每分钟请求数、每分钟Token数或每日使用配额上超过了provider限制。LLM provider返回此错误是为了保护共享推理集群免受计算饥饿，并执行商业账户层级阈值。

为什么指数退避在LLM流量高峰时失效？

标准指数退避在流量高峰时失效，是因为重试请求在缺乏Token感知的情况下重新进入队列。当多个并发客户端同时触发速率限制时，退避导致它们步调一致地重试，立即耗尽新补充的Token，引发跨应用集群的级联429错误。

RPM和TPM有什么区别？

RPM衡量60秒窗口内发起的HTTP API请求原始计数，与负载大小无关。TPM衡量这些请求处理的输入和输出文本Token总量。系统可以在远低于RPM限制时因TPM触发速率限制。

提示缓存有助于降低速率限制吗？

是的，提示缓存在Anthropic和Google Gemini等平台上显著降低速率限制压力。Anthropic不将缓存读取Token计入ITPM限制，允许具有稳定提示前缀的应用以更高吞吐量处理而不触发429错误。