用 Envoy 给 AI 流量装上"智能交通系统"：Envoy AI Gateway 深度解析

你有没有遇到过这样的场景？公司同时接入了 OpenAI、Anthropic、Google Gemini 等多个大模型 API，每个模型的接口格式略有不同，鉴权方式各不相同。更头疼的是，当 AI 调用量暴增时，如何统一做限流、路由、认证？一个个去改代码？那不得累死运维团队。

今天介绍一个来自 CNCF 生态的开源项目 —— Envoy AI Gateway，它用 Envoy Proxy 的能力给 AI 流量装上了一套"智能交通系统"。

📚 项目简介

Envoy AI Gateway 是一个基于 Envoy Gateway(https://github.com/envoyproxy/gateway) 构建的开源项目，用于统一管理对各类生成式 AI 服务的访问流量。

简单来说，它让你可以用一套统一的接口（兼容 OpenAI API 格式），对接数十个不同的 AI 模型提供商 —— 不管你是用 OpenAI、Google Gemini、AWS Bedrock、还是国内的天元 Hunyuan，都走同一个入口。

⭐ 核心功能

📊 关键数据

⭐ 1,787+ Stars | 👥 285 Forks | 🐧 Go 语言开发 | 📅 最近更新于 2026年6月25日（非常活跃）| 🏷️ CNCF 项目

🏗️ 架构解析：两级网关模式

Envoy AI Gateway 最核心的设计理念是 两层网关架构，这个设计相当精妙。

应用客户端    │    ▼┌─────────────────────┐│   Tier One Gateway  │  ← 全局入口：认证、路由、限流│   (集中式入口)       │└─────────┬───────────┘          │    ┌─────┴─────┐    ▼           ▼┌────────┐  ┌──────────┐│Tier Two│  │ Tier Two │  ← 细粒度控制：模型访问、端点选择│Gateway │  │ Gateway  │      LLM 推理优化└───┬────┘  └────┬─────┘    ▼            ▼  OpenAI      Anthropic

Tier One Gateway（全局网关）：作为集中式入口，处理所有请求的认证、顶层路由和全局速率限制。相当于大楼的前台 —— 所有人进来都要先登记。

Tier Two Gateway（模型网关）：负责对接具体的 AI 模型服务，提供细粒度的访问控制和端点选择器（endpoint picker），用于 LLM 推理优化。相当于各个部门的具体办事窗口。

这种分层设计的好处是：解耦。你可以独立扩展某一层的容量，而不影响另一层。比如当某个模型调用量激增时，只需扩容对应的 Tier Two 网关即可。

🎯 支持的 AI 提供商

Envoy AI Gateway 是目前对 AI 提供商支持最广泛的网关项目之一，目前已覆盖 17+ 个主流 AI 服务提供商：

这意味着你可以在一个网关后面同时管理来自不同供应商的多个模型，切换模型就像在音乐播放器切歌一样简单 —— 改一行配置就行。

🚀 快速开始

环境准备

项目基于 Kubernetes 运行，需要先部署 Envoy Gateway：

# 1. 安装 Envoy Gateway（使用 Helm）helm repo add envoy-gateway https://envoyproxy.github.io/helm-chart/helm repo updatehelm install eg oci://public.ecr.envoyproxy.com/envoy-gateway-helm/eg \  --namespace envoy-gateway-system --create-namespace# 2. 部署 AI Gateway 基础配置kubectl apply -f https://raw.githubusercontent.com/envoyproxy/ai-gateway/main/examples/basic/basic.yaml# 3. 等待网关就绪kubectl wait pods --timeout=2m \  -l gateway.envoyproxy.io/owning-gateway-name=envoy-ai-gateway-basic \  -n envoy-gateway-system \  --for=condition=Ready

发送第一个请求

部署完成后，通过 Gateway URL 发送一个聊天请求：

curl -H "Content-Type: application/json" \  -d '{    "model": "gpt-4",    "messages": [      {"role": "system", "content": "你是一个助手"},      {"role": "user", "content": "你好"}    ]  }' \  http://$GATEWAY_URL/v1/chat/completions

就是这么简单！你的请求会被网关自动路由到配置好的后端模型。

支持的 API 端点

除了 Chat Completions，还支持：

💡 技术亮点

1. 控制面与数据面分离

Envoy AI Gateway 采用现代云原生架构，将 控制面（Control Plane）和 数据面（Data Plane）完全分离：

这种设计让配置变更无需重启服务，动态生效。

2. Go 语言原生开发

项目使用 Go 编写，性能出色且内存占用低。Go 的并发模型天然适合处理高并发的 API 网关场景。

3. Kubernetes CRD 驱动配置

所有配置通过 Kubernetes Custom Resource Definition（CRD）管理，可以利用 kubectl 等标准工具进行操作：

apiVersion: gateway.envoyproxy.io/v1alpha1kind: ClientTrafficPolicymetadata:  name: client-buffer-limitspec:  targetRefs:    - group: gateway.networking.k8s.io      kind: Gateway      name: envoy-ai-gateway-basic  connection:    bufferLimit: 50Mi       # AI 模型响应通常很大，默认 32KB 不够用    http2:      initialStreamWindowSize: 16Mi      initialConnectionWindowSize: 24Mi

注意这里有个细节：AI 模型的响应体通常远大于普通 HTTP 请求，所以官方示例中将 bufferLimit 从默认的 32KB 提升到了 50MB。这个设计细节体现了对 AI 场景的深入理解。

✅ 优缺点分析

优点

⚠️ 注意事项

🎯 总结

Envoy AI Gateway 解决了 AI 时代的一个核心痛点：当你的应用需要接入多个大模型时，如何优雅地管理这些连接？

它没有重新造轮子，而是站在 Envoy Proxy 这个"网络界的老兵"肩膀上，用云原生的方式给 AI 流量装上了一套智能交通系统。对于正在构建 AI 应用、需要统一管理多个模型 API 的团队来说，这是一个值得关注的开源项目。

如果你也在思考"如何让 AI 调用更可控、更高效"，不妨花十分钟了解一下这个项目。

💬 互动环节：你们公司在接入多个 AI 模型时是怎么管理的？有没有遇到类似的痛点？欢迎在评论区聊聊！

🔗 相关链接：