AI API 速率限制对比 2026：OpenAI vs Claude vs Gemini vs Grok

选 AI API 的时候，大多数人第一反应是看价格。但实际跑起来之后你会发现，速率限制才是真正卡脖子的那个因素。

你的模型选好了，prompt 调优了，代码写完了，一上线——每分钟只能打 50 个请求，队列直接排爆。更恼火的是，很多厂商的速率限制不是一个固定数字，而是一套分层体系：你的账号花了多少钱、充了多少预付费，决定了你能用多少吞吐量。新注册的账号和消费过几千美元的老账号，可用的 RPM 和 TPM 可能差 100 倍。

这篇文章把 2026 年 2 月六大 AI API 厂商的速率限制体系拆开讲清楚，帮你在做架构决策之前就知道瓶颈在哪里。

速率限制的两个核心指标

开始之前先对齐概念。API 速率限制通常由两个指标共同约束：

RPM（Requests Per Minute）：每分钟请求数。不管你的请求大小是 100 token 还是 10 万 token，每打一次就计一次。
TPM（Tokens Per Minute）：每分钟处理 token 数。包括输入和输出 token 的总和。

两个指标是 AND 关系——先触发哪个，哪个就成为瓶颈。举个例子：你的 RPM 限制是 1000，TPM 限制是 10 万。如果你的每个请求平均 200 token（输入+输出），那你在发到 500 请求时 TPM 就先爆了，根本用不到 1000 RPM。

实际生产中，大多数应用的瓶颈是 TPM 而不是 RPM——因为现在的 prompt 动不动就几千 token，几十个请求就能把 TPM 吃满。

六大厂商速率限制总表

下面这张表汇总了 2026 年 2 月各厂商的速率限制体系。因为每家的分层逻辑不同，我把最低档和最高档都列出来，方便你快速对比。

最低档（新注册 / 免费 / Tier 1）

厂商	模型	RPM	TPM	获取条件
OpenAI	GPT-5 / GPT-4o	3	40,000	免费用户（Free Tier）
Anthropic	Claude Sonnet 4.5	50	40,000	Tier 1（充值 $5）
Google	Gemini 2.5 Pro	15	—	免费层（AI Studio）
Google	Gemini 2.5 Flash	500	—	免费层（AI Studio）
xAI	Grok 3	60	100,000	免费 $25 额度
DeepSeek	V3.2 / R1	60	1,000,000	默认，无分层
Mistral	全系列	300	—	默认

最高档（企业级 / 最高 Tier）

厂商	模型	RPM	TPM	获取条件
OpenAI	GPT-5 / GPT-4o	10,000	10,000,000	Tier 5（历史消费 $200+）
OpenAI	GPT-4.1 Nano	30,000	150,000,000	Tier 5
Anthropic	Claude Sonnet 4.5	4,000	400,000	Tier 4（历史消费 $4,000+）
Google	Gemini 2.5 Pro	2,000	4,000,000	付费（Vertex AI）
Google	Gemini 2.5 Flash	2,000	4,000,000	付费（Vertex AI）
xAI	Grok 3	1,200	—	付费升级
DeepSeek	V3.2 / R1	60	1,000,000	默认（无分层）
Mistral	全系列	300	—	默认

一眼就能看出几个关键差异：

Gemini 的 TPM 上限最高——付费后 Flash 和 Pro 都能到 400 万 TPM，适合需要大吞吐量的批处理场景。

OpenAI 的天花板也很高但要升级——Tier 5 的 GPT-4.1 Nano 能到 1.5 亿 TPM，但前提是你得先在 OpenAI 花掉 $200 以上才能解锁。免费用户只有 3 RPM，基本只能用来写 demo。

Anthropic 的限制最紧——即使升到最高的 Tier 4，Claude 的 TPM 也只有 40 万。这是所有主流厂商中最低的高档限额。如果你的应用需要高并发调用 Claude，这个瓶颈要提前规划好。

DeepSeek 简单粗暴——没有分层，所有用户统一 60 RPM / 100 万 TPM。RPM 不高，但 TPM 非常慷慨。

各厂商分层详解

OpenAI：5 级分层体系

OpenAI 的分层体系是所有厂商中最复杂的，也是上限最高的。

Tier	条件	GPT-5 RPM	GPT-5 TPM	GPT-4.1 Nano RPM	GPT-4.1 Nano TPM
Free	注册	3	40,000	3	40,000
Tier 1	充值 $5	500	200,000	500	4,000,000
Tier 2	消费 $50+	5,000	400,000	5,000	40,000,000
Tier 3	消费 $100+	5,000	600,000	5,000	100,000,000
Tier 4	消费 $200+	10,000	800,000	10,000	150,000,000
Tier 5	消费 $200+	10,000	10,000,000	30,000	150,000,000

几个关键点：

从 Free 到 Tier 1 的跳跃最大——充值 $5 就能把 RPM 从 3 拉到 500，TPM 从 4 万拉到 20 万。这是成本最低、效果最显著的一步。
Nano 的 TPM 宽裕得多——如果你只是需要大批量处理简单任务，GPT-4.1 Nano 在 Tier 3 就有 1 亿 TPM，远超 GPT-5 同级别的 60 万。
Tier 4 和 Tier 5 的条件一样（消费 $200+），但 Tier 5 的解锁可能还需要一定的账号年龄或 OpenAI 的人工审核。

Anthropic：4 级分层体系

Tier	条件	Claude Sonnet RPM	Claude Sonnet TPM	Claude Haiku RPM	Claude Haiku TPM
Tier 1	充值 $5	50	40,000	50	50,000
Tier 2	消费 $40+	1,000	80,000	1,000	100,000
Tier 3	消费 $200+	2,000	160,000	2,000	200,000
Tier 4	消费 $4,000+	4,000	400,000	4,000	400,000

Anthropic 的分层比 OpenAI 少一级，而且上限低得多。几个值得注意的点：

没有免费层——使用 Claude API 至少需要充值 $5 进入 Tier 1。这跟 OpenAI 有免费额度不同。
Tier 1 的 50 RPM 非常有限——如果你在做原型测试，50 RPM 基本够用；但稍微上点量就得升级了。
Tier 4 需要 $4,000 历史消费——这个门槛不低。即使到了 Tier 4，40 万 TPM 也只有 OpenAI Tier 5 的 4%。如果你的业务并发需求高，Claude 的速率限制是一个必须提前评估的硬约束。
Opus 4.5 的限制更紧——旗舰模型的 RPM 和 TPM 通常比上表更低，具体数字需要查看 Anthropic 控制台。

Google Gemini：免费 + 付费双轨

Google 的速率限制体系是最慷慨的，尤其是免费层。

计划	模型	RPM	TPM	每日上限
免费（AI Studio）	Gemini 2.5 Pro	15	—	25 次/天
免费（AI Studio）	Gemini 2.5 Flash	500	—	无上限
付费（Vertex AI）	Gemini 2.5 Pro	2,000	4,000,000	无
付费（Vertex AI）	Gemini 2.5 Flash	2,000	4,000,000	无

Gemini 的亮点：

Flash 免费层 500 RPM 且无每日上限——这是 2026 年所有厂商中最大方的免费额度，没有之一。对于原型开发和个人项目来说，这意味着完全零成本。
付费后 400 万 TPM——是 Anthropic Tier 4 的 10 倍，是 OpenAI Tier 5 GPT-5 的 40%（但 GPT-4.1 Nano 的 1.5 亿 TPM 还是更高）。
Pro 免费层只有 25 次/天——Pro 的免费用量严格受限，只够测试用。真正上量必须走 Vertex AI 付费。

xAI Grok：$25 免费额度起步

计划	RPM	TPM	备注
免费（$25 额度）	60	100,000	额度用完即止
付费基础	120	—	按量计费
付费进阶	1,200	—	需联系销售

Grok 的速率限制体系还比较简单。$25 的免费额度适合评估模型能力，但生产环境需要付费升级。相比其他厂商，Grok 的 RPM 上限（1200）处于中等水平。

DeepSeek：无分层，统一限制

模型	RPM	TPM	备注
V3.2	60	1,000,000	所有用户统一
R1	60	1,000,000	所有用户统一

DeepSeek 的策略最简单——没有分层、没有等级、不看历史消费。60 RPM 的限制看起来不高，但 100 万 TPM 意味着每个请求平均可以承载 1.6 万 token，这对大多数应用来说是够用的。

不过，DeepSeek 有一个其他厂商不太有的问题：高峰期拥堵。国内开发者集中使用的时段（工作日白天），实际响应延迟可能显著增加，虽然技术上没有被限流，但体验上等于变相降速。

Mistral：简单明了

模型	RPM	备注
Large 3	300	按计划有差异
Small 3.1	300	按计划有差异

Mistral 的速率限制在主流厂商中偏宽松，300 RPM 的默认值高于 DeepSeek（60）和 Anthropic Tier 1（50），但低于 OpenAI Tier 2+（5000+）和 Gemini 付费（2000）。

按场景对比：你的项目该选谁

不同阶段的项目对吞吐量的要求完全不同。下面按三个典型场景给出推荐。

场景 1：原型开发（零成本 / 免费额度）

你在做 MVP、写 Side Project、或者评估不同模型的效果。需求：不花钱或少花钱，速率限制够测试就行。

厂商	免费额度	速率限制	推荐度
Gemini Flash	无限（免费层）	500 RPM	首选
Grok	$25 额度	60 RPM	适合短期评估
OpenAI	有限免费	3 RPM	太慢，不建议
DeepSeek	无免费，但极便宜	60 RPM	充 $1 能用很久
Anthropic	无免费	50 RPM	需充 $5

结论：原型阶段首选 Gemini Flash。500 RPM 的免费额度足够你反复测试、快速迭代，而且不用担心意外产生费用。如果需要评估 Grok 的能力，$25 免费额度也值得用一下。OpenAI 的 3 RPM 只适合手动调试，自动化测试基本没法用。

场景 2：创业产品（中等用量）

日均 5-10 万请求，需要稳定的速率限制和合理的成本。

厂商	推荐 Tier	RPM	TPM	月估计成本
OpenAI (Tier 2-3)	消费 $50-100	5,000	400K-600K	$200-800
Gemini (付费)	Vertex AI	2,000	4,000,000	$100-300
DeepSeek	默认	60	1,000,000	$50-200
Anthropic (Tier 2-3)	消费 $40-200	1,000-2,000	80K-160K	$300-1,000

结论：Gemini 和 OpenAI 是创业期最稳的选择。Gemini 的 400 万 TPM 上限高、成本低；OpenAI 的 Tier 2-3 RPM 足够，生态工具也最成熟。DeepSeek 价格最低但 RPM 只有 60，如果你的请求都是小请求、高并发，60 RPM 可能不够。

如果你一定要用 Claude——比如因为它的代码能力确实强——Anthropic 的 TPM 限制是个实际问题。80K-160K TPM 在中等用量下可能会成为瓶颈，尤其是 prompt 比较长的场景。

场景 3：企业级（高吞吐量）

日均百万级请求，需要最高的速率限制和 SLA 保障。

厂商	推荐计划	RPM	TPM	特点
OpenAI (Tier 5)	消费 $200+	10,000+	10M+	最高上限
Gemini (Vertex AI)	企业合同	2,000+	4M+	可申请提升
Anthropic (Tier 4)	消费 $4,000+	4,000	400K	TPM 偏低
DeepSeek	无特殊企业层	60	1M	无法提升

结论：企业级首选 OpenAI。Tier 5 的 10M TPM 和 10K RPM 是最高的通用上限，如果还不够可以联系 OpenAI 申请进一步提升。Gemini 的 Vertex AI 企业合同也能拿到很高的限额。

Anthropic 在企业场景下的最大软肋就是速率限制——40 万 TPM 对于高吞吐应用来说远远不够。当然你可以通过多个 API Key 做并发来缓解，但这增加了架构复杂度。

DeepSeek 的 60 RPM 硬限制意味着它不太适合作为企业主力 API，但作为辅助路由的一环（比如处理低优先级任务）仍然很有价值。

速率限制如何影响架构设计

很多开发者在写原型的时候不会想到速率限制的问题，但一旦进入生产环境，它会从三个层面影响你的系统架构。

1. 请求队列是必须的

一旦你的用户数超过几十个并发，裸调 API 必然会遇到 429 (Rate Limit Exceeded) 错误。你需要在应用层建立请求队列，按照速率限制的窗口做流控。

这不是一个 nice-to-have，而是一个架构必需品。没有队列管理的生产应用在流量波动时会出现大量请求失败，直接影响用户体验。

2. 多厂商 Fallback 策略

单一厂商的速率限制是硬约束。如果你的主力模型触发了限流，请求要有备用出路。常见的做法：

主力模型 → Claude Sonnet 4.5
一级 Fallback → GPT-4.1（不同厂商，独立限额）
二级 Fallback → Gemini 2.5 Flash（最宽的限额）
三级 Fallback → DeepSeek V3.2（最便宜的兜底）

多厂商 Fallback 的好处不只是应对限流——某个厂商出现服务故障时，你的应用也不会完全瘫痪。

3. 预估 Token 消耗，而不是事后统计

在发送请求之前就计算好这个请求会消耗多少 token，这样你可以在应用层做精确的限流，而不是等到 API 返回 429 错误才知道超了。

用 AI Token 计算器测量你的典型 prompt，摸清不同场景下的 token 消耗范围。这个数字直接决定了你在给定 TPM 限制下每分钟能处理多少请求。

比如：Anthropic Tier 2 的 Claude Sonnet TPM 是 80,000。如果你的平均请求（输入+输出）是 4000 token，那你每分钟最多处理 20 个请求——RPM 限制的 1000 根本用不到，TPM 先爆了。

5 个提升吞吐量的实战技巧

技巧 1：Batch API 绕过实时速率限制

OpenAI 和 Anthropic 的 Batch API 不受常规速率限制的约束（或有独立的、更宽裕的限额）。如果你的任务不需要实时返回结果——数据标注、批量翻译、内容审核——走 Batch API 既能绕过 RPM/TPM 瓶颈，又能拿到 50% 的价格折扣。

from openai import OpenAI
import json

client = OpenAI()

# 准备批量请求
batch_requests = []
for i, text in enumerate(texts_to_process):
    batch_requests.append({
        "custom_id": f"task-{i}",
        "method": "POST",
        "url": "/v1/chat/completions",
        "body": {
            "model": "gpt-5",
            "messages": [
                {"role": "system", "content": "摘要以下文本，限 100 字内。"},
                {"role": "user", "content": text}
            ],
            "max_tokens": 300
        }
    })

# 写入 JSONL 并提交
with open("batch_input.jsonl", "w") as f:
    for req in batch_requests:
        f.write(json.dumps(req) + "\n")

batch_file = client.files.create(
    file=open("batch_input.jsonl", "rb"),
    purpose="batch"
)

batch_job = client.batches.create(
    input_file_id=batch_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h"
)

print(f"批量任务 ID: {batch_job.id}")
# 24 小时内完成，不受常规 RPM/TPM 限制

技巧 2：指数退避重试

遇到 429 错误后直接重试只会让情况更糟。正确的做法是指数退避（Exponential Backoff）：每次重试的等待时间翻倍，加上随机抖动避免多个客户端同时重试。

import time
import random
from openai import OpenAI, RateLimitError

client = OpenAI()

def call_with_backoff(messages, model="gpt-5", max_retries=5):
    """带指数退避的 API 调用"""
    for attempt in range(max_retries):
        try:
            response = client.chat.completions.create(
                model=model,
                messages=messages,
                max_tokens=1000
            )
            return response
        except RateLimitError as e:
            if attempt == max_retries - 1:
                raise  # 最后一次重试仍失败，抛出异常

            # 指数退避 + 随机抖动
            wait_time = (2 ** attempt) + random.uniform(0, 1)
            print(f"触发速率限制，等待 {wait_time:.1f}s 后重试 ({attempt + 1}/{max_retries})")
            time.sleep(wait_time)

    return None

技巧 3：请求前预计算 Token，做精确限流

不要等 API 返回 429 才知道超限了。在发送之前就用 tokenizer 计算好每个请求的 token 数，在应用层维护一个 TPM 计数器。

import tiktoken
import time
from collections import deque

class RateLimiter:
    """基于 token 的应用层限流器"""

    def __init__(self, tpm_limit: int, rpm_limit: int):
        self.tpm_limit = tpm_limit
        self.rpm_limit = rpm_limit
        self.token_log = deque()  # (timestamp, token_count)
        self.request_log = deque()  # timestamp
        self.encoder = tiktoken.encoding_for_model("gpt-4o")

    def estimate_tokens(self, messages: list) -> int:
        """估算消息的 token 数"""
        total = 0
        for msg in messages:
            total += len(self.encoder.encode(msg["content"])) + 4
        return total

    def can_send(self, estimated_tokens: int) -> bool:
        """检查是否可以发送请求"""
        now = time.time()
        cutoff = now - 60  # 60 秒窗口

        # 清理过期记录
        while self.token_log and self.token_log[0][0] < cutoff:
            self.token_log.popleft()
        while self.request_log and self.request_log[0] < cutoff:
            self.request_log.popleft()

        current_tpm = sum(t[1] for t in self.token_log)
        current_rpm = len(self.request_log)

        return (current_tpm + estimated_tokens <= self.tpm_limit
                and current_rpm + 1 <= self.rpm_limit)

    def record(self, token_count: int):
        """记录已发送的请求"""
        now = time.time()
        self.token_log.append((now, token_count))
        self.request_log.append(now)

# 使用示例：Anthropic Tier 2 的限制
limiter = RateLimiter(tpm_limit=80_000, rpm_limit=1_000)

这种方式的好处是你可以在请求排队阶段就知道该等多久，而不是发出去之后才被拒绝。用 AI Token 计算器测量你的典型 prompt 长度，确定 estimated_tokens 的合理估值。

技巧 4：多 API Key 轮换

如果你在同一个厂商内需要更高的吞吐量，可以注册多个账号、获取多个 API Key，然后在应用层做轮换。每个 Key 有独立的速率限制配额，N 个 Key 理论上能获得 N 倍的吞吐量。

import itertools

class KeyRotator:
    """API Key 轮换器"""

    def __init__(self, api_keys: list[str]):
        self.keys = api_keys
        self.cycle = itertools.cycle(api_keys)

    def get_next_key(self) -> str:
        return next(self.cycle)

    def get_client(self):
        key = self.get_next_key()
        return OpenAI(api_key=key)

# 3 个 Key = 3 倍 RPM/TPM
rotator = KeyRotator([
    "sk-key-1-...",
    "sk-key-2-...",
    "sk-key-3-...",
])

# 每个请求用不同的 Key
client = rotator.get_client()
response = client.chat.completions.create(...)

注意： 部分厂商（如 OpenAI）可能会按组织维度聚合速率限制，而不是按 Key。确认你的多个 Key 是否来自不同组织。另外，这种做法需要遵守厂商的 ToS，不要滥用。

技巧 5：多厂商并发 + 智能路由

最强大的吞吐量策略：不把鸡蛋放在一个篮子里。将请求分发到多个厂商，每个厂商有独立的速率限制池。

import asyncio
from openai import AsyncOpenAI

# 不同厂商的 client
providers = {
    "anthropic": AsyncOpenAI(
        api_key="sk-ant-...",
        base_url="https://api.anthropic.com/v1/"
    ),
    "openai": AsyncOpenAI(api_key="sk-..."),
    "gemini": AsyncOpenAI(
        api_key="your-google-key",
        base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
    ),
    "deepseek": AsyncOpenAI(
        api_key="your-ds-key",
        base_url="https://api.deepseek.com"
    ),
}

# 每个厂商的模型和权重
routing_config = {
    "anthropic": {"model": "claude-sonnet-4-5-20241022", "weight": 30},
    "openai":    {"model": "gpt-4.1",                    "weight": 30},
    "gemini":    {"model": "gemini-2.5-flash",            "weight": 25},
    "deepseek":  {"model": "deepseek-chat",               "weight": 15},
}

async def distributed_request(messages: list) -> str:
    """按权重分发请求到不同厂商"""
    import random
    total = sum(c["weight"] for c in routing_config.values())
    roll = random.randint(1, total)

    cumulative = 0
    for provider, config in routing_config.items():
        cumulative += config["weight"]
        if roll <= cumulative:
            client = providers[provider]
            response = await client.chat.completions.create(
                model=config["model"],
                messages=messages,
            )
            return response.choices[0].message.content

    # Fallback
    return await providers["deepseek"].chat.completions.create(
        model="deepseek-chat", messages=messages
    )

这种架构下，你的总吞吐量约等于各厂商限额之和。假设你有 OpenAI Tier 3（600K TPM）+ Gemini 付费（4M TPM）+ Anthropic Tier 2（80K TPM）+ DeepSeek（1M TPM），理论上限是 568 万 TPM——远超任何单一厂商能给你的。

错误处理：429 之外的速率限制陷阱

速率限制的错误不只是 HTTP 429。实际生产中你会遇到几种情况：

标准 429 Too Many Requests

# 所有厂商都返回 429 + Retry-After header
# 正确做法：读取 Retry-After 并等待

import requests

try:
    response = requests.post(api_url, json=payload, headers=headers)
    response.raise_for_status()
except requests.exceptions.HTTPError as e:
    if e.response.status_code == 429:
        retry_after = int(e.response.headers.get("Retry-After", 60))
        print(f"被限流，{retry_after}秒后重试")
        time.sleep(retry_after)
    elif e.response.status_code == 529:
        # Anthropic 特有：服务器过载
        print("Anthropic 服务过载，建议切换到备用厂商")
    else:
        raise

Anthropic 529 Overloaded

Anthropic 有一个特殊的 529 状态码，表示服务器过载而不是你的速率限制触发。这通常发生在 Claude 的使用高峰期。遇到 529 时，重试可能没用——因为问题不在你这边，而是服务器端的负载压力。建议直接切换到备用厂商。

DeepSeek 的隐性限流

DeepSeek 在高峰期可能不会返回 429，而是显著增加响应延迟（从正常的 1-2 秒增加到 10-30 秒）。你的代码不会报错，但用户体验会急剧下降。建议设置超时阈值：

import httpx

async def call_deepseek_with_timeout(messages, timeout_seconds=10):
    """带超时检测的 DeepSeek 调用"""
    client = AsyncOpenAI(
        api_key="your-ds-key",
        base_url="https://api.deepseek.com",
        timeout=httpx.Timeout(timeout_seconds)
    )

    try:
        response = await client.chat.completions.create(
            model="deepseek-chat",
            messages=messages,
        )
        return response.choices[0].message.content
    except httpx.TimeoutException:
        print("DeepSeek 响应超时，切换到备用厂商")
        # fallback 到 Gemini Flash 或 OpenAI
        return await call_fallback(messages)

完整的错误处理框架

import time
import random
from enum import Enum

class ErrorAction(Enum):
    RETRY = "retry"
    FALLBACK = "fallback"
    ABORT = "abort"

def classify_error(status_code: int, provider: str) -> ErrorAction:
    """根据错误码和厂商决定处理策略"""
    if status_code == 429:
        return ErrorAction.RETRY
    elif status_code == 529 and provider == "anthropic":
        return ErrorAction.FALLBACK  # 服务过载，别等了
    elif status_code == 500:
        return ErrorAction.RETRY  # 服务器内部错误，值得重试
    elif status_code == 503:
        return ErrorAction.FALLBACK  # 服务不可用，切厂商
    elif status_code in (400, 401, 403):
        return ErrorAction.ABORT  # 客户端错误，不要重试
    else:
        return ErrorAction.RETRY

def robust_api_call(messages, providers_priority, max_retries=3):
    """带多厂商 Fallback 的健壮 API 调用"""
    for provider in providers_priority:
        for attempt in range(max_retries):
            try:
                return call_provider(provider, messages)
            except APIError as e:
                action = classify_error(e.status_code, provider)

                if action == ErrorAction.RETRY:
                    wait = (2 ** attempt) + random.uniform(0, 1)
                    time.sleep(wait)
                elif action == ErrorAction.FALLBACK:
                    break  # 跳到下一个厂商
                elif action == ErrorAction.ABORT:
                    raise  # 客户端错误，直接报错

    raise Exception("所有厂商都失败了")

按日请求量选厂商推荐

最后做一个总结。根据你的日均请求量，给出最直接的推荐：

每天 100 请求以下（学习 / 评估）

推荐	原因
Gemini 2.5 Flash（免费）	500 RPM，完全免费，无每日上限
Grok（$25 额度）	够用几个月的免费评估

这个量级不需要考虑速率限制，重点是不花钱。

每天 1,000-10,000 请求（原型 / 早期产品）

推荐	原因
OpenAI Tier 1-2	充 $5-50 就有 500-5000 RPM
Gemini 付费	2000 RPM + 4M TPM
DeepSeek	60 RPM 可能够，100 万 TPM 很宽裕，价格最低

这个阶段要注意 TPM 瓶颈。如果你的 prompt 平均 3000 token，Anthropic Tier 1 的 40K TPM 只够每分钟 13 个请求——远不够 1 万日请求的需求。

每天 10,000-100,000 请求（增长期产品）

推荐	原因
OpenAI Tier 3-4	5000-10000 RPM，600K-800K TPM
Gemini Vertex AI	2000 RPM + 4M TPM，性价比最高
多厂商路由	组合使用拿到更高总吞吐

这个量级强烈建议做多厂商路由。单一厂商的限额可能在流量高峰期不够用。用 AI 模型价格计算器模拟不同路由比例下的月费。

每天 100,000+ 请求（规模化产品）

推荐	原因
OpenAI Tier 5 + 企业协议	最高上限，可申请进一步提升
Gemini Vertex AI 企业	4M TPM 基础，可谈更高限额
多厂商分布式架构	必需品，不是可选

这个量级下，你需要和厂商直接谈企业合同来获取更高的限额。同时，多厂商架构从”锦上添花”变成了”架构必需”——任何单一厂商的故障都不能打瘫你的服务。

总结

速率限制是 AI API 选型中最容易被忽略但影响最大的因素之一。总结几个核心要点：

1. 各厂商差距巨大。 Gemini 付费后 400 万 TPM，OpenAI Tier 5 有 1000 万 TPM，而 Anthropic 最高只有 40 万 TPM——相差 25 倍。选型时不能只看模型能力和价格，速率限制是第三个必须考虑的维度。

2. TPM 通常比 RPM 更关键。 现在的 prompt 动辄几千 token，TPM 往往先触及上限。在架构设计阶段就要测量你的典型 prompt 长度，算清楚给定 TPM 下你实际能承载多少并发。

3. 升级 Tier 的 ROI 极高。 OpenAI 充 $5 把 RPM 从 3 拉到 500，Anthropic 消费 $40 把 TPM 从 4 万拉到 8 万——这些都是低成本高回报的动作。

4. 多厂商架构是高可用的基础。 不管你的主力模型是谁，都需要至少一个备用厂商。速率限制触发、服务故障、延迟波动——这些都需要 Fallback 策略。

5. 提前限流好过事后重试。 在应用层维护 TPM/RPM 计数器，在请求发出前就判断是否可以发送，比等到 429 返回再重试效率高得多。

想精确计算你的 prompt 会消耗多少 token？用 AI Token 计算器测量。想对比不同模型在你的用量下的月费？用 AI 模型价格计算器。

相关文章和工具：

AI API 降本 80%：8 个省钱策略 — Batch API、Prompt Caching、智能路由，含代码示例
2026 AI API 价格对比 — 7 大厂商 25+ 模型完整定价表
AI Token 计算器 — 精确计算 prompt 的 token 数和成本
AI 模型价格计算器 — 25+ 模型月费在线对比
OpenAI API 定价指南 2026 — GPT-5、GPT-4.1、o3 定价，含分层速率限制详解
Claude API 价格指南 2026 — Opus/Sonnet/Haiku 对比，Prompt Caching 省 90%
Google Gemini API 定价指南 2026 — Flash 免费额度 500 RPM，百万上下文
DeepSeek API 价格指南 — V3.2 $0.27，无分层统一限额