AI 网关选型：Envoy(Go WASM )还是 BFE(Native Go)？
引言
随着大模型推理的加速发展和落地，AI 网关正在从“简单的 L7 代理”演变为承载调度、治理与可观测能力的数据面核心组件[1]。在这一过程中，系统面临的关键挑战不再只是吞吐量，而是长连接、流式返回与复杂策略链叠加带来的长尾延迟与可调试性问题。
当网关需要在请求路径上执行多级策略、语义处理与状态感知调度时，数据面的执行模型本身就成为性能与稳定性的决定性因素。换句话说，AI 网关的上限，不仅取决于调度算法或缓存策略，更取决于其扩展逻辑是运行在虚拟机边界之内，还是原生运行时之中。
本文考察了两条可能的技术路径，分别以 Envoy[2] 的 Go WASM 扩展模型和 BFE[3] 的 Native Go 扩展模型为代表。两者在隔离性、扩展效率与工程可控性上各有优势，但在 AI 流式推理场景下，其执行路径差异会被持续放大。
本文将从运行时模型出发，分析 Go WASM 与 Native Go 在 AI 网关数据面中的实际工程影响，并探讨在复杂策略与长连接负载下，不同执行路径所带来的性能与运维差异。
1. AI 网关对数据面的真实要求
AI 推理流量与传统 HTTP 流量有本质不同：
- 单请求生命周期从毫秒级变为秒级甚至分钟级
- 以 Streaming 为主，而非短连接
- 并发数高，但 QPS 未必高
- 请求过程中需要持续占用内存与连接资源
因此，AI 网关数据面的关键指标不再只是 QPS，而是：
- 长连接并发承载能力
- 资源占用的可预测性
- 长尾延迟稳定性
- 异常隔离能力
在这样的目标下，运行时模型就成为决定性因素。
2. 基于 Envoy 的 AI 网关：Go WASM 扩展模型的工程影响
背景
在 AI 网关场景中，虽然 Envoy 原生支持基于 C++ 的扩展开发，但实际工程落地时，绝大多数团队并不会选择 C++ 来实现复杂的网关逻辑，而是转向 Go WASM[4][5][6]。其原因主要包括：
首先，C++ 扩展的开发门槛和维护成本较高，涉及内存管理、线程安全、生命周期控制等底层细节，对团队工程能力要求极高，不符合 AI 网关“快速迭代策略”的需求。
其次，C++ 扩展需要与 Envoy 主进程同地址空间运行，一旦出现内存越界或未定义行为，可能直接影响整个数据面的稳定性，这与企业在 AI 场景中对隔离性和安全性的要求存在冲突。
相比之下，Go WASM 通过 VM 提供了更强的隔离性，同时 Go 语言在企业内部的普及度更高，更易于承载策略开发与快速迭代，因此成为基于 Envoy 构建 AI 网关时的主流扩展方式。这也是为什么在实际项目中，我们讨论 Envoy 的扩展模型时，往往等同于在讨论 Go WASM 扩展模型。
工程影响
从运行时角度看，Envoy+Go WASM的方案引入了一个关键特征：
AI 网关的核心逻辑运行在WASM VM中的Go 运行时中，而非原生进程中
这带来几个工程层面的影响：
（1）GC 行为放大长尾延迟
在 WASM 运行环境中，Go 运行时的并发调度能力受限，使 GC 停顿对请求路径的影响更容易放大。
在 AI 流式请求长时间驻留的情况下：
- 在长生命周期流式请求叠加高分配速率的情况下，GC 更容易触发
- Worker 上的请求处理可能出现可见停顿
- 同一 Worker 上的多个流式请求可能同时受到影响
这会直接放大长尾延迟。
（2）扩展模块数据拷贝与序列化开销
在 WASM 机制下：
- 每个扩展模块都有独立线性内存
- Host（Envoy）与 Guest（WASM）之间必须进行数据拷贝
- 需要序列化 / 反序列化传递上下文
这意味着：
每增加一个 WASM 扩展模块，就增加一次数据拷贝与一次序列化成本
而 AI 网关的能力正在持续增加：
- Token 级限流
- 内容审计
- 模型路由
- 推理负载感知调度
- …
这些能力往往拆分为多个模块实现，导致：
- 数据在模块之间反复拷贝
- CPU 与内存开销叠加
- 在多模块链式执行场景下，吞吐能力可能下降
- 长尾延迟抖动加剧
随着功能增长，开销随模块数量近线性叠加，最终可能成为系统瓶颈。
（3）故障影响范围扩大
在常见的 Worker 级 WASM 实例复用模型下，一个 WASM 实例通常服务多个请求。当出现：
- 内存泄漏
- 死循环
- panic 无法 recover
时，可能影响同一 Worker 上的所有流式连接。
在长连接驻留模型下，这种影响范围会被放大。
（4）调试复杂度提升
在 Go WASM 机制下：
- 调用栈经过 ABI 转换
- 无法获得完整的 Native Go stack trace
- 无法使用标准 pprof / runtime 工具进行深度诊断
这意味着：
- 不能通过 panic 栈直接定位问题代码行
- 需要跨 Envoy、WASM VM 与 Go Runtime 三层排查
对于生产环境中的长尾问题，这会显著增加定位难度与恢复时间。
小结
从工程视角来看，上述性能、长尾延迟与可调试性问题并不是孤立现象，其本质在于：
Go WASM 并不适合承载复杂业务逻辑。
这个问题并非通过优化单个插件即可解决，而是由执行模型本身决定的结构性限制。
3. 基于 BFE 的 AI 网关：Native Go 模型的工程特征
在 BFE 上实现 AI 网关能力，核心逻辑以内建 Go 模块运行，数据面逻辑与网络栈共享同一运行时与内存模型。
这带来几个关键工程特征：
（1）支持并行 GC，GC 延迟更小
在 Native Go 运行时中：
- 采用并行 GC
- STW 时间更短
- 对正在处理的长连接影响更小
在高并发流式场景下，有助于控制长尾延迟抖动。
（2）内存处理开销更低
对于数据请求：
- 直接进入业务逻辑处理
- 无需跨运行时边界传递
- 不存在 Host / Guest 数据拷贝
- 无序列化与反序列化开销
对于 Token 级高频路径，这意味着：
- 更低 CPU 消耗
- 更低内存占用
- 更稳定吞吐
（3）故障影响范围更可控
BFE 的模块化实现通常：
- 每个请求在独立的 goroutine 与上下文中运行
- 可通过 Go 的 recover 机制兜底
- 避免单点异常扩散至同一 Worker 的多个流
这对于长连接模型尤为关键。
（4）调试更简单
问题定位时：
- 只需关注单一 Go 进程
- 可以获得完整 panic 栈
- 可以使用标准 pprof、trace、runtime 工具
这使得长尾问题的定位效率显著高于Go WASM。
结语：运行时模型决定 AI 网关的数据面上限
在 AI 推理成为核心生产流量之后，数据面的技术选型不再只是性能或功能问题，而是运行时模型问题。两种方案的差异，本质上是“虚拟机扩展模型”与“原生运行时模型”的差异。
表1 两种方案的对比
维度 | Envoy: Go WASM | BFE: Native Go |
执行模型 | VM 内沙盒运行 | 进程内原生运行 |
数据路径 | Host/Guest 拷贝 | 直接内存访问 |
GC 影响 | 停顿更易放大 | 并行 GC，影响更小 |
调试难度 | 跨三层，无法充分利用Go语言能力 | 单进程，可充分利用Go语言能力 |
长尾延迟 | 抖动更大 | 更可控 |
基于 Envoy 的 AI 网关方案，通过 Go WASM 获得了极强的扩展能力，但也引入了：
- VM 运行时开销
- 扩展模块的数据拷贝与序列化成本
- GC 停顿放大效应
- 无法使用 Native Go 的异常定位能力
而基于 BFE 的 AI 网关方案，以 Native Go 实现核心逻辑，使得：
- 资源模型更可预测
- 流式稳定性更高
- 长尾延迟更可控
- 运维与调试路径更简单
对于企业级推理场景，这些差异将直接影响用户体验与服务质量。
AI 网关的复杂度是单调递增的，而Go WASM的成本是按模块叠加的。
在长连接流式推理场景下，Native Go 的技术路线更具工程可控性。
参考资料
[1] 大模型推理场景下的 AI 网关：定位、职责与架构演进，https://mp.weixin.qq.com/s/gtYAPqHqvSWoNHJzCryGPw，2026年1月
[2] Envoy，https://github.com/envoyproxy/envoy
[3] BFE, https://github.com/bfenetworks/bfe
[4] Envoy AI Gateway, https://github.com/envoyproxy/ai-gateway
[5] kgateway, https://github.com/kgateway-dev/kgateway
[6] Higress，https://github.com/alibaba/higress
作者简介
章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。
