将你的 LLM 提供商视为不可靠上游：AI 的分布式系统实战手册

你的监控仪表板一片绿色。响应时间看起来正常。错误率接近于零。然而你的用户却在提工单投诉垃圾回答，你的 agent 正在做出自信满满的错误决策，你的客服队列里塞满了与任何基础设施告警都不相关的投诉。

欢迎来到在生产环境中依赖 LLM API 的独特地狱。这是一个能在返回完美健康的 200 OK 的同时让你翻车的上游服务。

大多数后端工程师已经内化了一套处理不可靠第三方依赖的实战手册：熔断器、指数退避重试、舱壁、超时、降级响应。这些模式经过数十年分布式系统实践的战火洗礼。但 LLM API 打破了这些模式赖以建立的每一个假设，天真地应用它们只会给你一种虚假的安全感，而真正的故障却在不知不觉中溜走。

你没在监控的故障模式

传统的上游服务以你的监控栈知道如何捕获的方式故障。数据库返回连接错误。支付 API 返回 500。微服务超时。你的告警响了，熔断器跳闸，降级方案启动。系统优雅降级。

LLM API 引入了一种基础设施监控从未被设计来检测的故障模式：语义退化。API 返回 200，延迟看起来正常，响应体是格式良好的 JSON——但内容是错的。模型幻觉出了一个不存在的政策。它用竞争对手的信息回答了关于你产品的问题。它遵循了用户输入中嵌入的提示注入指令。这些都不会触发你 Datadog 仪表板上的任何一个告警。

这就是 LLM 上游与你依赖的其他所有 API 之间的根本区别。对于支付处理器，200 意味着扣款成功。对于 LLM，200 意味着模型产生了 token。这些 token 是否有用、准确或安全，是一个你的基础设施层没有任何意见的独立问题。

在生产环境中真正造成伤害的故障往往遵循一个模式：

• 幻觉漂移：模型开始基于越来越不相关的上下文生成回答，但响应保持流畅和自信，而正确性在衰退。
• 行为回归：提供商更新了他们的模型，你精心调优的提示开始产生微妙不同的输出。语气变了，格式变了，曾经好用的边界情况现在不行了。
• 静默工具调用损坏：在 agent 工作流中，模型行为的微小变化触发过多或不正确的工具调用，而你的基础设施指标不会标记这些问题。

为什么你的超时策略可能是错的

为 LLM API 设置超时比听起来更难，因为延迟分布与你技术栈中的任何东西都不一样。一个典型的微服务可能 P50 是 50ms，P99 是 200ms——4 倍的差距。LLM API 经常表现为 P50 500ms，P99 4-5 秒——10 倍的差距。在糟糕的日子里，P99 可以飙升到 15-20 秒，而提供商不报告任何事故。

这意味着你的超时必须适应一个巨大的范围。设得太紧，你会杀掉原本会成功的请求。设得太松，你的用户会盯着转圈图标 20 秒然后收到一个错误。两个选项都不可接受。

"将超时设为 2 倍 P99"的常规智慧在这里失效了，因为 P99 本身就是不稳定的。在高峰时段或提供商模型更新后，你的基线延迟可以在没有任何警告的情况下偏移 3-5 倍。根据昨天延迟分布校准的超时今天可能就是错的。

在实践中更有效的方法：

• 自适应超时，基于最近延迟百分位数的滚动窗口，而不是静态配置值。如果你的 P95 在过去 10 分钟一直在攀升，你的超时应该自动调整。
• 按操作的超时预算，考虑预期的输出长度。生成 50 个 token 的请求应该有一个与生成 2,000 个 token 的请求非常不同的超时。
• 截止时间传播，从你面向用户的 SLA 向后通过调用链传播。如果你的 API 承诺在 10 秒内响应，你已经花了 3 秒在检索上，你的 LLM 调用得到 6 秒的预算，而不是你的 HTTP 客户端配置的默认值。

熔断器需要语义维度

经典的熔断器模式监控错误率：当故障超过阈值时，熔断器跳闸断开并停止向故障服务发送流量。对于 LLM 提供商，这大概捕获了 20% 的问题——那些实际产生 HTTP 错误的问题。

生产 AI 团队最终构建的熔断器同时监控三个信号：

错误率（传统信号）：追踪 429、500、502 和 503。来自生产部署的社区共识大约是 5 次失败触发跳闸，60 秒冷却期。在错误率大于 5% 时告警，大于 15% 时升级为严重。

延迟退化：当 P95 延迟超过其滚动基线的 3 倍时，即使每个请求最终都成功了，也将其视为部分故障。一个技术上在线但每个请求需要 12 秒的提供商，对于任何面向用户的应用来说都是功能性宕机。

质量退化：这是最难的。你需要内联质量检查——在响应样本上运行的轻量级评估，以检测幻觉率增加、格式合规性下降或指令遵循回归。当你的质量分数降到阈值以下时，熔断器应该将流量路由到降级提供商，即使主提供商在技术上是健康的。

构建第三个信号是区分在生产中运行 LLM 的团队和在生产中演示 LLM 的团队的关键。

降级链比你想象的更复杂

REST API 的典型降级策略很简单：如果服务 A 失败，试服务 B。LLM 降级更棘手，因为服务之间不可互换。

不同提供商的不同模型有不同的能力、不同的上下文窗口、不同的指令遵循特性和不同的故障模式。你在 Claude 上完美工作的提示在 GPT-4o 上可能产出垃圾，反之亦然。OpenAI → Anthropic → Google 的降级链在白板上看起来很好，但需要维护三套提示、三套质量基线和三套集成测试套件。

在生产中实际有效的方法：

加载中…