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

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

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

OpenAI — 账户分层，但限额因模型与项目而异

OpenAI 的 API 限额随累计付费金额、首次成功付款后的时间、模型和端点变化。GPT-5.6 Sol、Terra、Luna 没有一张可以安全复制到所有账号的通用 RPM/TPM 表。生产容量必须查看当前模型页、账户 Limits 页和响应中的 x-ratelimit-* 头。

账户层级的升级门槛仍可用于判断资格：

Tier	升级条件
Tier 1	已付 $5
Tier 2	已付 $50，首次成功付款满 7 天
Tier 3	已付 $100，满 7 天
Tier 4	已付 $250，满 14 天
Tier 5	已付 $1,000，满 30 天

API 限流也不能和 ChatGPT/Codex 订阅额度混为一谈。个人 Codex 套餐目前仍写有滚动 5 小时窗口，并说明可能存在额外周限制；Plus/Pro 用完包含额度后可以购买 credits。Enterprise/Edu 正在把管理员原有的每周 credit 控制迁移为月度 Usage limits，但这不等于所有个人周限制已经统一取消。

详细区分见 GPT-5.6 Codex 限制与多 Agent 指南。

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 公开 T0 到 T4 的消费层级，成功付款门槛依次是 $0、$50、$250、$1,000、$5,000。当前官方文档使用每秒请求数（RPS），不再提供旧文章中的通用免费 RPM 承诺。

当前 T0 与 T4 示例：

模型家族	T0 RPS	T0 TPM	T4 RPS	T4 TPM
Grok 4.5	150	50M	500	100M
Grok 4.3、Grok 4.20、Grok Build 0.1	37	10M	208	85M
Grok 4.20 Multi-Agent	9	2.5M	56	21M

这些是组织级模型池，可能由同一家族中的多个模型共享。实际部署必须查看 xAI Console，不要继续按旧的 $25 注册赠金估算。

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	更强模型，采用闲时/高峰分时价格
deepseek-chat / deepseek-reasoner	已停止	-	2026-07-24 已停止使用，改用 deepseek-v4-flash

六大厂商速率限制总表（2026 年 8 月）

提供商	模型	层级/计划	RPM	TPM	最低门槛
OpenAI	GPT-5.6 系列	因账户/模型而异	查看 Limits 页	查看 Limits 页	适用 Tier 资格
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
xAI	Grok 4.5	T4	500 RPS	100,000,000	成功付款 $5,000
Anthropic	Sonnet 4.6	Tier 4	4,000	2,000,000 ITPM / 400,000 OTPM	标准 Tier 4

这张表不能直接当排行榜：xAI 公布组织池，Anthropic 分开计算输入和输出 TPM，Gemini 以项目为准，DeepSeek 动态调度，OpenAI GPT-5.6 则要读取具体账户和模型限额。

xAI Grok：按 T0-T4 升级

计划	Grok 4.5 RPS	Grok 4.5 TPM	付款门槛
T0	150	50M	$0
T4	500	100M	$5,000

Grok 4.20 Multi-Agent 使用独立且更低的池，T0 是 9 RPS/2.5M TPM，T4 是 56 RPS/21M TPM。多 Agent 架构不能直接套用 Grok 4.5 的单模型池。

DeepSeek：无分层，动态并发

模型	公开 RPM/TPM	官方并发限制	备注
V4 Flash	动态	2500	官方推荐的新默认模型
V4 Pro	动态	500	闲时/高峰分时价格

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	无通用赠金承诺	以组织 Tier 为准	先检查 xAI Console
OpenAI GPT-5.6	不假设免费额度	以项目为准	先检查模型与 Limits 页
DeepSeek	无免费，按时段计价	动态并发	先按高峰价做预算
Anthropic	无免费	50 RPM / 30K ITPM / 8K OTPM	需充钱

结论：原型阶段优先看 Gemini 和 DeepSeek。Gemini 的有效配额要在 AI Studio 查看；DeepSeek 没有固定公开 RPM/TPM 表，但价格很低，适合配合队列和超时策略测试。OpenAI 和 xAI 都应先检查当前项目的实际资格与账单状态。

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

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

厂商	推荐 Tier	RPM	TPM	月估计成本
OpenAI	GPT-5.6 项目限额	以账户为准	以账户为准	按量计费
xAI	Grok 4.5 T0	150 RPS	50M	按量计费
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 都要读取项目实际配额，xAI 要读取组织 Tier，DeepSeek 则按动态并发做队列和备用路由。

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

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

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

厂商	推荐计划	RPM	TPM	特点
OpenAI	GPT-5.6 项目/企业限额	以账户为准	以账户为准	可申请提升
xAI	Grok 4.5 T4	500 RPS	100M	公开组织池
Gemini (Vertex AI / AI Studio)	项目配额 / 企业合同	以项目为准	以项目为准	可申请提升
Anthropic (Tier 4)	标准 Tier 4	4,000	2M ITPM / 400K OTPM	输出 TPM 偏紧
DeepSeek	无固定公开层级	动态	动态	按动态并发处理

结论：企业级要以合同和有效项目配额为准。 xAI 公布 Grok 4.5 T4 为 100M TPM；OpenAI 和 Gemini 则需要在具体项目或企业合同中确认，不能继续沿用 GPT-5 时代的固定表。

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

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

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

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

1. 请求队列是必须的

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

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

2. 多厂商 Fallback 策略

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

• 主力模型 → GPT-5.6 Terra 或 Claude Sonnet 4.x
• 一级 Fallback → GPT-5.6 Luna（先确认是否为独立模型池）
• 二级 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 限额是 450K ITPM 和 90K OTPM。如果每次平均输入 3,000、输出 1,000 token，输出池大约只能支持每分钟 90 次请求，远早于 1,000 RPM。

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 读取项目的实时配额，DeepSeek V4 Flash 承接低成本、缓存命中率高的重复上下文流量；GPT-5.6 Sol 和 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	不假设赠金，先检查 xAI Console 的组织 Tier

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

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

推荐	原因
OpenAI GPT-5.6	Tier 决定资格，实际 RPM/TPM 看项目 Limits 页
Gemini 付费	以 AI Studio 项目配额为准，适合和 OpenAI 互为备用
DeepSeek	动态并发，价格最低，适合有队列和 fallback 的低成本流量

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

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

推荐	原因
OpenAI GPT-5.6 / xAI Grok 4.5	分别读取项目 Limits 页和组织 Tier
Gemini Vertex AI / AI Studio	项目配额制，性价比高但要看控制台有效限额
多厂商路由	组合使用拿到更高总吞吐

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

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

推荐	原因
OpenAI / xAI / Anthropic 企业协议	以合同限额和独立备用池为准
Gemini Vertex AI 企业	以项目/合同配额为准，可谈更高限额
多厂商分布式架构	必需品，不是可选

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

总结

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

1. 各厂商口径不同。 xAI 公布组织级 RPS/TPM 池；Anthropic Tier 4 是 200 万 ITPM / 40 万 OTPM；OpenAI 和 Gemini 必须查看当前项目限额。选型时不能只看模型能力和价格。

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

3. Tier 只决定资格，不保证一张通用数字表。 OpenAI、Anthropic 和 xAI 升级层级后通常会提高可用容量，但生产系统必须读取当前账户的有效限额。

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.6 Sol/Terra/Luna、缓存与长上下文计费
• Grok API 定价指南 2026 — Grok 4.5、4.3、4.20 与 Build 0.1
• 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 成本拆解

2026 年 7 月 14 日核对的官方限流来源：OpenAI API 限流指南、OpenAI Codex 定价、Anthropic 限流、Gemini 限流、xAI 限流 和 DeepSeek 限流行为。