原文作者：Micheál Kingston - F5 NGINX 解决方案架构师
原文链接：NGINX Gateway Fabric 支持 Gateway API Inference Extension
转载来源：NGINX 中文社区

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

大规模运行推理任务引入了常规路由无法解决的复杂性。大型语言模型（LLM）和其他生成式 AI 工作负载与标准 Web 服务有着根本性的区别。使用 NGINX Gateway Fabric (NGF) 2.2 版本，您现在可以利用 Gateway API Inference Extension在 Kubernetes 中启用智能、具备推理感知能力的路由。平台和机器学习（ML）团队可以发布自托管的 GenAI 和 LLM 服务及推理工作负载，通过更加智能的路由决策和对 GPU 与计算资源使用的精细控制。

Gateway API Inference Extension 是一个由社区推动的 Kubernetes 项目，用于标准化整个生态系统中推理工作负载的路由逻辑。NGF 2.2 集成了这一扩展，使 NGINX 能够基于 AI 工作负载和模型特性而非通用的流量启发式规则来做出路由决策。

挑战：传统网关不足以应对 LLM

NGINX 已经在微服务流量管理方面表现出色。但是推理工作负载带来了新的需求：

• 单个请求可能会独占昂贵的 GPU 资源

• 推理请求可能需要秒级（或更长）的时间，而非毫秒级

• 请求载荷在大小和资源消耗强度上变化很大

• 模型服务行为是有状态的且动态变化：队列长度变化、KV 缓存使用波动，以及不同适配器（例如 LoRA）可能被加载或未加载

在这种环境中，路由决策变得至关重要。将请求发送到已饱和的节点可能会阻塞整个 GPU、降低吞吐量并引入延迟。像轮询（round robin）或最短时间（least_time）这样的流行 NGINX 负载均衡算法无法感知模型状态，因此无法针对推理进行优化。相反，需要的是为 AI 工作负载设计的路由，能够响应运行时信号并做出智能决策。

Gateway API Inference Extension 的工作原理

该扩展并没有创造一种全新的路由范式，而是在现有的 Gateway API 模型（Gateway、HTTPRoute、backendRefs）基础上增加推理感知功能。

核心资源：InferencePool

核心 CRD 是 InferencePool。它代表一组模型服务器 Pod（即推理后端）。它还包含指示要调用哪个 Endpoint Picker (EPP) 实现以做出调度决策的配置。

当 HTTPRoute 的 backendRef 指向 InferencePool 时，网关知道要启用推理路由逻辑（而非普通的服务路由）。

Endpoint Picker（EPP）

Endpoint Picker是Gateway API Inference Extension架构中的核心组件。它充当智能调度器的角色。当请求到达时，网关将关于候选 pods 的元数据（例如队列长度、KV cache 使用情况、adapter 存在情况）发送给 EPP，EPP 随后选择"最佳"pod 来处理该请求。

由于 EPP 是社区扩展的一部分，各种网关实现（包括 NGINX）都可以采用它，而无需发明新的逻辑。

在上面的实例中，清单展示了 NGINX Gateway Fabric 如何使用 Gateway API Inference Extension 路由推理流量。HTTPRoute 将所有传入请求通过 inference-gateway 发送到名为 vitllama3-8b-instruct 的 InferencePool。该池代表模型服务 pods。与简单的负载均衡算法不同，NGF 查询该池中指定的 Endpoint Picker (vitllama3-8b-instruct-epp) 以基于实时指标选择最优的 Pod。简而言之，这确保每个请求都被定向到性能和资源效率最优的模型副本。

NGINX Gateway Fabric 如何实现推理路由

当请求到达 NGF 时，它像往常一样通过 HTTPRoute 进行匹配。但如果 HTTPRoute 的 backendRef 指向 InferencePool，则 NGF 会以不同方式处理路由：

1. NGF 将请求的元数据和候选后端传递给 EPP（通过 ext_proc / 外部处理机制）；

2. EPP 基于运行时指标从 InferencePool 中选择一个 endpoint（Pod）；

3. NGF 将流量路由到所选的 Pod；

4. 这样，NGF 成为推理网关，实现模型感知路由、发布控制、优先级逻辑和增强的可观测性。

由于 NGF 不捆绑专有的 EPP，它集成了标准推理扩展的调度逻辑。这避免了重复发明，并遵循社区设计。

NGF 对推理扩展的支持通过配置进行切换（例如在 Helm 中启用 Gateway API 推理扩展），以及 InferencePool 的 CRDs 和 EPP 的连接。

一个网关，多个工作负载

通过推理支持，NGINX Gateway Fabric 充当 APIs、微服务和 AI 模型的统一网关。AI 功能不再孤立；LLMs 与传统工作负载在同一控制平面下共存。

用户可以公开 GenAI 端点、管理流量模式（例如安全部署、模型优先级），并在其常规流量可观测栈中监控推理指标。

为什么这很重要

Gateway API Inference Extension 为 AI 路由引入了社区标准。NGF 2.2 通过集成该标准而非重新创建来与之对齐。

平台团队可以保持在 Kubernetes 内部并避免碎片化的工具链，而 ML 团队则受益于针对延迟、GPU 效率和自适应调度优化的路由。最终，AI 工作负载可以以团队对其 Web 服务所期望的运维成熟度运行。

想开始使用 Gateway API Inference extension 吗？ 立即下载 NGINX Gateway Fabric 并开始使用吧！

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号 | B 站