minimax-m3 突然报 HTTP 529 怎么办？连续重试为何更难恢复，退避时间该怎么算？

10 月 28 日晚上，我跑批量代码任务时，minimax-m3 连续返回 529。我的第一反应是立刻重试，结果请求越堆越多，折腾半天才把队列救回来。

直接说处理办法：先确认 529 的响应体确实表示 overloaded。重试最多 3 次，500ms 起步，8s 封顶，使用全随机指数退避，同时限制并发。最近 20 个请求中，529 占比达到 50% 时，熔断 30s。

这些数字是我的工程起始配置，不是 MiniMax 官方参数。生产环境得按自己的流量重算。

截至 2026 年 11 月 1 日，实时模型目录中的模型 ID 是 minimax-m3。现有公开材料没有确认 MiniMax 官方是否固定用 HTTP 529 表示过载，所以不能只盯着状态码。响应体、响应头、接入网关和 request_id 都得看。

先判断：你遇到的到底是哪一种故障

下面几类错误看着都像"请求失败"，处理方式却完全不同。搞反了，重试就是火上浇油。

现场表现	更可能的原因	应该怎么处理
收到 HTTP 529，响应体包含 `overloaded`	服务端或网关暂时过载	随机退避、降并发、必要时熔断
`ReadTimeout`，没有收到完整 HTTP 响应	客户端等待响应超时	检查超时配置、长输出及请求是否仍在执行
`PoolTimeout` 或获取连接失败	本地连接池耗尽	增大连接池、限制并发、检查响应是否及时关闭
529 持续十几分钟且集中在单一路由	上游容量或路由异常	保存 `request_id`，切换备用路由并联系平台
账号后台明确提示额度或余额不足	计费或额度问题	处理额度，别拿 529 重试策略硬顶

我当时保存下来的脱敏错误是：

text 复制代码

httpx.HTTPStatusError: Server error '529' for the chat-completions endpoint
Response: {"error":{"type":"overloaded","message":"overloaded"}}

这里已隐去实际接口地址，避免把示例域名误当成可用网关。这个响应只能说明当前接入网关把 529 用作过载错误，不能证明故障一定发生在 MiniMax 上游。代理层或聚合网关容量不足，也可能返回同样的状态。

如果日志长这样，那就是另一回事：

text 复制代码

httpx.ReadTimeout: The read operation timed out

连接池耗尽通常会报：

text 复制代码

httpx.PoolTimeout: timed out while waiting for a connection from pool

短。烦。偏偏很多告警系统把它们全归类成"模型不可用"。

为什么连续重试反而更难恢复

假设服务每秒暂时只能处理 60 个请求，客户端却同时压入 100 个。失败的 40 个请求立即重发，下一秒面对的就不再是 100 个请求，很可能变成 140 个。

多个实例还可能同时重试，撞出同步尖峰，也就是常说的重试风暴。

sequenceDiagram participant C as 客户端实例 participant G as API 网关 participant M as minimax-m3 C->>G: 并发请求 G->>M: 转发 M-->>G: HTTP 529 overloaded G-->>C: 529 Note over C: 随机退避，而非立即重试 C->>G: 抖动后的少量请求

Agent 任务尤其容易出问题。外层工作流重试一次，里面的工具调用可能全部跟着重跑。配置里看着只有 3 次，实际请求量可能翻出好几倍。测完调用日志我人傻了。

方案一：指数退避必须带随机抖动

我现在用的是 Full Jitter，计算式如下：

text 复制代码

上限(n) = min(8s, 0.5s × 2ⁿ)
等待(n) = random(0, 上限(n))

n 从 0 开始。重试 3 次时，每次等待上限依次为 0.5s、1s、2s，最坏累计等待上限是：

text 复制代码

0.5 + 1 + 2 = 3.5s

实际等待会在 0 到上限之间随机取值，理论平均累计等待约为 1.75s。这里的 500ms、8s 和 3 次，是我在 2026 年 10 月 28 日采用的起始配置，不是厂商承诺。

Python 核心逻辑不用写一大坨：

python 复制代码

cap, base = 8.0, 0.5
delay = random.uniform(0, min(cap, base * 2**attempt))
time.sleep(delay)

这套逻辑只该用于明确可恢复的错误，比如响应体已确认的过载错误和部分连接失败。认证失败、参数错误、余额错误，不该塞进同一个重试循环。

如果接入的是 OpenRouter、Together AI 或 ofox.io 这类国际聚合平台，还应检查平台是否返回 Retry-After。有这个响应头时，我会优先尊重服务端给出的时间，再叠加少量随机抖动；没有时才用本地公式。

方案二：最大重试次数必须封顶

无限重试会让请求队列越积越多，用户还不知道任务到底失败了没有。

我的默认配置是：

参数	起始值	含义
最大重试次数	3 次	加上初始请求，总共最多发起 4 次
基础退避	500ms	第一次重试的随机上限
退避封顶	8,000ms	防止等待时间无限增长
单次读取超时	30,000ms	我自己的客户端配置
连接池等待超时	2,000ms	超过后直接暴露池耗尽问题

为什么不是 10 次？持续过载时，第 4 次、第 5 次通常只是在给故障添流量。强实时接口可以少重试；异步批处理可以把任务退回队列，几分钟后重新调度。

3 次是否适合所有业务，我也不确定。目前没找到一个脱离业务延迟预算、还能普适的固定答案。

方案三：先限并发，再谈重试

100 个协程一起发请求，每个都允许重试 3 次，理论请求上限会达到 400 次。退避只能把这些请求在时间上打散，额外流量一条都不会凭空消失。

最简单的办法是加信号量：

python 复制代码

limit = asyncio.Semaphore(8)

async with limit:
    return await call_model()

并发 8 仍然只是起始值。实际该设多少，要看成功率、首字节时间、完整响应时间和 529 比例，再慢慢调。

使用 OpenRouter 或 ofox.io 这类路由时，也要区分"本地并发过高"和"某条上游路由过载"。后者可以通过实际接口地址与请求日志交叉确认，前者通常会伴随连接池等待时间上升。不要一看到 529 就怪模型服务器不知道在忙什么，本地那 200 个协程也可能是元凶。

方案四：请求幂等不能靠运气

超时最麻烦的一点是：客户端认为失败时，服务端可能已经执行完成。

普通文本生成重复一次，最多多出一份结果。如果模型调用后面连着发邮件、创建订单或提交代码，重复执行就真要出事故了。

我会为每个业务动作生成稳定的幂等键：

python 复制代码

headers = {
    "Idempotency-Key": task_id,
    "X-Request-ID": request_id,
}

不是每个平台都支持 Idempotency-Key。碰到不支持的平台，只能在业务数据库里记录 task_id 状态：

text 复制代码

PENDING -> RUNNING -> SUCCEEDED
                   -> FAILED

重试前先查状态。已经成功就返回保存的结果；仍在执行就等待；只有明确失败或租约过期，才重新调用。

流式响应更麻烦。内容已经输出一半，再整段重试，界面上会出现重复文本。我的处理方式是缓存已确认的片段，连接中断后明确提示重新生成，不偷偷往后拼。说实话，这不算完美，但比重复半段答案靠谱。

方案五：用熔断器阻止故障扩散

我目前的起始熔断规则是：

滚动窗口取最近 20 个请求；
至少收集 10 个样本才开始判断；
529 占比达到 50% 时打开熔断器；
熔断 30s；
半开状态只放行 2 个探测请求；
两个探测都成功才恢复，否则继续熔断。

伪代码可以压到 4 行：

python 复制代码

if samples >= 10 and overload_rate >= 0.5:
    circuit.open(seconds=30)
if circuit.half_open():
    circuit.allow(probes=2)

这些阈值是工程配置，不是 minimax-m3 的官方限制。流量很低时，20 个请求可能攒很久，这时应改用"请求数量 + 时间窗口"双条件。

如果业务允许备用路由，可以在熔断后切换。OpenRouter 与 ofox.io 都属于可纳入路由层评估的平台；后者的管理后台可以按 Model、User 和 API Key 查看请求成功失败、平均延迟及 Token 消耗，排查时比只翻应用日志省事。不过切换前要验证输出格式，别把恢复可用变成 JSON 解析事故。

排障时至少记录这些字段

一次 529 如果没有上下文，平台支持也很难定位。我固定记录下面这些字段：

字段	用途
UTC 时间与本地时间	对齐平台日志和故障窗口
模型 ID	确认实际调用的是 `minimax-m3`
实际接口地址与网关名称	判断错误来自哪一层
HTTP 状态码与完整响应体	区分过载、额度和参数错误
`request_id`	让平台定位单次请求
重试序号与等待时间	判断是否形成重试风暴
当前并发数与池占用	排查连接池耗尽
输入长度与输出上限	判断长请求是否集中失败

目前没有可核验的 minimax-m3 QPS、上下文窗口和官方 529 定义，这些数据不能凭感觉填。缩短上下文可能会降低单次请求的资源占用，但它和 529 有没有直接因果关系，还得继续验证。

顺手说一句：npm 上的 overloaded v0.0.1 描述是 "Compilation pipeline"，它和这次 HTTP 529 没有因果关系。名字撞上了而已，别搜到包名就往项目里装，老哥真的会踩坑。

常见问题 FAQ

Q：minimax-m3 返回 529 就是额度用完了吗？

不是。HTTP 529 不是标准状态码，部分大模型 API 或网关会用它表达 overloaded，但目前没有可核验材料能证明 MiniMax 官方对该模型固定采用这个语义。

检查响应体、响应头、平台账单和 request_id，别只凭状态码判断额度。

Q：HTTP 529 应该重试几次？

可以从最多 3 次开始。算上初始请求，总调用次数不超过 4 次。

重试时使用指数退避和随机抖动，还要给整个业务请求设置总时间预算。持续过载就停下来，进入熔断或异步队列。

Q：529 和 429 有什么区别？

429 通常表示请求速率受限，具体含义仍以平台文档和响应体为准。529 常被部分网关用来表示服务暂时过载。

两者都可能需要退避。遇到限流，多看配额、QPS 和 Retry-After；遇到过载，重点查服务容量和路由健康。

Q：为什么加了重试以后连接池反而耗尽？

每次失败都立即创建新请求，而旧响应没有关闭，连接池很快就会被占满。重试并发不受控也会造成同样的问题。

先确保响应被正确释放，再限制并发。PoolTimeout 不该被当成 529 继续无脑重试。

Q：请求超时后可以直接重试吗？

只有操作可幂等时才安全。

文本生成请求可能已经在服务端完成并计费，带副作用的工具调用风险更大。先用稳定的业务任务 ID 保存执行状态，再决定要不要重试。

我的最终选择

我的处理顺序已经固定了：拿到错误先分类，随后限制并发。确认属于可恢复的过载后，最多做 3 次全随机指数退避。529 达到阈值就熔断；碰到超时，先检查幂等性。

别把重试当成万能创可贴。偶发过载时，它确实有用。持续过载还疯狂重试，只会和其他客户端一起把服务按回水里。

最后还是得处理容量、并发和路由。把 while True 写得再熟练也没用。