有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。
这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。
你无意间建起的集群
一年前，典型的生产AI技术栈不过是一个API密钥和一个供应商。如今，它通常是多种组合：用于复杂推理的主力前沿模型、用于分类和路由的更廉价快速模型、针对特定领域任务的微调端点、用于数据敏感型工作负载的自托管开放权重模型，以及当主供应商触达速率限制或宕机时的备用供应商。
2025年1月，生产环境中可用的独立模型数量为253个，到当年年底已超过650个。同期，推理供应商从27家增至90家，增长了近三倍。团队并未主动规划这种扩散——他们一次集成一个，逐步积累，通常是在截止日期的压力下完成的。
最终结果是一个推理集群，它拥有微服务架构的全部运维复杂性，却没有任何使微服务变得可管理的工具、规范或所有权结构。集群已经存在，但适用于它的SRE操作手册几乎还是一片空白。
为什么LLM供应商不同于其他依赖项
当你添加一个新的微服务依赖时，你会得到可以推断的崩溃语义：服务要么响应，要么不响应。当它出现故障时，它会大声报错——错误码、超时、堆栈跟踪。
LLM供应商的故障方式截然不同。近期事故中记录在案的故障模式包括：一次模型更新波及了1.8亿用户，在回滚前持续三天系统性地引导用户做出错误决策；一次负载均衡变更悄无声息地将16%的请求路由到了有效上下文窗口更小的服务器；一次TPU配置错误提高了罕见Token的生成概率，在数周内持续降低输出质量，却始终未触发任何错误指标。
这些都不是传统意义上的宕机：正常运行时间是100%，错误率保持平稳，API返回200 OK，监控什么异常都没发现——因为监控衡量的是可用性，而不是行为。
当然，也有直白的宕机事故。LLM供应商API的正常运行时间从2024年第一季度的99.66%下降到2025年第一季度的99.46%，随着需求超过基础设施扩容速度，每年的停机时间增加了约60%。这仍然比大多数云基础设施组件差两到四倍。与云服务宕机（往往是区域性的且持续时间短暂）不同，LLM供应商的服务降级可以是全球性的、模糊的、且持续时间较长的。
行为劣化与低于SLA的可用性相叠加，意味着标准的生产工程假设——"只要依赖项正常运行并返回200，它就在工作"——对LLM供应商并不成立。
SRE规范填补的三个空白
在没有SRE实践的情况下运行推理集群，会产生三个不同的运维空白，它们相互叠加，演变为可靠性问题。
空白一：没有人负责次要供应商。 当一个团队只有一个LLM供应商时，所有权是明确的。当有四个供应商，每个供应商由不同的工程师在不同时间为不同用例选定时，没有人明确负责供应商级别的可观测性。一旦某个环节出现劣化，分类排查过程就变成了一场追查：是哪个供应商、哪个端点、哪个功能团队的集成出了问题？
与此同时，劣化仍在持续。2025年8月的一起事故在被发现之前持续了数周，原因正是没有任何团队监控着出问题的那个供应商。解决方案是为每个供应商创建一条服务目录记录——记录负责人、值班分配、健康检查定义和故障升级路径。创建它只需一个小时，却能预防那些需要数天才能发现的事故。
空白二：容量以错误的单位来衡量。 传统的速率限制是每秒请求数，而LLM的容量是每分钟Token数，并且请求数与Token数之间的关系既不恒定也难以预测。单个智能体工作流消耗的Token量可能是聊天机器人交互的5到30倍。
多智能体编排使这个问题更加复杂：每个智能体产生子调用，每个子调用消耗一个上下文窗口，而一个看起来是"单次请求"的用户操作，其总Token消耗可能跨越数十个API调用、高达数十万Token。以请求数规划容量的团队，往往会在流量高峰时发现他们的智能体密集型工作负载触碰了他们根本不知道存在的Token速率限制。按任务、按用户会话、按智能体循环进行的Token预算管理，才是真正重要的容量基本单元，而这需要大多数团队尚未建立的监控能力。
空白三：行为漂移没有告警。 40%的生产智能体故障被归因于模型漂移：模型的输出分布发生了变化，虽未到灾难性程度，但足以破坏下游解析、下游逻辑或用户预期。工具版本问题又导致了另外60%的故障。这两类都不是API错误，也都不会触发现有告警。
捕获它们的唯一方法是评估：通过自动化检查，按计划将代表性提示词发送到各供应商端点，并将输出与预期特征进行对比。这相当于LLM领域的合成监控，就像合成监控一样，在你遭遇第一次未被发现的漂移事故之前，它看起来是可选的。
构建服务目录
服务目录是将推理集群从隐式依赖图转变为可管理基础设施的起点。对于生产环境中的每个LLM供应商或端点，目录应包含以下内容：
- 端点标识：固定的具体模型版本（不是"gpt-4"，而是"gpt-4-2024-11-20"）、供应商、所服务的用例以及负责的团队。
- SLO定义：基于历史观测行为得出的针对每个供应商的可用性、p95延迟和错误率目标——供应商鲜少发布正式SLA。领先的团队会将内部SLO设置得比观测正常运行时间严格1-2%，以便在面向客户的SLA被破坏之前触发告警。
- 故障模式文档：该供应商劣化时的表现（静默质量下降、硬超时、速率限制错误）、哪些下游功能依赖它，以及备用路径是什么。
- 成本边界：每项任务的预期Token消耗、每日和每月的预算上限，以及当支出骤增时通知谁。
- 弃用注册表：该模型的预计生命周期结束日期、迁移目标，以及切换前所需的测试清单。
最后一项比大多数团队意识到的更重要。供应商的弃用通知通常只提前14天发出。对于一个有十多个服务依赖某个模型的团队来说，14天不足以安全地完成测试、预发布和迁移。拥有弃用注册表的团队清楚哪些服务依赖哪些模型版本，在通知到来的第一天就能启动迁移，而不是在恐慌袭来时才匆忙应对。
网关层
路由和备用层是运维规范转化为具体代码的地方。生产环境中涌现出的模式是LLM API网关——一个位于应用代码与供应商API之间的代理，负责处理路由、重试、备用、速率限制和可观测性。
有几款工具实现了这一模式：LiteLLM提供自托管代理，在100多个供应商上提供统一的OpenAI兼容接口、可配置的备用链和Token预算控制。OpenRouter提供跨300多个模型的托管式API密钥级接口，支持自动透明备用。Helicone增加了健康感知熔断器。这些工具在托管模式、治理要求和路由复杂度上各有差异，但共享一个共同的架构前提：应用程序不直接与供应商通信，而是与网关通信，由网关处理集群级别的关切。
有一个值得关注的运维风险：该领域的供应商整合进展迅速。Portkey是一个在2024和2025年被众多团队采用的热门路由平台，后来被Palo Alto Networks收购并重新定位为安全网关——一个侧重点完全不同的产品。那些将集群管理策略建立在这一特定独立供应商之上的团队，不得不在短时间内重新规划。应对之策是将网关层视为你自己拥有的基础设施，而非你消费的SaaS依赖。无论你运行LiteLLM还是自建轻量级路由层，备用链和SLO执行的业务逻辑都应存在于你的代码库中，而非供应商的托管服务中。
在没有供应商SLA的情况下追踪SLO
对LLM集群应用SRE实践时最常见的反对意见是："当供应商不发布SLA时，我们怎么设置SLO？"答案是：SLO是内部目标，而非合同承诺。你衡量的是你的用户所体验到的系统可靠性，而不是对供应商的合同约束。
多供应商设置中实用的SLO构建始于度量：对每次供应商调用的延迟、Token消耗、错误码和模型版本进行埋点。将这些数据汇总到按供应商划分的监控面板中，涵盖可用性（成功请求占比）、延迟（p95和p99）以及质量（来自合成监控的评估通过率）。基于90天历史基线设置SLO，然后逐步收紧。
在生产环境中行之有效的三层SLO结构：考虑备用行为的集群SLO（"95%的请求在2秒内完成，无论是在主供应商还是备用供应商上"）、触发路由决策的按供应商SLO（"如果供应商A在5分钟内错误率超过2%，则路由至供应商B"），以及执行预算纪律的成本SLO（"任务成本不超过预期Token预算的3倍"）。第三层相对于传统SRE实践是新颖的，但正是它能预防失控成本事故——有一个有据可查的案例，在11天内每周支出从127美元飙升至47,000美元，却无人察觉。
运维节奏
成熟的推理集群管理需要一套大多数团队尚不具备的定期运维节奏。
每周：审查各供应商的错误率和延迟趋势。检查供应商变更日志中的模型版本变动。扫描成本监控面板，排查Token消耗异常。
每月：对所有生产端点运行评估基准测试，以检测质量漂移。审查弃用注册表中即将到达生命周期终止日期的条目。审计新添加供应商的值班所有权，确认没有遗漏明确分配。
模型更新时：任何静默更新模型版本的供应商（某些供应商不会公告就进行更新）都应触发合成评估运行。固定使用明确的模型版本标识符，而非"latest"或"turbo"之类的语义别名——别名会在你毫无察觉的情况下悄然更改。
供应商事故后：在任何供应商服务降级事件后，运行事后分析，不仅要问"什么出了问题"，还要问"我们多久才发现，什么措施能让我们更快发现"。将这些积累进你的监控策略中。
这套节奏并不特别繁重。监控的搭建是半天的工作，服务目录是一份持续维护的文档，而非一个项目。所需的规范，与使传统基础设施保持可靠性的规范别无二致：所有权、可观测性，以及将依赖项视为"终将故障"而非"可能故障"的习惯。
未来走向
推理集群的问题不会消失。模型扩散仍在继续。多智能体架构正在推高Token消耗，使容量规划愈加困难。供应商竞争意味着能力的迭代速度超过了大多数团队的跟踪能力。
驾驭这一局面的团队，并非那些选择了最佳供应商或最聪明路由算法的团队，而是那些及早应用运维规范的团队：在集群变得难以管理之前建立服务目录，在第一次漏检事故之前定义SLO，在第一份14天通知到来之前准备好弃用注册表。多供应商AI基础设施的技术复杂性，在很大程度上已被现有工具解决。运维复杂性则需要与使分布式系统可靠的习惯如出一辙：记录所有权、明确故障模式，以及建立能真实反映用户体验的监控。
推理集群是基础设施，请将它当作基础设施对待——在一场事故逼着你这样做之前。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
