再看 AI 网关:助力 AI 应用创新的关键基础设施

作者:子丑

AI 网关作为云产品推出已有半年的时间,这半年的时间里,AI 网关从内核到外在都进行了大量的进化,本文将从 AI 网关的诞生、AI 网关的产品能力、AI 网关的开放生态,以及新推出的 Serverless 版,对其进行一个全面的介绍,期望对正在进行 AI 应用落地的朋友,在 AI 基础设施选型方面提供一些参考。

AI 网关是技术架构演进的产物

每一代应用架构的演进,都会产生新的网关诉求,从一开始的单体架构的流量网关(如 nginx),到微服务架构出现的微服务网关(如 Spring Cloud Gateway),再到云原生架构出现的云原生网关,网关都是企业应用基础设施中的重要一环,提供快速接入、统一管理、统一治理等关键能力。

当 AI 应用出现后,伴随着 AI 原生架构的发展,AI 网关也顺势而生了。

相对于传统应用,AI 应用具有明显的架构特征,简单来说即以模型为中心,通过模型的推理能力,给定提示词,借助工具和记忆,来满足特定的业务诉求。

如何支撑 AI 应用更快捷、更稳定、更安全地访问模型、访问工具、访问其它 Agent,成为 AI 网关的核心诉求。

在推出商业版的 AI 网关之前,Higress 在阿里云内部进行了大量的探索,当前已成为阿里云 AI 流量的核心承载网关,包括通义 APP、阿里云百炼、PAI 等服务,背后都有 Higress 的身影。

受限于当时 AI 应用的发展水平,最初的商业版 AI 网关只提供了模型代理的能力,但在过去半年中,AI 应用快速发展,MCP、A2A 等协议也逐渐成为主流,AI 网关也从模型代理发展到包含模型、MCP、Agent 三大 API 形态,集成各种治理能力的 AI 应用的统一入口。同时在 AI 网关之上以开源形式独立发展出了 HiMarket AI 开放平台。

AI 网关的核心产品能力

接下来我们从模型、工具、Agent 三种访问场景以及安全这个横向维度,了解下 AI 网关所解决的具体问题和核心产品能力。

2.1 模型访问场景

2.1.1 访问模型服务的挑战:三多两高

随着企业 AI 应用的落地深入,AI 应用对大模型的诉求呈现出多模型、多模态、多场景的"三多"特点。

  1. 多模型: 不同供应商的模型 API 接口标准不同,访问方式不同,模型 API 的调用方无法平滑地在不同供应商之间切换,无法同时使用不同供应商提供的模型。
  2. 多模态: 不同于文生文大模型 openAI 兼容标准的一统天下,多模态模型呈现百花齐放的特征,传输协议有 SSE、Websocket、WebRTC,请求响应方式有同步有异步,请求和响应结构更是发散,给基础设施团队带来很大的管理压力。
  3. 多场景: 不同业务场景在落地 AI 时诉求不同,有的要求低 RT(如实时语音转换),有的要求高稳定性(如长论文的理解),不同的场景在限流等手段的选择上差异很大。

除此以外,企业访问模型服务还有安全要求高、稳定性要求高的"两高"特征。

  1. 安全要求高: 企业在调用模型服务接口时,其内部数据存在泄露风险,同时,调用模型服务,尤其是开源或外部模型服务时,数据的合规也是不可忽视的问题。
  2. 稳定性要求高: 模型服务受到硬件限制,其接口限流阈值较低,且自身稳定性也低于一般 API 服务,接口的 RT 和成功率均不够稳定,进而会影响到 AI 应用的整体可用性。

2.1.2 AI 网关在模型访问场景的解决方案

"三多两高"的问题,借助 AI 网关,可以这么解决:

  • 多模型:AI 网关上可以配置多种模型路由策略,比如按照模型名称路由、按照比例路由,以及按照某些请求特征(如特定 header)路由等,同时支持将不同的模型供应商协议统一为 openAI 兼容,AI 应用只需要按照 openAI 兼容方式,即可在多种模型之间无缝切换。
  • 多模态:AI 网关支持代理 HTTP 和 Websocket 两种传输协议的多模态模型调用,AI 应用可以像使用文生文模型一样,按照统一的接入点接入多模态模型,同时,网关管理员可以通过插件等能力增强多模态模型的安全和稳定性。
  • 多场景:AI 网关推荐按照不同的模型场景(文生文、文生图、语音识别等)创建独立的 Model API,并为每个调用方分配独立的消费者身份,按照消费者进行观测、限流、安全防护和计量计费。
  • 安全要求高:AI 网关对调用方支持消费者鉴权,避免 API-KEY 的直接对外,对模型服务支持后端服务鉴权和 API-KEY 管理,在网关侧统一管理服务鉴权,同时,无论是鉴权的密钥还是 API-KEY,都可以托管到 KMS 中统一管理,避免数据在网关侧落盘的安全风险。另一方面,AI 网关深度集成 AI 安全护栏,可对各类安全风险和合规问题进行拦截阻断,同时,配合数据脱敏插件,可在数据发送到模型前移除敏感信息,保证内容安全。
  • 稳定性要求高:AI 网关在稳定性方面的增强体现在可见、可控两个层面。首先是全链路稳定性的观测,AI 网关会记录每次请求的供应商、模型、消费者,以及请求的各种指标如首包时长、token 数等,请求被限流、拦截、fallback 等也会标识出来,通过内置的大盘可视化展示;其次是模型访问的可控,主要包括负载均衡、fallback、限流、缓存等能力,我们推荐基于消费者配置治理能力,如消费者维度的 token 和并发度限流。

网关管理员可以持续关注观测大盘,根据调用情况,及时做出针对性的调整。

2.2 工具访问场景

2.2.1 访问工具的挑战:精准、安全

AI 应用访问工具的主要挑战是如何用最少的代价,调用最合适的工具,并且保证调用过程的安全。

随着工具数量的增加,将所有工具交给大模型推理,一方面造成 token 消耗地大幅增加,增加了推理成本,甚至可能超过大模型的上下文长度限制;另一方面由于工具过多,模型更可能选择到错误的工具,从而影响执行结果。

另外,工具调用直接影响业务,使用不当将极大扩展安全的风险边界,像 MCP 恶意投毒这样的新型攻击方式,对安全防护提出了新的挑战。

2.2.2 AI 网关在工具访问场景的解决方案

针对工具的精准和安全,AI 网关通过如下方式解决:

  • 精准:AI 网关同时支持存量 HTTP 服务和托管的 MCP Server,对于存量 HTTP 服务,用户可以在网关上即时调整工具描述,同时,AI 网关支持工具的动态组装,可以通过创建虚拟 MCP Server,按需组装工具列表,满足特定业务场景诉求,这样 provider 和 consumer 可以分别定义自己的 MCP Server。另一方面,AI 网关提供了工具智能路由的能力,可以在网关侧智能筛选工具列表,只返回与问题相关的工具集,从而节省模型推理的 token 和模型选择工具的准确度。
  • 安全:与模型访问类似,AI 网关在工具访问场景同样建设了丰富的安全能力,针对调用方的消费者鉴权,除支持 MCP Server 粒度的鉴权配置外,还可以针对某个工具单独设置鉴权,从而实现为不同风险等级的 Tool 赋予不同调用方权限的目的;针对 MCP 描述、工具描述、工具响应结果中的注入问题,可对接 AI 安全防护,在调用源头进行防护。

2.3 Agent 访问场景

2.3.1 访问 AI Agent 的挑战:稳定、灵活

开发者可通过多种形式构建 AI Agent,包括:

  • 高代码:如基于 Spring AI Alibaba、ADK、langchain 等框架自己编码,这种方式灵活性最高,能力也最丰富,当然对开发者要求也最高
  • 低代码:如基于 Dify 这样的平台进行流程的拖拉拽编排,这种方式搭建起来灵活、快速,能够快速验证与试错,对开发者要求也较低
  • 零代码:如基于 JManus 这样的工具,直接通过提示词完成 AI Agent 的构建

不同的 AI Agent 形态,导致 AI Agent 的接入方式多种多样,缺乏标准,难以像管理云原生应用那样进行统一的治理与管控。

同时 AI Agent 受制于背后的大模型能力,其稳定性很难保证,如果不做好防护,很容易牵一发而动全身,导致依赖该 Agent 的业务产生雪崩。

2.3.2 AI 网关在 Agent 访问场景的解决方案

与访问工具类似,AI 网关可以作为 AI 应用的统一代理:

  • 稳定:AI 网关可以直连包括 ACK、FC、SAE 在内的多种运行平台,通过主动和被动健康检测,及时隔离异常节点,并通过灰度发布,有效降低变更风险,通过多种限流策略避免应用过载,提升 AI 应用的稳定性。
  • 灵活:借助 AI 网关的服务发现,可以将部署在各种计算平台上的 AI 应用在 AI 网关上统一对外透出,并通过网关的 REST to A2A 转换能力,将存量 HTTP 应用自动转换为符合 A2A 协议的 AI 应用。对于运行在 dify 上的低代码 AI 应用,AI 网关可统一代理,并支持二次鉴权。

除此以外,AI 网关深度集成阿里云可观测体系,AI 应用接入 AI 网关后,可一键开启 AI 全链路观测能力,从应用到 MCP 工具到模型,实现全链路追踪与问题定位。

2.4 安全防护维度

2.4.1 AI 应用的安全防护挑战:网络+数据+内容

AI 原生架构下,大模型处于核心位置,很多时候是大模型而不是应用自身来调度工具和使用数据,这就让 AI 应用的安全风险边界比以往扩大了,而攻击方式也更为多样,比如针对大模型的爆破攻击、针对 MCP 的注入攻击等等,都是 AI 原生架构下新的安全风险。在这个背景下,安全防护的范围将从网络和数据,扩展到内容层面。而由于内容的发散性,针对 AI 应用的内容防护也将从以往的规则库和小模型,进化到微调大模型、小模型和规则库混合的方式。

2.4.2 AI 网关的安全防护方案

针对 AI 原生架构的安全挑战,AI 网关从网络安全、数据安全和内容安全三个层面进行了安全防护。

  1. 网络安全:在网络安全层面,AI 网关集成 SSL 证书和 WAF 防护,结合内置的四层/七层 IP 黑白名单能力,可在网络入口有效防护和阻断安全风险。
  2. 数据安全:在数据安全层面,AI 网关首先通过后端服务鉴权和 API-KEY 托管,将 API-KEY 进行二次签发,降低数据泄露的影响范围;其次,无论是 API-KEY 还是其它敏感信息,都可以在 AI 网关上集中托管到 KMS,做到敏感信息在网关侧不落盘。
  3. 内容安全:在内容安全层面,AI 网关与 AI 安全护栏深度集成,可按 API 一键开启,防护包括敏感词风险、合规风险、提示词注毒和爆破风险在内的各类安全问题,并支持按防护维度分别制定拦截策略,提升 AI 应用的安全水位和稳定性。

AI 开放平台帮助企业构建 AI 应用协作机制

3.1 HiMarket 的定位

通过 AI 网关,企业可以快速地进行 AI 应用创新,但是当企业开始大规模落地的时候,新的问题出现了,即 AI 应用的开发者和管理者如何进行高效地协同。相关的问题包括如何管理不同 AI 应用开发者的权限和配额,如何上架 MCP Server 和 Agent,如何让开发者自行注册和申请 MCP 和 Agent 的访问权限,如何进行审批等等。

按照最简的抽象视角,AI 开放平台面向两类角色:开发者和管理者,开发者申请和使用开放平台上的各类 MCP Server 和 Agent,构建自己的 AI 应用,管理者维护开放平台上的各类资产,对 MCP Server 和 Agent 进行上架,对开发者进行认证、审批和设定配额,并管理实际承载 MCP Server 和 Agent 的各个 AI 网关。于是,在用户界面上,AI 开放平台分为主要面向开发者的开发者门户,和主要面向管理者的开放平台后台。开发者门户主要承接开发者的注册和访问,与企业 SSO 对接,实现开发者的认证和鉴权。开放平台后台主要承接管理者的各类诉求,包括门户的管理、资产的管理、网关的管理等。

每个企业都有自己的研发协同机制和账号体系,在这个问题上,云产品很难提供一个标准解。为了解决这个问题,AI 网关团队参照业界最佳实践,开源了 HiMarket AI 开放平台,以帮助企业构建自己的 AI 开发者门户,可访问 github.com/higress-gro...

3.2 Himarket 的整体架构

HiMarket AI 开放平台在架构上分为三层:

  1. AI 开放平台门户:这一层面向开发者,每个 Agent 和 MCP Server 的门户都不尽相同,定制化程度最高。
  2. AI 开放平台后台:这一层面向管理员,管理三大核心对象:门户(portal)、产品(product,包括 MCP Server 和 Agent)、开发者。
  3. AI 网关/Nacos:这一层为基础设施,通常只有管理员可见,并通过 AI 开放平台后台进行统一管理与集成。

已经有部分用户基于 HiMarket 在构建自己的 AI 开放平台,如果您也有类似诉求,欢迎加入 HiMarket 开源社区共建。

AI 网关 Serverless 版,大幅降低开通成本

AI 网关在云栖前上线了 Serverless 版,相比专享实例版,Serverless 版极大地降低了开通和使用成本,在阿里云 Serverless AI 场景的大图上补上了重要的一块。AI 网关结合百炼、FC/FunctionAI 和云市场,用户可构建完整的 Serverless AI 基础设施。。

具体来说,AI 网关 Serverless 版有如下 3 大特点:

  1. 拥有专项实例版的全部核心功能,覆盖模型访问、MCP 访问和 Agent 访问场景。受产品形态限制,Serverless 版不支持内置 WAF 集成和插件能力,如果对这两块能力有强诉求,请使用专享实例版。
  2. 按调用量付费,没有实例费用,对于调用量较低的用户可降低 90% 的使用成本。
  3. 100% 免运维,AI 网关 Serverless 版无需用户手工运维,可自动升级和按水位弹性伸缩。需注意,如果流量在短时间内大量增加,为了保护网关实例,AI 网关 Serverless 版将会拒绝掉处理不了的请求,如果您的请求峰值 QPS 较高且快速增长,请使用专项实例版。

Serverless 版与专享实例版的详细对比,请参考:

help.aliyun.com/zh/api-gate...

Serverless 版的计费方式,请参考:

help.aliyun.com/zh/api-gate...

总结

过去半年,AI 网关完成了从"单一模型代理"到"AI 应用统一入口"的跨越------内核上,以模型、MCP、Agent 三大 API 形态覆盖 AI 原生架构的主要流量;治理上,围绕多模型、多模态、多场景等痛点,在路由、协议转换、限流、缓存、观测、安全护栏等方面形成了一站式闭环;生态上,开源 HiMarket 让任何企业都能快速搭建自己的 AI 开发者门户,实现开发者与管理者的协同;成本上,Serverless 版把开通门槛降到"零实例费 + 按调用付费",让中小团队也能零运维享受企业级 AI 流量治理。至此,AI 网关已不只是"流量网关",而是 AI 时代的新型基础设施:向下屏蔽异构算力与协议差异,向上支撑模型、工具、Agent 的统一编排、治理与安全,为正在落地的各类 AI 应用提供了可插拔、可扩展、可持续演进的坚实底座。

点击此处,关注 Higress AI 网关最新动态。

相关推荐
阿里云云原生5 小时前
零代码改造 + 全链路追踪!Spring AI 最新可观测性详细解读
spring·云原生
霖.245 小时前
Docker常见问题
服务器·docker·云原生·容器
荣光波比6 小时前
K8S(十七)—— Kubernetes集群可视化工具Kuboard部署与实践指南
云原生·容器·kubernetes
二宝1527 小时前
黑马商城day3-微服务01
微服务·云原生·架构
切糕师学AI9 小时前
云原生技术栈解析:宿主机、容器、Docker、Kubernetes 之间的区别于联系
docker·云原生·容器·kubernetes
云雾J视界10 小时前
Linux企业级解决方案架构:字节跳动短视频推荐系统全链路实践
linux·云原生·架构·kubernetes·音视频·glusterfs·elk stack
没有bug.的程序员15 小时前
分布式架构未来趋势:从云原生到智能边缘的演进之路
java·分布式·微服务·云原生·架构·分布式系统
AI云原生15 小时前
云原生系列Bug修复:Docker镜像无法启动的终极解决方案与排查思路
运维·服务器·python·docker·云原生·容器·bug
三坛海会大神55516 小时前
k8s(八)Ingress详解
云原生·容器·kubernetes