LLM API 限流对比：13 家服务商，2 个 SDK 从不重试 429
目录
本文调查了 13 个 LLM API，包括 10 家厂商以及 Bedrock、Vertex AI 和 Azure OpenAI。其中 4 个会在每次响应中返回剩余额度，Mistral 只返回一个剩余计数，另外 8 个在请求失败前不会提供任何信息。“429”实际对应四种情况：可以重试的限流、需要降低增速的加速限制、完全不该重试的配额或支出上限，以及服务商视情况以 429、503 或 529 报告的过载。客户端的行为不亚于服务商本身：OpenAI、Anthropic 和 Groq SDK 会重试 429 两次，但遇到超过 60 秒或 120 秒的 Retry-After 就会放弃；Google GenAI 和 Mistral SDK 则默认关闭重试。本文基于各官方 SDK 的源码，跨厂商梳理限流维度、token 计数规则、响应头、429 语义，以及每个官方 SDK 的实际行为。
TL;DR
- LLM API 通常按每分钟请求数和 token 数限流；Anthropic 将输入和输出分开计量，DeepSeek 只限制并发数。
- OpenAI、Azure 和 Bedrock 会预先扣除
max_tokens；Anthropic 不计 cache read；xAI 计入 reasoning token；在 Bedrock 上，Claude 5 每个输出 token 会消耗 10 个配额 token。 - OpenAI、Anthropic、Groq 和 Azure 会在每个 200 响应中返回剩余额度和重置时间；另有 8 个 API 没有记录任何相关响应头。
- google-genai 和 Mistral SDK 默认不重试 429；OpenAI、Anthropic 和 Groq 会重试两次，并将 Retry-After 上限设为 60 秒或 120 秒。
RPM、TPM 和其他限制分别是什么？
这些指标都表示一个时间窗口内允许发送的最大用量，但各服务商采用的组合不同：
| 分组 | 术语 | 含义及使用方 |
|---|---|---|
| 请求计量 | RPM、RPD、RPS、并发数 | 每分钟或每天的请求数，无论调用大小，每次调用都计为 1 次。RPS 通常是 RPM 除以 60，作为突发保护限制执行（xAI、Alibaba、Mistral、Azure）。并发数统计正在处理的请求，而不是某个窗口内的请求量，也是 DeepSeek 唯一的限制 |
| Token 计量 | TPM、TPD、ITPM、OTPM、消耗倍率 | 每分钟或每天的 token 数。部分服务商将其拆分为输入（ITPM）和输出（OTPM）。消耗倍率会先放大输出 token，再从配额中扣除（Bedrock）。哪些 token 会被计入，则由各服务商自行决定，下文会具体说明 |
| 其他单位的计量 | IPM、音频秒数、OCR 页数 | 图像模型每分钟处理的图像数（OpenAI、Gemini），每小时或每天的音频秒数（Groq、Mistral），以及文档 OCR 每分钟处理的页数（Mistral） |
| 时间窗口的执行方式 | Token bucket、加速限制 | Token bucket 持续补充额度，而不是在整分钟时重置。因此，即使总量没有超过每分钟上限，一次突发也可能耗尽额度（Anthropic；Alibaba 和 Azure 也描述了相同机制）。加速限制单独检查用量增长速度，即使尚未达到总量上限，突然放量也可能触发（Anthropic、OpenAI 的 slow_down） |
| 限额由什么决定 | 层级、支出上限或配额、预置容量 | 层级决定上述各项限额，通常根据付费用量或历史记录升级，而不是充值后立即提升。支出上限或每日配额限制的是费用或用量总额，不是速率，等待一分钟没有用。预置容量是按单位、按小时计费的预留吞吐量（Bedrock 和 Vertex AI Provisioned Throughput、Azure PTU）；此时 429 表示预留容量已满，而不是配额耗尽 |
页面上的数字是窗口上限，不是可以随意集中使用的额度。Anthropic 明确说明，60 RPM“可能按每秒 1 个请求执行”；Azure 也指出，“即使每分钟总量仍在限制内，1 秒或 10 秒窗口内的突发请求也可能触发 429”。
LLM API 按哪些维度限流？
几乎所有服务都按每分钟请求数和 token 数限流，但三大云平台并不会原样沿用底层模型厂商的规则。以下定义来自各服务商自己的页面，内容以 2026-09-03 和 2026-09-04 为准。
| 服务商 | 限流维度 | 限额如何增长 | 来源 |
|---|---|---|---|
| OpenAI | RPM、RPD、TPM、TPD、IPM、每分钟音频时长；Batch API 按排队中的输入 token 数限制队列 | 根据累计付款金额分为 Tier 1 到 5 | 限流说明 |
| Anthropic | 按模型类别设置 RPM、ITPM、OTPM；采用 token bucket 和加速限制 | 根据使用历史分为 Start、Build、Scale 层级 | 限流说明 |
| Google Gemini | RPM、TPM（输入）、RPD；图像模型另有 IPM | 免费层级，以及按每 10 分钟支出上限划分的 Tier 1 到 3 | 限流说明 |
| xAI | 每个模型分别限制 RPS（RPM / 60）和 TPM | Tier 0 到 4，以及 Enterprise | 限流说明 |
| Alibaba Model Studio | 每个模型分别限制 RPM 和 TPM，并以 RPS = RPM / 60、TPS = TPM / 60 作为突发保护 | 按模型设置；部分模型的 batch 请求不受限制 | 限流说明 |
| DeepSeek | 仅限制并发数：V4 Pro 为 500 个连接，V4 Flash 为 2,500 个连接 | 按模型固定 | 限流说明 |
| Mistral | 按模型和 workspace 设置 RPS、每分钟 token 数、每月 token 数 | 根据累计账单金额分为 Tier 1 到 4；“充值不会提高限流额度” | 用量和限制、帮助中心 |
| MiniMax | 每个模型分别限制 RPM 和 TPM；MiniMax M3 为 200 RPM 和 10M TPM | 联系销售 | 限流说明 |
| Moonshot Kimi | 并发数、RPM、TPM、TPD；Tier 0 为 1 个并发和 3 RPM，Tier 5 为 100 个并发和 300 RPM | 根据累计充值金额分为 6 个层级，从 $1 到 $3,000 | 限制说明 |
| Groq | RPM、RPD、TPM、TPD、ITPM、OTPM，以及每小时和每天的音频秒数 | 按模型设置 | 限流说明 |
| Amazon Bedrock | 每个区域、每个模型分别限制 RPM、TPM、TPD；TPD 默认值为 TPM x 1,440 | 通过 Service Quotas 管理，可申请提高；新账户初始额度较低 | 配额说明 |
| Google Vertex AI | 按量付费模式没有固定的项目级数值，而是使用共享资源池：“组织的历史支出决定 Usage Tier 和基准吞吐量（TPM）”，并尽力支持突发流量 | 按支出确定 Usage Tier；Provisioned Throughput“与共享 PayGo 资源池隔离” | Google Cloud 博客 |
| Azure OpenAI | 每个 deployment 分配 TPM，再由 TPM 推导 RPM（旧模型每 1,000 TPM 对应 6 RPM，当前模型每 1,000 TPM 对应 1 RPM）；PTU deployment 按利用率限制 | Quota Tier 0 到 6，自动升级 | 配额和限制、配额管理 |
其中两项根本不是分钟窗口。DeepSeek 限制的是打开的连接数。负载过高时，它不会直接拒绝请求，而是通过空行保持连接，streaming 模式下则发送 : keep-alive 注释，最长可持续 10 分钟。Vertex AI 的按量付费模式没有可查询的固定配额，429 只表示共享资源池当时容量不足。
哪些 token 会计入限额？
限流所统计的 token 与计费 token 并不相同。两者的差异会让实际容量只有页面标称值的一小部分，也可能是其数倍：
| 服务商 | 哪些 token 计入限额 | 影响 |
|---|---|---|
| OpenAI | 请求到达时，按 max_tokens 与根据 prompt 估算值中的较大者扣除：“如果 max_tokens 设置过高，即使实际响应短得多，用量也可能被高估”（Cookbook） | 如果答案只有 50 个 token，但 max_tokens 设为 4,000，仍会消耗 4,000 TPM |
| Azure OpenAI | 根据“prompt 文本和数量、max_tokens 参数、best_of 参数”估算，部分依据字符数；在 PTU deployment 上，“cached token 可享受 100% 折扣”（配额指南） | “限流可能比预期更早触发”；未设置 max_tokens 时，系统会自行估算 |
| Amazon Bedrock | 请求开始时扣除“输入 token 总数 + max_tokens”，结束后修正为 InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)，cache read 不计入。Claude 4.7 及更早模型的消耗倍率为 5x，Sonnet 5、Opus 5、Fable 5.1 和 GPT-5.6 系列模型为 10x，Claude 4.8 为 15x（token 计数说明） | 官方示例中，5x 模型的 1,000 个输入 token 和 100 个输出 token 会消耗 1,500 个配额 token，但计费量为 1,100 |
| Anthropic | ITPM 计入 input_tokens 和 cache_creation_input_tokens；cache_read_input_tokens“不计入 ITPM”。OTPM 按实际输出计算，“max_tokens 不影响 OTPM”（文档） | 官方示例中，2M ITPM 在 cache 命中率为 80% 时，每分钟可处理 10M 个输入 token |
| xAI | “请求消耗的所有 token 都计入 TPM：prompt token（文本、图像和音频）、completion token、reasoning token（reasoning 模型）以及 cached prompt token” | reasoning 会消耗用户不可见 token 的 TPM；缓存不会提高吞吐量 |
| Google Gemini | 输入 token | 输出长度不会消耗限额 |
| Alibaba、Mistral、MiniMax | 输入加输出 | |
| Kimi、Groq、DeepSeek、Vertex AI | 未说明 | Groq 分别计量 ITPM 和 OTPM；DeepSeek 没有 token 限制；Vertex AI 只公布 Usage Tier 的基准值 |
同一个请求在不同限额体系下的大小完全不同，上例从 800 到 6,000 个 token 不等。因此，将同一类工作负载分配到多个服务商的路由器，必须为每个服务商单独维护计量器。
每个服务商会返回哪些响应头？
4 个 API 会在每次响应中返回限流状态，Mistral 返回一个字段，另外 8 个只能由客户端自行计数。
| 服务商 | 正常响应中的响应头 | 格式说明 |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests、x-ratelimit-limit-tokens、x-ratelimit-remaining-requests、x-ratelimit-remaining-tokens、x-ratelimit-reset-requests、x-ratelimit-reset-tokens，以及 -project-tokens 三件套 | Reset 表示“距离限额重置还有多长时间”；429 响应包含 Retry-After |
| Azure OpenAI | 每次调用都返回同名的 6 个 x-ratelimit-* 响应头；429 时返回 retry-after-ms 和 retry-after | 如果 x-ratelimit-limit-tokens 低于配置的 TPM，说明“临时限流调整”正在生效 |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}，以及 tokens、input-tokens、output-tokens 各自对应的三件套；适用时还会返回 anthropic-priority-* 和 anthropic-fast-* | Reset 使用 RFC 3339；remaining 四舍五入到最接近的千位；tokens-* 三件套显示“当前生效的最严格限制” |
| Groq | x-ratelimit-limit-requests（每天）、x-ratelimit-limit-tokens（每分钟）、x-ratelimit-remaining-*、x-ratelimit-reset-*；“始终包含” | Reset 使用持续时间格式，如 "2m59.56s"、"7.66s"；retry-after 以秒为单位，仅在 429 时返回 |
| Mistral | X-RateLimit-Remaining | |
| Gemini、xAI、Alibaba、DeepSeek、MiniMax、Kimi、Bedrock、Vertex AI | 没有相关文档 | Gemini、Alibaba 和 Bedrock 会在错误 body 中说明原因；Kimi 记录了过载时的 Retry-After；如果服务返回 x-amz-retry-after，AWS SDK 会按毫秒读取 |
同一个字段有三种格式，这才是实际问题：OpenAI 使用持续时间，Anthropic 使用时间戳，Groq 使用 2m59.56s。客户端需要三套解析器，因此 SDK 通常只读取 retry-after。2026-09-03，我们分别向两个中间层发送了一次请求。某大型多服务商聚合平台在 200 响应中完全没有返回限流响应头，只在 429 时提供；Synthorai gateway 则同时返回 x-ratelimit-remaining-requests、x-ratelimit-reset-requests 和本次请求的成本。
429 表示什么，应该重试吗？
429 可能对应四种情况，其中只有两种应该重试：
| 含义 | 是否重试 | 各服务商如何表示 |
|---|---|---|
| 限流：超过某项限制 | 是，等待 Retry-After 或执行 backoff 后重试 | OpenAI 和 Anthropic 返回 429 rate_limit_error，Anthropic 同时带 retry-after；Gemini 和 Vertex AI 返回 429 RESOURCE_EXHAUSTED，在 Vertex AI 上表示共享资源池当时容量不足；Kimi 返回 rate_limit_reached_error；Bedrock 返回 ThrottlingException，另有 ModelNotReadyException，SDK 最多重试 5 次；Azure 返回“Rate limit is exceeded”；xAI 返回 RateLimitError；Alibaba 返回“Requests rate limit exceeded”；DeepSeek 和 Mistral 返回 429 |
| 加速限制：流量增长过快 | 降低增长速度，再重试 | OpenAI 返回 slow_down；Anthropic 称为“acceleration limits”；Alibaba 返回“Request rate increased too quickly”；Azure 会检查 1 秒或 10 秒窗口内的突发流量 |
| 配额或支出上限：等待不会释放额度 | 否，应处理账单问题或等待重置日期 | OpenAI 返回 insufficient_quota、credit_balance_exhausted、organization_spend_limit_exceeded；Anthropic 返回不带 retry-after 的 enforced_spend_limit_reached，用户自行设置的支出上限则返回 400；Gemini 返回 quota_exceeded（每日）；Kimi 返回 exceeded_current_quota_error；Bedrock 返回 400 ServiceQuotaExceededException；聚合平台和 DeepSeek 返回 402。Azure 的配额在 deployment 创建时分配，因此耗尽配额不会返回 429 |
| 过载：服务商容量不足，不是客户端额度不足 | 是，执行 backoff 后重试 | OpenAI 返回 503 server_is_overloaded；Anthropic 返回 529 overloaded_error；Gemini 返回 503 UNAVAILABLE；Kimi 返回带 Retry-After 的 429 engine_overloaded_error；Bedrock 返回 503 ServiceUnavailableException 和 529 overloaded_error；Azure 可能返回“System is experiencing high demand”、共享资源池的“temporary rate limit adjustment”，或 PTU 利用率达到 100% 并带有 retry-after-ms；DeepSeek 返回 503 |
第三种最容易误判。Anthropic 的支出上限 429 与普通限流使用相同的 rate_limit_error 类型，文档明确说明：“在访问恢复之前，所有重试都会失败，包括 SDK 的自动重试。”OpenAI 的 insufficient_quota 同样返回 429。仅按状态码分支的客户端会重试这两类错误，所有官方 SDK 也都如此。应按 error code 分支；如果 429 不带 Retry-After，通常意味着等待没有用。
第四种情况正是各云平台行为不同的地方。Azure 的故障排查指南写得很直接：“许多客户将容量相关的 429 误判为配额问题，从而采取了错误的处理措施。”在 Azure 上，如果 429 中的 x-ratelimit-limit-tokens 低于配置值，说明共享资源池正在自我保护；在 Vertex AI 上，按量付费模式的所有 429 都属于这一类；在 Bedrock 上，相同情况会返回 503 或 529，而不是 ThrottlingException。通过聚合平台调用时，这类信息会出现在 body 中。在响应头测量期间，一次 429 被包装为 provider_error_code: insufficient_quota、limit_source: upstream_provider_shared_pool。状态码表示限流，body 却说明耗尽的是别人的配额。
SDK 收到 429 后会怎么做？
具体行为取决于 SDK，其中两个使用广泛的 SDK 默认完全不处理。下表依据 2026-09-04 各官方客户端的源码，而不是文档：
| SDK | 默认重试次数 | 会重试的状态 | Backoff | Retry-After 处理方式 |
|---|---|---|---|---|
| openai-python（也用于 Azure OpenAI） | 2 | 408、409、429、5xx，或由 x-should-retry 指定 | min(0.5 × 2^n, 8) 秒，并加入 jitter | 先读取 retry-after-ms，再将 retry-after 解析为秒数或日期；超过 120 秒时完全不重试 |
| anthropic-sdk-python、groq-python | 2 | 相同 | 相同 | 解析方式相同；超过 60 秒时忽略该响应头，改用 backoff 公式 |
| openai-node、anthropic-sdk-typescript | 2 | 相同 | 相同 | 相同；超过 60 秒时退回默认 backoff |
| google-genai（Python，Gemini API 和 Vertex AI） | 0：retry_options 默认为 None，即只尝试一次 | 启用后：408、429、500、502、503、504 | 启用后：共尝试 5 次，从 1 秒开始翻倍，最高 60 秒，并加入 jitter | 不读取 Retry-After |
| mistralai（Python） | 0：默认不设置 retry_config | 配置后：429、500、502、503、504 | 配置后：500 ms × 1.5^n，最高 60 秒，总时长不超过 1 小时 | 遵循任意 Retry-After，支持秒数或日期 |
| boto3（Bedrock） | Legacy 模式：共尝试 5 次，包括首次请求；standard 模式：共尝试 3 次 | ThrottlingException 及同类错误、429、5xx | standard 模式下基数为 2，上限为 20 秒。2026 行为可通过 AWS_NEW_RETRIES_2026=true 启用，使用 full jitter，限流错误的基准值为 1,000 ms，并使用 retry token bucket | 默认不处理 Retry-After；2026 行为会按毫秒读取 x-amz-retry-after，最大值限制为 backoff 加 5 秒 |
| xai-sdk（Python、gRPC） | 5 次，只针对 UNAVAILABLE | 不重试 RESOURCE_EXHAUSTED，即 gRPC 中的 429 | 从 0.1 秒开始翻倍，最高 1 秒 | 不适用 |
| dashscope（Alibaba） | 不按 HTTP 状态重试；如果连接池中的连接在收到任何字节前断开，则重新发送一次 | |||
| DeepSeek、Kimi、MiniMax | 没有第一方 chat SDK；DeepSeek 文档建议使用 OpenAI 或 Anthropic SDK，并替换 base URL |
由此可以得出三点。第一，Gemini、Vertex AI 或 Mistral 首次返回 429 时，错误会直接到达业务代码，除非显式传入 retry 选项。google-genai 源码中“客户端会重试 4 次”的注释描述的是启用后的配置，不是默认行为。第二，Retry-After 上限与服务商要求的长时间等待相冲突：Anthropic SDK 收到等待 90 秒的要求时，会忽略该响应头，并在不到 8 秒后再次请求；OpenAI SDK 收到等待 150 秒的要求时，则直接停止重试。第三，由 Stainless 生成的 SDK，包括 OpenAI、Anthropic 和 Groq 客户端，会先处理未记录在文档中的 x-should-retry 响应头，再检查状态码；同时先读取 retry-after-ms，再读取 retry-after。因此，服务商或 gateway 无需修改状态码，也能控制重试行为。
这些 SDK 都无法区分支出上限 429 和普通限流。对 insufficient_quota 重试两次，每个客户端只浪费几秒，但整个服务集群同时这样做，就会制造一次不必要的流量突发。
Gateway 会带来哪些变化？
Gateway 可以集中处理这些差异。向上游请求时，它负责读取各服务商不同的响应头，因此三种 reset 格式和四种 429 语义无需由每个客户端分别处理；向下游响应时，它提供统一的响应头和错误结构，前文测得的 Synthorai 响应头就是如此。但 gateway 无法改变服务商的计量规则：调用 OpenAI 时，客户端的 max_tokens 仍会预先扣除 TPM；调用 Bedrock 时，Claude 每个输出 token 仍会消耗 10 个配额 token。如果 gateway 让多个客户端共用同一个服务商 key，也会比任何单个客户端更早触发该服务商的加速限制。因此，限流应使用按 key 划分的 bucket，而不是一个全局共享计数器。
常见问题
max_tokens 会计入限额吗？
在 OpenAI、Azure OpenAI 和 Bedrock 上会。请求到达时就会扣除 max_tokens，因此即使答案很短，设置过大的值也会浪费 TPM；Bedrock 会在响应结束后修正扣除量。在 Anthropic 上不会，OTPM 按实际生成的 token 计算，max_tokens“不参与”计量。
Cached token 会计入限额吗？
Anthropic、Bedrock 和 Azure PTU deployment 不计 cache read。xAI 则会全额计入。OpenAI 和 Gemini 没有说明。
429 响应一定会带 Retry-After 吗？
不会。OpenAI、Azure（使用 retry-after-ms）和 Groq 会在限流时返回；Anthropic 会在限流时返回，但达到支出上限时不返回；Kimi 和 Bedrock 只在过载时返回。Gemini、Vertex AI、xAI、Alibaba、DeepSeek 和 MiniMax 都没有相关文档，因此客户端必须自行实现 backoff。
为什么 SDK 没有重试 429？
如果使用 Google GenAI 或 Mistral Python SDK，重试默认关闭，需要传入 retry_options 或 RetryConfig。如果使用 OpenAI Python SDK，而服务端要求等待超过 120 秒，SDK 会主动放弃重试。如果 429 表示配额或支出上限，而不是普通限流，那么不重试才是正确行为。