glm-5.2 一直报 429 但 glm-5.1 同样的 Key 没问题怎么办？不是额度用完了，是新版独有的双轨并发限速

阅读前说明：本文描述的 glm-5.1 / glm-5.2 双轨限速行为、TPM 数值、滑动窗口粒度、retry-after header 等细节，均来自作者个人实测推断，尚无官方公开文档支撑，相关结论应视为经验性参考而非确认事实。glm-5.1、glm-5.2均为真实存在的模型 ID（可在智谱 API 平台实际调用验证），但智谱官方尚未就下述限速机制发布详细说明，请以官方最新文档为准。

把一个 RAG pipeline 从 glm-5.1 升级到 glm-5.2，跑了不到两分钟就开始疯狂 429。同一个 API Key 切回 glm-5.1 立刻恢复正常。折腾了大半天才搞明白：glm-5.2 疑似引入了 RPM（requests-per-minute）+ TPM（tokens-per-minute）双轨并发窗口限速，而 glm-5.1 只有单一的 RPM/QPM 限制。解决方案是指数退避 + 请求队列拆分，或者走聚合网关让平台帮你做流量整形。下面把完整排查过程和代码贴出来。

为什么会出现这个问题

glm-5.1 沿用的是较早一代限速策略——纯 RPM（requests per minute）计数，比如付费账户 RPM=60，只要一分钟内请求数不超 60 就行，不管每次请求塞了多少 token。

根据实测推断，glm-5.2 的限速升级为双轨（以下为推测，非官方确认信息）：

graph TD A[你的请求] --> B{RPM 检查} B -->|超限| C[429 Too Many Requests] B -->|通过| D{TPM 检查} D -->|超限| C D -->|通过| E[正常响应 200]

两道关卡任何一道触发都会返回 429。这就是为什么你觉得"请求频率没变啊"但还是被限——因为 glm-5.2 的长上下文场景下，一条请求可能吃掉几万 token 的 TPM 配额。

实际报错长这样：

HTTPError: 429 Client Error: Too Many Requests for url: https://open.bigmodel.cn/api/paas/v4/chat/completions {"error":{"code":"rate_limit_exceeded","message":"Rate limit reached for model glm-5.2: TPM quota exhausted, retry after 12s"}}

注意 message 里会告诉你是 RPM 还是 TPM 触发的，以及建议等待秒数。glm-5.1 的 429 只会说 "rate_limit_exceeded" 不带 TPM/RPM 区分——这是最直观的版本差异（此差异为实测观察，非官方文档描述）。

glm-5.1 vs glm-5.2 限速规则对比

⚠️ 下表中标注"实测近似值"的数据均为作者个人测试推断，未经官方文档证实，仅供参考。

关键差异（以下为实测推断）：glm-5.2 的 TPM 窗口疑似为10 秒粒度的滑动窗口，不是整分钟翻转。这意味着你在第 0–10 秒内连续发了 3 条长 prompt（每条 15,000 tokens），瞬间耗尽 40k TPM，接下来 50 秒内所有请求都会 429——哪怕 RPM 还没用完。

方案一：指数退避重试（最简单）

用tenacity库做退避，遇到 429 时按指数间隔重试。如果响应体里有retry-after建议值，可以手动解析后作为wait参数的下界，但下面的示例使用固定指数退避，已能覆盖大多数场景：

from tenacity import retry, wait_exponential, stop_after_attempt from zhipuai import ZhipuAI client = ZhipuAI(api_key="your_api_key")

装饰器配置——指数退避，等待下界 2 秒、上界 30 秒，最多重试 5 次（wait_exponential(multiplier=1, min=2, max=30)的实际等待时间为clamp(1 × 2^(n-1), 2, 30)秒，首次重试约 2 秒）：

@retry(wait=wait_exponential(multiplier=1, min=2, max=30), stop=stop_after_attempt(5)) def call_glm(prompt: str) -> str: resp = client.chat.completions.create( model="glm-5.2", messages=[{"role": "user", "content": prompt}]) return resp.choices[0].message.content

这个方案能解决偶发的 429，但如果你的并发量本身就贴着上限跑，退避只是把错误延后了，不是根治。

方案二：请求队列拆分（治本）

思路是把并发请求塞进一个令牌桶队列，同时控制 RPM 和 TPM 两个维度。

⚠️ 注意：以下代码中 TPM 限制数值（35,000）和窗口粒度（10 秒）均为基于实测推断的经验值，并非官方确认参数，请根据实际观察到的限速行为自行调整。

import asyncio import time class DualRateLimiter: def __init__(self, rpm=50, tpm=35000): # rpm=50：付费账户约 60 RPM × 0.83，留安全余量 # tpm=35000：基于约 40k 实测推断值留 buffer self.rpm = rpm self.tpm_remaining = tpm self.tpm_limit = tpm self._rpm_timestamps: list[float] = [] self._lock = asyncio.Lock()

每次请求前先估算 token 数，RPM 用滑动窗口计数，TPM 不足则等待。注意：等待期间需先释放锁，避免其他协程被阻塞：

async def acquire(self, estimated_tokens: int): while True: async with self._lock: now = time.monotonic() # 清理 60 秒之前的请求记录 self._rpm_timestamps = [ t for t in self._rpm_timestamps if now - t < 60 ] rpm_ok = len(self._rpm_timestamps) < self.rpm tpm_ok = self.tpm_remaining >= estimated_tokens if rpm_ok and tpm_ok: self._rpm_timestamps.append(now) self.tpm_remaining -= estimated_tokens return # 两个条件均满足，持锁期间完成状态更新后立即释放 # 条件不满足时在锁外等待，避免持锁阻塞其他协程 await asyncio.sleep(0.5)

每 10 秒重置 TPM 配额（基于实测推断的窗口粒度，非官方确认值；此处为固定周期硬重置，与真实滑动窗口语义不同，实际效果是每个 10 秒周期开始时恢复全量配额）：

async def refill_loop(self): while True: await asyncio.sleep(10) async with self._lock: self.tpm_remaining = self.tpm_limit

使用时需显式启动refill_loop协程，否则 TPM 配额永远不会恢复：

limiter = DualRateLimiter(rpm=50, tpm=35000) async def main(): asyncio.create_task(limiter.refill_loop()) # 必须启动，否则 TPM 不恢复 # ... 你的业务逻辑

RPM 限制通过acquire中的滑动窗口时间戳实现，无需额外重置逻辑。

方案三：走聚合网关让平台帮你做流量整形

方案二写起来不难，但维护起来烦——如果限速参数发生变化，硬编码的数值就需要重新调整。

另一个思路是用 API 聚合平台（如 OpenRouter、ofox.io 这类），网关层自带限流排队和自动重试。改动量就一行 base_url：

import openai client = openai.OpenAI( api_key="your-gateway-key", base_url="https://api.ofox.io/v1")

调用方式完全不变：

resp = client.chat.completions.create( model="glm-5.2", messages=[{"role": "user", "content": "你好"}])

利益披露：本文提及 ofox.io 仅基于个人使用体验，作者与该平台无商业关系。ofox.io 宣称"0% 加价对齐官方价格"及"官方授权服务商"等资质，作者无法独立核实，请读者自行评估。各聚合平台的手续费结构因模型和套餐不同而异，建议以各平台官方页面公示信息为准。

聚合平台的重试策略不一定对所有场景都最优——如果你的 pipeline 对延迟极度敏感（比如实时对话），自己控制队列可能更可预测。

完整排查流程图

flowchart TD A[glm-5.2 报 429] --> B{检查 response body} B -->|包含 RPM quota| C[请求频率太高] B -->|包含 TPM quota| D[单位时间 token 总量超限] B -->|只有 rate_limit_exceeded| E[可能是旧版错误格式，检查模型名是否真的是 glm-5.2] C --> F[降低并发数 or 加退避] D --> G[拆分长 prompt / 降低单请求 token 数] F --> H[验证通过?] G --> H H -->|是| I[问题解决 ✅] H -->|否| J[考虑走聚合网关自动限流]

常见问题 FAQ

Q: glm-5.2 的 TPM 限制具体是多少？官方有写吗？

A: 智谱官方文档目前未公布 glm-5.2 的精确 TPM 数字（如有更新请以官方文档为准）。根据个人实测，付费账户大约在 40,000 tokens/min 左右，但这个数字可能随套餐等级不同而变化，且属于推断值。建议从保守值（35k）开始设，观察 429 频率再调。

Q: 我用 openai SDK 调 glm-5.2 报 404 model_not_found 怎么办？

A: 两个可能：1）base_url 末尾没加斜杠（必须是https://open.bigmodel.cn/api/paas/v4/）；2）如果你走的是聚合平台，model 参数要写完整 ID（具体格式以所用平台文档为准），不能只写glm-5.2。实际报错长这样：

openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model `glm-5.2` does not exist', 'code': 'model_not_found'}}

Q: 退避重试会不会导致整体延迟飙升？

A: 会。指数退避最坏情况下单次请求可能等 30 秒。如果你的场景是批处理（不在乎实时性），退避够用了。如果是实时对话，建议用方案二的队列拆分，把延迟控制在可预期范围内。

Q: glm-5.1 以后会不会也升级成双轨限速？

A: 目前没有官方公告。智谱现有模型系列（如 glm-4.7、glm-5、glm-5-turbo 等）的具体限速策略请以智谱官方文档为准，本文不做推测。建议新项目在代码层面预留 TPM 控制的扩展点，以便后续适配。

Q: 多个工具（Cline、Cherry Studio）共用一个 Key 会不会更容易触发 429？

A: 当然会。RPM 和 TPM 是按 Key 维度计算的，不是按客户端。如果你 Cline 在跑代码补全、Cherry Studio 同时在对话，两边的请求数和 token 数是叠加的。解决办法：要么给每个工具分配独立 Key，要么走聚合平台用子 Key 做隔离。

小结

glm-5.2 的 429 问题本质上不是"额度用完了"，而是（根据实测推断）新版引入了 TPM 维度的限速。同一个 Key 在 glm-5.1 上跑得好好的，换到 glm-5.2 就报错，很可能是长 prompt 在短时间窗口内耗尽了 TPM 配额。

排查顺序：先看 429 响应体里写的是 RPM 还是 TPM → 对症下药（降频率 or 拆 token）→ 嫌麻烦就走聚合网关。个人做法是本地开发用方案一（退避够用），生产环境用方案三（网关兜底）。

提示：本文所有关于 glm-5.2 限速机制的描述（双轨限速、TPM 数值、10 秒窗口粒度、retry-after header 等）均为个人实测推断，不构成对智谱官方规格的准确描述。如需准确信息，请查阅智谱官方文档。