OpenAI错误处理和重试的血泪经验
上周四凌晨 2:47，我们组的聊天机器人挂了。
第二天客服主管的脸色，比我凌晨三点调试的那个破代码还难看。翻了半天日志，就一行：openai.RateLimitError: Error code: 429。就这一个限流错误，整个服务像多米诺骨牌一样塌下去——没重试，没降级，连个报警都没有。我当时对着屏幕愣了半天，心想这一年多都白干了。
这事让我特感慨。想起来 2023 年初刚接 ChatGPT 那会儿，总觉得 API 调通就等于上线了，天真得可以。后来在生产环境里摸爬滚打，踩过的坑比我小区门口那条修了三年还没修好的路都多。今天聊聊 OpenAI API 的错误处理和重试机制，全是实战换来的经验，没有官方文档那种"你应该优雅地处理异常"的废话。
先搞清楚敌人在哪
OpenAI API 的错误我分四类，比官方文档直白多了：
HTTP 429 - Rate Limit
最常见，也最让人抓狂。不是你的代码有问题，是请求太猛被限了。OpenAI 对不同模型的 RPM（每分钟请求数）和 TPM（每分钟 token 数）都有限制。GPT-4 的 RPM 大概也就 200-500，看你账号等级。我们有个内容生成的业务，高峰期 QPS 能到 30，一算 GPT-4 的 RPM 根本扛不住。一开始傻乎乎地加钱升 tier，后来发现优化 prompt 减少 token 消耗才是正道，直接省了 40% 的请求量。
等等，这里我要更正一下——现在 GPT-4 Turbo 的 RPM 默认是 500，GPT-4 是 200，但如果你升到 Tier 5，GPT-4 能到 10000 RPM。不过升 tier 要花钱花时间，不是所有团队都等得起。
HTTP 5xx - 服务端挂了
OpenAI 那边炸了。2023 年 11 月那波大面积宕机还记得吧？status.openai.com 红了一片，我们当时没做容灾，业务停摆 4 个小时。2024 年 6 月也抽过一次，虽然就 20 分钟，但正好赶上我们的促销活动。后来学乖了，接了 Azure OpenAI Service 做备份。
网络超时 / 连接错误
嗯...这个比较复杂。国内直连 OpenAI API 偶尔抽风，timeout 设得不合理的话，一个请求能卡 60 秒，把整个线程池都堵死。我们后来把 timeout 设成 30 秒，但说实话，这数字也是拍脑袋定的。
Token 超限 / 内容审查
400 错误里的细分。比如 context window 爆了，或者 prompt 触发审查。这种错误重试没用，得从业务逻辑上规避。有一次我们运营同学在 prompt 里塞了个用户输入的脏话，直接被拒了，重试了 5 次都不行——后来才知道触发了 content filter。
重试机制，不是套个 for 循环就完事
我见过最离谱的实现——有个同事用 while True 包了个 API 调用，sleep 5 秒无限重试。结果 429 的时候还在疯狂请求，直接被 OpenAI 封了 API key。凌晨三点，他给我打电话说 key 没了，我差点没背过气去。
正确的重试，得这么搞：
第一层：指数退避 + 随机抖动
429 错误时 OpenAI 会在响应头里返回 Retry-After，告诉你要等多少秒。但别傻傻精确等那么久，加个随机因子，避免"惊群效应"——所有请求同时醒来，再次把 API 打爆。
import random
import asyncio
async def call_with_retry(prompt, max_retries=3):
for attempt in range(max_retries):
try:
response = await openai.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": prompt}]
)
return response
except openai.RateLimitError as e:
if attempt == max_retries - 1:
raise
retry_after = e.response.headers.get("Retry-After")
if retry_after:
wait_time = float(retry_after) + random.uniform(0, 1)
else:
wait_time = (2 ** attempt) + random.uniform(0, 1)
await asyncio.sleep(wait_time)我觉得优先用 Retry-After 这个做法特别实用，实测能减少大概 30% 的无效等待。
第二层：熔断器
这个太重要了。当错误率超过阈值，直接熔断，不再发请求。不然你的重试逻辑会加剧问题。我们用 pybreaker 实现的，配置是：1 分钟内失败率超 50% 就熔断 30 秒。熔断期间走缓存或者返回兜底回复："AI 助手暂时休息，请稍后再试"。
今年 2 月有一次凌晨 3 点，OpenAI 又挂了。熔断器自动触发，看了下监控，熔断了 47 分钟，省了 2 万多条注定失败的请求。虽然用户体验打了折扣，但至少没崩溃。
第三层：队列削峰
别让所有请求直接打过去。我们中间加了 RabbitMQ，请求先入队，worker 按固定速率消费。这样即使上游流量暴涨，下游调用也是平滑的。
这个改造是因为有次老板在抖音直播带货，导流过来的用户瞬间把并发打到平时 10 倍，API 额度直接爆了。加上队列后，用户等了几秒才收到回复，但服务没挂。直播带货的场景，等 5 秒和直接报错，转化率差了 20 倍——这是我们电商部门给的数字，我觉得可能有点夸张，但方向是对的。
几条血泪教训
别把 API key 写死在代码里
这好像不用多说，但我真见过有人把 key 硬编码然后提交到 GitHub，第二天收到 OpenAI 账单——3000 美元。Key 被爬虫扫到拿去挖矿了。现在我们的 key 全走环境变量 + HashiCorp Vault 动态注入，而且设了 usage limit，每月最多花 1500 刀自动停。
监控比代码更重要
我们接 Prometheus + Grafana，盯这几个指标：
- API 调用成功率（按错误码分类）
- P50/P99 延迟
- 每分钟请求数（接近限额就告警）
- 重试次数占比
有一次 P99 延迟突然从 2 秒飙到 15 秒，查了半天发现是某个同事在 prompt 里塞了一整本产品手册当 context，token 数爆炸。没监控的话根本发现不了这种"慢性自杀"。那同事后来请大家喝了杯奶茶，这事就算过去了。
成本优化要趁早
刚开始用 GPT-4 没在意成本，月底账单 800 刀，老板差点让我自己掏。后来做了几件事：
- 能用 GPT-3.5 的场景绝不用 4
- 加 Redis 缓存，相似问题直接返回缓存结果，命中率做到 35%
- Prompt 精简，别塞没用的 system message
成本降了 60%，效果几乎没差。
准备 Plan B
我们现在是 OpenAI 主路 + Azure OpenAI 备用，再加一个本地部署的 Llama 3 70B 做最后兜底。虽然 Llama 的效果差一些，但至少不会让用户看到 500。三层降级，核心业务可用性从 99.2% 提到 99.8%。这 0.6% 听起来不多，但对我们这种日均 50 万次调用的业务来说，就是每个月少挂了 9 万次请求。
还有个小插曲。Azure OpenAI 的接口和原生 OpenAI 不完全一样，我们最开始切换的时候，有个参数名写错了，降级失败。运维同事半夜打电话骂我，说我文档写得不清楚。他说的对。
说实话，现在 OpenAI API 的稳定性比 2023 年好多了。但生产环境里让你头疼的往往不是 API 本身，而是各种边界情况：网络抖动、流量突增、成本失控、安全漏洞。重试机制只是最后一道防线，前面的架构设计、监控告警、成本控制才是大头。
你们在生产环境接过 OpenAI API 吗？遇到过什么奇葩问题？我特别想听听有没有人跟我一样，凌晨被 429 搞醒的经历——欢迎评论区分享你的踩坑故事，让我知道不是我一个人半夜爬起来看日志。
#OpenAI #API错误处理 #生产部署 #重试机制 #SRE
读者评论 4