先讲一个我亲身踩过的坑。某个项目接入 AI 接口后，某天凌晨收到告警，账单比平时多了一倍。查日志发现，代码里有一段“超过 3 秒就重试”的逻辑，而那天网络恰好抖动，一批请求都超时了。于是每个请求都发了两遍，其中没响应回来的那一次，服务端其实已经在处理，只是响应在某个环节丢了。重试没有补救任何东西，反而让对方多算了一次钱。从那以后，我对“AI 接口超时就重试”这句话开始警惕。

很多人遇到 AI 接口超时，第一反应都是“加个重试不就行了”。听起来很简单，也很符合直觉：网络抖动嘛，再发一次大概率就能成功。但对于按调用次数、按 token 量计费的 AI 接口来说，重试不是免费的，超时也不等于失败。你眼中的一次“补救操作”，在计费系统眼里，就是一次全新的、需要付钱的服务请求。

这篇内容不打算讲高深理论，就把我这些年在生产环境里踩过的坑、改过的代码、复盘过的账单整理出来。重点说清楚三件事：AI 接口超时重试为什么容易多花钱，怎么判断该不该重试，以及真需要重试时应如何设计才能既保稳定又控成本。

1. 超时重试的“账单陷阱”：触发一次重试，就是新增一笔费用

1.1 重试不是“免费补偿”，而是一笔新订单

把 AI 接口调用类比成外卖下单。你下单后等了 20 分钟没收到，于是取消重下一单。如果前一单商家其实已经在做了，厨师都快出锅了，结果只是骑手路上耽误了，你这一“重试”，就变成了两单的钱。

AI 接口也一样。你调用一次 OCR、一次语音转写、一次大模型生成，计费系统的逻辑通常是你“提交任务”就算一次消费，或者按“服务端实际完成一次处理”来计费。不管哪种，自动重试都意味着服务端可能把同一个请求处理了两遍。

最冤的情况是：第一次调用其实已经成功了，只是响应太慢，在网关或网络链路上丢了。客户端等不到结果，判定超时，于是自动重试。第二次调用又成功返回，客户端拿到结果很开心，但账单上已经扣了两次。这种情况几乎无法通过客户端日志直接看出来，因为你会看到两次调用都“成功”了，或者一次超时、一次成功，很难第一时间联想到重复计费。

之前我在排查一个客服机器人项目时，就是被这个坑害过。某个供应商的接口偶尔需要 8 到 10 秒才返回，而我们的超时时间是 5 秒。一超时，代码立刻重发，结果前一个请求在 7 秒时生成了结果，第二个请求在 6 秒时也生成了结果。两条完整回复，双倍 token 计费。用户端看到一条答案，账务端却记了两笔。

1.2 超时位置决定风险等级

同样是“超时”，风险完全不一样。需要先搞清楚超时发生在哪个阶段，再决定要不要重试。

我的经验是：连接超时通常可以放心重试，因为请求大概率没到达服务端，重试不会造成重复扣费。但读取超时和网关超时要非常谨慎，这两种情况都是“请求已送达，只差结果回传”，服务端大概率已经跑了一次完整任务。

如果你用的是异步任务接口，那就更简单：提交任务后拿到 task_id，然后用查询接口主动查状态即可，千万别重新提交一遍任务。有些团队图省事，超时后直接重新调“创建任务”接口，一个任务被创建了好几次，费用自然翻倍。

2. 动手前先看懂AI接口的计费模型与超时真相

2.1 按次、按量、资源包：重试代价大不相同

不同的 AI 接口计费方式差别很大，重试的成本也天差地别。我在实际项目里遇到过四种常见模式。

最危险的是按次计费和按 token 计费。前者好理解，一次重试就是一次新的计费单位；后者更隐蔽，因为即使重试的第二次请求没有返回完整结果，服务端也已经消耗了计算资源、生成了部分内容，这部分成本会体现在账单里。

我之前接触过一个批量翻译场景，翻译接口按字符数计费。代码里设了 3 次重试，某天源文本长度不均衡，一部分请求超过 15 秒，于是这些请求全部重试了 3 次。结果账单里多了大量重复字符数，费用直接超出预期。后来看了明细才发现，同一段文本付了 4 次钱。

2.2 网关层也会制造“假超时”

还有一个容易被忽略的点：你的请求路径不止有客户端和服务端两层，中间可能还有 API 网关。如果服务端生成内容耗时很长，超过了网关的默认超时时间，网关就会向客户端返回超时错误，但上游的服务端还在继续处理。

这种场景在生成式 AI 接口中越来越常见。一个长文本生成任务，常见耗时十几秒甚至几十秒，而网关默认超时可能只有 10 秒。客户端一看超时就重试，服务端又生成了一篇，两篇内容都计算了费用。

遇到这种情况，正确的思路不是加重试，而是压缩链路等待时间：一是主动调大网关超时配置；二是使用流式接口，边生成边返回，避免一次性等待整个响应；三是优先选择提供异步任务提交的接口，用查询代替重试。

2.3 能查询就不重试：异步任务的省钱优势

很多大型 AI 服务商提供两种接口风格：同步接口和异步任务接口。同步接口就是调用后一直等结果，简单直接；异步任务接口则是先提交任务，返回 task_id，然后用查询接口轮询状态。

从成本角度，异步任务接口天然适合做容错。因为“查询任务状态”通常不计费或费用极低，而“重新提交任务”可能是一笔完整费用。超时之后，第一选择永远是查状态，而不是重新提交。

我现在的习惯是：只要是长耗时任务，优先用异步接口；同步接口如果连续超时达到阈值，立即改为异步查询流程。这样既保住了业务连续性，也避免了重复计费。

3. 重试策略优化：从“无脑重试”到“按需重试”

3.1 先按错误类型分类，再决定是否重试

不是所有错误都值得重试。把错误分类清楚，重试策略就成功了一半。我参考自己的生产项目，整理了一张决策表。

一个简单的代码骨架可以这样写，先判断错误类型再进入重试逻辑：

import time import random import requests API_URL = "https://ai-api.example.com/v1/generate" def call_with_retry(request_body, request_id, max_retries=2): for attempt in range(max_retries + 1): try: resp = requests.post( API_URL, json={**request_body, "request_id": request_id}, timeout=(3, 10) # connect_timeout=3, read_timeout=10 ) if resp.status_code == 200: return resp.json() if resp.status_code in (400, 401, 403, 422): return None if resp.status_code == 429: retry_after = int(resp.headers.get("Retry-After", "2")) time.sleep(retry_after + random.uniform(0, 1)) continue # 5xx 或其他网络错误 time.sleep(backoff(attempt)) except requests.exceptions.ConnectTimeout: # 连接超时：可以重试 time.sleep(backoff(attempt)) except requests.exceptions.ReadTimeout: # 读取超时：服务端可能已处理，停止自动重试 return None return None def backoff(attempt, base=1.0, cap=10.0): return min(base * (2 ** attempt) + random.uniform(0, 1), cap)

注意一个细节：这个示例里，读取超时是直接返回 None 而不是重试。原因就是前面说的，请求已经发出去，服务端很可能已经处理完了，再重试就是送第二次钱。

3.2 指数退避加抖动，保住上游服务

如果确实需要重试，重试间隔不能是固定的。固定间隔带来的最大问题是“重试风暴”：当一个上游服务出现抖动，所有客户端都在同一时间失败，又都在同一时间重试，瞬间流量是平时的几十倍，直接把服务打崩。

指数退避就是让重试间隔随次数指数增长，比如第 1 次等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒。加抖动 jitter 是在退避时间上叠加一个随机值，比如 0 到 1 秒之间的随机数，让各客户端的重试时间错开。

还是用代码解释比较清楚：

def backoff_with_jitter(attempt, base=1.0, cap=10.0): exponential = base * (2 ** attempt) jitter = random.uniform(0, min(exponential, cap) / 2) return min(exponential + jitter, cap)

这样的效果是：即便有几千个客户端同时失败，重试请求也会在这几秒内均匀散开，不会完美同步。配合每次重试前重新检查上游健康状态，能进一步减少无谓的重试。

另外，总重试次数一定要设上限。我见过有人把重试次数设成 10 次，结果是某个下游故障 5 分钟，客户端就咬着不放，每个请求都发 10 次，十分钟内产生了平时一个月都花不完的调用费用。通常重试 1 到 2 次已经足够，第 3 次以上的重试成功率会急剧下降，边际收益很低。

3.3 给重试画一条“成本预算线”

除了次数，还要给整条链路设置一个总时间预算。否则重试太多，用户等不起；退避太久，业务响应时间又失控。

我一般这样设计：先确定一个总预算，比如 20 秒，然后拆解给各次尝试。第一次超时设 8 秒，重试第二次超时设 6 秒，退避间隔合计预留 6 秒。当总时间超过预算，就放弃重试，返回降级结果。

DEADLINE = 20 start = time.time() for attempt in range(max_retries + 1): if time.time() - start >= DEADLINE: return None # 计算剩余预算 remaining = DEADLINE - (time.time() - start) timeout = min(8.0, remaining) ...

费用预算同样重要。在按次计费的场景里，我会在配置中心维护一个“日放弃阈值”：当某接口当天调用量异常上涨或费用同比超过 50% 时，自动把重试策略切换成“仅连接超时重试，其余一律不重试”，把损失控制住，等人工确认后再恢复。

4. 幂等性设计：少花冤枉钱的真正核心

4.1 接口幂等：为什么AI接口特别容易破防

幂等这个词听起来拗口，其实意思很简单：同一个请求发多少遍，服务端都只处理一遍。就像你付款时点了一下“提交订单”，结果按钮卡顿，你下意识又点了一下，如果系统没做防重复提交，你就可能付两笔钱。

AI 接口里，幂等性之所以容易被忽视，是因为很多接口文档根本不提幂等。大家想的是“调用一次生成一个结果”，但服务端实现时未必会为每个请求生成唯一标识。两个参数完全相同的请求，在服务端就是两次独立业务，分别计算费用，分别生成结果。

所以在接入 AI 接口时，第一步就应该确认服务端支持什么形式的幂等键。如果支持，在请求头或请求体里带上 request_id；如果不支持，就要在客户端自己做防护。

4.2 用request_id给请求绑定“身份证”

最通用的做法是，客户端在发起调用前生成一个唯一的 request_id，并保证重试时携带同一个 request_id。这样服务端如果能识别这个字段，就能识别出这是同一笔业务，避免重复处理。

{ "request_id": "req_8f2f2a1e9f4c4d1a", "task_type": "text_generation", "input": "请总结这份合同的风险点", "model_params": { "temperature": 0.3 } }

request_id 的生成规则要保证全局唯一，不能只靠时间戳拼一下。建议用 UUID4，或者 Snowflake 风格的自增 ID，至少保证同一天内不会重复。

还需要注意：重试请求的 request_id 必须是第一次生成的那个，而不是每次重试都重新生成。这个坑我见得太多了，代码里把 request_id 生成放在重试循环内部，导致每次重试都换了一个“身份证”，服务端根本无法判断是同一笔请求。正确写法是把 request_id 放在循环外面，只在函数入口生成一次。

4.3 厂商不支持幂等时，本地怎么补救

如果厂商接口不支持幂等键，也别慌。本地可以做一层“结果缓冲表”：以请求内容摘要为 key，第一次调用时记录“处理中”状态，拿到结果后缓存结果。后续如果再遇到相同请求，直接返回缓存，不再调用上游。

processed_cache = {} def request_with_local_dedup(payload): key = payload.get("request_id") if key in processed_cache: return processed_cache[key] result = call_upstream_once(payload) if result is not None: processed_cache[key] = result return result

不过本地缓存只能防住“客户端自己重复触发”的情况，如果超时后你依然直连重试，上游还是会执行两次。所以最根本的解法还是优先使用支持幂等键的接口，或者改用异步查询模式。

5. 排查实录：三个被重试“吃掉”钱的真实场景

5.1 大模型对话：任务已完成，响应超时导致重复计费

某次我在一个对话机器人项目里，发现大模型接口的用量突然翻了一倍。日志显示很多请求都经历了“超时-重试-成功”的完整链路。按代码逻辑，超时重试后用户能收到结果，体验没问题，但费用不对劲。

后来把网络抓包和供应商后台的调用记录拉出来对比，发现一个扎心的事实：很多“超时”的请求，服务端其实已经计算完成，生成了完整回复，只是响应在返回时超过了客户端的等待阈值。客户端判定失败后重试，服务端又算了一遍。两遍的钱都记在了账单上。

修复办法很简单：把读取超时时间从 5 秒调到 15 秒，同时去掉读取超时后的自动重试。如果 15 秒还没返回，改为让用户稍后重试，而不是后台自动补一枪。改动上线后，账单立即回落到正常水平。

从那次之后我明白了一个道理：超时时间设置不合理，本身就是故障源。一味追求“快失败”会造成大量假失败，重试又制造双倍费用。合理的超时应该是 P95 响应时间的两倍左右，而不是拍脑袋定个 3 秒。

5.2 OCR批量任务：并发重试触发限流，费用雪上加霜

另一个项目是做发票 OCR 批量识别，一次任务会拆成几百张图片并行调用。某天上游服务不稳定，一批请求失败。按代码里的固定重试逻辑，每个失败请求等 1 秒重试，于是几百个并发全部回来再撞一次，瞬时流量翻了一倍。

结果很糟糕：上游被冲得限流，返回一批 429。客户端看到 429，又进入重试逻辑，再一次抬高峰值。最终那天的调用总量是平时的 3 倍多，其中有将近一半是重试请求，且大量请求在限流状态下其实根本没成功。

这个问题的解法分三层：第一，给并发调用加上最大并发限制，避免批量任务瞬间打出过高的请求量；第二，重试间隔改成指数退避加抖动，不要统一等 1 秒；第三，总重试次数限制在 2 次以内，达到上限后立刻把该批次降级为“待人工重跑”，而不是让程序无限循环。

5.3 语音合成流式接口：半截输出与重复拼装

流式接口是另一个容易踩的坑。语音合成、流式对话这类接口通过 SSE 或 WebSocket 返回结果，客户端一边收数据一边播放。如果网络抖动导致流断开，客户端往往只收到前半段内容。

此时如果抱着“重试就完了”的心态重新调用接口，会出现两个问题：一是服务端会重新生成整段内容，又一次计费；二是客户端如果把新生成的整段内容拼接到此前收到的音频上，会得到一段前后重复甚至语义冲突的音频。

我处理流式断线的方法是：不在客户端直接重发请求，而是先向服务端查询已生成的文件片段或任务状态，拿到已完成的部分，续传剩余段。如果服务端不提供断点续传能力，就整段生成并替换掉旧内容，同时记录费用差异；如果价格敏感，就优先用下载任务结果文件的方式，而不是流式长连接。

6. 成本监控与可观测性：让每一笔调用都有踪迹

6.1 重试占比、响应码分布、单请求成本

重试逻辑改完之后，如果不做成本监控，迟早还会出问题。我给自己定的核心指标有三个。

第一，重试请求占比。即“重试次数 / 总请求数”。正常的系统，这个值应该在 2% 以下。如果某天突然升到 5% 或 10%，说明上游或网络已经不稳定，而每一次重试都是真金白银。

第二，响应码分布。重点看 502、504 和 429 的比例。429 变多说明上游在限流，需要检查并发量；502 变多说明网关或服务端不稳定，可能需要切换备用通道。

第三，单请求成本。很多计费平台会提供用量明细。把单请求成本做成趋势图，一旦出现“单请求成本翻倍”的异常，第一时间优先检查是否发生了重复计费，而不是先看模型价格调整。

这三个指标不需要多复杂的平台，一个日志表加一个定时统计任务就能跑起来。关键是数据要有。

6.2 最小可落地的日志与告警方案

我的做法是建立一张调用日志表，每条日志包含这些字段：

告警规则我设置这几条：重试占比连续 10 分钟超过 5%，触发通知；单小时费用环比上一小时增长超过 30%，触发通知；同一 request_id 的重试次数超过 2 次，记录一条 WARN 日志。这套规则成本低，但能覆盖大部分重复计费场景。

日常复盘也很重要。我每两周会拉一次各接口的“重试次数与成功次数”对比。如果某个接口的高重试次数并没有带来更高的成功率，那说明重试大概率只是白花钱，应该下调重试次数或干脆关闭自动重试。

7. 关于重试，我现在的个人心法

回头再看这个坑，我最大的体会就是：把“AI 接口超时”和“AI 接口失败”当成两件事。超时只是没收到响应，不代表服务端没干活；只有明确知道请求没被处理，重试才是合理的。

我现在接到“接口偶尔超时”的需求时，第一反应不是写重试代码，而是先查三样东西：这个接口怎么计费？服务端支不支持幂等？有没有查询任务状态的接口？这三个问题问完，很多方案根本不需要重试，改用流式或异步查询就能解决。

如果最后还是需要重试，那就一定要满足三个条件：携带同一个 request_id；只有连接超时或明确 5xx 才重试；重试总次数不超过 2 次且总时间有预算。这套规矩救了我好几次，也帮不少朋友省下过莫名其妙的账单。希望看到这里的人，也能少交一次“重复调用税”。