内部 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 脱敏。出口边界是唯一可以强制执行而非推荐脱敏的地方。分发给五十个团队的脱敏库只是一个软性建议。
• 成本归属。网关是可以将令牌计数与发起团队、功能和租户挂钩的地方。请求发出后，归属所需的数据就消失了。
• 合规性强制执行。地区绑定、数据保留、供应商白名单——法务关心的规则必须在一个地方强制执行，否则就不会被执行。

产品属性 —— 应该留在边缘的内容：

• Prompt 内容和版本选择。中心化处理会让网关成为产品瓶颈。团队应该选择自己的 Prompt 版本并发布自己的更改。
• 按功能的路由策略。平台团队不应决定推荐服务是使用 GPT-4o 还是 Claude。平台团队应提供切换的能力。
• 针对工作负载调整的缓存策略。适用于 FAQ 流量的语义缓存会破坏代码审查界面的正确性。
• 采样参数。Temperature、top-p、max tokens 属于拥有该界面评估套件的团队。

试图在网关内部中心化处理 Prompt 的团队最终会得到一个康威定律博物馆：每一次 Prompt 更改都需要平台团队审核，平台团队成为瓶颈，调用团队为了逃避而克隆网关，网关失去了证明其存在价值的审计属性。

一场没人能赢得体面的政治斗争

LLM 网关的所有权是一场伪装成架构问题的地盘争夺战。三个团队都有合理的诉求，而其中一个通常会因为错误的理由胜出。

安全团队想要网关，因为它是敏感数据的出口边界。PII 脱敏、供应商白名单、审计日志——这些控制措施与十年前购买 CASB 的理由如出一辙，只是现在应用于一个新的出口界面。安全团队写出的设计文档很有说服力，而且在必须具备哪些控制措施方面，他们的观点是正确的。

基础设施团队想要网关，因为它是可靠性的保障面。熔断、重试、回退路由、容量余量——这些是基础设施团队已经在为所有其他外部依赖项运行的相同控制措施。基础设施团队写出的文档很专业，而且在网关在负载下的行为方式方面，他们的观点也是正确的。

AI 平台团队想要网关，因为这里是 Prompt 版本控制、模型选择和评测（eval）集成的所在地。如果没有这个团队，网关就会变成一个“笨水管”（dumb proxy），漏掉对产品迭代速度至关重要的那一半问题。

这种争斗往往处理得很糟糕——通常取决于哪个团队先写完设计文档，或者哪个 VP 先发起升级。健康的结果是权责清晰的共同所有：安全团队负责策略合同（policy contract），基础设施团队负责运行时（runtime），AI 平台团队负责路由和 Prompt 集成层。不健康的结果是一个团队独占所有权，另外两个团队心怀不满，并在九个月内出现一个分叉的第二个网关。

工程师绕路而行的失效模式

一个在质量上无法与直连路径竞争的网关注定会失败。这是该项目最常见的失败方式。

这种模式是机械化的：网关增加了 200 毫秒的延迟，因为它对每个请求进行同步 PII 扫描；或者在负载下拒绝了 0.5% 的有效调用，因为速率限制器（rate limiter）的抽象是错误的；或者它不支持产品团队下周想要发布的最新模型。感到沮丧的团队发现他们仍然可以导入供应商的 SDK 并绕过网关。于是他们就这样做了。网关的流量份额开始下降。平台团队的应对方式是编写一份更强硬的策略文档。

但这行不通。自愿采纳永远不会真正完成。从“每个团队都使用 SDK”到“每个团队都使用网关”的迁移路径必须在网络出口层通过策略强制执行——在出口防火墙处屏蔽供应商 API 端点（除非通过网关访问），将供应商 API 密钥轮换为仅限网关的凭据，并将 SDK 安装路径弃用或包装在指向网关的薄封装（thin shim）中。这种强制执行的形式与十年前服务网格（service-mesh）的采纳过程如出一辙：你不能靠请求，你必须让“铺好的路”（paved road）成为唯一的路。

但只有当这条路足够好时，强制执行才有效。一个只增加 50 毫秒开销、在供应商发布后 48 小时内支持每个模型、且具有比直连 SDK 更好可观测性的网关会被采纳，因为抵制它的成本比使用它的成本更高。而一个增加 200 毫秒延迟、模型支持滞后数月、且提供的可观测性还不如 SDK 的网关，无论安全团队写多少份备忘录，都会被工程师绕开。

架构上的觉醒

这种模式之所以独立且反复出现，原因与 2016 年和 2017 年服务网格独立出现的原因相同：一个拥有上千个依赖项的系统的横向关注点（cross-cutting concerns）并不是任何单一应用程序的属性。它们是应用程序共享的网络属性。在每个应用程序中解决这些问题，意味着解决得既差劲又不一致，还要重复七次。

早早意识到这一点的公司会将网关构建为由安全、基础架构和 AI 平台团队共同拥有的平台基础设施，将策略强制执行视为出口防火墙问题而非文档问题，并保持中心化与边缘边界的严明，以确保产品团队保持迭代速度。

意识到得太晚的公司则会花一年时间进行“整合计划”，让七个团队协商现有网关原型中的哪些功能应该保留，与此同时 AI 账单不断增长，而下一次合规审计则会将“对 LLM 出口缺乏集中控制”列为一个发现项。

选择不在于是否构建网关。而是在于是在审计之前有目的地构建一次，还是在审计之后意外地“发现”它七次。