把重试预算算清楚：LLM 调用的「一次失败」到底成本多少

上周一个朋友的线上服务半夜报警。模型服务商那边一切正常，是我们这边 23% 的流量在重试。更值钱的证据在账单上：一个多月的 API 消耗里，有相当一部分 429 重试其实是在重复一个注定会失败的调用——那段时间服务商在降级，重试永远救不回来，钱照烧。

问题不出在重试本身，而是「重试三次」这种拍脑袋的常量。没有人真正算过：这次失败救回来的概率有多大，烧掉的 token 又值多少钱。

LLM 管线里 429、5xx、timeout 的处理方式，直接决定了你的账单结构和系统真实可用性。这笔账，今天就可以算。

一次失败的真实成本

一次失败重试至少花两层钱：已消耗 token 的费用＋重试时要重发的全量 prompt。

LLM 调用和传统 HTTP 接口最不同的是：失败前，钱已经烧了。输出到一半超时，供应商照算；输入侧的 system prompt、几万 token 的 context、工具调用结果，请求一发出就不可回收。

所以一次「救活」的重试，真实成本至少 2× 单次成本；「救不活」的重试是 3×，还一无所获。

哪些故障值得重试

按「重试后恢复率」分层：

- **429 / 5xx / 网络 timeout**：恢复率高（429 一次退避后基本都能过），值得重试。

- **输出截断（finish_reason=length）**：有条件重试——保留已生成的前半段接续，别重发全量 prompt。

- **400 参数错误、内容审核拦截（content policy）**：恢复率为 0，重试只是白烧钱，必须第一次就 fail fast。

timeout 比较微妙：如果服务端还在算而客户端先放弃了，重试等于「烧了一半的钱再赌一次」。判断依据是 timeout 阈值与 p99 生成时长的比值——timeout 远小于 p99 时，「假超时」会让重试率虚高，账单也跟着虚高。

大约 30 行的实现

核心是**预算＋分类**，不是无脑循环：

import time, random
RETRY_ON = (RateLimitError, ServerError, TimeoutError)

def call_with_budget(fn, max_retries=2, base=0.5):
    for attempt in range(max_retries + 1):
        try:
            return fn()
        except BadRequestError:      # 400 / policy：不重试
            raise
        except RETRY_ON:
            if attempt == max_retries:
                raise
            time.sleep(base * 2 ** attempt + random.uniform(0, 0.3))

三个刻意选择：max_retries=2，而不是更「安全」的 3 或 5（下面解释为什么）；指数退避加随机抖动，避免多实例同时打到同一个限流窗口；BadRequest/Policy 直接抛出，不进重试循环。

为什么是 2 次，不是 3 次

经验数据：429 第一次退避后的恢复率通常在 95% 以上；第 2 次重试追加的救回收益约 3–4%；第 3 次以后，每次重试救回的调用占比往下掉，成本却线性往上走。

「多一次重试更保险」听起来对，但把 3 次和 2 次的成本画出来：3 次相当于把 15% 的账单花在救回 <2% 调用的事情上。对月调用量过万的系统，这笔纯亏。

所以把 max_retries 从 3 砍到 2，通常能用约 10% 的重试费用节省，换完全系统可用性的损失约 0.5%。这笔账大部分系统都赚。

两个要监控的指标

**重试花费占比** = 重试产生的 token 费用 / 总费用。健康值 <5%。如果长期 8–15%，说明依赖方抖动压力大，该评估 fallback 模型或多供应商。

**重试救回率（按次数）** = 第 N 次重试成功的调用数 / 首次失败的调用数。第 2 次救回率若还在 10% 以上，说明你的失败模式值得再多一次尝试；若已降到 3% 以下，max_retries=2 就是对的边界。

这两个指标一起看，比「就按惯例 3 次」稳得多。

小结

重试不是信仰，是算术题。三个今天下午就能改完的动作：把 400/policy 类错误移出重试路径（第一次就 fail fast）；max_retries 从 3/4 降到 2 并写注释说明依据；监控面板加「重试花费占比」一条，超 5% 触发 review。