从架构决策看 Envoy AI Gateway 的产品定位

它所有"重"设计——强依赖 K8s、构建在 Envoy Gateway 之上、CRD 声明式配置——不是技术包袱，而是定位声明。理解了这一点，才知道你该不该选它。

同类型对比

LiteLLM 五分钟能跑起来，One-API 一条 docker 命令搞定。而 Envoy AI Gateway 的生产部署要求你：先有 Kubernetes 集群，先装 Envoy Gateway，再学一套 CRD。

如果只看"落地成本"这一项，它已经输得彻底。

但这个项目背后站着 Envoy 社区、Tetrate、Bloomberg——一个 CNCF 生态的项目，不可能意识不到五分钟上手体验的价值。它选择如此，只有一种解释：特意设计。它筛选的不是技术能力，而是组织形态。

它从哪来：一个甲方需求，不是创业项目

先看出身，因为出身决定基因。

Envoy AI Gateway 的需求方是 Bloomberg。他们的平台团队要向内部应用暴露多个 LLM——有自托管的，有外部 API——需要统一入口、统一鉴权、Token 级限流和成本追踪。据 The Stack 对 Bloomberg 团队的报道，他们评估市场后的结论很直接：商业 AI 网关太贵，号称开源的方案把好功能锁在企业版里，而 LLM API 本身已经够贵了，不想再交一层专有工具税。

于是 Bloomberg 的工程师向 Envoy 社区提议：扩展 Envoy Gateway 来处理 LLM 流量。Tetrate 作为 Envoy Gateway 的主要维护者响应了这个提议。Tetrate 的博客里有一句话概括了整个技术路线：

"Instead of reinventing the wheel, we extended the tools many teams already use."

这就意味着：它不是"为 AI 应用开发者做一个好用的代理"，而是"为已经在用 Envoy 的平台团队补齐 AI 流量能力"。2025 年 2 月首发，2026 年 6 月 v1.0 GA，生产验证来自 Bloomberg、Tetrate、Nutanix。

这个基因写进了仓库的每一份设计文档。

三份文档，三次表态

从文档说明上，我们能找到相关的线索。

GOALS.md 直接点名了服务对象：

"Envoy AI Gateway enables Platform Engineers to provide a Gateway solution that enables application developers to focus on leveraging GenAI for feature development."

主语是平台工程师。应用开发者是这句话的宾语——他们是被服务的对象。

001 号创始提案的 Personas 更彻底。API 设计围绕三类角色展开：Inference Platform Admin（管网关基础设施、模型清单、流量策略）、Payment Team（按 user/tenant/model 出账单）、Security Team（管模型访问 ACL）。翻遍提案，应用开发者不在 Persona 列表里。

一个把"计费团队"和"安全团队"写进创始提案的项目，目标用户是谁，大家就能明白了。

GOALS.md 的 Non-Objectives 只写了一条：

"Disruption of Existing Envoy Patterns: This project is an additive layer designed to expand use cases for Envoy Proxy and Envoy Gateway without changing existing deployment or control patterns."

你已有的 Envoy 部署模式、控制模式，一概不动。AI 流量治理是现有流量治理的延伸，不是一个新中间件。

源码

一：直接扩展 Envoy Gateway，且只用官方扩展点

Envoy AI Gateway 的控制面通过 Envoy Gateway 的 Extension Server 机制工作：注册一个 gRPC 服务，在 xDS 配置下发给 Envoy 之前挂钩子修改它（插入 extproc filter、加 cluster）。这是 Envoy Gateway 的官方扩展机制，不是 fork，不是魔改。

数据面控制面ExtensionServergRPChooksxDSext_procgRPCAIGatewayRoute等CRDAIGatewayControllerEnvoyGatewayEnvoyProxyAIGatewayExtProc协议转换·上游鉴权·Token计数OpenAI/Bedrock/自托管模型

这个选择的含义是：它把自己的存在绑在了 Envoy Gateway 的架构演进上，换来的是平台团队已有的 Gateway API 资源、部署模式、运维经验全部直接复用。AI 路由和 HTTP 路由用同一套 Gateway、同一个数据面进程、同一套 xDS。

对比一下：LiteLLM 是一个独立的 Python 代理，你的 Envoy/Nginx 之外再加一跳；Envoy AI Gateway 是让你已有的那一跳长出 AI 能力。前者是加一个组件，后者是给现有组件加一层语义。哪个更好取决于你有没有"现有组件"——这就是组织形态筛选。

二：连本地运行都拒绝分叉架构

它有一个单机模式：aigw run，不需要 K8s，一条命令启动，设好 OPENAI_API_KEY 连配置文件都可以省。看起来是对开发体验的让步。

本来以为这是个简化版实现，但看了 cmd/aigw/run.go 之后发现完全不是：aigw run 把整个 Envoy Gateway 控制面原封不动嵌进了单进程。它直接 import 了 envoy-gateway 的入口包，用 provider: File + infrastructure: Host 的配置把"监听 K8s API Server"换成"监听本地文件目录"。之后的一切照旧：extension server 插 filter，下载并拉起真实的 Envoy 二进制，extproc 通过 unix socket 挂上去。

宁可把整个控制面塞进单进程，也不为低门槛场景维护第二套实现。而且让步是有边界的：aigw run 的命令帮助原文就写着 "Run the AI Gateway locally"，官方文档的生产路径只指向 K8s。单机模式的安全模型也印证了这一点：文件模式下 API key 明文落盘在本地状态目录里——Secret 机制属于 K8s，生产的安全边界从一开始就设计在那边。

三：治理能力是一等公民，且承认自己的架构约束

第一，OTel GenAI 语义规范的指标开箱即用：token 用量直方图（区分 input/output/cached）、请求时延、TTFT（首 Token 延迟）。我用 DeepSeek 的 Anthropic 兼容端点实测，TTFT 0.309s 直接出现在 /metrics 里。更有意思的是标签设计：gen_ai_original_model（你请求的模型）和 gen_ai_response_model（上游实际返回的模型）分开记录——我请求 deepseek-chat，上游实际返回 deepseek-v4-flash，这种"模型映射和转换"在指标层直接可见。

第二，001 提案里有一段罕见的坦诚。Token 级限流的扣减发生在响应完成后（因为精确的 token 数在响应里才有），提案原文直接写明：

"Since the reduction happens after the response is complete, the rate limiting is not enforced for the current but the subsequent requests."

限流窗口内永远存在超额空间——这不是 bug，是架构约束，作者在创始提案里就说清楚了，并为此给 Envoy Gateway 上游提了通用的 cost-based rate limiting 支持。一个项目愿意在第一份设计文档里写明自己"做不到什么"，这种工程文化本身就是选型时的加分项。

它在市场里的位置：按组织形态选，不是按功能表选

综合上述讨论，选型对比就不该是功能打勾表，而是一个问题：你的组织里，谁对 AI 流量负责？

所以：Envoy AI Gateway 赌的是"AI 流量治理最终会归属平台工程团队"——和其他南北向流量同一个团队、同一套数据面、同一套声明式配置。它的所有设计决策都体现出这个理念：绑定 Envoy Gateway 是赌你已有云原生流量层；CRD 是要求操作者习惯 kubectl 和 GitOps；把计费、安全团队写进 Persona 是认定 AI 流量会成为需要正式治理的企业资源。

这个前提不一定对所有团队项目成立。反过来说，如果下面任何一条命中你，它大概率不适合：

• 没有 K8s，或者不想为一个网关引入 K8s——生产模式没有第二条路
• 单应用、单团队，想快速验证——LiteLLM 类工具的五分钟体验是真实价值
• 没有专职平台团队——CRD、xDS、ext_proc 这套认知成本需要有人长期持有
• 你的"入口协议 × 后端协议"组合不在它的转换矩阵里，且没能力自己补

这个系列接下来写什么

架构设计是定位声明，它是为平台工程团队设计的 AI 流量基础设施。我打算多点精力和时间放在这上面，逐模块用源码和实验验证：

• ext_proc 架构：一跳 gRPC 换来什么、损失什么
• 跨 provider 转换：矩阵里哪些语义能对齐，哪些会静默丢失
• Token 限流：为什么超额不可避免，软失败能不能感知
• 成本归因、TTFT 指标的采集位置、多租户隔离的真实强度

参考

• Envoy AI Gateway GOALS.md (https://github.com/envoyproxy/ai-gateway/blob/main/GOALS.md)
• 001 创始设计提案 (https://github.com/envoyproxy/ai-gateway/blob/main/docs/proposals/001-ai-gateway-proposal/proposal.md)
• Announcing Envoy AI Gateway 1.0 (https://aigateway.envoyproxy.io/blog/v1.0-release-announcement/)
• Tetrate: Envoy AI Gateway from Concept to Reality (https://tetrate.io/blog/envoy-ai-gateway-concept-to-reality)
• The Stack: Bloomberg 为什么自建而不是买 (https://www.thestack.technology/buy-an-expensive-ai-gateway-thanks-well-just-build-and-open-source-it-says-bloomberg-2/)
• KubeCon: Scaling LLMs at Bloomberg Using Envoy AI Gateway (https://www.youtube.com/watch?v=qFVJmnvmAQ4)