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 疑似引入了 RPMrequests-per-minute TPMtokens-per-minute双轨并发窗口限速而 glm-5.1 只有单一的 RPM/QPM 限制。解决方案是指数退避 请求队列拆分或者走聚合网关让平台帮你做流量整形。下面把完整排查过程和代码贴出来。为什么会出现这个问题glm-5.1 沿用的是较早一代限速策略——纯 RPMrequests per minute计数比如付费账户 RPM60只要一分钟内请求数不超 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.1glm-5.2限速维度单一 RPMRPM TPM 双轨实测推断免费账户 RPM55付费账户 RPM约 60实测近似值官方未列明约 60实测近似值官方未列明TPM 限制无实测推断约 40,000 tokens/min实测近似值官方未公布429 响应体仅rate_limit_exceeded区分RPM quota或TPM quota实测推断滑动窗口固定 60s 翻转实测推断滑动窗口约 10s 粒度实测推断retry-after header未观察到观察到返回建议等待秒数实测推断关键差异以下为实测推断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_keyyour_api_key)装饰器配置——指数退避等待下界 2 秒、上界 30 秒最多重试 5 次wait_exponential(multiplier1, min2, max30)的实际等待时间为clamp(1 × 2^(n-1), 2, 30)秒首次重试约 2 秒retry(waitwait_exponential(multiplier1, min2, max30), stopstop_after_attempt(5)) def call_glm(prompt: str) - str: resp client.chat.completions.create( modelglm-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, rpm50, tpm35000): # rpm50付费账户约 60 RPM × 0.83留安全余量 # tpm35000基于约 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(rpm50, tpm35000) async def main(): asyncio.create_task(limiter.refill_loop()) # 必须启动否则 TPM 不恢复 # ... 你的业务逻辑RPM 限制通过acquire中的滑动窗口时间戳实现无需额外重置逻辑。方案三走聚合网关让平台帮你做流量整形方案二写起来不难但维护起来烦——如果限速参数发生变化硬编码的数值就需要重新调整。另一个思路是用 API 聚合平台如 OpenRouter、ofox.io 这类网关层自带限流排队和自动重试。改动量就一行 base_urlimport openai client openai.OpenAI( api_keyyour-gateway-key, base_urlhttps://api.ofox.io/v1)调用方式完全不变resp client.chat.completions.create( modelglm-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[考虑走聚合网关自动限流]常见问题 FAQQ: 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: 两个可能1base_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 会不会更容易触发 429A: 当然会。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 等均为个人实测推断不构成对智谱官方规格的准确描述。如需准确信息请查阅智谱官方文档。