AI 网关选型：Envoy 还是 BFE？

引言

随着大模型推理的加速发展和落地，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，聚焦研发面向云和大模型场景的现代化流量管理平台。