AI API 速率限制对比 2026：OpenAI、Claude、Gemini、DeepSeek RPM 与 TPM

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

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

OpenAI — 按累计付费和账号时间升级

OpenAI 的 API 限额随累计付费金额和首次成功付款后的时间提升，具体 RPM/TPM 还会因模型而异。

GPT-5.4 与 GPT-5 当前速率限制：

模型	Tier	升级条件	RPM	TPM
GPT-5.4	Free	不支持	—	—
GPT-5.4	Tier 1	已付 $5	500	500,000
GPT-5.4	Tier 2	已付 $50 + 7 天	5,000	1,000,000
GPT-5.4	Tier 3	已付 $100 + 7 天	5,000	2,000,000
GPT-5.4	Tier 4	已付 $250 + 14 天	10,000	4,000,000
GPT-5.4	Tier 5	已付 $1,000 + 30 天	15,000	40,000,000
GPT-5	Free	不支持	—	—
GPT-5	Tier 1	已付 $5	500	500,000
GPT-5	Tier 2	已付 $50 + 7 天	5,000	1,000,000
GPT-5	Tier 3	已付 $100 + 7 天	5,000	2,000,000
GPT-5	Tier 4	已付 $250 + 14 天	10,000	4,000,000
GPT-5	Tier 5	已付 $1,000 + 30 天	15,000	40,000,000

推理模型示例（Tier 3）：

模型	RPM	TPM
o3	5,000	800,000
o3-mini	5,000	4,000,000

Anthropic Claude — RPM、输入 TPM、输出 TPM 分开计算

Anthropic 的 Messages API 不适合再写成单一 TPM。官方文档按 RPM、input tokens per minute (ITPM)、output tokens per minute (OTPM) 分开计数。

Claude Opus 4.6 / Sonnet 4.6 当前速率限制：

Tier	RPM	ITPM	OTPM
Tier 1	50	30,000	8,000
Tier 2	1,000	450,000	90,000
Tier 3	2,000	800,000	160,000
Tier 4	4,000	2,000,000	400,000

Anthropic 官方文档把 Opus 4.x 和 Sonnet 4.x 按模型家族共享速率限制，而不是给每个小版本单独列限额。多数当前 Claude 模型的缓存读取 token 不计入 ITPM，因此缓存命中高的工作负载，实际输入吞吐会比表面数字更高。

Google Gemini — 基于层级的弹性吞吐

Google 的速率限制体系已经演变为复杂的项目配额制。官方文档明确说：实际限额取决于用量层级、账号状态等因素，应在 AI Studio 查看；文档中的指定限额也不保证一定可用。因此，Gemini 3.x 不适合在文章里写成稳定的通用 RPM/TPM 表。

Gemini 2.5 系列（用于规划器的保守基线）：

计划	RPM	TPM	每日上限
Tier 1 (2.5 Pro)	150	2,000,000 输入 TPM	10,000
Tier 1 (2.5 Flash)	1,000	1,000,000 输入 TPM	10,000
Tier 1 (2.5 Flash-Lite)	4,000	4,000,000 输入 TPM	以 AI Studio 为准

Google 体系的关键点：

• 免费层和付费层都要看项目配额。不要把网上流传的 Gemini RPM 表直接写进生产容量规划。
• 开启结算后通常会提升配额，但 Google 官方仍要求到 AI Studio 查看有效速率限制。
• 上下文窗口影响：处理极长上下文（1M+ token）的单次请求可能会有额外的延迟，且不完全受 TPM 桶的简单加减法控制。

xAI (Grok) — 免费额度 + 动态层级

xAI 提供 $25 的起步免费额度，速率限制随账单历史增长。

Grok 3 & 4 速率限制：

模型	免费层 RPM	免费层 TPM	付费 RPM	付费 TPM
Grok 4	60	100,000	最高 2,000	最高 1,000,000
Grok 3 Mini	100	200,000	最高 4,000	最高 2,000,000

DeepSeek — 动态并发，无付费层级

DeepSeek V4 不适合写成固定 RPM/TPM 表。英文官方文档说 API 会根据服务器负载动态限制并发，达到限制时返回 429；中文官方文档则强调不限制用户并发量，但高流量压力下请求可能排队，并通过空行或 SSE keep-alive 保持连接。生产规划应按“无固定公开表 + 可能排队/429”处理。

DeepSeek V4 当前行为：

模型	公开 RPM/TPM	官方并发限制	备注
DeepSeek V4 Flash (deepseek-v4-flash)	动态	2500	低成本 Agent 流量默认首选
DeepSeek V4 Pro (deepseek-v4-pro)	动态	500	更强模型，5月31日后正式调整为原定价 1/4
deepseek-chat / deepseek-reasoner	兼容别名	-	计划 2026-07-24 弃用

六大厂商速率限制总表 (2026 年 5 月)

提供商	模型	层级/计划	RPM	TPM	最低门槛
OpenAI	GPT-5.4 / GPT-5	Tier 5	15,000	40,000,000	$1,000 + 30 天
OpenAI	GPT-5.4 / GPT-5	Tier 3	5,000	2,000,000	$100 + 7 天
Google	Gemini 2.5 Flash-Lite	Tier 1 基线	4,000	4,000,000 输入 TPM	开启结算
Google	Gemini 2.5 Pro	Tier 1 基线	150	2,000,000 输入 TPM	开启结算
DeepSeek	V4 Flash	动态	动态	动态	$0
Anthropic	Sonnet 4.6	Tier 4	4,000	2,000,000 ITPM / 400,000 OTPM	标准 Tier 4

结论：

• 如果你需要最高公开标准限额，OpenAI GPT-5.4 / GPT-5 Tier 5 是目前最清晰的上限。
• 如果你需要快速上量，Gemini 需要以 AI Studio 里的项目配额为准。
• 如果你需要极低成本/高吞吐，DeepSeek V4 是不二之选。
• 注意：Anthropic 要按 ITPM/OTPM 分开评估，生成型负载通常先碰到 OTPM。

xAI Grok：$25 免费额度起步

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

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

DeepSeek：无分层，动态并发

模型	公开 RPM/TPM	官方并发限制	备注
V4 Flash	动态	2500	官方推荐的新默认模型
V4 Pro	动态	500	5月31日后正式调整为原定价 1/4

DeepSeek 的策略最简单——没有公开的付费层级，也没有“消费多少解锁多少 TPM”的固定阶梯。真正要关注的是排队时间、超时、429 和 503，而不是表格里的固定数值。

不过，DeepSeek 有一个其他厂商不太有的问题：高峰期拥堵。国内开发者集中使用的时段（工作日白天），实际响应延迟可能显著增加。建议所有生产调用都设置超时、队列和备用厂商。

Mistral：简单明了

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

Mistral 的速率限制在主流厂商中偏宽松，300 RPM 的默认值高于 Anthropic Tier 1（50），但低于 OpenAI Tier 2+（5000+）和 Gemini 付费（2000）。DeepSeek 现在应单独按动态并发评估，而不是拿固定 RPM 表硬比。

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

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

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

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

厂商	免费额度	速率限制	推荐度
Gemini Flash / Flash-Lite	免费层	以 AI Studio 为准	首选之一
Grok	$25 额度	60 RPM	适合短期评估
OpenAI GPT-5	Free 不支持	—	不适合作为免费 API 路线
DeepSeek	无免费，但极便宜	动态并发	充 $1 能用很久
Anthropic	无免费	50 RPM / 30K ITPM / 8K OTPM	需充钱

结论：原型阶段优先看 Gemini 和 DeepSeek。Gemini 的有效配额要在 AI Studio 查看；DeepSeek 没有固定公开 RPM/TPM 表，但价格很低，适合配合队列和超时策略测试。OpenAI GPT-5 当前 API 文档显示 Free tier 不支持。

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

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

厂商	推荐 Tier	RPM	TPM	月估计成本
OpenAI (Tier 2-3)	消费 $50-100 + 账号时间	5,000	1M-2M	$200-800
Gemini (付费)	AI Studio / Vertex 配额	以项目为准	以项目为准	$100-300
DeepSeek	默认	动态	动态	$5-100
Anthropic (Tier 2-3)	标准 Tier 2-3	1,000-2,000	450K-800K ITPM / 90K-160K OTPM	$300-1,000

结论：OpenAI 和 Gemini 是创业期最稳的选择。OpenAI 的 Tier 2-3 RPM 明确，生态工具成熟；Gemini 的上限取决于你的项目配额，需要以 AI Studio 为准。DeepSeek V4 Flash 价格最低、缓存命中成本极低，但要按动态并发来做队列和备用路由。

如果你一定要用 Claude——比如因为它的代码能力确实强——Anthropic 的 OTPM 和加速限制是实际问题。长输出场景下，90K-160K OTPM 可能先成为瓶颈；缓存命中高的长输入场景则会好很多。

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

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

厂商	推荐计划	RPM	TPM	特点
OpenAI (Tier 5)	消费 $1,000 + 30 天	15,000	40M	最高公开标准上限
Gemini (Vertex AI / AI Studio)	项目配额 / 企业合同	以项目为准	以项目为准	可申请提升
Anthropic (Tier 4)	标准 Tier 4	4,000	2M ITPM / 400K OTPM	输出 TPM 偏紧
DeepSeek	无固定公开层级	动态	动态	按动态并发处理

结论：企业级首选 OpenAI 或企业合同。OpenAI Tier 5 的 40M TPM 和 15K RPM 是目前最清晰的公开标准上限；如果还不够，可以联系 OpenAI、Google 或 Anthropic 申请定制限额。

Anthropic 在企业场景下的最大软肋通常是输出速率限制——40 万 OTPM 对于高吞吐长输出应用来说仍然偏紧。当然你可以通过缓存、模型拆分和企业提额来缓解，但这增加了架构复杂度。

DeepSeek 没有公开固定 RPM/TPM 阶梯，动态并发也不适合承诺强 SLA，但作为辅助路由的一环（尤其是处理低优先级、重复上下文、低成本任务）很有价值。

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

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

1. 请求队列是必须的

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

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

2. 多厂商 Fallback 策略

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

• 主力模型 → Claude Sonnet 4.x
• 一级 Fallback → GPT-5 Nano（不同模型池，独立限额）
• 二级 Fallback → Gemini 2.5 Flash（最宽的限额）
• 三级 Fallback → DeepSeek V4 Flash（最便宜的兜底）

多厂商 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_codex": AsyncOpenAI(api_key="sk-..."),
    "openai_frontier": AsyncOpenAI(api_key="sk-..."),
    "gemini_flash": 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 = {
    "deepseek":        {"model": "deepseek-v4-flash", "weight": 45},
    "gemini_flash":    {"model": "gemini-2.5-flash",  "weight": 25},
    "openai_codex":    {"model": "gpt-5.2-codex",     "weight": 15},
    "openai_frontier": {"model": "gpt-5.5",           "weight": 10},
    "anthropic":       {"model": "claude-sonnet-4-6", "weight": 5},
}

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-v4-flash", messages=messages
    )

这种架构下，你的吞吐量不再依赖单一厂商。OpenAI/Gemini 提供明确的 RPM/TPM 池，DeepSeek V4 Flash 承接低成本、缓存命中率高的重复上下文流量；GPT-5.5 和 Claude 只处理少量高难度升级任务。

错误处理：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-v4-flash",
            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 / Flash-Lite（免费）	有免费层，但有效 RPM/RPD 以 AI Studio 为准
Grok（$25 额度）	够用几个月的免费评估

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

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

推荐	原因
OpenAI Tier 1-2	充 $5-50 就有 500-5000 RPM
Gemini 付费	以 AI Studio 项目配额为准，适合和 OpenAI 互为备用
DeepSeek	动态并发，价格最低，适合有队列和 fallback 的低成本流量

这个阶段要注意输入和输出 token 瓶颈。如果你的 prompt 平均 3000 输入 token，Anthropic Tier 1 的 30K ITPM 大约只够每分钟 10 个未缓存请求；如果输出很长，8K OTPM 会更早成为瓶颈。

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

推荐	原因
OpenAI Tier 3-4	5000-10000 RPM，2M-4M TPM
Gemini Vertex AI / AI Studio	项目配额制，性价比高但要看控制台有效限额
多厂商路由	组合使用拿到更高总吞吐

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

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

推荐	原因
OpenAI Tier 5 + 企业协议	最高上限，可申请进一步提升
Gemini Vertex AI 企业	以项目/合同配额为准，可谈更高限额
多厂商分布式架构	必需品，不是可选

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

总结

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

1. 各厂商差距巨大。 OpenAI Tier 5 目前公开到 4000 万 TPM；Anthropic Tier 4 是 200 万 ITPM / 40 万 OTPM；Gemini 必须查看 AI Studio 当前项目限额。选型时不能只看模型能力和价格，速率限制是第三个必须考虑的维度。

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

3. 升级 Tier 的 ROI 极高。 OpenAI 充 $5 进入 Tier 1 后，GPT-5 / GPT-5.4 可用到 500 RPM 和 50 万 TPM；Anthropic 升到更高 Tier 后 ITPM/OTPM 都会提升。这些都是低成本高回报的动作。

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-5 Nano、o3 定价，含分层速率限制详解
• Claude API 价格指南 2026 — Opus/Sonnet/Haiku 对比，Prompt Caching 省 90%
• Google Gemini API 定价指南 2026 — Gemini 2.5 Pro/Flash、免费层和百万上下文
• DeepSeek API 价格指南 — V4 Flash 缓存命中价、V4 Pro 永久降价和 Agent 成本拆解