LLM 应用与传统 API 调用最大的区别在于其不确定性:响应时间波动大、偶发性失败多、上游服务限流严格。一个生产级的 LLM 应用必须在错误处理层做足功课,否则用户体验会因为偶发故障而大幅劣化。
错误分类:可重试与不可重试
首先需要区分错误类型。网络超时、500 服务端错误、429 限流错误属于暂时性故障,重试有意义;而 400 参数错误、401 鉴权失败、413 请求体过大属于永久性错误,重试只会浪费资源。
实现时建议维护一个错误码白名单,只对明确可重试的状态码(如 408、429、500、502、503、504)执行重试逻辑。遇到 400 系列错误应立即返回,同时记录详细日志供开发者排查参数构造问题。
超时控制:分层设置阈值
LLM 推理耗时受 token 数量、模型档位、上游负载影响,单次调用可能从几秒到几十秒不等。超时设置过短会导致正常请求被误杀,过长则让用户长时间等待无响应。
建议按场景分层:对于实时对话场景,客户端超时可设为 30 秒,服务端调用 LLM 的超时设为 25 秒,留出 5 秒缓冲处理降级逻辑;对于后台批处理任务,可放宽到 60-120 秒。流式响应(SSE)场景需要特别注意:超时应以"首字节到达时间"(TTFB)为准,而非整体响应完成时间。
指数退避:避免雪崩
简单的固定间隔重试会在上游服务恢复瞬间形成流量尖峰,加剧不稳定。标准做法是指数退避 + 随机抖动:第一次重试等待 1 秒,第二次 2 秒,第三次 4 秒,每次等待时间加入 ±20% 的随机偏移。
假设一个场景:某 LLM 服务在高峰期返回 429,如果 100 个客户端同时以固定 1 秒间隔重试,会在每秒整点形成 100 QPS 的冲击;加入随机抖动后,重试请求会分散在 0.8-1.2 秒区间内,峰值降低约 40%。
重试次数上限建议设为 3 次。超过 3 次仍失败说明问题不是暂时性的,继续重试只会拖累整体响应时间。
限流应对:主动降级与排队
遇到 429 错误时,响应头通常包含 Retry-After 或 X-RateLimit-Reset 字段,指示何时可以重试。优雅的做法是解析这些头部,按建议时间等待,而不是盲目套用指数退避公式。
如果应用本身也面向多租户,建议在网关层实现令牌桶或漏桶算法,主动控制向上游发送的请求速率。当检测到持续 429 时,可触发降级策略:优先保证付费用户请求,将免费用户请求放入队列延迟处理,或直接返回友好提示"当前负载较高,请稍后重试"。
降级与回退:保证核心体验
并非所有功能都需要 LLM 才能完成。对于摘要生成、分类打标等任务,可以准备基于规则或小模型的降级方案:当旗舰档模型调用失败时,自动切换到轻量档模型;当所有 LLM 服务不可用时,返回基于关键词提取的简化结果。
降级不意味着沉默失败。应在响应中标注降级状态(如在 API 返回体中加入 "fallback": true 字段),让调用方知晓当前结果来自备选方案,避免误导用户或下游系统。
可观测性:日志与告警
错误处理策略的有效性需要通过监控验证。建议记录每次重试的触发原因、等待时长、最终结果,按错误码类型聚合统计。当某个错误码的出现频率超过阈值(如 5 分钟内 429 超过 100 次),应触发告警通知运维团队。
对于流式响应,还需监控"首字节延迟"和"流中断率"。如果发现某个上游服务的流中断率持续偏高,可能需要调整超时策略或切换备用服务商。
构建稳定的 LLM 应用需要在错误处理上投入足够精力。如果你的团队在 AI 应用开发中遇到稳定性挑战,Taylent Labs 提供从架构设计到代码实现的全流程支持,欢迎联系我们探讨具体方案。