AI 网关需要具备的10大基本能力

大模型主战场从训练转向推理，已经成为业内共识。越来越多的公司已经开始设计满足企业内部需求和外部商业方向的大模型应用，并在生产环境中进行部署。这个过程中，我们遇到了一系列新的需求。

这些需求与最初的大模型应用在 “概念验证阶段” 有所不同，更多地源于对规模化和安全使用，其中，AI 网关成为被讨论较多的 AI 基础设施关键组件之一。

我们认为 AI 网关并不是独立于 API 网关的新形态，本质也是一种 API 网关，区别在于针对 AI 场景的新需求专门做了扩展，它既是 API 网关的继承，也是 API 网关的演进。因此我们从 API 视角，对 AI 网关的能力做了分类，便于形成概念的共识。

01

API 网关的继承

由于围绕 API 提供的网关能力繁多，涉及的角色众多，我们将所有能力基于使用方进行分类，包括研发、供应和消费三类场景，分别对应 API 接口的研发团队、API 平台的研发和运维团队、API 平台的外部调用方。

API 研发场景

API First 是先定义好 API 规范，再 code。不同于不定义 API，直接 coding，API First 强调的是在构建应用程序之前优先设计和开发 API 接口，将 API 视为系统的核心架构组件，通过定义良好的接口规范实现模块化。例如公共云的云产品都提供了 API 的调用方式，微信小程序、钉钉开放平台也面向开发者提供了 API 接口，类似乐高积木的模块化系统，通过标准接口实现服务间的灵活组合，提升系统的可扩展性和维护性，从而提升生态效率。

API 供应场景

API 供应场景指 API 提供方（如企业、平台或服务）通过标准化接口对外暴露数据或功能的过程。其核心是创建、管理和维护 API，确保其可用性、安全性和高效性。核心能力包括：

• API 安全：保护 API 免受各种安全威胁，确保只有经过授权的用户、应用程序能够访问 API，并保障数据在传输和存储过程中的保密性、完整性和可用性。例如身份验证、授权管理、数据加解密、防攻击机制。
  

• 灰度：是一种在生产环境中逐步引入新 API 版本或功能的策略，允许将一部分用户或请求流量导向新版本的 API，同时将其余部分仍保持在旧版本上，从而在不影响整体系统稳定性和用户体验的前提下，对新 API 进行测试和验证。

• 缓存：指将 API 的响应结果临时存储在缓存服务器中，当有相同的请求再次到来时，直接从缓存中获取响应结果，而无需再次访问后端服务器，从而提高 API 的响应速度和系统的性能。

API 消费场景

API 消费场景指调用方（如应用、开发者）通过集成外部 API 快速实现功能或获取数据的过程。其核心是使用平台方提供的能力或数据，实现业务需求。

• 调用审计：对 API 的调用活动进行全面记录、监控和分析的过程。它会详细记录每一次 API 调用的相关信息，包括调用时间、调用方身份、调用的 API 接口、请求参数、响应结果、响应时间等。
  

• 调用方配额限速：指 API 网关根据预先设定的规则，对每个调用方（如用户、应用程序、IP 地址等）在一定时间内对 API 的调用次数、流量大小或资源使用量进行限制的机制。
  

• 后端保护式限流：对 API 的访问流量进行管理和控制，确保 API 能够稳定、高效地运行，避免因流量过大或异常流量导致的系统崩溃和性能下降，包括负载均衡、限流、降级、熔断等能力。

02

API 网关的演进

在大模型场景下，大模型通过 API 对外提供服务，因此研发场景、供应场景、消费场景都出现了更加丰富的诉求。

大模型 API 研发场景

API First 或者 API 是一等公民不再是一种口号，而是逐步成为实实在在的应用开发规范。Agent 的开发和运行，要调用 API，Agent 通过开放平台形式提供对外服务，也要提供 API。API 网关可以覆盖 API 的设计、开发、测试、发布、售卖、运维监测、安全管控、下线等各个生命周期阶段，企业的诉求将更为强烈。基于 API 网关，还可以提供多个插件能力，提升 Agent 开发效率，例如 AI 提示词模版[1]，API AI Agent[2]，Json 格式化[3]，用于根据默认或用户配置的 Json Schema 对 AI 的响应进行结构化等等。

大模型 API 供应场景

• 多模型灵活切换&兜底重试：大模型应用后端对接多个大模型，已经成为应用的标配，一是供用户选择使用哪一个后端模型，二是应用出现故障或容量限制时的 faalback 机制。[4]
  

• 内容安全和合规：通过内容安全插件，过滤掉有害或不适当的内容，检测和阻止包含敏感数据的请求，并对 AI 生成内容进行质量和合规性审核。[5]
  

• 语义化缓存：大模型 API 服务定价分为每百万输入 tokens X 元（缓存命中）/ Y 元（缓存未命中），X 远低于 Y，以通义系列为例，X 仅为 Y 的40%，通过在内存数据库中缓存 LLM 响应，并以网关插件的形式来改善推理的延迟和成本。在网关层自动缓存对应用户的历史对话，在后续对话中自动填充到上下文，从而实现大模型对上下文语义的理解。[6]
  

• 多 API Key 均衡：API Key 是用于识别和验证调用方身份以及控制其对 API 访问权限的密钥。多 API Key 均衡就是当存在多个 API Key 时，API 网关通过一定的策略将 API 请求均匀地或根据特定规则分配到这些 API Key 上进行处理。

大模型 API 消费场景

• Token 配额管理和限流：“令牌”（Token）是大模型应用的常见衡量单位，准确地量化了大模型应用处理的数据量，和传统网关管理服务的访问量一样，AI 网关也需要具备对 Token 的管理能力，包括对使用量的观测，并提供限流功能，以及面向调用租户配置精确的调用额度限制。[7][8]
  
  

• 流量灰度：基模和大模型应用都在持续改善内容生成质量，使得大模型应用的变更频率保持在一个较高的 level，将会高度依赖 A/B 测试和服务灰度能力来进行模型迭代。作为流量入口，AI 网关需要在流量灰度和观测方面发挥关键作用，包括灰度打标以及入口流量延时和成功率等指标的监测。
  
  
• 调用成本审计：大模型调用所消耗的计算资源远高于 Web 应用请求所消耗的计算资源，因此对调用成本的控制需求更加刚需。这里的调用既包括直接的经济成本，例如使用第三方 API 服务时需支付的费用，或者因 API 调用消耗企业内部计算资源（如服务器、存储、带宽等）而产生的成本；也包括间接成本，例如因 API 调用错误导致的资源成本等。
  
  

03

为什么要在网关上，而非大模型服务层实现这些能力

架构设计与解耦

• 功能分离：网关和大模型服务层承担着不同的核心功能。大模型服务层专注于执行复杂的计算任务，如自然语言处理、图像识别等，为用户提供智能响应。而 API 网关的主要功能是管理 API 的访问，包括安全认证、流量控制、协议转换等。将 API 网关的能力放在网关上实现，能够实现功能的清晰分离，使各个组件的职责更加明确，便于系统的开发、维护和扩展。
  
  

• 解耦系统：如果在大模型服务层实现 API 网关的功能，会导致大模型服务与 API 管理功能紧密耦合。当需要对 API 管理策略进行调整（如更改安全认证方式、调整流量限制规则）时，可能会影响到大模型服务的稳定性和性能。而在网关上实现 API 网关能力，可以将大模型服务与 API 管理解耦，使两者可以独立发展和升级，降低系统的复杂度和维护成本。
  
  

• 统一安全防护：网关作为系统的入口，可以对所有进入系统的 API 请求进行全面的安全检查，形成一道统一的安全防线。在网关上实现身份验证、授权、防攻击等安全功能，可以有效阻止恶意请求进入大模型服务层，保护大模型和相关数据的安全。如果在大模型服务层实现安全功能，可能会因为大模型服务的分散性而导致安全防护存在漏洞。

04

AI 网关未来的演进方向

得益于 Wasm 插件的动态扩展能力，Higress 在 AI 时代快速演进并发展 AI 时代的能力。本文提到的大模型 API 管理底层能力，均已经在开源 Higress 和阿里云云原生 API 网关上线：

Higress 开源控制台

阿里云云原生 API 网关控制台

同时，在阿里云云原生 API 网关上我们提供了 AI API 管理能力，可以更便捷更高效地管理 AI 时代的 API：

创建 AI API 选项