Zhipu 一次模型级 429 让 GLM flash 系列断流。TheRouter 现在按模型冷却，并为它们加了第二条路由。

2026-10-02 下午，Zhipu 的 API 对 zhipu/glm-4.6v-flash 的请求返回了一种限流响应——它只针对这一个模型，而不是整个账号。TheRouter 当时没有区分这两种情况，把它当成账号级限流处理，整个 Zhipu 账号在冷却窗口内被停用，共享池里所有 Zhipu 模型同时停止接收流量。对 glm-4.6v-flash 来说后果更严重：TheRouter 当时只为它配置了一条路由，这条路由被停用后，请求无处可去。本文的事件数据是 TheRouter 网关的第一手记录；上方链接的厂商文档记载的是限流响应本身。

两种在线路上长得一样的限流

Zhipu 的错误码参考列出了多种都以 HTTP 429 返回的情况：针对密钥的请求频率限制、用量配额限制，以及与所请求模型绑定的"服务暂时过载"响应。2026-10-02 触发的是最后一种。它的含义是某一个模型已经饱和，同一组凭据仍然可以调用账号有权访问的其他所有模型。

修复前，TheRouter 为每个上游账号只维护一个冷却时间。任何 429 都会写入这个冷却时间，账号下的所有模型一起等它过期。对密钥级限流来说这是正确行为，对模型级限流则是错误的——它把一个模型的限流放大成所有模型的中断。

TheRouter 改了什么

改了两处，都已经在真实请求路径上生效。

第一，冷却现在有了作用域。当 Zhipu 的响应表明限流只针对单个模型时，TheRouter 只停用该模型，账号下其余模型继续轮转。默认窗口是 15 秒，仍高于事件期间观察到的客户端 2 秒重试节奏；如果 Zhipu 返回了 retry-after 头，TheRouter 以该值为准。真正账号级的 429 仍然会停用整个账号，这在厂商表明凭据本身已耗尽时是正确的响应。

第二，GLM flash 系列不再只有一条路由。Zhipu 为同一批模型运营着一个国际服务，下列每个模型在 TheRouter 中的路由现在都把该服务作为第二选择，仅在第一条路由失败或被停用时启用：

• zhipu/glm-4.6v-flash
• zhipu/glm-4.6v-flashx
• zhipu/glm-4.7-flash
• zhipu/glm-4.7-flashx
• zhipu/glm-4.6v
• zhipu/glm-4.5-air

六个模型的原有路由都保持在首位，日常的延迟和价格没有变化。对 glm-4.6v-flash 和 glm-4.7-flash 来说，第二条路由不带来额外成本：Zhipu 的国际价目表把这两个模型标为 $0，而 TheRouter 对一个模型的定价不取决于哪条路由承接了请求。

并非所有 Zhipu 模型都获得了第二条路由。GLM-4.1V thinking 变体、CogView-4 和 embedding-3 在国际服务上没有提供，仍然是单路由；GLM-5 Turbo 在国际服务上有提供但尚未定价，所以暂缓加入。如果你依赖这些模型，模型级 429 仍会让它们在冷却窗口内停用。

使用者需要做什么

请求格式没有任何变化。如果你已经通过 TheRouter 的 Zhipu 路由调用 glm-4.6v-flash 或 glm-4.7-flash，第二条路由会自动生效；你不需要改模型 ID、base URL 或 API key。接下来可以预期的行为是：Zhipu 的模型级 429 只停用该模型 15 秒（或厂商给出的 retry-after 时长），之后 TheRouter 会在上述六个模型的第二条路由上重试。

有一点值得在你的路由配置里核对：如果你用显式的 provider 覆盖把请求固定到某条路由，这个覆盖会完全绕过兜底逻辑。自动兜底只在由 TheRouter 选择路由时生效。六个模型的价格见共享价目表，两条路由价格相同。

更广的教训很简单：厂商级限流和模型级限流需要不同的响应，一视同仁只会放大每一次模型级限流的影响范围。修复已经上线，六个 GLM flash 系列模型现在有了 2026-10-02 这次事件证明它们缺失的冗余。