AI 推理模式
随着人工智能和机器学习能力越来越被视为推动各种规模公司创新和效率的关键，组织必须确定如何最好地为其应用开发人员提供对这些功能的访问权限。 在许多情况下，将使用 AI 推理服务，即“调用 AI 模型根据给定的输入产生输出的服务”（例如预测分类或生成文本），最常见的是响应来自其他应用代码的 API 调用。
这些推理服务可以通过多种方式构建和使用（即使在单个组织内）。 这些服务可以完全在内部开发，也可以作为 SaaS 使用，利用开源项目，并使用开放或商业模型。 它们可能作为支持更广泛的数据科学和模型创建工作的功能齐全的“机器学习平台”的一部分出现，或者它们可能只为您提供调用模型的 API 端点。 它们可能在私有数据中心、公共云、主机托管设施或这些的混合环境中运行。 较大的组织可能会依赖多个单一选项进行 AI 推理（尤其是在该领域成熟度较低的组织中）。 虽然没有一种适合所有人的万能方法，但一些常见的模式正在浮现。
模式概述
我们将研究三种广泛的 AI 推理消费模式，以及它们的各种优势和劣势：
- AI 推理作为 SaaS –applications连接到外部专用 AI 推理服务提供商。
- 云管理 AI 推理——applications连接到在公共云中运行的完全托管的 AI 推理服务。
- 自我管理的 AI 推理——应用s使用组织本身管理的 AI 推理，可以作为集中式服务的一部分，也可以直接在应用级别使用。
关键决策点
在评估以下操作模式之间的权衡时，需要牢记几个关键因素：
操作注意事项
- 可扩展性——谁负责，以及随着容量需求随时间变化，给定选项的扩展和缩小程度如何？ 规模或者容量有限制吗？
- 成本——全面托管服务乍一看似乎更昂贵，但考虑到总拥有成本（包括任何专用硬件和人员）可能会使决策变得不那么明确。 随着产能增加或减少，运营成本如何变化？成本有底线吗？
- 维护/支持——谁负责维护推理服务？ 您的组织是否需要雇用员工或聘请具有该领域专业知识的顾问，或者提供托管服务是否更有意义？
开发注意事项
- 工作负载集成的简易性——AI 服务能够多快与消耗工作负载集成？ 该服务是否适合您预期的使用模式（例如离线/批量推理）和操作环境？
- 敏捷性——整体应用能多快适应不断变化的业务需求？ 架构中的哪些方面更加根深蒂固并且难以改变？
性能注意事项
- 性能——服务的物理位置（相对于服务消费者）和推理的延迟是否对您的用例重要？
- 硬件可用性——该服务是否有任何特殊的硬件要求？如果有，您是否有能力满足预期的需求（适用于本地和云环境）？
数据考虑
- 数据泄露——是否担心敏感数据可能会被发送到推理服务或可能出现在推理结果中？ 如果有，能检查交通、设置护栏吗？
- 数据治理——应用程序数据发送到哪里（以及如何发送）？ 直接控制权是否仍保留在组织内部，还是交给第三方？ 是否存在适用于如何处理数据的特殊法规或合规政策？
SaaS 模式
组织可以选择使用专用 SaaS 提供商的服务，该提供商专注于托管用于推理的 AI 模型（例如 OpenAI 或 Cohere）。 在这种情况下，组织基础设施（私有数据中心、主机托管或公共云）上运行的工作负载利用 SaaS 提供商发布的 API。 采用这种模式，运营托管模型所需的基础设施的负担完全落在 SaaS 提供商身上，并且启动和运行所需的时间可能非常短。 然而，这些好处是以控制为代价的，这种模式是我们将要介绍的模式中“灵活性”最差的。 同样，在这种模式下，对敏感数据的控制通常最低，因为通常使用公共互联网连接服务，而外部 SaaS 供应商不太可能解决严格的监管合规问题。
非常适合
- 上市时间： 快速原型设计，MVP 发布。
- 缺乏内部 AI 推理专业知识/经验的组织。
- 没有重大或严格的数据安全/治理需求的applications。
优势
- 上市时间短： 简单的操作模型可以缩短集成时间。
- 专注的服务提供商有能力应对推理扩展挑战。
- 不需要投资专门的硬件或人员。
挑战
- 与应用程序工作负载共置的服务相关的延迟和连接问题。
- 数据隐私、治理和安全问题依赖于（或可能与）外部 SaaS 提供商。
- 更大规模的运营费用成本可能高于自托管模式。
- 可能不支持自定义模型托管和模型定制服务。
云管理模式
在这种模式下，组织利用公共云提供商提供的托管服务（例如 Azure OpenAI、Google Vertex、AWS Bedrock）。 与第一种模式一样，部署、扩展和维护 AI 模型的运营负担落在云提供商而不是消费组织身上。 这种模式与上述 SaaS 模式的主要区别在于，在这种情况下，推理 API 端点通常可以通过私有网络访问，并且 AI 消费者工作负载可以与 AI 模型服务共置（例如，同一区域、地区）。 因此，数据通常不会通过公共互联网，延迟可能会更低，并且连接这些服务的机制与其他云提供商管理服务的机制类似（即服务帐户、访问策略、网络 ACL）。 即使在工作负载和 AI 推理服务托管在不同的云中的情况下，利用多云网络的组织也可能能够实现其中一些相同的好处。
非常适合
- 拥有现有公共云投资的组织。
- 在其他云托管服务中运行或连接到其他云托管服务的applications。
优势
- 许多组织已经熟悉将其工作负载连接到其他云提供商管理的服务（例如数据库、对象存储等）。
- 运行和扩展模型的运营和基础设施负担主要落在云提供商身上。
- 延迟问题和一些数据隐私问题可能更容易解决。
挑战
- 多/混合云应用需要额外的努力来连接和保护。
- 云管理服务和 API 缺乏统一性可能会导致供应商锁定。
- 没有广泛公共云存在的组织可能会面临困难。
- 更大规模的运营费用成本可能高于自托管模式。
- 可能不支持自定义模型托管和模型定制服务。
自我管理模式
对于自我管理模型，我们首先讨论 AI 模型推理作为集中式“共享服务”运行的情况，然后研究不存在集中式服务的情况，而运营问题则留给各个应用团队处理。
自主管理、共享服务
在自管理模式的“共享服务”变体中，组织可能有专门的团队负责维护推理基础设施、在其上运行的模型、用于连接到它的 API 以及推理服务生命周期的所有操作方面。 与其他模式一样，AI应用工作负载将通过API调用使用推理服务。 模型服务基础设施可能在私有数据中心、公共云或主机托管设施中运行。 负责运营推理服务的团队可以利用自托管机器学习平台（例如 Anyscale Ray 或 MLFlow）。 或者，他们可能依赖更为狭隘的推理服务工具，如 Hugging Face 的文本生成推理服务器或内部开发的软件。 通过自我管理推理，组织只能使用自己训练的模型或可在本地运行的模型（因此，面向 SaaS 的服务的专有模型可能不是一种选择）。
非常适合
- 拥有丰富基础设施管理经验的成熟组织。
- 具有大量推理需求的组织，证明了自我管理服务的 TCO 是合理的。
- 具有最严格的数据隐私和合规性要求的applications。
优势
- 组织完全控制推理服务的各个方面。
- 数据隐私挑战通常最容易通过自托管模型解决。
- 大规模成本可能比基于云管理或 SaaS 的推理服务更有效率。
挑战
- 组织完全控制推理服务的各个方面（可能需要大量的基础设施和人员投资，以及持续的维护、开发和可扩展性问题）。
- 对于具有最少推理需求和最少数据隐私顾虑的组织来说，这通常不具成本效益。
- 无法访问可能作为 SaaS 或云托管服务提供的封闭/专有模型。
自主管理，而非共享服务
没有中央团队负责运行应用使用的 AI 推理服务的组织是自我管理模式的另一种变体。 在此版本中，各个应用团队可能会在为应用工作负载分配给他们的相同基础架构上运行他们的模型。 他们可以选择通过 API 访问这些模型，或者以“离线”方式直接使用它们。 通过这种模式，开发人员可能能够在较小规模上实现与“共享服务”自我管理模型相同的一些好处。
非常适合
- 需要批处理和离线推理的applications。
- 推理消耗很少但数据隐私和合规性要求严格的组织。
优势
- 对于应用开发人员来说最灵活，允许与工作负载进行广泛集成的可能性。
- 可以在小规模内实现数据隐私和延迟目标。
- 在某些情况下可能比讨论的其他模型更具成本效益（例如对消耗要求较高的单个团队）。
挑战
- 模型生命周期的运营负担落在各个应用团队身上。
- 随着组织对 AI 推理的消耗不断增长，无法利用规模经济（缺乏一致性、资源利用效率低下等）
模式权衡总结
保护 AI 应用和模型推理服务
从本质上讲，AI应用与其他现代应用程序非常相似。它们由面向用户的组件和后端组件混合构建而成，通常依赖于外部数据存储，大量使用 API 调用等。 这些应用继承了所有现代应用程序共有的安全挑战，并且需要以相同的方式应用相同的保护（例如，AuthNZ、DDoS 保护、WAF、安全开发实践等）。 然而，人工智能应用程序，尤其是那些利用生成式人工智能的应用程序，也面临一些可能不适用于其他应用的独特问题（例如，参见OWASP Top 10 For LLMs ）。 这些模型的普遍不可预测性可能会导致新的问题，特别是在模型被赋予重要权力的用例中。
幸运的是，由于上述模式严重依赖 API 驱动的与 AI 模型推理的交互，许多组织已经准备好实施这些新的安全措施。 例如，提供传统速率限制、身份验证、授权和流量管理功能的 API 网关可能会扩展为支持基于令牌的速率限制，以帮助控制成本（在应用程序级别出站到 SaaS / 提供商托管服务或入站 RBAC 授权作为自管理推理服务前的保护）。 同样，当前执行传统 Webapplication防火墙 (WAF) 服务（例如检查 SQL 注入或 XSS）的基础设施可能是添加针对提示注入和类似攻击的保护的合理位置。 大多数现代可观察性实践直接适用于 API 驱动的 AI 推理特定用例，团队应该能够充分利用该领域的现有工具和实践。
结论
虽然围绕人工智能应用和推理服务的讨论无疑是新的，但部署和保护它们的基本原则已经存在很长时间了。 在确定如何最好地利用人工智能能力时，组织需要权衡利弊，就像使用任何其他技术时一样；基于其特定的用例、可用资源和长期目标。 同样，尽管人工智能（尤其是生成式人工智能）用例确实带来了一些新的安全挑战，但它们与其他现代应用共享的需求以及对 API 驱动模型交互的严重依赖为使用和扩展现有模式、实践和工具提供了绝佳的机会。 无论是自托管还是托管服务，确保开发人员能够访问满足您特定业务需求的安全、可扩展、高性能的解决方案，对于最大化您的 AI 投资的价值和影响至关重要。