大模型的主战场正从训练转向推理，这已成为行业共识。越来越多的企业开始设计和部署真正契合内部及外部商业场景的大模型应用，并且是在生产环境中进行实际落地。在这一过程中，一系列新需求逐渐浮现，与当初“概念验证阶段”的尝试性质截然不同。这些需求的核心正是规模化与安全，因此AI网关作为基础设施组件，成为业内讨论最频繁的关键词之一。

在深入探讨之前，我们先明确一个概念。AI网关并非凭空产生的新事物，本质上它仍然是一种API网关。区别在于，它针对AI场景下的新需求进行了专门的扩展。可以说，它既是API网关的继承者，也是API网关的演进者。因此，从API的视角对AI网关的能力进行分类，是最容易达成共识的方法。

01 API 网关的继承

API网关的能力体系较为复杂，涉及多个团队角色。为便于理解，我们可以将全部能力按使用方划分为三类：研发场景、供应场景、消费场景。这三个场景分别对应API接口的开发团队、API平台的运维团队以及平台的外部调用方。

API 研发场景

“API First”的理念强调先定义API规范，再编写代码，这与某些团队先写代码后补文档的做法截然不同。API First要求应用构建之前优先设计和开发API接口，将API视为系统的核心架构组件。通过定义良好的接口规范，可以实现模块化——就像玩乐高积木，通过标准接口将不同服务模块灵活组合，从而提升系统的可扩展性、可维护性以及生态效率。

API 供应场景

该场景关注API提供方（无论是企业还是平台）如何通过标准化接口对外暴露数据或功能，核心在于创建、管理和维护这些API，确保其可用性、安全性和高效性。核心能力包括：

• API 安全：保护API免受各类威胁，确保只有授权用户和应用才能访问，并保障数据在传输与存储过程中的保密性、完整性和可用性。身份认证、授权管理、数据加密、防攻击是基础能力。
• 灰度：这是一种在生产环境中逐步引入新版本API或功能的策略。将部分用户或流量导向新版API，其余继续运行在老版本上，从而在不影响整体稳定性和用户体验的前提下测试和验证新功能。
• 缓存：将API的响应结果临时存储，遇到相同请求时直接从缓存中读取，无需重复请求后端服务，从而提升响应速度和系统性能。

API 消费场景

该场景指调用方（如应用、开发者）通过集成外部API来快速实现功能或获取数据，核心是利用平台能力满足业务需求。

• 调用审计：对API的调用活动进行全面记录、监控和分析，包括每次调用的发起方、时间、接口、输入参数、返回结果、响应时长等。
• 调用方配额限速：API网关根据预设规则，对每个调用方（如用户、应用或IP）在单位时间内的调用次数、流量或资源消耗进行限制。
• 后端保护式限流：通过负载均衡、限流、降级、熔断等手段管理API流量，确保系统稳定高效，防止因流量过大或异常导致服务宕机。

02 API 网关的演进

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

大模型 API 研发场景

“API First”或“API是一等公民”不再只是一句口号，而是切实的开发规范。Agent的开发和运行需要调用API，Agent通过开放平台对外服务也需要提供API。API网关能够覆盖API的全生命周期，包括设计、开发、测试、发布、售卖、运维监控、安全管控、下线等。基于API网关，还可以提供多种插件提升Agent开发效率，例如AI提示词模板、API AI Agent、JSON格式化等。

大模型 API 供应场景

• 多模型灵活切换与兜底重试：大模型应用后端对接多个模型已成标配。一方面允许用户选择模型，另一方面在某个模型发生故障或容量不足时，可以自动切换或重试，确保服务连续性。
• 内容安全与合规：通过内容安全插件过滤有害或不合适内容，检测并阻止包含敏感数据的请求，同时对AI生成内容进行质量与合规性审核。
• 语义化缓存：大模型服务按tokens计费，缓存命中价远低于未命中价。通过在内存中缓存LLM响应，以网关插件形式改善延迟和成本。网关层还能自动缓存用户对话历史，后续对话时自动填充上下文，帮助模型更好地理解语义。
• 多 API Key 均衡：API Key用于识别调用方身份和控制访问权限。当存在多个API Key时，网关通过策略将请求均匀或按规则分配到这些Key上处理。

大模型 API 消费场景

• Token 配额管理与限流：Token是大模型应用常见的计量单位，能精确量化处理的数据量。AI网关需要具备Token管理能力，包括用量监控、限流，以及为不同租户配置精确的调用额度限制。
• 流量灰度：基模和大模型应用更新频繁，高度依赖A/B测试和服务灰度进行模型迭代。作为流量入口，AI网关在流量灰度与观测中发挥关键作用，包括灰度打标、入口流量延迟和成功率监测。
• 调用成本审计：大模型调用消耗的计算资源远高于普通Web请求，成本控制是硬性需求。成本包括直接经济成本（如第三方API调用费）和间接成本（如调用错误导致的资源浪费）。

03 为什么是在网关层，而不是大模型服务层

看到这里，你可能会问：为什么这些能力必须放在网关层，而不是直接集成到大模型服务层？原因如下。

架构设计与解耦

• 功能分离：网关与大模型服务层的核心职责不同。大模型服务层专注于处理复杂计算任务（如NLP、图像识别），而API网关负责管理API访问，包括安全认证、流量控制、协议转换。将能力放在网关层，可实现功能清晰分离，职责明确，便于开发、维护和扩展。
• 解耦系统：若将网关功能集成到大模型服务层，会导致两者紧密耦合。调整API管理策略（如更换安全认证方式）可能影响大模型的稳定性与性能。而在网关层实现，两者可以独立演进和升级，从而降低系统复杂度与维护成本。

性能优化

• 减少大模型负载：大模型本身需要大量计算资源和内存，若再承担身份验证、限流、缓存等网关任务，会进一步增加负载，影响处理速度。将这些功能放在网关层，可以在请求到达大模型之前进行预处理和过滤，减少不必要的请求。
• 提高并发能力：网关可通过负载均衡等技术将大量请求均匀分配到多个大模型实例。如果每个大模型实例都要自行处理API管理任务，并发能力将受限。网关集中处理，能够更好地应对高并发场景。

安全保障

• 统一安全防护：网关作为系统唯一入口，可对所有请求进行安全检查，形成统一防线。在网关层实施身份认证、授权、防攻击，能有效阻止恶意请求进入大模型层。
• 数据保护：网关可对请求和响应数据进行加密、脱敏。若在大模型服务层处理这些操作，会增加复杂性和安全风险。在网关层统一处理，能更好地保护敏感信息。

可扩展性与灵活性

• 方便新功能集成：当业务需要添加新的API管理功能（如新的安全认证协议）时，在网关层集成比修改大模型服务层更容易、响应更快。
• 支持多模型接入：实际应用中可能同时对接多个不同的大模型。网关作为统一接入点，可为它们提供一致的API管理服务，便于调度和管理。

可观测性与监控

• 集中监控与分析：网关可集中监控所有API请求，收集响应时间、调用频率、错误率等指标。分析这些数据能及时发现性能瓶颈和安全漏洞。若在大模型层分散监控，难以获得全局视角。
• 故障排查与定位：出现调用故障时，网关记录了每个请求的详细信息，包括来源、参数、响应等。利用这些信息可快速定位故障原因和位置，缩短修复时间。

04 AI 网关的演进方向

得益于Wasm插件的动态扩展能力，Higress在AI时代快速演进，具备了AI网关的能力。前面提到的大模型API管理底层能力，已在开源Higress和阿里云云原生API网关上成功落地。

在阿里云云原生API网关上，我们提供了专门的AI API管理能力，能够更高效地管理AI时代的API。