五家大模型 API 限速横评（2026）：五套规则根本排不出名次

摘要。 没有哪张表能给大模型 API 的限速排出名次，因为五家最大的厂商量的不是同一个东西。Anthropic 同时卡每分钟请求数、输入 token 数和输出 token 数，而且缓存读取不算你头上。Moonshot 和 OpenAI 按你花的钱抬天花板。DeepSeek 完全不管每分钟速率，只卡你同时能有多少请求在飞。Google 和 OpenAI 都把每模型的数字从公开文档撤进了后台。有用的问题不是「谁 RPM 最高」，而是哪种限制设计跟你的应用实际调用方式对得上，以及先撞到的那一条你打算怎么绕。

限速不是一个能排序的数字。Anthropic 数每分钟 token，DeepSeek 数在飞的请求，OpenAI 数你付了多少钱。把它们并到一列里是范畴错误。

先给一张对照，看哪种限制会先咬到哪种负载，你可以直接跳到跟自己对得上的那一段。

所有人都想要的那张表（以及它为什么对不齐）

每篇「限速对比」都承诺给你一张扫一列就能挑赢家的网格。这张网格一碰就碎，因为五家对「限制」是什么都没谈拢。下面是诚实的版本：同样五列，填的是「这几列根本对不上」这个事实。

横着读任何一行，形状都在变。三家会给你精确的每模型数字，两家不给。两家卡 token，一家卡在飞请求，两家主要卡你往账号里划了多少钱。这个对不上本身才是真正的发现，本文剩下的部分讲的是当你就是那个吃到 429 的人时，每一格具体意味着什么。

下面所有数字都是 2026-07-22 从各厂商官方限速文档抓的。厂商已不再公布每模型数值的地方，本文直说，不猜。

Anthropic：三根轴，而且缓存读取不要钱

Anthropic 是五家里最透明的，也是维度最多的。每个模型档同时受三根轴限制：每分钟请求数（RPM）、每分钟输入 token 数（ITPM）、每分钟输出 token 数（OTPM）。任意一根越线就是 429，并带一个 retry-after 头明确告诉你等多久。桶是连续回补的（token bucket），所以你不是在等一个固定的重置时刻。

档位是 Start、Build、Scale 和 Custom。你不能直接花钱买档位——组织是根据使用历史和账号状态自动上升的。每档带一个月度消费上限：

每模型的数字才是 Anthropic 真正给了细节的地方。以 Claude Opus 4.x 为例，Opus 4.8、4.7、4.6、4.5 共用同一个桶：

最值得注意的一条、也是 Anthropic 天花板比表面上高的原因，是那条缓存感知的 ITPM 规则。对多数 Claude 模型，cache_read_input_tokens 不计入 ITPM。写入缓存的 token 和普通输入 token 照算，但从缓存读回来的 token 不占限速额度。官方自己的算例：200 万 ITPM 配 80% 缓存命中率，实际每分钟能推大约 1000 万输入 token，因为那 800 万缓存 token 不登记在限制里。Claude Haiku 3.5 是唯一仍然计入缓存读取的例外。

如果你的输入里有很大一块是稳定的 system prompt、或者每次调用都要带的长文档，这条规则对你实际吞吐的影响比升一档还大。钱那一侧我们在 DeepSeek 缓存配置实践 里算过；限速这一侧是同一根杠杆，只是撬的是吞吐不是账单。

两个容易让团队措手不及的脚注：Message Batches API 有自己独立的限制，Managed Agents 也是（create 端点 300 RPM，read 端点 1,200 RPM）。批量流量撞墙不代表你的 Messages API 额度用完了。

Moonshot / Kimi：花钱爬梯，四个维度一起动

Moonshot 是这一组里最直白的付费升档阶梯。你的档位完全由累计充值决定，从 $1 到 $3,000，每一档同时拨动四个旋钮：并发、RPM、TPM，以及每日 token 数（TPD）。

国际站（platform.kimi.ai）的档位，按美元计：

拿这些数字去跟别处对照之前，有个坑必须知道：Moonshot 跑着两个独立平台、两套独立阶梯。 国际站（platform.kimi.ai，也可从 platform.moonshot.ai 进）按美元计量，而且要先充 $1 才能开始调用。大陆站（platform.moonshot.cn）有自己的人民币阶梯，从 ¥0 起，依次经过 ¥50 / ¥100 / ¥500 / ¥5,000 / ¥20,000。两者不是彼此的汇率换算，入门条件也不同：一个要求先付一笔钱，另一个不要求。看档位之前先确认你的 key 属于哪个平台。

Tier 0 到 Tier 1 那一跳最值得注意：多充 $9，你就从 3 RPM 和单个并发，跳到 200 RPM 和 50 并发，而且每日 token 上限直接取消。Tier 0 本质上只是一道「证明你是真人」的门槛，不是一个能在上面搭东西的地方。

档位表没写的一件事：单个模型在你的档位之外还可能受容量约束。像 Kimi K3 这种刚上线的模型，即使你离档位限制还很远，也可能因为上游容量返回 429——约束的是厂商对那个模型的总余量，不是你账号的速率。这种时候买更高的档位没用，解法是降级到别的模型，也就是本文后面那套路由模式。

DeepSeek：完全没有 RPM，只有并发

DeepSeek 是打破所有对比网格的那个异类。它不公布 RPM 也不公布 TPM，它在账号层面卡并发——你同时能有多少请求在飞：

不超上限，模型返回多快你就能发多快。越过就是 429。没有每分钟预算需要你去掐着节奏，这对并行负载来说反而明显更好推理：按并发上限定 worker 池大小，然后不用再操心每分钟 token。

DeepSeek 处理过载的方式也不一样。服务器忙的时候它不拒绝请求，而是保持连接——非流式调用发空行，流式发 SSE 的 : keep-alive 注释——只有在 10 分钟后推理仍未开始才关闭连接。配额扩容过的账号还能用 user_id 参数按终端用户隔离并发，如果你用一把 key 复用很多客户，这一条有用。想看 DeepSeek 在 agent 循环里的账单侧，DeepSeek V4 API 指南 讲了并发模型跟缓存未命中、思考 token 是怎么互相作用的。

OpenAI：按消费分档，数字锁进了后台

OpenAI 依然按累计付费金额分档，共六档：

维度铺得很宽：RPM、RPD、TPM、TPD、每分钟图片数，部分流式模型还有每分钟音频分钟数。在限制之内时，响应会带 x-ratelimit-limit-requests、x-ratelimit-remaining-requests 以及对应的 token 版本，可以实时盯余量。

但这里有个把网格打破的地方：OpenAI 的限速文档已经不再列每个模型的具体 RPM 或 TPM 了。那一页把你导向模型页或你自己的账号后台去看实际数字。这不是个值得抱怨的疏漏，它本身是个数据点——OpenAI 认为每模型限速变动得足够频繁，静态表格会误导人，所以数字放在跟你账号和档位绑定的后台里。任何把 OpenAI 每模型 RPM 当成固定值印出来的文章，引的都是一张可能已经过期的快照。

Google Gemini：档位、时间闸，和一个 10 分钟消费窗

Gemini 的档位把计费状态、消费金额和经过时间揉在了一起：

那个 3 天和 30 天的要求很少见：钱付到位也不能跳过等待期去够 Tier 2 或 Tier 3。Gemini 还在常规的 RPM / TPM / RPD 之上叠了一层按消费的管控，按每滚动 10 分钟窗口执行（Tier 1 是 $10，Tier 2 和 3 是 $200），所以哪怕你的每分钟 token 速率没问题，一次突然的消费尖峰也能把你限住。越线返回 429 RESOURCE_EXHAUSTED。

跟 OpenAI 一样，Gemini 把每模型的 RPM / TPM / RPD 数字挪出了静态文档，放进 AI Studio 里给你看当前生效的限制。而且整页只适用于 Gemini Developer API，不覆盖 Vertex AI——那边跑的是完全另一套配额系统。

为什么这些单位对不齐（没人做成表的那部分）

退一步看，这个不兼容本身就是故事。下面这张表讲的是在每一家那里，一个「单位」的余量到底给你买到了什么，以及这个单位在哪里会夹到你。

一个每天发几千次微型分类调用的团队最先撞 RPM，完全不在乎 ITPM。一个每次请求都塞 20 万 token 文档的团队会撞每分钟 token 的墙，而它的 RPM 几乎贴地。一个跑五十个并行 agent 的团队撞并发。这三个团队不可能共用同一条「限速最好」的推荐，因为它们被三个不同的单位约束着，没有任何单一排名能同时服务这三家。

举个具体的例子把这个陷阱说清楚。假设你跑 50 个 worker，每个发一个 3 万 token 的 RAG 请求。在 DeepSeek 的 deepseek-v4-pro 上，这是 50 个在飞对 500 的并发上限，你有十倍余量，永远见不到 429。把同一个负载原样搬到一家限制为每分钟 200 万输入 token 的厂商，如果这 50 个请求落在同一分钟里，那就是一个突发的 150 万输入 token，再加上你别的流量。你突然就到了一条在 DeepSeek 上压根没在盯的限制的 75%，而一点点流量增长就会把你推过去。同样的并发、同样的请求大小，完全不同的墙。

这就是跨厂商迁移会让人意外的原因。你从来没在看的那条限制变成了咬你的那条，一段稳跑几个月的代码路径，在你换 provider 那天开始抛 429。

哪条限制会先咬到你（决策框架）

在升档或者重构任何东西之前，先搞清楚你实际撞的是哪一堵墙。

• 什么时候直接升档就好。 你的 429 集中在某一根轴上（比如 RPM），你在低档位，而下一档的天花板能带余量地覆盖你的峰值。花钱是最便宜的解法。这在 Moonshot 和 OpenAI 上是常见情形，因为它们的档位就是一个消费旋钮。
• 什么时候该开缓存而不是升档。 你在 Anthropic 上撞 ITPM，而且你的输入里有很大一块在多次调用间重复。打开 prompt 缓存能在不换档的情况下抬高有效吞吐，因为缓存读取不计入 ITPM。在提交提额申请之前先试这个。
• 什么时候该绕开它。 你的限制对这个负载来说是结构性的（一个你持续打满的并发上限，或者一个返回上游容量 429、换什么档位都修不好的模型）。解法是切到另一家的可比模型，让一次限流降级成一次跳转而不是一次报错。这正是 AI API 报错排查大全 和 多模型路由 派上用场的地方。
• 可以停的规则。 如果你的 429 比例低于 1% 左右、而且重试一次就过，你没有限速问题，你有的是正常的突发噪声。加一个带抖动的退避然后继续干活。别为一堵你几乎没碰到的墙去重构。

怎么读一个 429（你撞的是哪堵墙）

429 不是自解释的，而且五家告诉你「撞的是哪堵墙」的方式各不相同。重试之前先读响应，能省下你去干等一条其实没撞破的限制。

实用的分野在「等一等」型限制和「慢下来」型限制之间。Anthropic、OpenAI 和 Google 给的是每分钟预算，所以一个 retry-after 或者一个逼近零的剩余量响应头，意味着退避几秒钟桶就回补了。DeepSeek 的并发上限是「慢下来」型：只要你保持同样数量的请求在飞，等待毫无作用，因为那堵墙是并行度不是时间。不缩小 worker 池就重试一个并发 429，只是再撞一次同一堵墙。这个区分搞错了，你的退避逻辑要么在该卸载时睡觉，要么在等一秒就能过时去卸载。

一个端点，五套规则

你没法让 Anthropic 的 ITPM 或 DeepSeek 的并发上限消失。你能做的是别让任何单独一家的限制变成单点故障。五家各执行一套不同的规则时，实际的防御手段是把它们放到同一个端点后面，让被限流的请求自动切到另一家。像 ofox 这样的网关把它们都暴露在一个 OpenAI 兼容 API 和一把 key 上，于是「撞上 A 家的限制」变成「由 B 家回答」而不是一次失败调用。这也是 企业级 LLM 网关横评 的论点，只是具体落到了限速这件事上。

模式是一个短的「重试再跳」循环：任何一家的 429 触发几次带抖动的重试，然后切到跨厂商链条里的下一个模型。

import time, random, openai

CHAIN = [
    "anthropic/claude-opus-4.8",
    "deepseek/deepseek-v4-pro",
    "moonshotai/kimi-k3",
]

def ask(prompt, retries=2):
    for model in CHAIN:
        for attempt in range(retries):
            try:
                r = client.chat.completions.create(
                    model=model,
                    messages=[{"role": "user", "content": prompt}])
                return model, r.choices[0].message.content
            except openai.RateLimitError:
                time.sleep((2 ** attempt) + random.random())
        # 这一家重试完还是被限，换下一家
    raise RuntimeError("链条上所有 provider 都被限流了")

把命中的模型名跟结果一起返回。等你之后要排查某一批结果为什么风格不一致，知道每一条究竟是谁答的，能省很多时间。

需要说清楚的边界：网关抬不高任何一家的天花板。它改变的是撞墙之后发生什么。如果你的全部流量都压在一家上、而且你持续打满它的某根轴，那你需要的是更高的档位或者更少的流量，不是一个网关。

本文核对过的来源

• Anthropic API 限速文档（2026-07-22 核对）
• OpenAI 限速指南（2026-07-22 核对）
• DeepSeek 限速文档（2026-07-22 核对）
• Google Gemini API 限速（2026-07-22 核对）
• Moonshot / Kimi 限速文档，国际站（2026-07-22 核对）
• Moonshot / Kimi 限速文档存档副本
• Moonshot 大陆站限速文档，人民币阶梯（2026-07-23 核对）