什么是AI网关？

为什么需要 AI 网关？

大模型主战场从训练转向推理，越来越多的公司已经开始设计能满足企业内部需求和外部商业方向的大模型应用，并在生产环境中进行部署。这个过程中，出现了一系列新的需求，这些需求与最初的大模型应用在“概念验证阶段”有所不同。这些新需求更多地源于对规模化和安全使用的关注，其中，AI 网关成为被讨论较多的 AI 基础设施关键组件之一。

AI 网关并不是独立于 API 网关的新形态，本质也是一种 API 网关，区别在于针对 AI 场景的新需求专门做了扩展，它既是 API 网关的继承，也是 API 网关的演进。

大语言模型正被广泛应用于企业的 AI 场景，包括以下三种典型的调用场景：

• 开发者直接使用大模型服务：开发人员直接对接不同供应商的大语言模型 API，以满足业务需求。

• AI 应用调用大模型服务：企业内部的 AI 应用通过调用大模型服务来处理复杂任务。

• AI 应用调用普通应用：AI 应用通过调用普通应用的 API 接口来扩展功能。

在实际应用中，企业往往需要在多个模型之间进行选择和切换。当某个模型因稳定性或效果不佳而需要更换时，企业希望能够快速切换到另一个模型，同时对新推出的模型进行灰度测试以便评估效果。与个人应用不同，企业在采用 AI 技术时，还面临着以下四大挑战：

• 与不同的大模型服务的集成和切换成本高：不同模型供应商的 LLM API 接口标准不同，访问方式不同，LLM API 的调用方无法平滑地在不同供应商之间切换，无法同时使用不同供应商提供的模型。

• 对企业内大模型服务使用者的管理难度大：LLM API 作为企业内的共享和稀缺资源，需要避免因为部分调用者使用不当导致被限流等问题，且不同的模型成本差异较大，企业需要保证高成本的模型能被用在高价值的业务场景上，但仅靠管理手段，很难做到对使用者的精细化的权限管理和资源管控，也难以针对不同的业务场景采用不同的模型和策略。

• 数据安全和合规风险高：大模型服务受限于背后的硬件等因素，一般均为 SaaS 服务的形式，企业在调用大模型服务接口时，其内部数据存在泄露风险，同时，调用大模型服务，尤其是开源或外部大模型服务时，数据的合规也是不可忽视的问题。

• 大模型服务自身的稳定性差：大模型服务受到硬件限制，其接口限流阈值较低，且自身稳定性也低于一般 API 服务，接口的 RT 和成功率均不够稳定，进而影响 AI 应用的整体可用性。

以上的需求，均是传统网关所无法满足的。

AI 网关有哪些核心能力？

多模型服务

企业往往会实施多模型策略。企业员工在前端选择大模型，可以按需切换后端的大模型服务，例如企业内部可以部署 DeepSeek、Qwen、自建等多个大模型，由员工自行选择，以获得更加丰富、可选的生成效果。企业越是多元化，对多模型服务的需求越强烈。

需求场景：

• 多模态业务整合场景，企业需同时处理文本、图像、音频、3D 等多模态数据。研发、产品团队对推理能力强的模型需求多；客服、营销、平面设计等团队对图片大模型的场景需求多；工业设计、影视制作团队对音视频大模型的场景需求多。

• 企业业务覆盖多个垂直领域，需针对不同行业特性调用专用模型。尤其是供应链端的企业往往服务多个行业，可能会涉及多款垂直行业的大模型需求。

• 复杂任务协同场景，单一任务需多个模型分工协作以提升效果。多个大模型员工协同生成内容才能达到最佳效果。

• 安全与效率双重要求场景，例如医疗机构的场景，处理患者数据使用专属私有模型分析，其他和患者无关的需求使用通用模型，避免敏感数据和非敏感数据混入数据库中。

消费者鉴权

在多租户模型服务分租场景中，企业为不同部门或团队提供共享的大模型服务时，会通过 API Key 区分租户，确保数据隔离和权限管控。具体要求包括：

• 为每个租户分配独立 API Key，控制其调用权限和资源配额，例如部门 A 的调用资源配额是每天每人 20 次，部门 B 的调用资源配额是每天 30次。

• 支持租户自定义模型参数（如温度系数、输出长度），但需通过网关校验权限。

企业内部权限分级管控：企业内部不同角色需差异化访问模型能力。具体要求包括：

• 基于 RBAC（基于角色的访问控制）限制敏感功能（如模型微调、数据导出）。

• 出于成本考虑，多模态大模型只供设计部门调用。

• 记录操作日志并关联用户身份，满足内部审计需求。例如，金融企业限制风险评估模型仅限风控部门调用，防止普通员工滥用。

模型自动切换

• 模型自身特性引发的异常：大模型生成结果存在概率性波动，导致随机性输出不稳定的情况；发布新版本导致的流量损失。

• 用户使用不规范导致的异常：使用者请求参数不符合 API 规范，导致连接超时或中断，或者输入包含恶意构造的提示词，触发模型安全防护机制，返回空结果或错误码。

• 资源与性能限制：请求频次过高，触发限流策略，导致服务不可用，长请求占用过多内存，导致后续请求被阻塞，最终导致超时。

• 依赖服务故障：外部 API，例如 RAG 检索的数据库不可用，导致模型无法获取必要上下文。

Token 级限流

虽然企业内部使用，不会频繁存在并发的需求，但通过设置限流能力，可以更经济地配置硬件资源。例如一家 10000人的企业，不需要配置同时支持 10000 人上线的硬件资源，只需要配置 7000 人的硬件资源，超出部分进行限流，避免资源闲置。其他需求包括：

• 提升资源管理：大模型对计算资源的消耗不可控，限流可以防止系统过载，确保所有用户都能获得稳定性能，尤其在高峰期。

• 指定用户分层：可以基于 ConsumerId 或者 API Key 进行 Token 限流。

• 防止恶意使用：通过限制 Token 数量来减少垃圾请求或攻击，以免产生资损。

内容安全合规

企业自建大模型需要确保生成内容符合安全和合规要求，包括过滤掉有害或不适当的内容，检测和阻止包含敏感数据的请求，并对 AI 生成内容进行质量和合规性审核。

• 金融行业敏感数据处理：审核用户输入的金融交易指令、投资咨询内容，防范欺诈、洗钱等违规行为。对模型生成的财务报告、风险评估结果进行合规性校验。

• 医疗健康信息交互：电子病历生成内容，防止泄露患者隐私（如身份证号、诊断记录），确保 AI 生成的医疗建议符合相关法规。通过多模态大模型识别医疗影像中的敏感信息，并结合合规规则库进行自动化拦截。

• 社交媒体与 UGC 内容管理：实时审核用户发布的图文、视频内容，拦截涉黄、暴恐、虚假信息。对 AI 生成的推荐内容（如短视频标题、评论）进行合规性检查。

• 政务服务平台交互：审核公众提交的政务咨询内容，防止恶意攻击或敏感信息传播，确保 AI 生成的政策解读、办事指南符合相关法规。

• 电商与直播平台风控：审核商品描述、直播弹幕内容，拦截虚假宣传、违禁品信息，对 AI 生成的营销文案进行广告法、合规性检查。

语义缓存

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

• 高频重复性查询场景：客服系统、智能助手等场景中，用户常提出重复问题（如“如何重置密码”、“退款流程”），通过缓存常见问题的回答，避免重复调用模型，降低调用成本。

• 固定上下文多次调用场景：法律文件分析（如合同条款解读）、教育教材解析（如知识点问答）等场景，需对同一长文本多次提问。通过缓存上下文，避免重复传输和处理冗余数据，提升响应速度，降低调用成本。

• 复杂计算结果复用场景：数据分析与生成场景（如财报摘要、科研报告生成），对相同数据集的多次分析结果缓存，避免重复计算。

• RAG（检索增强生成）场景中：缓存知识库检索结果（如企业内部 FAQ），加速后续相似查询的响应。

联网搜索+获取检索网页的全文

联网搜索已经成为大模型的标配。如果不支持联网搜索，或者支持联网搜索，仅能获取网页标题、摘要、关键词而非全文，内容生成效果都会大打折扣。

大模型可观测

可观测常见于成本控制和稳定性场景。由于大模型应用的资源消耗比 Web 应用更加敏感和脆弱，因此成本控制对可观测的需求更为强烈，如果缺少完备的可观测能力，异常调用可能会导致几万甚至几十万的资损。

除了QPS、RT、错误率等传统观测指标，大模型的可观测还应具备：

• 基于 consumer 的 token 消耗统计。

• 基于模型的 token 消耗统计。

• 限流指标：每单位时间内有多少次请求因为限流被拦截，限流消费者统计（是哪些消费者被限流）。

• 缓存命中情况。

• 安全统计：风险类型统计、风险消费者统计。

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

架构设计与解耦

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

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

性能优化

• 减少大模型负载：大模型通常需要大量的计算资源和内存来运行，处理复杂的推理任务已经消耗了大量的系统资源。如果再在大模型服务层实现 API 网关的功能，如身份验证、限流、缓存等，会进一步增加大模型的负载，影响其处理速度和响应时间。而将这些功能放在网关上实现，可以在请求到达大模型服务层之前对其进行预处理和过滤，减少不必要的请求进入大模型服务层，从而提高大模型的性能和效率。

• 提高并发处理能力：网关可以通过负载均衡等技术，将大量的 API 请求均匀地分配到多个大模型服务实例上，提高系统的并发处理能力。如果在大模型服务层实现 API 网关功能，每个大模型服务实例都需要独立处理 API 管理任务，这会限制系统的并发处理能力。而网关可以集中处理这些任务，更好地应对高并发场景。

安全保障

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

• 数据保护：网关可以对 API 请求和响应的数据进行加密、脱敏等处理，确保数据在传输和存储过程中的安全性。在大模型服务层处理这些数据保护任务可能会增加大模型的复杂性和计算负担。而在网关上统一处理，可以更好地保护用户的敏感信息，同时避免大模型直接接触敏感数据带来的安全风险。

可扩展性与灵活性

• 方便新功能集成：随着业务的发展，可能需要为 API 管理添加新的功能，如支持新的安全认证协议、引入新的流量控制算法等。在网关上实现 API 网关能力，更容易集成这些新功能，而无需对大模型服务层进行大规模的修改。这样可以快速响应业务需求的变化，提高系统的扩展性。

• 支持多模型接入：在实际应用中，可能会同时使用多个不同的大模型服务。网关可以作为统一的接入点，为不同的大模型服务提供相同的 API 管理服务，方便对多个大模型进行管理和调度。如果在每个大模型服务层分别实现 API 网关功能，会增加系统的复杂性和管理难度。

可观测性与监控

• 集中监控与分析：网关可以对所有 API 请求进行集中监控和分析，收集各种指标数据，如请求响应时间、调用频率、错误率等。通过对这些数据的分析，可以及时发现系统中存在的问题，如性能瓶颈、安全漏洞等，并采取相应的措施进行优化和修复。如果在大模型服务层实现监控功能，将难以对整个系统的 API 调用情况进行全面的了解和分析。

• 故障排查与定位：当出现 API 调用故障时，在网关上可以更容易地进行故障排查和定位。网关可以记录每个 API 请求的详细信息，包括请求的来源、请求参数、响应结果等，通过分析这些信息可以快速确定故障的原因和位置，减少故障修复的时间和成本。

阿里云 AI 网关服务有哪些核心能力？

阿里云如何为您提供 AI 网关服务？

阿里云以插件的形式提供 AI 网关的能力，即插即用，方便维护，基于 WASM 技术支持热更新，不影响业务变更。