线上服务的调用量涨到每天几十万次之后我最怕的不是报错而是报错和延迟一起变坏。上个月某个凌晨监控面板上接口错误率从 0.3% 跳到 12%同一时间段 P95 延迟从 1.8 秒涨到 11 秒。值班的同学第一反应是上游挂了准备把流量切走结果排查下来上游状态页一片绿问题出在我们自己这边一个批处理任务没做并发闸门几千个请求同时打出去触发了限流触发限流之后又没有区分错误类型所有失败请求一律原地重试重试又进一步放大了压力。报错是结果延迟是症状真正的病灶在调用方。这篇内容讲的就是这件事OpenAI API 报错怎么分层处理ATL我这里指的是 API Total Latency也就是从发出请求到拿到完整响应的端到端总延迟同时也看平均延迟怎么优化。适合正在把大模型能力接进生产系统的后端同学、算法工程同学也适合刚接手这类服务、被 429 和超时折磨过几轮的人。我会把错误码的判定逻辑、重试的边界、延迟的分段拆解、以及几个我亲手踩过的坑一条条摊开讲。不追求大而全只讲能直接抄作业的部分。1. 报错和延迟经常一起爆发但根因是两条线新手最容易犯的错是把报错多和慢当成同一个问题处理。看到错误率上来、延迟也上来就判断是上游服务抖动然后统一加重试、统一拉长超时。这套操作在传统 CRUD 接口上可能侥幸过关在大模型接口上几乎是灾难因为这两类问题的传导方向是相反的。报错率飙升最常见的三个来源限流请求发得太快或 token 消耗太快、参数问题上下文超长、格式非法、以及客户端自身的连接管理失控。延迟变高最常见的三个来源输入 token 太多导致预填充阶段变慢、输出太长导致解码阶段变慢、连接池太小导致请求在本地排队。注意最后一条请求在本地排队时你看到的延迟是 11 秒但上游可能只花了 1.5 秒——这 9 秒多全耗在你自己的进程里你去上游那边查日志什么都查不到。1.1 为什么这两类指标会耦合在一起耦合点在于重试这个动作。一次失败请求重试三次等于把一次调用放大成四次调用请求量瞬间翻四倍。如果失败原因是限流那么重试会让限流更严重如果失败原因是本地排队那么重试会把队列撑得更满。延迟和错误率就这样互相喂养形成正反馈。我在一个模拟项目里做过一次对照实验同样的 200 并发A 组不做任何错误分类失败即重试最大 3 次B 组只对 5xx 和连接异常重试且带随机抖动最大 2 次。结果 A 组的有效成功率是 71%P95 延迟 14 秒B 组有效成功率 96%P95 延迟 3.2 秒。差别不在重试次数多少而在该不该重试这个判断上。1.2 处理顺序先止血再定位最后优化我的做法是固定成三步任何一次线上异常都按这个顺序走不要跳步。第一步是止血用开关而不是改代码。准备好三个运行时开关全局并发上限、单接口超时、重试开关。出问题时先把并发上限砍半、把重试关掉观察一分钟错误率和延迟通常立刻回落一半以上。这一步的意义是把系统从雪崩边缘拉回来给你争取排查时间。第二步是定位靠日志而不是靠猜。每次请求必须落一条结构化日志包含 request_id、model、status_code、prompt_tokens、completion_tokens、排队耗时、首字耗时、总耗时、重试次数。有了这几个字段你能在一分钟内回答是排队慢还是上游慢这个问题。没有这些字段就只能靠反复试验那是另一种形式的猜。第三步才是优化。优化的对象永远是定位出来的那个瓶颈而不是看起来最可疑的环节。我见过团队在没有观测数据的情况下直接上缓存结果缓存命中率只有 4%因为请求的 prompt 里带时间戳每次 hash 都不一样。提示先把能观测这件事做完再谈优化。没有分段延迟数据的优化本质上是在赌运气。2. 错误码逐层拆解哪些能重试哪些重试就是自杀重试策略的前提是错误分类。同一套重试逻辑套在所有错误上等于把可恢复的故障和不可恢复的故障混为一谈。我把实际遇到的错误按能不能重试分成三档这个分类在我经手的几个项目里几乎没有变过。2.1 第一档绝对不能重试的错误这一类重试只会浪费配额和时间而且可能带来副作用。400 invalid_request_error里的context_length_exceeded是最典型的。输入加输出的 token 超过了模型窗口你重试一百次结果都一样。正确的处理是裁剪上下文或者换更长的窗口模型而不是重试。我建议在调用前就做一次 token 预估超了就主动截断历史消息别等报错回来再处理。400里的参数格式错误比如temperature传了字符串、tools结构不合法同理属于代码 bug重试毫无意义。401密钥无效、403权限不足、404模型名拼错都属于配置问题重试只会把错误日志刷满。这里有个特别容易误判的429里有一种是额度耗尽insufficient_quota它在状态码上和限流完全一样但重试是纯粹浪费。判断方法很简单看错误体里的code字段限流是rate_limit_exceeded额度是insufficient_quota。很多团队只判断了状态码 429结果在余额耗尽的那几个小时里疯狂重试日志量翻了几十倍。2.2 第二档可以重试但必须限流的错误429 rate_limit_exceeded属于这一档但要细分维度。限流通常有两个维度每分钟请求数RPM和每分钟 token 数TPM。如果是 RPM 打满说明并发太高重试时应该退避如果是 TPM 打满说明单次请求太重这时候光退避没用得考虑压缩输入或者拆批。500、502、503、504这一组属于服务端侧问题。503通常表示服务过载退避重试是合理的500是内部错误重试一次有较大概率成功504是网关超时这种情况要小心——上游可能还在处理你的重试会造成重复计费所以要么接受一次重复要么在业务层做幂等。连接层异常APIConnectionError、APITimeoutError要看具体原因。如果是本地连接池耗尽重试只会让情况更糟如果是链路抖动重试有效。区分方法看异常发生时本地的活跃连接数和等待队列长度。2.3 第三档需要改架构才能解决的错误这一类是我认为最值得单独讲的因为它们看起来像偶发错误实际上是系统性问题的信号。第一个是流式响应中途断开。你已经开始接收 token 了连接突然断掉。这时候部分内容已经推给前端或者写进数据库了重试会导致内容重复。我的处理是流式场景下不自动重试改为把已接收内容标记为不完整由业务层决定是补全还是丢弃。第二个是长尾超时。99% 的请求 2 秒内返回1% 的请求 60 秒还没返回。这不是错误处理能解决的得靠超时设置加异步化。把非实时任务从同步链路里摘出去走队列用户先看到处理中结果出来后推送。这一条改动量不小但收益最大。下面这张表是我实际在用的判定逻辑可以直接照着写代码错误类型状态码/异常类是否重试处理动作上下文超长400 context_length_exceeded否裁剪历史重新构造请求参数非法400 invalid_request_error否修代码告警密钥/权限401 / 403否检查配置告警模型不存在404否检查模型名额度耗尽429 insufficient_quota否告警人工充值请求限流429 rate_limit_exceeded是指数退避抖动最多 2 次服务过载503是退避后重试最多 3 次内部错误500是退避后重试最多 2 次网关超时504谨慎需业务幂等最多 1 次连接异常APIConnectionError视情况检查本地连接池后再决定流式中断读取异常否标记不完整业务层兜底2.4 重试本身要写成有预算的组件很多人写重试就是一个for循环加sleep这不够。我要求重试组件必须满足四个条件指数退避、随机抖动、总时间预算、可关闭。指数退避的底数建议 0.5 秒倍数 2也就是 0.5、1、2 秒。抖动一定要加否则同一批请求会在同一时刻再次撞在一起。最常用的全抖动公式是delay random(0, base * 2^attempt)。总时间预算是容易被忽略的一条如果单次请求超时是 20 秒重试 3 次最坏情况下这个请求会占住一个 worker 80 秒上游早就放弃了你还在等。我一般把总预算控制在单次超时的 2 倍以内。import random import time from openai import OpenAI, RateLimitError, InternalServerError, APIConnectionError client OpenAI(api_keyAPI_KEY, timeout20.0, max_retries0) # 关闭SDK内置重试自己控 RETRYABLE (RateLimitError, InternalServerError, APIConnectionError) def call_with_budget(messages, max_attempts3, budget_sec30.0, **kwargs): start time.monotonic() last_exc None for attempt in range(max_attempts): try: return client.chat.completions.create(messagesmessages, **kwargs) except RETRYABLE as exc: last_exc exc elapsed time.monotonic() - start # 全抖动退避 delay random.uniform(0, 0.5 * (2 ** attempt)) if elapsed delay budget_sec: break # 预算不够了直接放弃别硬撑 time.sleep(delay) except Exception: raise # 非可重试错误立即上抛 raise last_exc这段代码有两个细节值得说。一是把 SDK 内置的max_retries关掉避免它和你自己的重试逻辑叠加两次退避乘在一起实际等待时间会失控。二是预算检查放在 sleep 之前而不是之后否则会出现睡完了才发现预算已经超了的情况。3. 延迟优化先找准瓶颈TTFT、TPOT、队列排队三处最费时间延迟这件事最忌讳一上来就说要提速。大模型接口的延迟天然有三个不同的阶段每个阶段的优化手段完全不一样你得先知道时间花在哪儿。3.1 把一次请求切成四段来看我用四个时间点来切割一次调用请求发出时间、首字节到达时间、首个 token 到达时间、最后一个 token 到达时间。由此得到三个指标TTFTTime To First Token从发出到首 token主要受输入长度、网络往返、排队影响。TPOTTime Per Output Token平均每个输出 token 的耗时主要受输出长度、解码速度影响。E2E端到端前两者之和加上网络传输。为什么要分这么细因为用户体感由 TTFT 决定。一个总耗时 8 秒但 0.6 秒出首字的回答用户会觉得挺快一个总耗时 8 秒、前 7 秒一片空白然后瞬间刷满的回答用户会觉得卡死了。这两个在监控上看 E2E 完全一样优化方向却完全相反。我通常会算一个比值TTFT / E2E。如果这个比值超过 0.5说明瓶颈在预填充阶段要砍输入如果低于 0.1说明瓶颈在解码阶段要控输出长度。这个比值比任何单一指标都好用。3.2 输入长度是隐形的成本放大器输入 token 对延迟的影响接近线性而且它对延迟和成本是双杀。我见过最夸张的一个场景系统消息里塞了一份 6000 字的业务规则文档每次请求都带导致单次输入的 token 数是输出的一百多倍TTFT 稳定在 4 秒以上。处理方式有几种按实施成本从低到高排第一种是瘦身。把提示词里的客套话、重复说明、过时的 few-shot 示例删掉。我做过一次清理把系统提示从 1800 token 压到 400 tokenTTFT 从 2.1 秒降到 0.9 秒效果立竿见影。做这件事的方法很朴素把最近的请求样本导出来按 token 数排序看前十个最长的是谁逐个问这段真的每次都需要吗。第二种是把静态内容挪出请求。规则文档、知识库片段这类内容能缓存就缓存能走检索就走检索只把最相关的两三段塞进上下文。检索的召回数量从 10 降到 3输入能少一半以上回答质量通常反而更好——上下文太长会稀释注意力。第三种是分级模型。简单任务用小模型复杂任务才上大模型。这一条我在第 4 章展开讲。3.3 输出长度要用参数硬约束max_tokens这个参数很多团队设成一个很大的值比如 4096理由是防止截断。这个做法在延迟上代价极高因为解码是逐 token 生成的你设的每一个 token 都是潜在的时间成本。我的建议是按任务类型分别设分类、抽取这类任务输出通常在 100 token 以内max_tokens设 256 足够摘要类设 512只有创作类才需要放宽。设小了被截断怎么办让返回的finish_reason告诉你——如果它是length说明被截断了这时候再做一次续写请求比一开始就留 4096 的空间要划算得多。还有一个反直觉的点让模型少说废话能省很多时间。在提示词里明确写直接给结论不要复述问题不要解释过程能稳定省下 20% 到 40% 的输出 token。这一条几乎是零成本的优化我每个项目都会加。3.4 本地排队是最容易被误判的延迟来源前面提过请求在本地排队时你看到的延迟和上游的真实延迟完全不是一回事。判断方法很简单在发请求之前记一个时间戳拿到响应之后记一个时间戳两者之差是客户端观测延迟同时把响应头里的服务端处理信息如果有或者请求 ID 关联的服务端日志拿来对比。如果客户端延迟远大于服务端延迟那就是本地问题。本地问题的三大成因线程池或协程池太小、连接池太小、同步调用堵住了事件循环。第三个最常见。你在异步框架里调用了一个同步的 SDK 方法整个事件循环被这一个请求卡住后面所有请求都在等它。判断特征是这个接口的 P99 出现规律性的、和并发数正相关的尖刺。还有一个具体参数值得单独说连接池的最大连接数。默认值通常很小有的库默认 10而你的并发可能是 200。这时候 190 个请求在队列里等待每个都要等前面释放连接。把连接池调到和并发上限匹配延迟能直接降下来。同时记得开 keep-alive复用连接能省掉每次 TLS 握手的开销在跨区域调用时这部分开销可能是几百毫秒。4. 把优化落到代码超时、连接复用、并发闸门与缓存分层前面讲的是看什么这一章讲怎么改。我把优化手段按投入产出比排了个序前两项几乎不需要改架构收益却最直接。4.1 超时设置要分层不能只有一个值我要求至少设三个超时连接超时、读超时、总超时。连接超时短一点3 到 5 秒读超时长一点按任务类型定总超时是兜底。很多 SDK 只暴露一个timeout参数那就把它理解成总超时来用。这里有个非常隐蔽的坑如果你的服务对外暴露的超时比内部调用上游的超时还短就会出现客户端已经超时返回但上游还在处理的状态。这时候上游会继续消耗 token 并计费你的用户已经看到错误了。我踩过这个坑一次线上故障里网关超时 10 秒客户端调上游的超时设了 30 秒结果接口返回 504 的同时后台还在跑着一堆注定被丢弃的请求白白烧了一笔费用。正确的顺序是对外超时 内部总超时 单次请求超时。比如对外 45 秒内部总预算 30 秒单次 20 秒。这样任何一次内部重试都在对外超时之前收尾不会出现白跑的请求。import httpx from openai import OpenAI # 连接池与超时分开配置 http_client httpx.Client( limitshttpx.Limits( max_connections100, # 和你的并发上限对齐 max_keepalive_connections50 ), timeouthttpx.Timeout( connect3.0, # 连接超时 read25.0, # 读超时覆盖最长输出 write5.0, pool2.0 # 从连接池取连接的等待上限 ) ) client OpenAI(api_keyAPI_KEY, http_clienthttp_client, max_retries0)pool这个超时特别值得注意。它控制的是排队等连接的时间设得很长会让你误以为上游慢设得很短会误杀正常请求。我一般设 2 秒超过 2 秒还拿不到连接说明并发打满了这时候快速失败比排队更合理——反正排队下去也是超时。4.2 并发闸门宁可排队在业务层不要排队在连接层大模型调用和普通接口的一个本质区别是它很贵且服务端有速率限制。无限并发不但提升不了吞吐还会触发限流整体吞吐反而下降。我的做法是在业务层加一个信号量把并发控制在自己的手里。信号量的大小怎么定不能拍脑袋要算假设上游给你的配额是每分钟 600 次请求平均响应时间 2 秒那么理论并发上限约等于 600 / 60 × 2 20。按这个数再打个七折取 14 到 15留出余量应对突发。除了并发数还要控队列长度。信号量后面必须有一个有界队列队列满了直接快速失败返回系统繁忙请稍后重试而不是无限堆积。无限队列的后果是延迟无限增长用户在页面上转圈转三分钟最后还是失败这个体验比立刻失败差得多。另外建议加一个简单的熔断连续 N 次失败比如 20 次里有 15 次失败就打开熔断直接拒绝新请求 30 秒期间只放少量探针请求。这一招在依赖方整体不可用时能保住你自己的服务不被拖死。4.3 缓存分三层命中率差距很大缓存在这个场景下非常好用但必须分层设计否则命中率会低得让你怀疑人生。第一层是精确缓存把请求参数模型、messages、temperature、max_tokens序列化成稳定字符串做 key结果整体缓存。命中率取决于你的业务是否有重复请求。如果 prompt 里带了时间戳、用户 ID、随机数命中率基本为零。这里有个技巧把 prompt 拆成模板部分和变量部分只对模板部分做规范化变量部分单独处理。有的业务场景下一次会话里用户反复问相似问题这一层能吃掉不少流量。第二层是语义缓存把用户输入做向量化和缓存里的历史输入比相似度超过阈值我一般用 0.95 以上就复用结果。这一层适合客服问答、知识库问答这类问题重复度高的场景。阈值不能太低0.9 以下就开始出现答非所问了宁可少命中也不要错命中。还要注意语义缓存对时效性敏感的问题不适用比如今天的天气这类问题必须绕过缓存。第三层是结果级缓存对结构化输出比如分类结果、抽取的字段单独缓存不缓存原始文本。这一层的好处是即使上游模型换了只要语义没变缓存依然有效。三层叠加我经手的一个问答类项目命中率做到了 34%平均延迟降了 40%成本降了差不多三成。但我要强调缓存是锦上添花不是雪中送炭——如果基础链路的超时和并发都没管好上缓存只会掩盖问题等缓存失效时故障会以更猛烈的形式回来。4.4 分级模型与异步化分级模型的逻辑很简单给每个任务打一个难度标签简单的走小模型复杂的走大模型。实测下来分类、意图识别、简单改写这类任务小模型的质量和大模型差距很小但延迟能低一个数量级成本低一个数量级。难点在于怎么判断简单。我的做法是先全量走大模型同时把请求和结果都记下来人工抽样标注一批看哪些任务小模型也能答对。有了这批标注数据再上路由规则就靠谱了。没有标注数据直接上规则路由很容易把复杂任务误判成简单任务质量掉得莫名其妙。异步化则适用于所有非实时场景。批量摘要、离线审核、定时报告这类任务用户根本不需要等在页面上。把它们从同步接口里摘出去走消息队列用独立的 worker 池处理同步接口的延迟和错误率立刻好看很多。这一条改造成本不低但只要你的系统里有超过 30% 的调用是非实时的就值得做。优化手段预期延迟收益实施成本主要风险提示词瘦身中高TTFT 降 30%~60%低过度裁剪影响质量限制 max_tokens中E2E 降 20%~40%低输出被截断需续写连接池与超时调优中消除本地排队低参数需反复试并发闸门中降低限流概率中需算准配额精确缓存视业务0~40%中命中率不稳定语义缓存中高20%~40%高误命中影响质量分级模型高延迟降一个量级高需标注数据支撑异步化高同步链路彻底减负高改架构周期长5. 观测体系与四个真实踩坑复盘优化做完不等于结束。我见过太多团队优化上线之后没有留观测过两周流量涨了、模型换版本了延迟悄悄回去了没人发现。这一章讲怎么把指标建起来以及几个我觉得最有代表性的坑。5.1 必采字段与分位数视角每条请求日志必须有这几项请求 ID用于和服务端对账、模型名、状态码、错误码、输入 token 数、输出 token 数、重试次数、排队耗时、TTFT、总耗时、是否命中缓存。字段不多但缺一项你就少一个排查维度。看指标的时候只看平均数等于没看。平均延迟 1.2 秒听起来很棒但如果 P99 是 30 秒意味着每 100 个用户就有 1 个在等 30 秒。我的告警策略是P50 看趋势判断整体是否变慢P95 看报警超过阈值就响P99 看容量判断是否需要扩并发或加缓存。还有一个指标容易被忽略重试率。它不直接反映在延迟上但它是雪崩的前兆。重试率超过 3% 就说明有问题在酝酿哪怕此时错误率还很低。我现在的告警规则里重试率的优先级排在错误率前面。5.2 坑一SDK 内置重试和自定义重试叠加这是我最早就踩的坑。SDK 默认会重试 2 次我以为关掉了实际上只改了业务层的循环次数。结果一次请求最坏情况下被放大成 3×39 次退避时间乘以两次指数一个本该 20 秒结束的请求拖到了 90 秒把线程池占满引发全站超时。排查过程很有意思日志里单次请求的耗时分布出现了三个明显的簇分别在 20 秒、45 秒、90 秒附近。看到这种阶梯状的分布基本可以断定是嵌套重试。修法很直接初始化客户端时显式设max_retries0所有重试逻辑收归到自己的封装层一处配置、一处生效。5.3 坑二流式返回中断后内容被截断入库流式场景下如果连接在生成中途断开for chunk in stream循环会直接结束不会抛异常。如果你没检查完整的finish_reason就会把半截内容当成完整结果写进数据库。这个问题很隐蔽因为大部分时候流是完整的只有偶发的网络抖动才会触发比例可能只有千分之几但一旦触发就是脏数据。修法是循环里捕获异常循环结束后检查是否收到了正常的结束标志。没收到就把这条记录标记为不完整让下游的消费方知道这份内容需要重新生成。别指望重试能补上——已经推给前端的部分没法收回重试只会让内容重复。5.4 坑三把限流当成故障触发了错误的重试风暴有一次上游调整了配额策略我们的 RPM 配额降了一半多。因为错误处理逻辑里没区分rate_limit_exceeded和insufficient_quota所有 429 都进了重试分支重试又消耗 RPM导致配额雪上加霜。那段时间错误率一直在 20% 上下震荡怎么调并发都没用。根因定位花了两个小时最后是导出了错误体的原文才发现的。经验教训是错误处理里一定要打印错误体的code和type字段光打状态码不够。这两个字段才是判断该不该重试的真正依据。5.5 坑四用平均值掩盖了模型版本切换的影响模型服务方升级版本是常事每次升级之后延迟特性可能有细微变化比如 TTFT 略增、输出变得更啰嗦。这种变化在平均值上几乎看不出来但会在 P95 上体现。我们有一次换版本后平均延迟只涨了 3%看着可以接受但 P95 涨了 60%用户投诉明显变多。所以每次模型版本变更我都会做一次对照用固定的一批测试请求覆盖长短输入、简单复杂任务在切换前后各跑一遍记录 TTFT、TPOT、输出 token 数的分布。这批固定请求我建议长期维护它就是你的回归基线比任何一次性的压测都有价值。注意模型版本切换不要做灰度发布之后只看错误率延迟分布的变化同样重要尤其是 P95 和输出长度这两个维度。最后分享一个我在实际项目里养成的习惯每次优化上线都在日志里打一个config_version标记把当时的并发上限、超时值、缓存阈值、模型名一起记下来。好处是当两周后延迟又变差了你可以直接对比两个版本之间的配置差异不用去翻部署记录猜当时改了什么。这个小字段帮我省过好几次排查时间成本几乎为零建议你也在自己的服务里加上。