调用大模型 API和调用一个普通 HTTP 接口其实不是一回事。普通接口大多是“请求进来—服务计算—结果返回”耗时通常比较可预期。但大模型 API 就复杂得多模型大小、上下文长度、GPU 排队、供应商限流、流式输出、工具调用链路都会影响一次请求的耗时和成功率。也就是说它的延迟不太稳定失败方式也更多样。所以在设计大模型 API 的高可用方案时不能简单写一句“超时后重试 3 次”就结束。更靠谱的做法是先把错误类型分清楚再分层设置超时在时间和成本允许的范围内谨慎重试如果仍然不稳定就通过模型降级、能力降级、结果降级和交互降级尽量把用户体验兜住。下面就围绕“大模型 API、API 超时重试、接口降级策略”这几个问题整理一套更适合落地的设计思路。为什么大模型 API 比普通接口更容易超时大模型 API 的超时通常不是某一个单点问题导致的而是很多因素叠在一起造成的。推理本身就慢大模型需要一个 token 一个 token 地生成内容回答越长耗时自然越久。上下文越长首 token 越慢prompt、历史对话、检索结果塞得越多输入 token 就越多模型开始输出第一个 token 的时间往往也会变长。GPU 资源可能要排队高峰期请求不一定马上进入推理阶段可能先在队列里等一会儿。流式输出不代表请求已经完成即使首 token 已经返回后面的 token 仍然可能变慢、中断甚至超时。供应商限流很常见429、并发限制、配额不足这些都会直接影响接口稳定性。Agent 链路更长用户一次提问背后可能要经过检索、工具调用、函数执行、多轮推理任何一步慢了都会拖累整体耗时。客户端、网关、服务端的超时不一致上游已经放弃了下游还在继续生成这不仅浪费成本还可能产生脏状态。因此大模型 API 的超时、重试和降级策略不能只盯着“请求能不能成功”。更重要的是在用户等待体验、系统稳定性和调用成本之间找到平衡。先建立错误分类哪些失败能重试哪些不能重试不是万能药。对大模型 API 来说盲目重试很容易带来三个问题重复扣费、重复执行有副作用的操作以及把供应商限流进一步打爆。比较好的做法是先按错误类型建立一张决策表。错误类型是否重试处理建议408 / 网络超时可以重试使用指数退避并加上随机抖动429 限流谨慎重试优先遵守Retry-After同时降低并发500 / 502 / 503 / 504可以重试短暂退避必要时切换备用模型或备用供应商400 参数错误不重试检查请求参数、模型名、消息格式401 / 403 鉴权错误不重试检查 API Key、权限和额度配置413 请求过大不重试原请求压缩上下文、截断历史消息、减少检索片段内容安全拦截不重试原请求改写提示词或者返回合规说明流式输出中断通常不直接覆盖重试保留部分结果提示用户继续生成或重新生成除了看错误码还要看接口本身是否幂等。Embedding 一般可以重试。同样的输入重复请求通常不会造成业务副作用。普通问答可以重试但结果可能不一样。大模型生成有随机性两次回答不完全一致是正常的。Agent 工具调用要特别谨慎。如果涉及写数据库、发消息、下单、调用外部系统就必须使用request_id或idempotency_key。已经开始流式返回后不建议自动覆盖重试。用户已经看到一部分内容了系统突然换一版新答案体验会很割裂。大模型 API 的超时应该分层设计很多线上问题最后追到根因都是因为只设置了一个总 timeout。对普通接口来说这可能勉强够用但对大模型 API特别是流式接口就远远不够了。更合理的超时设计通常要拆成几层来看。1. 连接超时连接超时主要限制 TCP 连接、DNS 解析、TLS 握手这些阶段的等待时间。这个值一般不应该太长否则网络一抖动请求就会被卡住很久。2. 请求发送超时当 prompt 很长或者上传了文件、图片、多模态内容时请求本身发送到服务端也可能耗时。这个阶段也要单独限制避免请求还没送到模型服务用户耐心就已经被耗光了。3. 首 token 超时首 token 延迟是大模型体验里非常关键的指标。用户最敏感的往往不是完整回答一共花了多少秒而是“系统多久开始有反应”。在线聊天、智能客服、RAG 问答这类场景都应该重点关注首 token 时间。4. token 间隔超时对于流式输出只看总超时很容易误判。只要 token 持续往外吐长回答可以适当允许更久但如果很长时间没有新 token就要认为流可能中断了或者模型卡住了。5. 总响应超时总响应超时用来限制一次生成的最长时间避免超长回答一直占着连接、线程和 token 成本不释放。6. 业务 deadline业务 deadline 应该从用户体验倒推而不是从模型能力倒推。比如用户最多愿意等 10 秒那么检索、模型生成、后处理、网络传输、前端渲染加起来就不能超过 10 秒。不能给大模型 API 单独设置 30 秒然后让用户在页面上干等。7. 队列超时如果请求进入了内部任务队列也要设置排队超时。上游已经取消的请求不应该继续排队等待昂贵的模型资源。8. 链路级 deadline 传递每个下游调用都应该知道自己还剩多少时间。比如总预算是 12 秒检索用了 2 秒重排又用了 1 秒那么 LLM 实际只剩下 9 秒。不能让下游在上游已经放弃后还继续生成这样既浪费钱也容易让系统状态变复杂。不同接口可以参考下面这样的策略接口类型建议关注指标超时策略Chat / 对话首 token、总生成时长首 token 5–15s总超时 30–120s按模型和场景调整RAG 问答检索耗时、首 token、总耗时检索和 LLM 分别设置超时Embedding批量大小、并发量使用较短超时失败后一般可安全重试JSON 结构化生成完整性、解析成功率总超时可以稍长失败后可降级为普通文本图片/视频生成排队时间、异步完成状态不建议长连接同步等待优先任务化Agent 工具调用多步骤累计耗时设置全局 deadline每一步消耗预算重试策略怎么设计次数、间隔、抖动和预算API 超时重试的重点不是“多试几次”而是“只在值得重试的时候用可控成本再试一次”。最大重试次数在线请求一般建议最多重试 1–2 次不建议默认重试 5 次甚至更多。原因很简单大模型 API 一次请求本身就可能比较慢如果重试次数太多延迟、成本和供应商压力都会被放大。用户也不一定愿意等这么久。如果是后台任务、离线任务可以适当增加重试次数。但这类任务最好放到任务队列里异步执行而不是阻塞在线请求。指数退避与随机抖动比较常见的做法是第一次失败后等待 300–800ms第二次失败后等待 1–2s每次等待都加一点随机抖动总等待时间不能超过业务 deadline。这里的随机抖动非常重要。没有 jitter 的话大量客户端可能同一时间失败又在同一时间重试最后形成“重试风暴”。429 要特殊处理429 代表被限流了。这个时候最不应该做的就是马上原地重试更不能让所有请求一起重试。更合理的处理方式是如果响应里有Retry-After优先遵守降低这个模型或供应商的并发把低优先级任务排队甚至临时暂停必要时切换到备用模型重试请求也要计入限流不能绕过限流规则。重试预算重试一定要有预算包括时间预算、次数预算和成本预算。举个例子一个在线聊天请求总预算是 15 秒主模型第一次调用已经花了 10 秒。这时再完整重试一次大概率只是让用户继续空等。更好的选择可能是切到轻量模型、缩短输出或者直接返回“继续生成”的入口。幂等 key 与重复扣费只要调用链路里涉及副作用就必须做幂等设计。常见做法包括每次用户请求生成唯一的request_id工具调用、写库、发消息时使用idempotency_key重试前先检查任务状态避免出现“模型请求失败但工具其实已经执行成功”的不一致状态。接口降级策略不要只返回错误要保住用户体验传统接口降级经常是返回 null、mock 数据或者一句“系统繁忙”。但在大模型应用里这样往往不够。更好的降级策略应该围绕一个问题来设计用户还能不能拿到一个可接受的结果1. 模型降级原策略降级策略使用高阶模型切换到轻量模型使用长上下文模型压缩上下文后改用短上下文模型使用主供应商模型切换备用供应商实时生成使用缓存答案、历史相似答案或模板回复模型降级一定要提前验证尤其是 JSON 输出、函数调用、多轮对话这些场景。不要等线上故障发生后才发现备用模型的输出格式不兼容。2. 能力降级当系统压力变大或者模型服务不太稳定时可以先降低能力复杂度。比如临时关闭联网搜索减少检索片段数量关闭复杂工具调用限制 Agent 的规划步数降低max_tokens关闭多候选答案生成从深度推理切换到快速回答多模态任务先降级为文本任务。这类降级的好处是用户仍然能得到答案只是答案没那么“重”。3. 结果降级结果降级不等于失败而是给用户一个更小但仍然可用的结果。例如返回摘要而不是生成一篇长文返回已经生成出的部分内容提示“已生成部分内容可继续生成”JSON 生成失败时先降级为自然语言说明对低优先级请求排队处理给出清楚的失败原因并提供重新生成按钮。很多时候一个“可继续”的半成品比一个冷冰冰的错误提示要好得多。4. 交互降级图片生成、视频生成、长文生成、复杂 Agent 任务不太适合一直同步等待。更自然的交互方式是创建异步任务返回任务 ID前端通过轮询或 WebSocket 获取状态高峰期展示排队状态失败后允许用户一键重试。这样用户不会被迫盯着一个一直转圈的页面系统也能更从容地调度资源。5. 业务分级不同业务的价值不同不应该使用同一套降级规则。业务等级示例策略P0 核心链路付费用户对话、客服回复优先保障必要时使用备用模型P1 重要功能文档摘要、RAG 问答缩短输出但保留核心答案P2 辅助功能标题润色、推荐语生成可以排队必要时暂时关闭P3 后台任务离线批处理、低优先级生成可以延迟、暂停或重跑降级触发条件也要写清楚不能只说“压力大时降级”。常见触发条件包括错误率升高、P95/P99 延迟超过阈值、429 比例上升、tokens/s 明显下降、队列长度过高、单个供应商异常、单租户流量异常、成本预算接近上限等。超时、重试、降级如何组合成一条决策链在真实工程里超时、重试和降级最好不要散落在各个业务代码里而是形成一条统一的调用链。一个比较完整的流程可以是第一请求进入后先读取全局 deadline。第二判断当前用户、租户、接口和模型是否触发限流。第三根据业务等级选择主模型和调用参数。第四调用主模型并记录连接耗时、首 token 时间和总耗时。第五如果出现 408、5xx 或网络异常再判断这个错误是否值得重试。第六如果可以重试就检查剩余时间和重试预算。第七在预算内使用指数退避和 jitter 进行重试。第八如果遇到 429要尊重Retry-After并降低并发。第九如果重试仍然失败再判断是否切换备用模型。第十如果模型不可用就触发能力降级或结果降级。第十一如果降级后还是失败再返回可解释的错误。第十二整个链路都要记录错误码、token 用量、成本、重试次数和降级原因。这里的关键点是不要等所有重试都失败了才想起降级。对在线请求来说及时降级通常比长时间等待更符合用户体验。推荐参数表不同场景下怎么配置下面这些参数只能作为设计参考真正上线时还要结合模型速度、供应商限制、上下文长度和业务 SLA 来调整。场景超时重试降级在线聊天首 token 设置较短总超时中等最多 1 次切轻量模型、缩短输出RAG 问答检索和生成分别设置超时检索可重试生成谨慎重试无检索时基于已知信息回答Embedding使用短超时可重试 1–2 次拆小批次、降低并发JSON 结构化生成总超时中等可重试 1 次降级为文本后再解析Agent 任务使用全局 deadline单步骤谨慎重试减少工具调用或转为异步图片/视频生成不长时间同步等待查询任务状态可重试异步通知、排队、稍后查看一个比较实用的原则是在线链路优先控制等待时间后台链路优先保证最终完成高价值用户优先保障体验低优先级任务优先让出资源。代码示例一个可落地的调用封装下面是一段简化版 Python 伪代码主要展示错误分类、重试预算、退避和模型降级的思路importrandomimporttime RETRYABLE_STATUS{408,500,502,503,504}defis_retryable(error):iferror.status_codeinRETRYABLE_STATUS:returnTrueiferror.status_code429:returnTruereturnFalsedefbackoff(attempt):base0.5*(2**attempt)jitterrandom.uniform(0,0.3)returnmin(basejitter,3)defcall_llm_with_policy(client,request,deadline_seconds15):starttime.time()models[primary-large-model,fallback-small-model]max_retries1formodel_index,modelinenumerate(models):attempt0whileattemptmax_retries:remainingdeadline_seconds-(time.time()-start)ifremaining0:raiseTimeoutError(global deadline exceeded)try:returnclient.chat(modelmodel,messagesrequest[messages],timeoutremaining,max_tokensrequest.get(max_tokens,800))exceptExceptionaserror:log_error(error,modelmodel,attemptattempt)ifnotis_retryable(error):breakifattemptmax_retries:breaksleep_timebackoff(attempt)iftime.time()-startsleep_timedeadline_seconds:breaktime.sleep(sleep_time)attempt1# 主模型失败后尝试切换到备用模型ifmodel_indexlen(models)-1:request[max_tokens]min(request.get(max_tokens,800),400)continuereturn{type:fallback,message:当前模型服务繁忙已返回简化结果或建议稍后重试。}在真实生产环境里还需要补上很多细节比如Retry-After解析、流式首 token 超时、token 间隔超时、幂等 key、限流计数、熔断状态、指标上报和成本记录。熔断、限流与隔离也要一起设计虽然这里重点讨论的是 API 超时重试和接口降级策略但熔断、限流、隔离其实是配套能力不能分开看。熔断主要是为了保护下游。当某个模型或供应商持续出现 5xx、超时或者 429 明显飙升时就应该短时间快速失败或者直接切到备用模型而不是让所有请求继续排队等超时。限流最好分层做用户级限流租户级限流接口级限流模型级限流供应商级限流重试请求单独计数。隔离则要按业务和模型拆开。不要让低优先级批处理任务占满在线问答资源也不要让某一个租户的异常流量拖垮整个模型调用池。上线后要监控哪些指标没有观测就很难判断策略到底有没有效果。大模型 API 建议重点关注下面这些指标。指标作用首 token 延迟判断用户等待体验总响应时长判断超时配置是否合理tokens/s判断模型生成速度prompt tokens / completion tokens判断上下文和输出规模timeout rate判断超时是否频繁429 rate判断是否触发供应商限流5xx rate判断模型或供应商稳定性重试次数分布判断是否存在重试放大重试成功率判断重试是否值得降级触发率判断系统是否长期不健康fallback 成功率判断降级方案是否有效单请求成本判断重试和长输出是否推高成本用户取消率判断等待时间是否超过用户耐心尤其要关注“重试放大倍数”。比如原始请求只有 1000 次但实际打到模型供应商的请求变成了 1800 次这就说明重试已经明显放大了流量需要重新评估策略。常见错误做法设计大模型 API 调用策略时下面这些做法最好尽量避免所有错误都重试包括 400、401、413。超时时间设置得过长让用户一直等。流式接口只设置总超时不监控首 token 和 token 间隔。429 之后立刻重试导致限流更严重。降级时只返回“系统繁忙”没有任何可用替代结果。Agent 工具调用没有幂等 key。重试请求不计入限流。多模型切换后输出格式不一致。不记录 token 用量和单次请求成本。后台任务和在线请求共用同一个资源池。总结推荐的默认策略设计大模型 API 的超时、重试和降级策略时可以先遵循下面这些默认原则。超时要分层设置连接、首 token、token 间隔、总响应、业务 deadline 分开管理。重试只针对临时错误408、5xx、部分网络异常可以重试400、401、413、内容安全失败不要重试原请求。重试次数要克制在线请求通常最多 1–2 次并配合指数退避和随机抖动。遇到 429 先降速尊重Retry-After降低并发而不是马上批量重试。降级优先保体验优先考虑模型降级、能力降级、输出降级和异步化不要一上来就直接失败。用熔断保护下游供应商持续异常时要快速切换或快速失败。观测必须覆盖成本延迟、错误、重试、降级、token 和单请求成本都要记录。一句话来说大模型 API 的高可用设计不是简单把 timeout 调大、把 retry 次数加多而是在有限时间、有限成本和不稳定外部依赖之间尽量给用户一个稳定、可解释、能接受的结果。