内部 LLM 网关是新一代 Service Mesh

走进任何一家有五十名工程师在生产环境编写 LLM 代码的公司，你都会发现七个网关形态的产物。推荐团队造了一个用于在 OpenAI 和 Anthropic 之间路由。支持机器人团队写了一个用来挂载他们的 Prompt 注册表。平台团队有一个半成品代理，处理鉴权但不处理限流。增长团队有一个 Lambda，在数据发出时进行 PII 脱敏。数据科学团队直接调用供应商 SDK，而且没人告诉他们停止这样做。没有共享网关。只有七个共同的问题，每个都被孤立且拙劣地解决了，而首席财务官 (CFO) 正准备询问为什么 AI 账单环比增长了 40%，却没有任何明确的负责人。

这与行业在 2016 年和 2017 年遇到微服务时的架构节奏完全相同。成千上万的外部依赖，每个团队都有相同的共同关注点——鉴权、重试、可观测性、策略——以及在“解决一次”或“随处重新发明”之间做出选择。当时的答案是服务网格 (Service Mesh)。现在的答案是内部 LLM 网关，而大多数公司仍处于“随处重新发明”的阶段。

每个团队都在独立构建什么

清单在不同公司之间惊人地一致。一旦 LLM 的使用跨越了演示阶段，每个团队都会重新发现同一组横切关注点：

• 供应商 API 鉴权 —— 谁的密钥，谁的预算，谁的审计踪迹。最初作为黑客松便利手段的共享 OPENAI_API_KEY 环境变量，现在将七个业务部门的费用计入同一个账目。
• 跨供应商和模型的路由 —— 按功能、按租户、按成本层级，并在停机期间进行降级。供应商 SDK 在这方面毫无帮助；路由逻辑最终被复制粘贴到应用代码中。
• 限流 —— 按用户、按功能、按租户。供应商配额对 API 密钥是全局的，并不匹配你业务关心的任何单位。
• Prompt 注册表 —— 系统 Prompt 的规范版本存储在哪里，谁可以更改它，如何回滚。在没有注册表的情况下，Prompt 存在于源代码、功能标志 (feature flag) 和 Notion 页面中，且彼此冲突。
• 结构化输出归一化 —— JSON 模式在不同供应商那里意味着不同的东西。在运行手册中看起来可以直接替代的降级路径在主要停机期间激活，导致 12% 的下游解析器开始报错。
• 请求和响应日志 —— 用于取证、评估以及六周后不可避免的事件回顾。
• 出口边界的 PII 脱敏 —— 客户数据进入第三方模型的界面。合规部门将其视为控制点。没有网关，它就是一个不存在的控制面。
• 成本归属 —— 追溯到发起调用的团队或功能。没有它，你只有一份账单，却不知道该找谁。

每个团队在遇到这个清单时，都会独立地将这些功能的一个半成品子集构建到他们自己的服务中。结果就是“七个产物”问题：公司已经为网关模式支付了七次成本，却从未真正拥有过它，并且没有共享任何工作成果。

正在出现的模式

始终胜出的形态是：一个位于每个外部供应商调用之前的专用 LLM 网关，由平台团队拥有，并具有稳定的内部 API，下游服务调用它而不是供应商 SDK。现代企业级网关现在将语义路由、令牌感知限流、虚拟密钥管理、语义缓存、熔断器和按团队的可观测性捆绑到同一个控制平面中。网关是出口点、策略点、计量点，而且越来越多地成为评估和护栏 (guardrail) 的集成点。

借用网络领域的词汇并非偶然。该网关扮演了 Envoy 在 2017 年扮演的角色：一个可重用的基础设施，吸收了没人想写两次的横切关注点，向上游暴露稳定的合同，并让应用团队停止关注网络。将“模型供应商”替换为“服务”，架构压力完全吻合。

实现选择也已经稳定。大多数生产环境的网关是带有 OpenAI 兼容 API 表面的 HTTP 代理，具有基于 YAML 或数据库的路由配置，一个将规范请求转换为供应商特定调用的适配层，以及一个写入独立于标准可观测性管道的取证存储的日志抽头。优秀的网关每次请求仅增加个位数的微秒延迟。糟糕的网关会使尾部延迟翻倍，并成为工程师绕过它们的原因。

中心化 vs 边缘的决策矩阵

最难的架构问题不是是否构建网关，而是什么属于网关，什么属于调用服务。如果搞错了这个边界，要么会产生一个扼杀实验的瓶颈，要么会产生一个违背网关初衷的蔓延。

在负载下站得住脚的划分大致如下：任何属于治理属性的内容必须中心化，而任何属于产品属性的内容应保持在边缘可配置。

治理属性 —— 必须存在于网关中的内容：

• 鉴权和凭证管理。应用服务不应持有供应商 API 密钥。网关使用内部凭证对调用者进行身份验证，然后在出口时附加供应商密钥。
• 审计日志。每次外部调用都在同一个取证存储中留下记录，具有相同的保留政策和访问控制。分布式的审计等于没有审计。
• PII 脱敏。出口边界是唯一可以强制执行而非推荐脱敏的地方。分发给五十个团队的脱敏库只是一个软性建议。

加载中…