低价背后的补偿成本：失败重试怎么算进预算

比价时最常见的错误，是拿标价直接比较。标价只是成本的一部分，失败重试、超时等待与人工兜底都要折算进去。

先算重试成本。假设单次请求成功率 97%，平均重试 1.35 次才成功，那么实际成本是标价的 1.35 倍。成功率 99.5% 的线路即使贵两成，实际成本也可能更低。这个系数可以用一周的真实日志算出来，不需要精确建模。

再算超时成本。首 token 时间从 400 毫秒涨到 1.5 秒，用户侧的感知是“卡”，业务侧的成本是并发连接被占用更久。同样的并发上限，能承载的请求量下降，等于变相涨价。

还有人工兜底。失败率高的线路需要有值班同学盯告警、处理重放、向用户解释。这部分成本很难量化，但通常比 API 账单本身更高。把过去一个月的故障工单数量乘上平均处理时长，能得出一个粗略数字。

最后是机会成本。生产环境中断一小时，损失与业务规模相关。低价线路如果每月抖动两次，即使单价便宜三成，也不适合承载核心链路。

建议做法：把每条线路的成本拆成四列——标价、重试系数、并发折算、故障成本，加总后排序。多数团队做完这一步会发现，选择区间会从“最便宜的三家”收缩到“稳定性达标的两家”，决策反而更简单。

补充一个可执行的做法：给每条线路设置一个“熔断预算”。例如允许每小时最多 200 次失败请求，超过就暂停该线路 15 分钟。这样即使上游持续异常，也不会因为无限重试把成本推高，同时保留了自动恢复的能力。熔断状态要能在监控里看到，避免长期静默降级。