引言

从 2025 年初开始,大模型领域进入了新一轮加速发展阶段。随着大模型在企业内部系统和生产环境中的落地,大模型推理逐渐演化为一类重要的基础设施能力。在这一背景下,围绕大模型推理访问、资源管理与安全控制的 AI 网关(AI Gateway) 受到了业界的广泛关注(参见参考资料 [1] [3] [5])。

由于 AI 网关仍处于快速演进阶段,不同厂商和社区对其定位与边界的理解并不完全一致。本文尝试基于当前较为主流的工程实践,对大模型推理场景中的工作机制 以及 AI 网关的角色、作用和分类方式 进行系统性说明。

1. 大模型的推理场景

在说明 AI 网关之前,有必要先明确大模型推理场景的基本工作机制。

016fcc15a0b14d1ff625e8b676006563.png

图1 大模型推理场景的工作机制

站在“智能体(Agent)”的视角,一个典型的大模型推理场景可以抽象为以下几类交互关系(见图1):

  • 用户 → 智能体:用户向智能体发起请求
  • 智能体 → 大语言模型:智能体通过 LLM API 调用大语言模型进行推理
  • 智能体 → 传统服务:智能体调用已有业务系统或工具提供的能力
  • 智能体 → 智能体:智能体之间进行协作或能力委托

在接口层面,OpenAI API [6]的接口语义正在逐步成为事实上的接口参考标准(de facto standard),但在底层推理系统和企业内部场景中,仍然存在大量非 OpenAI 协议的实现方式。与此同时,MCP(Model Context Protocol)[7]等协议更多用于工具能力描述和上下文编排,其底层调用仍然依赖 HTTP、gRPC 或内部 RPC 等通信机制。对于智能体之间的协作,也正在出现 A2A(Agent to Agent)[8]等新型协议尝试。

2. 大模型推理场景中的网关

02eacff54a768d396c7541037ccd0bb8.png

图2 大模型推理场景中的网关

在上述推理场景中,随着调用链条变长、资源成本上升以及安全风险增加,单纯依靠传统 API 网关已难以满足需求。围绕大模型推理,业界逐步形成了三类不同侧重点的“网关型能力”[2](参见图2):

  • AI 网关(AI Gateway):用于对 LLM 资源消费进行统一控制
  • 推理网关(Inference Gateway):用于对 LLM 推理资源进行抽象和调度
  • 智能体网关(Agent Gateway):用于控制智能体对工具或其他智能体的调用

需要说明的是,上述分类主要是从功能和职责视角对大模型推理场景中的网关能力进行拆分。在实际工程实现中,这些能力可能由同一个网关系统统一承载,也可能以插件、子模块或独立组件的形式存在,其具体形态取决于系统规模、组织复杂度以及对稳定性和演进性的要求。

本文后续将重点讨论 推理网关 与 AI 网关。智能体网关由于仍处于快速演进阶段,这里不做展开,感兴趣的读者可参考资料 11。

3. 推理网关(Inference Gateway)

推理网关的定位

推理网关并不直接执行模型推理,其核心职责是:

  • 对 LLM 推理资源进行抽象
  • 在多个推理实例之间进行调度
  • 控制推理请求的访问路径与生命周期

可以将推理网关理解为 连接推理客户端与底层推理实例的重要控制节点

推理网关的工作场景

b1499c4e5ef5cd879ceba10c8bceb1f1.png

图3 推理网关的工作场景

如 图3 所示,在一个 Kubernetes 集群中,通常会部署多种不同规格或不同模型的推理资源(例如 Qwen-72B、DeepSeek-32B 等)。每一种模型资源对应一个推理池(Inference Pool),而一个推理池中则包含多个推理实例。

推理网关的核心工作包括:

  • 根据请求中指定的模型名称,将请求路由到对应的推理池
  • 在目标推理池中,为该请求选择一个合适的推理实例

GPU 推理调度的复杂性

与传统基于 CPU 的服务实例相比,基于 GPU 的推理实例在调度层面存在显著差异:

  • GPU 推理实例的并发处理能力有限,更容易出现过载
  • 推理实例通常维护 KV Cache 等状态,不同实例之间的状态差异会直接影响延迟和吞吐
  • 是否命中缓存,对整体性能和资源消耗有决定性影响

因此,在推理实例选择上,简单的轮询或最小连接策略往往难以取得理想效果,需要结合实例负载、缓存状态、排队情况等多维信息进行调度。

目前,业界已经出现多种实现方案(参见 [4] [9] [10])。其中,Gateway API Inference Extension [4]作为 Kubernetes 社区的官方项目,引入了 EPP(EndPoint Picker)[9]作为独立的调度组件(见 图 3)。EPP 负责感知推理实例状态,并向推理网关返回合适的目标实例。

上述对比主要针对典型 Web 服务负载与大模型推理负载的差异进行说明,实际生产环境中仍需结合具体模型特性和业务请求模式进行设计。

4. AI网关(AI Gateway)

AI 网关的核心职责

AI 网关最重要的职责是 对 LLM 资源消费进行统一控制。

24af84dbfb95feb4248f52f2dc137952.png

图4 传统服务网关的工作场景

在传统服务网关场景中(见 图 4),不同业务通常对应各自独立的服务资源,网关的主要任务是完成路由和基础治理。而在大模型推理场景中,由于推理资源成本高昂,不同业务往往需要共享同一组推理资源池(见 图 5)。

8450a097aa4402359c366f16f8b4bb3c.png

图5 AI网关的工作场景

在这种模式下,AI 网关需要承担以下职责:

  • 对不同调用方的并发数、配额和使用总量进行控制
  • 缓解多业务竞争同一推理资源时带来的服务质量波动
  • 为上层业务提供稳定、可预期的访问体验内容

安全与合规控制

对入向提示词和出向模型结果进行内容安全检测,也是 AI 网关的重要能力之一。

在工程实践中,通常会将内容安全检测系统独立部署(参见 图 5),由 AI 网关通过远程调用的方式进行集成。这种模式具有以下优势:

  • 安全策略变更频繁,可降低对核心转发路径稳定性的影响
  • AI 网关可以对异常或不可用的检测节点进行自动摘除
  • 便于同时集成多个厂商或多种检测能力

在实际落地过程中,往往需要结合同步检测、异步审计以及分级处置策略,在安全性与端到端延迟之间取得平衡。

统一入口与多资源池调度

为LLM的调用提供统一入口,是 AI 网关的另一项关键价值。

在单LLM资源池场景下(见图6),AI 网关与推理网关往往可以合并部署,由同一组件同时完成资源消费控制和实例级调度。

74e07ef4b51638c2a86cdb7a8e0925c2.png

图6 AI网关的工作场景(单LLM资源池)

而在多LLM资源池场景下(见图7),AI网关和推理网关会分离部署。对于LLM的消费者来说,只需要发送请求到AI网关,而不需要关心LLM资源池的具体物理位置。AI网关会基于预置的调度比例、LLM资源池的忙闲状态、访问速度、成本等信息,将请求发往合适的LLM资源池

在该场景下,AI 网关实际上承担了跨推理池、跨模型、甚至跨地域和跨云环境的二级调度角色,用于在成本、性能和可用性之间进行全局权衡。

26af1d582e567a64598b9e6bd3454fcf.png

图7 AI网关的工作场景(多LLM资源池)

5. 总结

本文围绕大模型推理场景,对 AI 网关的产生背景、核心作用以及3种AI网关职责(推理网关、AI网关、智能体网关)之间的关系进行了系统性说明。

总体来看,AI 网关并不是一个单一形态的产品,而是一组围绕大模型推理逐步演进的关键能力集合。在成本控制、安全合规、访问质量和系统演进性等方面,AI 网关都将发挥越来越重要的作用。

随着大模型推理基础设施的持续发展,可以预见,AI 网关将在未来几年内成为企业级 AI 系统架构中的关键组成部分。

参考资料

作者简介

章淼,博士,1994年进入清华大学计算机科学与技术系学习,2004年获得博士学位,2004年至2006年在清华大学留校任教,在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年,聚焦云网络基础架构的研发工作,是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升,曾担任百度代码规范委员会主席,2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术:用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO,聚焦研发面向云和大模型场景的现代化流量管理平台。

标签: none

添加新评论