AI 网关与 API 网关有何区别？

本文转载自 The New Stack。

图片来源：由 alphaspirit.it 在 Shutterstock 上发布

AI 网关是 AI 基础设施领域的新热点。这些系统将成为关键缓冲区，是 AI 应用与外部用户及内部 AI 建模团队之间的安全防护和负载均衡层。采用 AI 网关的紧迫性显而易见。

随着大型语言模型 (LLM)、高级计算机视觉算法及其他机器学习技术成为应用的重要组成部分，其集成和管理挑战也日益严峻。AI 网关为这些复杂挑战提供了一个新型解决方案，这也为 AI 工作负载提供了一个集中控制点。

但令人困惑的是，许多 AI 网关提供商并不采用“AI 网关”的说法，而是将它们描述为 AI 开发人员门户、AI 防火墙、AI 安全防护或 AI 负载均衡 —— 所有这些都包含 AI 网关的元素。

不出所料，AI 网关经常被拿来与 API 网关进行比较。管理 API 是 AI 网关的关键一环，这些网关通常被设计用来与大型云或 OpenAI 等外部 AI 提供商进行交互。（事实上，一些公司所谓的 AI 网关产品均基于 API 网关进行构建，只是添加了一些针对 AI 而微调的插件）。

因此，要正确设计可满足现代应用设计和部署要求的 AI 应用基础设施，必须了解 API 网关与 AI 网关之间的区别。

API 网关仍然发挥着不可或缺的作用

API 网关充当客户端与后端服务之间的中介，可帮助应用开发人员、安全团队及 DevOps 或 Platform Ops 团队减少在应用前管理和部署 API 的复杂性。API 网关还可以充当安全防护和负载均衡层，既能确保企业的 API 安全，又能保护企业的外部 API 免遭攻击者利用。

API 网关的主要功能包括：

• 治理：定义和实施一套策略、标准及流程，以管理、监控并控制 API 的使用、开发和维护。
• 请求路由：智能地将请求定向到相应的服务，确保数据到达正确的 AI 模型进行处理。
• 身份验证和授权：通过 API 密钥、OAuth 和 JSON Web Token (JWT) 等机制执行严格的访问控制。
• 性能提升：通过速率限制（防止过度使用）和缓存（存储常用响应）优化响应时间和资源使用。
• 监控和日志记录：提供有关 API 使用情况、错误率及整体系统健康状况的详细信息，这对故障排除和优化至关重要。
• 商业变现：提供基于 API 的产品和服务的商业变现控制和管理，并确定通过 API 提供的产品和产品功能的消费对象和收费标准。

AI 系统需要专门的网关

如今，大多数企业都通过第三方 API（来自 OpenAI、Hugging Face 或超大规模云服务商）来使用 AI。实际构建、调整和托管各自模型的企业也可通过内部 API 使用它们。AI 网关的基本作用是支持应用开发人员、AI 数据工程师及运维团队轻松地快速调用 AI API，并将其连接到自己的应用。AI 网关的工作原理类似于 API 网关。

但两者之间也有着显著区别。例如，在计算要求方面，AI 应用与传统应用截然不同，并需要使用不同的硬件。训练 AI 模型、微调 AI 模型、为其添加其他专业数据以及查询 AI 模型等每项作业可能有着不同的性能、延迟或带宽要求。

由于深度学习固有的并行性或推理的实时响应要求，可能需要不同的方法来分配 AI 工作负载。要衡量 AI 系统的消耗量，还需要对令牌和模型效率有深入理解。

AI 网关将监控入站提示，以发现滥用迹象，如提示注入或模型盗窃。简而言之，虽然 API 网关对于传统应用而言必不可少，但在处理 AI 特定流量模式和要求时，可能力不能及，例如：

• 成本优化：使用 AI 模型会产生大量费用。AI 网关可提供详细指标和成本跟踪工具，有助于做出明智的成本管理决策。
• 模型多样性：AI 应用通常使用来自不同提供商的多个模型，每个模型都有各自的接口和协议。AI 网关提供了一个统一的交互点，可简化开发。
• 模型版本控制和部署：AI 模型发展迅速。AI 网关能够简化不同模型版本的更新、回滚及 A/B 测试。
• 安全防护需求：AI 模型具有潜在敏感性，因此需要采用专门的安全协议。AI 网关支持针对 AI 工作负载量身定制的细粒度授权、输入验证和加密。
• 可观测性：对于 AI 而言，只监控标准 API 指标是不够的。AI 网关可跟踪推理时间、偏差检测、令牌使用和概念漂移等模型特定指标，为主动维护提供必要的洞察。
• 负载均衡：AI 负载均衡比传统负载均衡更复杂，因为 AI 的计算作业种类更多，包括各种推理和训练、内外部任务。用于 AI 计算的 GPU 非常昂贵，因此确保并行编程流水线的均衡和同步至关重要。

AI 网关采购或部署前要问的问题

舍鱼而取熊掌往往会带来风险和挑战。有些企业干脆选择只使用单个 AI 服务并管理其单服务 API，以避免出现问题。但此举可能会引发 AI 锁定风险，也会对希望在其 AI 服务中使用定制功能的团队造成影响。所以在决定试用 AI 网关之前，请考虑以下几点：

• 全面的模型支持：网关能否轻松处理来自内部和外部不同提供商的各种 AI 模型？
• 高级安全防护和治理：专为 AI 模型设计的安全协议的可靠性如何？它能否执行细粒度访问控制并检测潜在滥用或误用？
• 成本管理和优化：AI 网关是否提供细粒度使用和成本跟踪工具，以及是否采用优化技术来控制支出？
• 深度可观测性：平台是否跟踪推理时间、准确性、漂移和偏差等关键 AI 模型健康指标，以实现主动管理？
• 易于集成和可扩展性：网关能否无缝集成现有开发和部署工作流？它能否扩展以处理不断增长的 AI 工作负载？

API 网关和 AI 网关将会共存

需要说明的一点是，AI 网关是相对较新的技术，在短期内可能会有很大发展。但切勿幻想它能够适用于任何情形。一些 AI 应用能够与传统 API 网关完美搭配。

例如，如果应用主要通过 OpenAI API 使用，并且没有进行大量调整或额外训练，那么其应用的要求可能与传统应用非常相似。在这种情况下，可能会适得其反，增加 AI 网关成本并加大运维复杂性。

实际上，AI 应用的部署模式很可能兼有 API 网关和 AI 网关，因为这两种用例通常共存，甚至相辅相成。

目前，AI 网关功能不仅已经添加到现有 API 网关产品中，而且 AI 团队还部署了 NGINX 反向代理和 Ingress controller（Ingress 控制器），从而为 AI 应用（包括训练和推理）提供一些治理、负载均衡和交付功能。

未来，AI 网关将以多种形式和规模出现在现有 API 网关产品中，或作为独立套件使用。实际上，AI 网关是 API 网关在新 AI 时代演进的必然结果，正如 API 网关是从反向代理演变而来一样。

了解了这两类网关之间的区别，就能理解为何二者均必不可少以及明白应如何使用它们——即使它们作为相关或相依的应用或微服务并存。