AI推理模式

Chris Hain

随着AI和机器学习能力日益被视为推动各种规模企业创新和提升效率的关键，组织必须确定如何以适当方式让应用开发人员使用这些能力。在许多情况下，组织会使用AI推理服务，即“调用AI模型，根据给定输入生成输出的服务”（例如预测分类或生成文本），通常用于响应其他应用代码发出的API调用。

这些推理服务可以采用多种方式构建和使用，即使在同一组织内也是如此。这些服务可以完全由内部开发，也可以作为SaaS使用；可以利用开源项目，并采用开放模型或商业模型。它们可能是功能完备的“机器学习平台”的一部分，为更广泛的数据科学和模型创建工作提供支持；也可能只提供一个用于调用模型的API端点。它们可以在私有数据中心、公有云或托管设施中运行，也可以混合部署。大型组织可能会采用多种AI推理方案，尤其是在该领域的组织成熟度较低时。虽然没有一种方法能够适用于所有情况，但一些常见模式正在逐渐形成。

模式概览

我们将探讨三种主要的AI推理使用模式，以及它们各自的优缺点：

1. AI推理即服务（SaaS）：应用连接到外部专用AI推理服务提供商。
2. 云托管AI推理，应用连接到在公有云中运行的全托管AI推理服务。
3. 自主管理的AI推理：应用使用由组织自行管理的AI推理，该推理可以作为集中式服务的一部分提供，也可以直接在应用层提供。

关键决策点

评估以下运行模式之间的取舍时，需要考虑几个关键因素：

运营注意事项

可扩展性：随着容量需求不断变化，谁负责扩容和缩容？给定方案的扩缩容能力如何？是否存在扩展限制或容量上限？成本：全托管服务乍看之下可能成本更高，但将总拥有成本（包括任何专用硬件和人员配置）纳入考量后，如何选择可能并不明确。运营成本会如何随容量的增加或减少而变化？是否存在成本下限？维护和支持：谁负责维护推理服务？贵组织是否需要聘用具备相关专业知识的员工或付费聘请顾问，还是选择托管服务更为合理？

开发注意事项

工作负载集成便捷性：AI服务能以多快的速度与使用该服务的工作负载集成？该服务是否适用于预期的使用模式（例如离线推理或批量推理）和运行环境？敏捷性：整个应用能以多快的速度适应不断变化的业务需求？架构的哪些方面较为固化，难以更改？

性能考量

性能：服务的物理位置（相对于服务使用者）和推理延迟是否会影响您的用例？硬件可用性：服务是否有任何特殊硬件要求？如果有，现有容量能否满足预期需求（适用于本地和云环境）？

数据注意事项

数据泄露：是否担心敏感数据可能会发送到推理服务，或出现在推理结果中？如果是，能否检查流量并应用防护措施？数据治理：应用数据会发送到哪个地理位置（以及如何发送）？数据是否仍由组织直接控制，还是会发送给第三方？是否有特殊的法规或合规政策规定必须如何处理这些数据？

SaaS模式

组织可以选择使用专门的SaaS提供商所提供的服务，这类提供商专注于托管用于推理的AI模型（例如OpenAI或Cohere）。在这种情况下，运行在组织基础设施（无论是私有数据中心、托管数据中心还是公有云）上的工作负载会调用SaaS提供商发布的API。采用这种模式时，运行模型托管所需基础设施的负担完全由SaaS提供商承担，因此可以在很短时间内投入使用。不过，这些优势以牺牲控制力为代价。在本文介绍的模式中，这种模式的“灵活性”最低。同样，这种模式通常对敏感数据的控制力也最低，因为连接服务通常需要使用公共互联网，而且外部SaaS供应商往往难以满足严格的法规合规要求。

适用场景

• 上市时间：快速原型设计和MVP发布。
• 缺乏丰富内部AI推理专业知识或经验的组织。
• 对数据安全或治理没有重大或严格要求的应用。

优势

• 缩短上市时间：简单的运营模式有助于缩短集成时间。
• 专注于特定领域的服务提供商具备充分能力，可应对推理扩展挑战。
• 无需投资专用硬件或专业人员。

挑战

• 与应用工作负载共置的服务相比，存在延迟和连接方面的顾虑。
• 数据隐私、治理和安全方面的要求依赖外部SaaS提供商（或可能与其不兼容）。
• 在规模较大时，运营支出可能高于自托管模式。
• 可能不支持自定义模型托管和模型定制服务。

云托管模式

在此模式下，组织使用公有云提供商提供的托管服务（例如Azure OpenAI、Google Vertex、AWS Bedrock）。与第一种模式一样，AI模型的部署、扩展和维护等运维工作由云提供商承担，而非使用服务的组织。此模式与上述SaaS模式的主要区别在于，推理API端点通常可通过专用网络访问，并且AI使用方的工作负载可与AI模型服务部署在同一位置（例如同一可用区或区域）。因此，数据通常无需经过公共互联网，延迟可能更低；连接这些服务的机制也与连接云提供商其他托管服务的机制类似（即服务账号、访问策略和网络ACL）。即使工作负载与AI推理服务托管在不同的云中，采用多云网络的组织也可能获得其中一些相同的优势。

非常适合

• 已投资公有云的组织。
• 在其他云托管服务中运行或连接到这些服务的应用。

优势

• 许多组织已经熟悉如何将工作负载连接到其他云提供商的托管服务（例如数据库、对象存储等）。
• 运行和扩展模型所需的运维及基础设施工作主要由云服务提供商承担。
• 延迟问题和部分数据隐私问题可能更容易解决。

挑战

• 连接多云和混合云应用并确保其安全需要投入更多精力。
• 云托管服务和API缺乏统一性，可能导致供应商锁定。
• 未广泛采用公有云的组织可能会面临困难。
• 在规模较大时，运营支出可能高于自托管模式。
• 可能不支持自定义模型托管和模型定制服务。

自主管理模式

对于自主管理模式，我们将首先讨论将AI模型推理作为集中式“共享服务”运行的情况，然后分析不存在集中式服务、由各应用团队自行处理运营问题的情况。

自主管理的共享服务

在自主管理模式的“共享服务”变体中，组织可能会设立专门团队，负责维护推理基础设施、在其上运行的模型、用于连接该基础设施的API，以及推理服务生命周期的所有运营环节。与其他模式一样，AI应用工作负载通过API调用使用推理服务。模型服务基础设施可能运行在私有数据中心、公有云或托管设施中。负责运营推理服务的团队可以利用自托管机器学习平台（例如Anyscale Ray或MLFlow）。或者，也可以使用更专注于推理服务的工具，例如Hugging Face的Text Generation Inference服务器，或内部开发的软件。采用自主管理推理时，组织只能使用自行训练或可在本地运行的模型（因此，面向SaaS服务的专有模型可能无法使用）。

非常适合

• 拥有丰富基础设施管理经验的成熟组织。
• 推理需求量大，且采用自管理服务的总体拥有成本（TCO）具有合理性的组织。
• 对数据隐私和合规性要求极为严格的应用。

优势

• 组织可以全面控制推理服务的各个方面。
• 通常，使用自托管模型最容易应对数据隐私挑战。
• 大规模部署时，成本效益可能优于云托管或基于SaaS的推理服务。

挑战

• 组织可以全面掌控推理服务的各个方面（可能需要在基础设施和人员配置方面投入大量资源，同时还需持续应对维护、开发和可扩展性问题）。
• 对于推理需求较少且对数据隐私顾虑较少的组织而言，通常不具备成本效益。
• 无法访问可能以SaaS或云托管服务形式提供的闭源或专有模型。

自行管理，而非共享服务

对于没有中央团队负责运行供应用使用的AI推理服务的组织，可以采用另一种“自主管理”模式。在这种模式下，各应用团队可能会在分配给其应用工作负载的同一基础设施上运行模型。他们可以选择通过API访问这些模型，也可以采用“离线”方式直接使用。借助这种模式，开发人员或许能以较小规模获得与“共享服务”自主管理模式相似的部分优势。

适用场景

• 需要批处理和离线推理的应用。
• 推理用量很低，但对数据隐私和合规性有严格要求的组织。

优势

• 为应用开发人员提供高度灵活性，可通过多种方式与工作负载集成。
• 可在小规模部署中实现数据隐私和延迟目标。
• 在某些情况下（例如单个团队有大量使用需求），可能比所讨论的其他模式更具成本效益。

挑战

• 模型生命周期的运维负担由各个应用团队承担。
• 随着组织对AI推理的使用量增加，无法发挥规模经济效益（缺乏一致性、资源利用效率低下等）

模式权衡总结

保护AI应用和模型推理服务

从本质上看，AI应用与其他现代应用非常相似。它们通常由面向用户的组件和后端组件共同构成，往往依赖外部数据存储，并大量调用API等。这些应用同样面临所有现代应用普遍存在的安全挑战，因此需要以相同方式采取同类保护措施（例如AuthNZ、DDoS防护、WAF和安全开发实践等）。不过，AI应用，尤其是采用生成式AI的应用，还面临一些其他应用可能没有的特有问题（例如，参见OWASP大语言模型应用十大安全风险）。这些模型通常具有不可预测性，可能引发新的问题，在赋予模型较大自主权的用例中尤其如此。

值得庆幸的是，上述模式中的AI模型推理高度依赖API驱动的交互，因此许多组织已经具备实施这些新安全措施的良好基础。例如，提供传统速率限制、身份验证、授权和流量管理功能的API网关，可以扩展为支持基于令牌的速率限制，从而帮助控制成本（既可在应用层对发往SaaS或提供商托管服务的出站流量实施，也可对入站流量实施RBAC授权，为自主管理的推理服务提供前置保护）。同样，当前提供传统Web应用防火墙（WAF）服务（例如检查SQL注入或XSS）的基础设施，也可以合理地用于增加针对提示词注入及类似攻击的防护。大多数现代可观测性实践都可直接应用于API驱动的AI推理特定用例，团队应能充分利用这一领域的现有工具和实践。

结论

尽管围绕AI应用和推理服务的热议确实是新近出现的，但部署和保护这些应用与服务所依据的基本原则早已存在。与采用任何其他技术一样，组织需要根据具体用例、可用资源和长期目标权衡取舍，以确定如何更好地利用AI能力。同样，虽然AI（尤其是生成式AI）用例确实带来了一些新的安全挑战，但它们与其他现代应用有许多共同需求，而且模型交互高度依赖API，这为利用和扩展现有模式、实践及工具提供了良好契机。无论采用自托管方式还是托管服务，要充分发挥AI投资的价值和影响力，关键在于确保开发人员能够使用符合具体业务要求且安全、可扩展、高性能的解决方案。

关于作者

Chris Hain

Chris Hain 的更多博客文章