grok-4.7 调用一直 429 怎么办？不是额度用完——是 RPM 和 TPM 双桶限流，附响应头读取代码和退避策略

标题：grok-4.7 调用一直 429 怎么办？不是额度用完------是 RPM 和 TPM 双桶限流，附响应头读取代码和退避策略

正文：

上周三晚上我在跑一个批量摘要任务，把模型从 grok-4.6 切到 grok-4.7，同样的代码、同样的 Key，grok-4.6 跑得好好的，4.7 直接开始疯狂吐 429。一开始以为是额度用完了，登上 console.x.ai 一看------余额充足，RPD（日请求配额）也没到。排查了大半天才搞明白：grok-4.7 的 RPM（每分钟请求数）上限比 grok-4.6 收紧了不少，而且 RPM 桶和 TPM（每分钟 token 数）桶是独立计算的，任意一个触顶都会返回 429。你必须同时读响应头里的剩余请求数和剩余 token 数，分别判断是哪个桶触限了，然后用对应的退避策略处理。盲目 time.sleep(60) 是最常见的反模式。

注意：本文涉及的 RPM/TPM 具体数字均为个人实测估算，xAI 官方未公开精确配额数值，且配额可能因账户等级和消费额度不同而变化。所有数字仅供参考，请以实际响应头返回值为准。

为什么 grok-4.7 比 grok-4.6 更容易触发 429

先贴一下大概率见过的报错原文：

复制代码

openai.RateLimitError: Error code: 429 - {
  'error': {'message': 'Rate limit exceeded',
            'type': 'rate_limit_error',
            'code': 'rate_limit_exceeded'}
}

看到这个不必慌张。429 不是 bug，是 xAI 的流量保护机制在正常工作。

更棘手的是 TPM 桶也独立收紧了。你可能 RPM 还没到，但单次请求 token 太长（比如塞了一整篇文章做摘要），TPM 桶先到顶了，照样 429。两个桶独立计算，任意一个耗尽都触发限流。

graph TD A[你的请求] --> B{xAI 网关检查} B -->|RPM 桶剩余 > 0 且 TPM 桶剩余 > 0| C[正常返回 200] B -->|RPM 桶耗尽| D[返回 429] B -->|TPM 桶耗尽| D D --> E[读响应头判断哪个桶触限] E -->|remaining-requests = 0| F[RPM 超限：降并发] E -->|remaining-tokens = 0| G[TPM 超限：缩 token]

方案一：先诊断，不要盲目重试------读响应头判断是哪个桶

收到 429 的第一反应往往是加个 sleep 硬等。先别急，看响应头。

说明：以下响应头字段名（x-ratelimit-remaining-requests 等）参考自 OpenAI 兼容 API 规范。xAI API 是否完全采用相同字段名，官方文档未明确列出，建议实际打印全部响应头确认字段名称。API 端点请以 xAI 官方文档为准。

python 复制代码

import httpx

# 注意：端点地址请以 xAI 官方文档（https://docs.x.ai）为准
resp = httpx.post(
    'https://api.x.ai/v1/chat/completions',
    headers={'Authorization': 'Bearer YOUR_KEY'},
    json={'model': 'grok-4.7', 'messages': [{'role': 'user', 'content': 'hi'}]}
)
print(f"状态码: {resp.status_code}")
# 先打印全部响应头，确认实际字段名，再针对性读取
print(f"全部响应头: {dict(resp.headers)}")

确认字段名后，再针对性地读取：

python 复制代码

# 以下字段名参考 OpenAI 兼容规范，xAI 是否采用相同字段名需实测确认
# 建议先通过上方打印全部响应头的方式验证，再使用下列代码
print(f"RPM剩余: {resp.headers.get('x-ratelimit-remaining-requests')}")
print(f"TPM剩余: {resp.headers.get('x-ratelimit-remaining-tokens')}")
print(f"RPM上限: {resp.headers.get('x-ratelimit-limit-requests')}")
print(f"TPM上限: {resp.headers.get('x-ratelimit-limit-tokens')}")
print(f"retry-after: {resp.headers.get('retry-after')}")

remaining-requests 耗尽说明是 RPM 超限（并发太高），remaining-tokens 耗尽说明是 TPM 超限（单次请求太长或短时间内总 token 太多）。两个都不是零？那可能是 RPD（日配额）到了，去 console.x.ai 看一眼。

还有一种棘手的情况：响应头完全没有这些字段，body 也是空的，只有一个光秃秃的 RateLimitError: 429 status code (no body)。这种一般是网络层截断了响应，换个网络环境或者走聚合网关通常能解决。

方案二：双桶退避策略------优先读 retry-after，回退指数退避

确认了是哪个桶之后，重试策略要分开处理。核心逻辑：

python 复制代码

import time
import openai

def call_with_retry(client, max_retries=5, **kwargs):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(**kwargs)
        except openai.RateLimitError as e:
            # openai-python v1.x 中，RateLimitError 继承自 APIStatusError，
            # e.response 是 httpx.Response 对象，可直接调用 .headers.get()
            # retry_after 不一定作为属性直接挂在异常对象上，优先从响应头提取
            wait = None
            try:
                wait = float(e.response.headers.get('retry-after') or 0) or None
            except Exception:
                pass
            if wait is None:
                wait = 2 ** attempt  # 指数退避：1s → 2s → 4s → 8s → 16s
            print(f"429，第 {attempt + 1} 次重试，等待 {wait}s")
            time.sleep(wait)
    raise RuntimeError('超过最大重试次数')

优先取 retry-after 头里的等待时间。xAI 的 API 在 429 响应里通常会带这个头，告诉你具体等多少秒。只有拿不到这个值的时候，才降级到指数退避（1s → 2s → 4s → 8s → 16s）。

之前犯的错是每次都 time.sleep(60) 硬等一分钟。实际上 retry-after 经常只要求等 3--5 秒，白白浪费了 55 秒。反过来，如果 retry-after 说等 120 秒只等了 4 秒就重试，那就是在浪费重试次数。

方案三：并发场景用 Semaphore 控制请求频率

如果是批量任务（摘要场景就是这种），单靠重试不够，需要在发送端主动限速。以下示例以"实测估算约 30 RPM"为目标进行配置，实际参数请根据你账户的真实配额调整：

API 端点说明 ：base_url 请以 xAI 官方文档为准。

python 复制代码

import asyncio
from openai import AsyncOpenAI

sem = asyncio.Semaphore(2)
client = AsyncOpenAI(
    api_key='YOUR_KEY',
    base_url='https://api.x.ai/v1'  # 请以 xAI 官方文档确认实际端点
)

然后每个请求都走 Semaphore：

python 复制代码

async def safe_call(messages):
    async with sem:
        resp = await client.chat.completions.create(
            model='grok-4.20', messages=messages
        )
        await asyncio.sleep(4)  # 主动限速，在请求完成后等待
        return resp

# 调用示例（最小可运行入口）：
# async def main():
#     tasks = [safe_call(m) for m in all_messages]
#     results = await asyncio.gather(*tasks)
#     return results
#
# if __name__ == '__main__':
#     asyncio.run(main())
#
# 更复杂的任务队列场景请参考 asyncio 官方文档

关于参数选择的说明 ：Semaphore(2) + sleep(4s) 的理论上限 ≤ 30 RPM（仅在请求本身耗时趋近于零时才能接近此值）。实际上 asyncio.sleep(4) 是在请求完成后才执行，每个槽的实际周期 = 请求耗时 + 4s，真实吞吐会低于 30 RPM。因此这是一个保守配置，留有余量，不会刚好"卡线"。如果你的账户实际 RPM 上限更高，可以适当调大 Semaphore 或缩短 sleep。

如果你之前用过 Semaphore(5) + sleep(2s) 的配置：请求时延为零时理论上限为 5 ÷ 2s × 60 = 150 RPM，实际因请求延迟低于此值，但仍远超 30 RPM 的估算上限，因此需要降低并发或增大间隔。

这个吞吐对批量任务确实有点慢。如果你的场景对延迟不那么敏感，可以考虑通过 API 聚合网关来调用------比如 OpenRouter 或 ofox.io 这类平台，有些网关会在服务端做请求队列和限流平滑，客户端代码不用自己维护 Semaphore。不过这不能突破 xAI 本身的配额上限，只是让客户端逻辑简单一些。

方案四（治本）：降 token 或换模型混用

TPM 桶超限的话，退避策略只是缓解手段，更有效的办法：

缩短 system prompt。把一个 1200 token 的 prompt 压到 400，TPM 压力直接降了三分之二
长文本分段发，每段控制在 2000 token 以内
非核心任务降级到 grok-4.6 或 grok-4.5，它们的配额宽松得多
混合调度：重要请求走 grok-4.7，普通请求走 grok-4.6，代码里加个路由逻辑就行

目前的做法是在聚合平台上同时配好 grok-4.7 和 grok-4.6 的 Key，代码里根据任务优先级自动切换模型。聚合平台的好处是改个 model 参数就行，不用换 base_url。

常见问题 FAQ

Q: grok-4.7 的 RPM 和 TPM 具体是多少？

xAI 官方没有在公开文档里给出 grok-4.7 的精确配额数字。正文中提到的"约 30 RPM"是个人实测付费账户的粗略估算，不同账户等级和消费额度下数字可能差异很大，不应作为精确参考。最准确的方式是读响应头 x-ratelimit-limit-requests 和 x-ratelimit-limit-tokens（字段名以实际返回为准），它们会返回你当前账户的实际上限。

Q: 免费账户和付费账户的限流差距大吗？

差距非常大。社区反馈免费层通常限制在个位数 RPM（比如 5 RPM），付费层根据消费额度动态提升。如果是免费账户还在跑批量任务，429 几乎是必然的。

Q: 收到 429 后 retry-after 头没有怎么办？

降级到指数退避：第 1 次等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒，以此类推。上面的代码示例已经覆盖了这个逻辑。另外检查一下是不是遇到了 429 status code (no body) 的情况------这种通常是网络层问题，换个请求路径（比如走聚合网关 ofox.io 或 OpenRouter）可能就有完整响应头了。

Q: 我用 Claude Code / Cline 调 grok-4.7 也报 429，怎么配置限流？

这些工具底层也是走 OpenAI 兼容 SDK，429 的根因一样。在工具的配置文件里找到并发设置，把最大并发请求数降到 2 以下。Cline 中可以查找并发相关配置项（具体字段名请以你所用版本的官方文档为准），设成 1 最保险。

Q: grok-4.7 和 grok-4.6 的 429 报错信息一样，怎么区分？

报错信息确实一模一样，都是 rate_limit_exceeded。区分的方式是看响应头里的限额字段值------4.7 的上限数字比 4.6 低。建议在日志里同时记录 model 名和响应头，方便事后排查。

最终方案小结

经过上述排查，目前的配置是：Semaphore(2) + sleep(4) 控制并发，优先读 retry-after 做退避，system prompt 压到 400 token 以内，非核心任务自动降级到 grok-4.6。跑了三天，零 429。

最大的教训其实不是技术层面的------而是没有意识到同一个厂商的新旧模型配额会差这么多。以后换模型第一步：先发一个请求，打印全部响应头看配额，再上批量任务。这个习惯能省下好几个小时的排查时间。