AI 工具的速率限制与并发上限对比：你的额度够不够，不看总量看速度

选 API 的时候，「额度」是所有人第一个看的数字。Tier 几、每月能用多少钱、免费额度有多少——这些数字被放在定价页最显眼的位置，因为大就是好卖。

但真正决定一个批量任务能不能在今晚跑完的，往往不是总额度，而是速率限制。速率限制和额度是两套完全独立的机制：额度决定你一个月能花多少钱，速率决定你一分钟能发多少请求。前者可以在后台点一下升级，后者只能靠提升 tier 慢慢涨，而且涨得不均匀。

更麻烦的是，五家厂商用的单位完全不一样。OpenAI 写 RPM 和 TPM，Anthropic 写 RPM、ITPM 和 OTPM，Google 写 RPM、TPM 和 RPD，Cursor 干脆取消了请求数改成两个用量池，两家订阅制产品则只给「5 小时窗口」和「每周上限」这种时间描述。这些单位之间没有任何直接可比性。

这篇要做的事只有一件：把这些五花八门的限制折算到同一把尺上——一次处理 1,000 条、每条 2,000 输入 token 的请求，各家需要多久才能跑完。折算之后会发现，总量额度大的那一家，跑得不一定快。数据于 2026 年 9 月 24 日重新核对各厂商官方文档与定价页。本站此前盘点过 API 的免费额度总量，那篇讲的是「你有多少」，这篇讲的是「你多快能用完」。

本文方法：官方公开数据交叉核对，未做本地实测。所有数字均标注来源，核对日期见文末。

一、五家用的根本不是同一把尺

先把每家的官方说法摆出来。下面每一行都对应官方文档里的原文表述，不是我归纳的。

表里有三处值得单独说。

OpenAI 把限制定义在组织和项目层级，不是用户层级。官方原文是「Rate limits are defined at the organization level and at the project level, not user level.」——这意味着同一个组织下的所有成员共享一个池子，团队里一个人跑批处理，全组的速率都会受影响。同页还有一句话值得记住：「Rate limits can be hit across any of the options depending on what occurs first.」任何一个维度先打满，请求就会被拒。

Anthropic 用的是 token bucket，不是固定窗口。官方原文写得很清楚：「your capacity is continuously replenished up to your maximum limit, rather than being reset at fixed intervals.」这句话的实践含义是：容量是连续补的，所以短时间的突发可以超过平均速率。同页的原文举了一个例子：「a rate of 60 requests per minute (RPM) might be enforced as 1 request per second.」——也就是说 60 RPM 在产品里可能被实现成每秒 1 个，突发会直接撞上限。反过来，如果你的请求间隔均匀，token bucket 会比固定窗口更宽容。

Cursor 已经从「按请求数」转向「按用量池」。官方文档里，Max Mode 被归到「Legacy request-based pricing」之下，并注明「Max Mode is available only on legacy request-based plans.」现在的 Pro / Pro Plus / Ultra 提供两个池子：Cursor Models 池（Grok 4.7、Grok 4.6、Grok 4.5、Composer 2.5）和 Other Models 池（第三方模型，按模型 API 价格计费）。超出后官方给两条路：「Add on-demand usage」或「Upgrade your plan」，并明确写「Requests are never downgraded in quality or speed.」——也就是 Cursor 不做降速，只做加钱。

而两家订阅制产品的披露方式完全相反。Anthropic 公开了两个时间窗口但不公开条数：官方帮助中心的原文是「Your session-based usage limit will reset every five hours.」，同时说明「The number of messages you can send will vary based on message length, including the length of files you attach, the length of your current conversation, and the model or feature you use.」OpenAI 则连窗口都不写，定价页上只有「Unlimited text chats subject to abuse guardrails.」这一句，唯一量化的是上下文窗口（Free 27K、Go 与 Plus 54K、Pro 128K）和 Pro 档的「5x more usage」。

所以「哪家订阅更耐用」这个问题，用官方页面是回答不了的：一家给了时间窗口但不给条数，一家给了模型档位但不给窗口。两家都不给消息条数。

二、折算：跑完 1,000 条请求要多久

现在把场景定死：一次批量任务，1,000 条请求，每条 2,000 输入 token，合计 2,000,000 输入 token，走同步接口，不做重试。

每家的完成时间由两个约束里更慢的那个决定。请求数约束是「1,000 ÷ RPM」，token 约束是「2,000,000 ÷ TPM」。两个都算出来，取大的那个。

这张表推翻了一个很常见的直觉。很多人挑模型时默认「便宜模型更快」，因为便宜模型通常更快出字。但在速率限制这一层，Claude Haiku 3.5 是表里最慢的，比同厂的 Sonnet 5 慢 20 倍——因为它的 ITPM 只有 100,000，是同厂其他模型的二十分之一。它的单价便宜，但它的速率也便宜。

另一个反常的地方是 Anthropic Sonnet 5 那一行：两个约束算出来都是 1.0 分钟。这不是巧合。1,000 RPM × 2,000 token = 2,000,000，恰好等于 Sonnet 5 的 ITPM 限额。也就是说，如果你的请求平均是 2,000 token，Anthropic 的两个限制会同时打满，没有一个是浪费的。请求尺寸一旦偏离这个值，就会有一个限制开始空转——请求更小，RPM 先满；请求更大，ITPM 先满。

还有一件事必须说清楚：Gemini 没有进入这张表，因为它的官方文档页不公布各模型的具体 RPM 和 TPM。Google 的速率限制文档只写「Rate limits depend on a variety of factors (such as your usage tier) and can be viewed in Google AI Studio.」，并把具体数值指向 AI Studio 的页面。同页还有一句免责声明：「Specified rate limits are not guaranteed and actual capacity may vary.」所以对 Gemini 只能做定性判断：它的限制是三个维度（RPM、TPM、RPD）同时生效，按项目而不是按 API key 计算，RPD 在太平洋时间午夜重置，预览模型更严格。具体数字必须登录 AI Studio 查自己账号的实际值。

三、TPM ÷ RPM：那个没人算过的数字

把 TPM 除以 RPM，得到一个很有意思的指标：在速率限制下，每条请求平均能用多少 token。这个数字决定了你的请求尺寸会不会撞上 token 墙。

读这张表的方式是：如果你的请求平均大于「TPM ÷ RPM」这个值，那么 token 限制会先打满，RPM 再高也用不上。

OpenAI Tier 2 是这张表里最值得注意的一行。从 Tier 1 升到 Tier 2，官方发布的 RPM 从 500 涨到 5,000（10 倍），TPM 从 500,000 涨到 1,000,000（2 倍）。看起来是全面提速，但 TPM ÷ RPM 从 1,000 掉到 200——每条请求的平均 token 预算缩水了 80%。一个带系统提示和上下文的真实请求很少低于 200 token，所以绝大多数实际负载在 Tier 2 上根本用不到那 5,000 RPM：token 限制会先把速率卡在 500 请求/分钟。

把这个结论推到底：一旦 TPM 成为瓶颈，升 tier 的速度收益就等于 TPM 的倍数，与 RPM 的倍数无关。Tier 1 到 Tier 2 的 TPM 是 2 倍，所以在 2,000 token 的请求尺寸下，提速也只有 2 倍，而不是 RPM 暗示的 10 倍。只有当你的请求足够小（小于 200 token）时，Tier 2 的 5,000 RPM 才真正可用。

反过来看 Anthropic。主力模型全线都是 1,000 RPM / 2,000,000 ITPM，TPM ÷ RPM 稳定在 2,000。这个设计的含义是：它在 2,000 token 的请求尺寸上不浪费任何一个限制。而且 Anthropic 还有一个 OpenAI 和 Google 都没有的机制——缓存读取的 token 大多不计入 ITPM。官方原文写：「For most Claude models, only uncached input tokens count toward your ITPM rate limits.」并给了一个具体算例：「With a 2,000,000 ITPM limit and an 80% cache hit rate, you could effectively process 10,000,000 total input tokens per minute (2M uncached + 8M cached).」

这个 80% 缓存命中的例子对本文的批量任务是决定性的：同样 2,000,000 输入 token，如果其中 80% 命中缓存，计入 ITPM 的只有 400,000 token，token 约束从 1.0 分钟缩短到 12 秒。Anthropic 的「速率」在缓存场景下是可以被工程手段放大的，而 OpenAI 和 Google 的 TPM 是硬的。注意例外：官方标注 Haiku 3.5 会把 cache_read_input_tokens 也计入 ITPM，所以上面这个放大效应不适用于 Haiku 3.5——这也解释了为什么它在这张表里垫底。

Gemini 的情况又不一样。它的文档页不公布每模型的 RPM / TPM，但公布了另一个东西：按支出计的速率限制。官方原文是「the Gemini API enforces spend-based rate limits to protect against unexpected charges」，且「These limits are evaluated on a rolling 10-minute window.」具体数值是 Free 无、Tier 1 为 $10、Tier 2 为 $50、Tier 3 为 $200（每 10 分钟）。

这个机制很特别：它的上限不是一个请求数或 token 数，而是一个金额。换算成请求速率，就完全取决于你选了哪个模型。

同样是 Tier 1 的 $10 / 10 分钟，换成 Flash-Lite 是每分钟 540 条请求，换成 3.1 Pro 是 100 条——差 4.1 倍，而这个差距与你的 tier 无关，只与模型价格有关。这是「速率限制」这个概念被重新定义的地方：在 OpenAI 和 Anthropic 上，速率是一个独立于价格的数字；在 Gemini 上，速率是价格的一个函数。需要说明的是，Google 明确写了这类限额是否生效「depends on your billing history and account standing」，所以它不是一个保证值，而是一个上限。

四、批量接口：用时间换 50% 的折扣

上面所有折算都是同步接口。三家都另有一条路：批量接口。它的规则高度一致——全部是标准价格的 50%，代价是完成时间从分钟级变成小时级。

三家在「完成时间」上的表述差别很大，这个差别值得读一下原文。OpenAI 写的是「a clear 24-hour turnaround time」，并注明「For now, the completion window can only be set to 24h.」——是一个承诺窗口。Anthropic 写的是「The system processes each batch as fast as possible, with most batches completing within 1 hour.」——给了典型值和一个 24 小时的兜底：「You can access batch results when all messages have completed or after 24 hours, whichever comes first.」Google 写的是「The target turnaround time is 24 hours, but in majority of cases, it is much quicker.」——目标值加 48 小时的过期线。

拿本文的任务对照：1,000 条请求、2,000,000 输入 token，在 OpenAI Sol Tier 1 上走同步接口是 4.0 分钟，走批量接口最长要等 24 小时。完成时间差了 360 倍，价格只差 2 倍。这个交换在什么情况下划算？只有一种：当任务量超过速率限制、同步接口根本跑不完的时候。

OpenAI 官方把这一点写得很直白：「Because Batch API rate limits are a new, separate pool, using the Batch API will not consume tokens from your standard per-model rate limits, thereby offering you a convenient way to increase the number of requests and processed tokens you can use when querying our API.」——批量接口的速率池与同步接口完全独立，所以它是绕过 RPM/TPM 墙的正规手段。

但队列本身也有上限，而且这个上限常常比你想的小。OpenAI 的批量队列是按「该模型已排队的输入 token 总数」计算的：GPT-5.6 Sol 在 Tier 1 的队列限额是 1,500,000 token，本文的 2,000,000 token 任务一次提交就超了，必须拆成两批；升到 Tier 2 才是 3,000,000，可以一次进。Gemini 同理，Tier 1 下 Gemini 3.8 Flash 的 Batch enqueued tokens 是 3,000,000，Gemini 3.5 Flash-Lite 是 10,000,000，而 Gemini 3.1 Pro Preview 只有 5,000,000。

还有一个容易被忽略的细节：批量任务的结果不是永久的。Anthropic 写「Batch processing stores request and response data for up to 29 days after batch creation.」，OpenAI 写输出文件「will automatically be deleted 30 days after the batch is complete」，Gemini 写结果默认保留 6 周。如果你的流水线依赖事后重新下载结果，这三条期限就是硬约束。

五、三个容易踩的坑

六、按场景怎么选

• 任务能在 1 小时内跑完：走同步接口，别碰批量。Anthropic 主力模型在 2,000 token 请求尺寸下是 1.0 分钟跑 1,000 条，是本文折算里同步接口的最优解之一；OpenAI 要到 Tier 3 才有同样的 1.0 分钟。
• 请求平均 token 数大于 2,000：优先看 TPM，而不是 RPM。OpenAI Tier 2 的 TPM ÷ RPM 只有 200，这类负载在它上面根本用不到发布的 5,000 RPM，实际被卡在 500 请求/分钟。
• 能用缓存复用同一段上下文：Anthropic 是唯一把「缓存读取不计入速率」写成明确规则的，官方算例是 2M ITPM 在 80% 缓存命中下等效 10M。注意 Haiku 3.5 是例外，它的 cache_read 也计入 ITPM。
• 成本敏感、模型可换：Gemini 的支出限额让速率与模型价格挂钩。Tier 1 下用 Flash-Lite 是每分钟 540 条请求，用 3.1 Pro 是 100 条。换模型不只是省钱，也是提速率。
• 任务量超过速率上限：走批量接口。三家都是 5 折，且队列与同步接口独立。提交前先核对队列限额：OpenAI Sol 在 Tier 1 的队列上限是 1,500,000 token，2,000,000 token 的任务必须拆两批。
• 跑编程代理、需要并发：Cursor 已经不按请求数限速，官方原文是「You can run as many agents as you want in parallel」，限制换成了月度用量池和按需付费。团队档 Premium 席位（$120/席/月）的 Agent 限额是 Standard（$40/席/月）的 5 倍。
• 订阅制产品、要估「能用多少」：目前官方口径回答不了这个问题。Claude 公开 5 小时会话窗口和每周上限但不公开条数；ChatGPT 只写「Unlimited text chats subject to abuse guardrails.」，连窗口都不公开。要用得放心，只能靠实际记录自己的用量曲线。

把五家放在一起看，会发现「速率限制」这件事没有统一的设计语言。OpenAI 把它做成一套分 tier 的双旋钮，Anthropic 把它做成连续补充的 token bucket 加缓存豁免，Google 把它做成三个维度的叠加再加一个金额上限，Cursor 干脆取消了它，两家订阅制产品则把它藏在未公开的额度里。唯一能横向比较的方法，就是把它折算成「跑完一个具体任务要多久」。折算完之后，那个最显眼的数字——总额度——几乎总是不是决定速度的那个数字。

这个思路和本站其他横评是同一套方法。我们此前把 API 的单次任务成本、免费额度的实际购买力都拉平到同一把尺上算过，结论也类似。相关阅读：AI 工具的 API 免费额度盘点、大模型 API 价格横评：为什么每百万 token 单价不能直接比、AI 编程工具的上下文窗口与输出上限对比。