跳到主要内容

推理集群:将SRE规范应用于多供应商LLM依赖管理

· 阅读需 13 分钟
Tian Pan
Software Engineer

有一种故障模式,在一切为时已晚之前,任何监控面板都看不到它:你的生产系统正在悄然劣化——某个次要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供应商或端点,目录应包含以下内容:

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates