先讲一个我亲身踩过的坑。某个项目接入 AI 接口后某天凌晨收到告警账单比平时多了一倍。查日志发现代码里有一段“超过 3 秒就重试”的逻辑而那天网络恰好抖动一批请求都超时了。于是每个请求都发了两遍其中没响应回来的那一次服务端其实已经在处理只是响应在某个环节丢了。重试没有补救任何东西反而让对方多算了一次钱。从那以后我对“AI 接口超时就重试”这句话开始警惕。很多人遇到 AI 接口超时第一反应都是“加个重试不就行了”。听起来很简单也很符合直觉网络抖动嘛再发一次大概率就能成功。但对于按调用次数、按 token 量计费的 AI 接口来说重试不是免费的超时也不等于失败。你眼中的一次“补救操作”在计费系统眼里就是一次全新的、需要付钱的服务请求。这篇内容不打算讲高深理论就把我这些年在生产环境里踩过的坑、改过的代码、复盘过的账单整理出来。重点说清楚三件事AI 接口超时重试为什么容易多花钱怎么判断该不该重试以及真需要重试时应如何设计才能既保稳定又控成本。1. 超时重试的“账单陷阱”触发一次重试就是新增一笔费用1.1 重试不是“免费补偿”而是一笔新订单把 AI 接口调用类比成外卖下单。你下单后等了 20 分钟没收到于是取消重下一单。如果前一单商家其实已经在做了厨师都快出锅了结果只是骑手路上耽误了你这一“重试”就变成了两单的钱。AI 接口也一样。你调用一次 OCR、一次语音转写、一次大模型生成计费系统的逻辑通常是你“提交任务”就算一次消费或者按“服务端实际完成一次处理”来计费。不管哪种自动重试都意味着服务端可能把同一个请求处理了两遍。最冤的情况是第一次调用其实已经成功了只是响应太慢在网关或网络链路上丢了。客户端等不到结果判定超时于是自动重试。第二次调用又成功返回客户端拿到结果很开心但账单上已经扣了两次。这种情况几乎无法通过客户端日志直接看出来因为你会看到两次调用都“成功”了或者一次超时、一次成功很难第一时间联想到重复计费。之前我在排查一个客服机器人项目时就是被这个坑害过。某个供应商的接口偶尔需要 8 到 10 秒才返回而我们的超时时间是 5 秒。一超时代码立刻重发结果前一个请求在 7 秒时生成了结果第二个请求在 6 秒时也生成了结果。两条完整回复双倍 token 计费。用户端看到一条答案账务端却记了两笔。1.2 超时位置决定风险等级同样是“超时”风险完全不一样。需要先搞清楚超时发生在哪个阶段再决定要不要重试。超时类型含义重试风险连接超时 connect timeout请求没建立连接服务端很可能根本没收到较低可以谨慎重试写入超时 write timeout请求体还没完全发出去服务端可能收到一部分中等取决于服务端解析能力读取超时 read timeout请求已发出但响应在限定时间内没回来较高很可能服务端已经在处理网关超时 504中间网关没等到上游结果很高上游很可能已执行完任务连接被重置请求已发出连接中途断开高无法判断服务端是否处理我的经验是连接超时通常可以放心重试因为请求大概率没到达服务端重试不会造成重复扣费。但读取超时和网关超时要非常谨慎这两种情况都是“请求已送达只差结果回传”服务端大概率已经跑了一次完整任务。如果你用的是异步任务接口那就更简单提交任务后拿到 task_id然后用查询接口主动查状态即可千万别重新提交一遍任务。有些团队图省事超时后直接重新调“创建任务”接口一个任务被创建了好几次费用自然翻倍。2. 动手前先看懂AI接口的计费模型与超时真相2.1 按次、按量、资源包重试代价大不相同不同的 AI 接口计费方式差别很大重试的成本也天差地别。我在实际项目里遇到过四种常见模式。计费模式一次重试会发生什么风险等级按次计费重试一次就多计一次调用费用极高按 token / 时长计费服务端可能重复生成内容按两次处理的总量计费极高包月/资源包消耗套餐配额额度耗尽后触发限流高按并发时长计费重试会占用额外并发槽位拉长整体占用时间中到高最危险的是按次计费和按 token 计费。前者好理解一次重试就是一次新的计费单位后者更隐蔽因为即使重试的第二次请求没有返回完整结果服务端也已经消耗了计算资源、生成了部分内容这部分成本会体现在账单里。我之前接触过一个批量翻译场景翻译接口按字符数计费。代码里设了 3 次重试某天源文本长度不均衡一部分请求超过 15 秒于是这些请求全部重试了 3 次。结果账单里多了大量重复字符数费用直接超出预期。后来看了明细才发现同一段文本付了 4 次钱。2.2 网关层也会制造“假超时”还有一个容易被忽略的点你的请求路径不止有客户端和服务端两层中间可能还有 API 网关。如果服务端生成内容耗时很长超过了网关的默认超时时间网关就会向客户端返回超时错误但上游的服务端还在继续处理。这种场景在生成式 AI 接口中越来越常见。一个长文本生成任务常见耗时十几秒甚至几十秒而网关默认超时可能只有 10 秒。客户端一看超时就重试服务端又生成了一篇两篇内容都计算了费用。遇到这种情况正确的思路不是加重试而是压缩链路等待时间一是主动调大网关超时配置二是使用流式接口边生成边返回避免一次性等待整个响应三是优先选择提供异步任务提交的接口用查询代替重试。2.3 能查询就不重试异步任务的省钱优势很多大型 AI 服务商提供两种接口风格同步接口和异步任务接口。同步接口就是调用后一直等结果简单直接异步任务接口则是先提交任务返回 task_id然后用查询接口轮询状态。从成本角度异步任务接口天然适合做容错。因为“查询任务状态”通常不计费或费用极低而“重新提交任务”可能是一笔完整费用。超时之后第一选择永远是查状态而不是重新提交。我现在的习惯是只要是长耗时任务优先用异步接口同步接口如果连续超时达到阈值立即改为异步查询流程。这样既保住了业务连续性也避免了重复计费。3. 重试策略优化从“无脑重试”到“按需重试”3.1 先按错误类型分类再决定是否重试不是所有错误都值得重试。把错误分类清楚重试策略就成功了一半。我参考自己的生产项目整理了一张决策表。状态码 / 错误是否重试补充说明400 / 401 / 403 / 404不重试参数、鉴权或资源不存在重试徒劳422 / 409不重试业务校验失败或状态冲突429 限流有限重试按 Retry-After 等待最多 1 到 2 次500谨慎重试服务端异常需确认接口是否幂等502 / 503 / 504谨慎重试网关或服务不可用退避后重试连接超时可以重试请求大概率未到达服务端读取超时不自动重试服务端可能已处理优先查询状态一个简单的代码骨架可以这样写先判断错误类型再进入重试逻辑import time import random import requests API_URL https://ai-api.example.com/v1/generate def call_with_retry(request_body, request_id, max_retries2): for attempt in range(max_retries 1): try: resp requests.post( API_URL, json{**request_body, request_id: request_id}, timeout(3, 10) # connect_timeout3, read_timeout10 ) 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, base1.0, cap10.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, base1.0, cap10.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 最小可落地的日志与告警方案我的做法是建立一张调用日志表每条日志包含这些字段字段示例用途request_idreq_8f2f2a1e9f4c4d1a追踪同一笔业务的所有尝试attempt1 / 2 / 3记录第几次调用api_nameocr / llm / tts区分不同接口status_code200 / 504 / null判断响应状态error_typeconnect_timeout / read_timeout / 429定位重试原因duration_ms3200记录耗时cost0.012记录预估费用告警规则我设置这几条重试占比连续 10 分钟超过 5%触发通知单小时费用环比上一小时增长超过 30%触发通知同一 request_id 的重试次数超过 2 次记录一条 WARN 日志。这套规则成本低但能覆盖大部分重复计费场景。日常复盘也很重要。我每两周会拉一次各接口的“重试次数与成功次数”对比。如果某个接口的高重试次数并没有带来更高的成功率那说明重试大概率只是白花钱应该下调重试次数或干脆关闭自动重试。7. 关于重试我现在的个人心法回头再看这个坑我最大的体会就是把“AI 接口超时”和“AI 接口失败”当成两件事。超时只是没收到响应不代表服务端没干活只有明确知道请求没被处理重试才是合理的。我现在接到“接口偶尔超时”的需求时第一反应不是写重试代码而是先查三样东西这个接口怎么计费服务端支不支持幂等有没有查询任务状态的接口这三个问题问完很多方案根本不需要重试改用流式或异步查询就能解决。如果最后还是需要重试那就一定要满足三个条件携带同一个 request_id只有连接超时或明确 5xx 才重试重试总次数不超过 2 次且总时间有预算。这套规矩救了我好几次也帮不少朋友省下过莫名其妙的账单。希望看到这里的人也能少交一次“重复调用税”。 
长河君 · 2026/10/22 15:26:44 · 阅读 1.2k AI接口超时重试，如何避免重复计费与成本失控
先讲一个我亲身踩过的坑。某个项目接入 AI 接口后某天凌晨收到告警账单比平时多了一倍。查日志发现代码里有一段“超过 3 秒就重试”的逻辑而那天网络恰好抖动一批请求都超时了。于是每个请求都发了两遍其中没响应回来的那一次服务端其实已经在处理只是响应在某个环节丢了。重试没有补救任何东西反而让对方多算了一次钱。从那以后我对“AI 接口超时就重试”这句话开始警惕。很多人遇到 AI 接口超时第一反应都是“加个重试不就行了”。听起来很简单也很符合直觉网络抖动嘛再发一次大概率就能成功。但对于按调用次数、按 token 量计费的 AI 接口来说重试不是免费的超时也不等于失败。你眼中的一次“补救操作”在计费系统眼里就是一次全新的、需要付钱的服务请求。这篇内容不打算讲高深理论就把我这些年在生产环境里踩过的坑、改过的代码、复盘过的账单整理出来。重点说清楚三件事AI 接口超时重试为什么容易多花钱怎么判断该不该重试以及真需要重试时应如何设计才能既保稳定又控成本。1. 超时重试的“账单陷阱”触发一次重试就是新增一笔费用1.1 重试不是“免费补偿”而是一笔新订单把 AI 接口调用类比成外卖下单。你下单后等了 20 分钟没收到于是取消重下一单。如果前一单商家其实已经在做了厨师都快出锅了结果只是骑手路上耽误了你这一“重试”就变成了两单的钱。AI 接口也一样。你调用一次 OCR、一次语音转写、一次大模型生成计费系统的逻辑通常是你“提交任务”就算一次消费或者按“服务端实际完成一次处理”来计费。不管哪种自动重试都意味着服务端可能把同一个请求处理了两遍。最冤的情况是第一次调用其实已经成功了只是响应太慢在网关或网络链路上丢了。客户端等不到结果判定超时于是自动重试。第二次调用又成功返回客户端拿到结果很开心但账单上已经扣了两次。这种情况几乎无法通过客户端日志直接看出来因为你会看到两次调用都“成功”了或者一次超时、一次成功很难第一时间联想到重复计费。之前我在排查一个客服机器人项目时就是被这个坑害过。某个供应商的接口偶尔需要 8 到 10 秒才返回而我们的超时时间是 5 秒。一超时代码立刻重发结果前一个请求在 7 秒时生成了结果第二个请求在 6 秒时也生成了结果。两条完整回复双倍 token 计费。用户端看到一条答案账务端却记了两笔。1.2 超时位置决定风险等级同样是“超时”风险完全不一样。需要先搞清楚超时发生在哪个阶段再决定要不要重试。超时类型含义重试风险连接超时 connect timeout请求没建立连接服务端很可能根本没收到较低可以谨慎重试写入超时 write timeout请求体还没完全发出去服务端可能收到一部分中等取决于服务端解析能力读取超时 read timeout请求已发出但响应在限定时间内没回来较高很可能服务端已经在处理网关超时 504中间网关没等到上游结果很高上游很可能已执行完任务连接被重置请求已发出连接中途断开高无法判断服务端是否处理我的经验是连接超时通常可以放心重试因为请求大概率没到达服务端重试不会造成重复扣费。但读取超时和网关超时要非常谨慎这两种情况都是“请求已送达只差结果回传”服务端大概率已经跑了一次完整任务。如果你用的是异步任务接口那就更简单提交任务后拿到 task_id然后用查询接口主动查状态即可千万别重新提交一遍任务。有些团队图省事超时后直接重新调“创建任务”接口一个任务被创建了好几次费用自然翻倍。2. 动手前先看懂AI接口的计费模型与超时真相2.1 按次、按量、资源包重试代价大不相同不同的 AI 接口计费方式差别很大重试的成本也天差地别。我在实际项目里遇到过四种常见模式。计费模式一次重试会发生什么风险等级按次计费重试一次就多计一次调用费用极高按 token / 时长计费服务端可能重复生成内容按两次处理的总量计费极高包月/资源包消耗套餐配额额度耗尽后触发限流高按并发时长计费重试会占用额外并发槽位拉长整体占用时间中到高最危险的是按次计费和按 token 计费。前者好理解一次重试就是一次新的计费单位后者更隐蔽因为即使重试的第二次请求没有返回完整结果服务端也已经消耗了计算资源、生成了部分内容这部分成本会体现在账单里。我之前接触过一个批量翻译场景翻译接口按字符数计费。代码里设了 3 次重试某天源文本长度不均衡一部分请求超过 15 秒于是这些请求全部重试了 3 次。结果账单里多了大量重复字符数费用直接超出预期。后来看了明细才发现同一段文本付了 4 次钱。2.2 网关层也会制造“假超时”还有一个容易被忽略的点你的请求路径不止有客户端和服务端两层中间可能还有 API 网关。如果服务端生成内容耗时很长超过了网关的默认超时时间网关就会向客户端返回超时错误但上游的服务端还在继续处理。这种场景在生成式 AI 接口中越来越常见。一个长文本生成任务常见耗时十几秒甚至几十秒而网关默认超时可能只有 10 秒。客户端一看超时就重试服务端又生成了一篇两篇内容都计算了费用。遇到这种情况正确的思路不是加重试而是压缩链路等待时间一是主动调大网关超时配置二是使用流式接口边生成边返回避免一次性等待整个响应三是优先选择提供异步任务提交的接口用查询代替重试。2.3 能查询就不重试异步任务的省钱优势很多大型 AI 服务商提供两种接口风格同步接口和异步任务接口。同步接口就是调用后一直等结果简单直接异步任务接口则是先提交任务返回 task_id然后用查询接口轮询状态。从成本角度异步任务接口天然适合做容错。因为“查询任务状态”通常不计费或费用极低而“重新提交任务”可能是一笔完整费用。超时之后第一选择永远是查状态而不是重新提交。我现在的习惯是只要是长耗时任务优先用异步接口同步接口如果连续超时达到阈值立即改为异步查询流程。这样既保住了业务连续性也避免了重复计费。3. 重试策略优化从“无脑重试”到“按需重试”3.1 先按错误类型分类再决定是否重试不是所有错误都值得重试。把错误分类清楚重试策略就成功了一半。我参考自己的生产项目整理了一张决策表。状态码 / 错误是否重试补充说明400 / 401 / 403 / 404不重试参数、鉴权或资源不存在重试徒劳422 / 409不重试业务校验失败或状态冲突429 限流有限重试按 Retry-After 等待最多 1 到 2 次500谨慎重试服务端异常需确认接口是否幂等502 / 503 / 504谨慎重试网关或服务不可用退避后重试连接超时可以重试请求大概率未到达服务端读取超时不自动重试服务端可能已处理优先查询状态一个简单的代码骨架可以这样写先判断错误类型再进入重试逻辑import time import random import requests API_URL https://ai-api.example.com/v1/generate def call_with_retry(request_body, request_id, max_retries2): for attempt in range(max_retries 1): try: resp requests.post( API_URL, json{**request_body, request_id: request_id}, timeout(3, 10) # connect_timeout3, read_timeout10 ) 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, base1.0, cap10.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, base1.0, cap10.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 最小可落地的日志与告警方案我的做法是建立一张调用日志表每条日志包含这些字段字段示例用途request_idreq_8f2f2a1e9f4c4d1a追踪同一笔业务的所有尝试attempt1 / 2 / 3记录第几次调用api_nameocr / llm / tts区分不同接口status_code200 / 504 / null判断响应状态error_typeconnect_timeout / read_timeout / 429定位重试原因duration_ms3200记录耗时cost0.012记录预估费用告警规则我设置这几条重试占比连续 10 分钟超过 5%触发通知单小时费用环比上一小时增长超过 30%触发通知同一 request_id 的重试次数超过 2 次记录一条 WARN 日志。这套规则成本低但能覆盖大部分重复计费场景。日常复盘也很重要。我每两周会拉一次各接口的“重试次数与成功次数”对比。如果某个接口的高重试次数并没有带来更高的成功率那说明重试大概率只是白花钱应该下调重试次数或干脆关闭自动重试。7. 关于重试我现在的个人心法回头再看这个坑我最大的体会就是把“AI 接口超时”和“AI 接口失败”当成两件事。超时只是没收到响应不代表服务端没干活只有明确知道请求没被处理重试才是合理的。我现在接到“接口偶尔超时”的需求时第一反应不是写重试代码而是先查三样东西这个接口怎么计费服务端支不支持幂等有没有查询任务状态的接口这三个问题问完很多方案根本不需要重试改用流式或异步查询就能解决。如果最后还是需要重试那就一定要满足三个条件携带同一个 request_id只有连接超时或明确 5xx 才重试重试总次数不超过 2 次且总时间有预算。这套规矩救了我好几次也帮不少朋友省下过莫名其妙的账单。希望看到这里的人也能少交一次“重复调用税”。