只限 RPM，不限 TPM

维度	限制
RPM（每分钟请求数）	60 次 / 分钟
TPM（每分钟 token 数）	无限制
并发数	与 RPM 档位同步提升

也就是说：请求发得够快不会被卡，但请求发得太多会被卡。一次请求里塞多长的上下文都不影响限流判定。

需要更高 RPM 怎么办

累计充值 / 消费达到 $500 后，可以提交工单申请升级档位：

档位	申请条件	效果
默认	—	RPM 60 / 分钟
T2 – T4	累计额度达到 $500	提高 RPM 与并发速率，具体档位由工单评估确定

升级走工单，不需要改代码——档位调整后你的 Key 立即生效。

超限会怎样

返回 HTTP 429 Too Many Requests。

客户端必须实现指数退避，否则重试风暴只会让情况更糟：

import time
from openai import OpenAI, RateLimitError

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.wxiai.com/v1")

def request_with_backoff(messages, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="grok-4.6",
                messages=messages,
            )
        except RateLimitError:
            time.sleep(2 ** attempt)   # 1s, 2s, 4s, 8s, 16s
    raise RuntimeError("重试次数用尽")

三种 429，处理方式不一样

排查时先分清是哪一类，否则会白折腾：

类型	触发条件	特征	怎么办
RPM 超限	一分钟内请求数超过 60	降速后立刻恢复	加退避重试；长期不够就申请升档
额度不足	余额 / 配额用尽	换模型也一样失败	充值，见 错误码 的 insufficient_quota
上游限流	上游 Grok 按自己的档位判定	报错里带上游原文	只能退避重试，或降低瞬时并发

接入建议

• 退避要带随机抖动：纯指数退避会让所有客户端在同一时刻一起重试，加 ±20% 的随机量能打散。
• 429 只对请求数敏感：既然不限 TPM，把多次小请求合并成一次大请求，比拆成很多次小请求更不容易触发限流。
• 流式请求的重试逻辑要单独写：流已经吐了一部分再重试，用户会看到内容重复。
• 长连接别和短请求共用一个并发池：实时语音这类长连接会长时间占住并发额度。
• 别为每个用户开一条长连接：RPM 是 60/分钟，连接建立本身也占请求额度。

具体数值在哪看

• 控制台：https://api.wxiai.com
• 模型与价格：https://api.wxiai.com/models

相关页

• 错误码 —— 429 之外的其他错误怎么判断
• 模型列表 —— 程序化查询当前可用的模型