随着基础模型（Foundation Models，简称FMs）的民主化趋势日益普及和对AI增强服务的需求增加，软件即服务（SaaS）提供商正寻求使用支持多租户的机器学习（ML）平台，以供其内部的数据科学家和外部客户使用。越来越多的公司意识到使用FMs为客户生成高度个性化和有效的内容的价值。通过在自己的数据上进行微调，可以显著提高模型在特定使用案例下的准确性，无论是使用页面访问上下文生成销售电子邮件、生成与公司服务相关的搜索答案，还是通过对历史对话进行训练来实现客户支持的自动化。
提供作为服务的生成式AI模型托管，使任何组织可以轻松集成、试验和大规模部署FMs，以一种具有成本效益的方式，无需内部拥有AI专业知识。这使得企业可以通过使用在可信客户数据上进行微调的托管生成模型，向客户提供更个性化和有效的AI应用程序，以更好地吸引和服务他们的客户。
Amazon SageMaker提供不同的ML推理选项，包括实时、异步和批量转换。本文重点介绍如何以成本效益高且可扩展的方式托管FMs。具体而言，我们将探讨实时推理的快速响应世界，探索FMs的不同实时推理选项。
对于推理而言，多租户的AI/ML架构需要考虑数据和模型的需求，以及执行推理所需的计算资源。重要的是要考虑多租户的AI/ML模型如何部署，理想情况下，为了最佳利用CPU和GPU，您必须能够设计一个推理解决方案，可以以高效的方式将模型分布在计算基础设施中，以提高服务吞吐量并降低成本。此外，客户希望能够在不需要从头开始构建一切的情况下，找到帮助他们部署最佳实践推理架构的解决方案。
SageMaker推理是一个完全托管的ML托管服务。它支持构建生成式AI应用程序，同时符合FedRAMP等监管标准。SageMaker可以支持高吞吐量推理工作负载的高效扩展。它支持实时、异步和批量推理，支持AWS Inferentia、AWS Graviton、NVIDIA GPU和英特尔CPU等硬件上的多样化工作负载。SageMaker使您完全控制优化、工作负载隔离和容器化。它使您能够构建具有多模型和多容器部署支持的大规模生成式AI服务解决方案。
大规模托管基础模型的挑战
以下是托管FMs进行推理的一些挑战：
- 大内存占用 – 具有数十亿或数百亿模型参数的FMs往往超出了单个加速器芯片的内存容量。
- 变压器速度慢 – FM中的自回归解码，特别是对于较长的输入和输出序列，加剧了内存I/O操作。这导致不可接受的延迟时间，影响实时推理。
- 成本 – FMs需要提供高内存和高计算能力的ML加速器。在不牺牲任何一方的情况下实现高吞吐量和低延迟是一项专门的任务，需要深入了解硬件-软件加速协同优化。
- 上市时间长 – 从FMs获得最佳性能需要严格的调整。这种专门的调整过程以及基础设施管理的复杂性导致了较长的上市时间周期。
- 工作负载隔离 – 在大规模托管FMs中，需要最小化波及范围并处理有噪声的邻居的挑战。根据模型特定的流量模式扩展每个FM的能力需要付出艰苦努力。
- 扩展到数百个FMs – 同时运行数百个FMs会引入大量的运营开销。有效的端点管理、合适的分片和加速器分配以及模型特定的扩展是随着部署更多模型而复杂化的任务。
适应度函数
选择正确的托管选项很重要，因为它会影响您的应用程序呈现给最终用户的方式。为此，我们借鉴了“适应性函数”的概念，Neal Ford和他在AWS合作伙伴Thought Works的同事们在他们的作品Building Evolutionary Architectures中提出了这一概念。适应度函数基于您的目标，提供了对各种托管选项的评估。适应度函数帮助您获取必要的数据，以允许计划中的架构演进。它们设定可测量的值，以评估您的解决方案与实现您设定的目标的接近程度。适应度函数可以和应该根据架构演变进行调整，以指导所需的变更过程。这为架构师提供了一种在保持团队自治的同时指导其团队的工具。
在选择合适的FM推断选项时，我们建议考虑以下适应性函数，以实现规模化和成本效益：
- FM模型大小 – FM基于transformers。由于模型的庞大尺寸，transformers在生成长文本序列时速度较慢且占用大量内存。大型语言模型（LLMs）是FM的一种类型，在生成文本序列时需要巨大的计算力，并且难以访问可用的高带宽内存（HBM）和计算容量。这是因为大部分可用内存带宽被加载模型的参数和自回归解码过程所消耗。因此，即使有大量计算能力，FM仍受限于内存I/O和计算限制。因此，模型大小决定了很多决策，例如模型是否适合单个加速器或需要使用模型分片在实例上运行推断以实现更高吞吐量。具有超过30亿参数的模型通常会开始需要多个ML加速器，因为模型可能无法适应单个加速器设备。
- 性能和FM推断延迟 – 许多ML模型和应用对延迟非常敏感，推断延迟必须在服务级目标指定的范围内。FM推断延迟取决于多种因素，包括：
- FM模型大小 – 包括运行时量化。
- 硬件 – 计算能力（TFLOPS）、HBM大小和带宽、网络带宽、实例内部连接速度和存储带宽。
- 软件环境 – 模型服务器、模型并行库、模型优化引擎、集合通信性能、模型网络架构、量化和ML框架。
- 提示 – 输入和输出长度以及超参数。
- 扩展延迟 – 响应流量的扩展时间。
- 冷启动延迟 – 预热模型加载等功能可以减少加载FM所需的冷启动延迟。
- 工作负载隔离 – 这涉及到从监管和合规角度保护工作负载隔离的要求，包括保护AI模型和算法的机密性和完整性，AI推断期间数据的机密性，以及保护未经授权访问或从风险管理角度保护AI知识产权（IP）。例如，可以通过有意减少爆炸半径或防止嘈杂邻居来减小安全事件的影响。
- 成本效益 – 在可扩展框架上部署和维护FM模型和ML应用程序是一个关键的业务过程，成本可能因对模型托管基础架构、托管选项、ML框架、ML模型特性、优化、扩展策略等选择的不同而变化很大。工作负载必须最大限度地利用硬件基础设施，以确保成本控制在合理范围内。此适应性函数特指基础架构成本，它是总体拥有成本（TCO）的一部分。基础架构成本包括存储、网络和计算的综合成本。还要了解TCO的其他组成部分，包括运营成本和安全合规成本。运营成本是根据每种情况所需的工程师数量和工程师的年薪在特定时期内汇总计算的。当没有流量时，它们自动缩减到每个模型的零以节省成本。
- 可扩展性 – 包括：
- 在多租户平台中管理数百个FM的运营开销。
- 能够将多个FM打包到单个端点并针对每个模型进行扩展。
- 根据工作负载模式，支持实例级别和模型容器级别的扩展。
- 支持每个端点扩展到数百个FM。
- 支持将模型初始放置在群集中并处理加速器不足。
在适应性函数中表示维度
我们使用蜘蛛图，有时也称为雷达图，来表示适应性函数中的维度。蜘蛛图通常用于在多个独特维度上显示数据。这些维度通常是定量的，并且通常从零到最大值。每个维度的范围归一化，以便在绘制蜘蛛图时，从零到维度的最大值的线的长度在每个维度上都相同。
下图展示了在选择SageMaker上的架构时所涉及的决策过程。蜘蛛图上的每个半径都代表您在构建推断解决方案时要优先考虑的适应性函数之一。
理想情况下，您希望所有边都是等边形（一个五边形）。这表明您能够在所有适应性函数上进行优化。但现实情况是，要实现这种形状将是具有挑战性的——当您优先考虑一个适应性函数时，它将影响其他半径的线条。这意味着根据您对每个函数的看法，总会存在权衡。在我们的图表中，每个适应性函数的度量权重都定义为如下方式——值越低，对于该适应性函数来说越不理想（除了模型大小，在这种情况下，值越高，模型的大小就越大）。
例如，让我们以一个使用大型摘要模型（如Anthropic Claude）根据案例数据和客户历史创建工作摘要的用例为例。我们有以下蜘蛛图。
由于这可能涉及敏感的客户数据，您选择将此工作负载与其他模型隔离，并将其托管在一个单模型端点上，这可能会增加扩展的难度，因为您必须针对每个FM启动和管理单独的端点。您正在实时地将用于该模型的生成型AI应用程序用于服务代理，因此延迟和吞吐量是优先考虑的，因此需要使用更大的实例类型，如P4De。在这种情况下，成本可能会更高，因为优先考虑的是隔离、延迟和吞吐量。
另一个用例是一个为大量客户定制的问答聊天机器人应用程序的服务组织。以下蜘蛛图反映了他们的优先事项。
每个聊天机器人体验可能需要根据每个特定客户进行定制。使用的模型可能相对较小（FLAN-T5-XXL，Llama 7B和k-NN），每个聊天机器人每天在不同时区都有指定的工作时间。该解决方案还可能将检索增强生成（RAG）与包含所有知识库项目的数据库集成，以便在实时推理中使用。此聊天机器人不会交换任何特定于客户的数据。冷启动延迟是可以容忍的，因为聊天机器人会按照定义的时间表运行。对于这种用例，您可以选择使用多模型端点架构，并且可以通过在每个端点上托管多个模型来以规模化方式减少较小实例类型（如G5）的成本，并潜在地减少运营开销。除了工作负载隔离外，此用例中的适应性函数可能具有更均衡的优先级，且权衡被最小化到一定程度。
最后一个例子是使用Stable Diffusion 2.0这样的图像生成应用程序，该模型拥有35亿个参数。我们的蜘蛛图如下。
这是一个面向数千个FM和客户的订阅式应用程序。响应时间需要快，因为每个客户都希望图像输出快速完成。吞吐量同样至关重要，因为每秒将有数十万个请求，所以实例类型必须是更大的实例类型，如具有足够GPU和内存的P4D。对于这种情况，您可以考虑构建一个多容器端点，托管多个模型的副本，以便从一个请求集到另一个请求集去噪图像生成。对于这种用例，为了优先考虑延迟和吞吐量以及满足用户需求，计算成本和工作负载隔离将是权衡的。
选择FM主机选项时应用健身函数
在本节中，我们将展示如何在规模化的SageMaker FMs中应用上述健身函数来选择合适的FM主机选项。
SageMaker单模型端点
SageMaker单模型端点允许您在托管在专用实例上的容器上托管一个FM，以实现低延迟和高吞吐量。这些端点是完全托管的，并支持自动扩展。您可以将单模型端点配置为预配置端点，其中包括传递端点基础架构配置（例如实例类型和计数），SageMaker会自动启动计算资源，并根据自动扩展策略进行伸缩。您可以使用多个单模型端点来扩展至托管数百个模型，并采用基于单元的架构以增加弹性和降低爆炸半径。
在评估预配置单模型端点的适应性函数时，请考虑以下因素：
– 基础模型大小 – 如果您的模型无法适应单个ML加速器的内存，因此需要在一个实例中使用多个加速器，则此选项适合您。
– 性能和FM推断延迟 – 这在对延迟关键的生成式AI应用中很重要。
– 工作负载隔离 – 由于安全合规的原因，您的应用可能需要Amazon Elastic Compute Cloud（Amazon EC2）实例级别的隔离。每个FM将获得单独的推断端点，并且不会与其他模型共享EC2实例。例如，您可以使用专用安全组配置和网络隔离将与HIPAA相关的模型推断工作负载（例如PHI检测模型）隔离在一个单独的端点中。您可以基于基于Nitro的p4dn等EC2实例将基于GPU的模型推断工作负载与其他工作负载进行隔离，以将其与不受信任的工作负载隔离开来。基于Nitro系统的EC2实例提供了一种独特的虚拟化和隔离方法，使您能够始终从AWS操作员和软件中保护和隔离敏感数据处理。它提供了最重要的保护维度，作为一套系统软件和云操作员的默认设置，提供了保密计算的核心能力。该选项还支持在SageMaker上部署第三方模型提供商提供的AWS Marketplace模型。
SageMaker多模型端点
SageMaker多模型端点（MMEs）允许您在GPU核心上合并多个模型，跨多个模型共享GPU实例，并根据传入的流量动态加载和卸载模型。通过这种方式，您可以在成本和性能之间达到显著的节省。
如果您需要托管可全部适应单个ML加速器的较小模型，那么MMEs是最佳选择。如果您拥有大量（最多数千个）大小类似（少于10亿个参数）的模型，可以通过在一个实例内的共享容器中提供服务并且不需要同时访问所有模型来考虑使用此策略。您可以加载需要使用的模型，然后卸载它以加载其他模型。
MMEs还适用于共同托管使用相同ML框架的模型，因为它们使用共享容器加载多个模型。因此，如果您的模型群中包含多个ML框架（如PyTorch和TensorFlow），则使用具有InferenceComponents的SageMaker端口是更好的选择。我们将在本文后面进一步讨论InferenceComponents。
最后，如果您的应用程序可以容忍偶尔出现的冷启动延迟惩罚，那么MMEs是适合的选择，因为不经常使用的模型可以被卸载以提供频繁调用的模型。如果您拥有一批不经常访问的模型，多模型端点可以高效地服务该流量并实现显著的成本节约。
在评估使用MMEs的时候，请考虑以下因素：
- 基础模型的尺寸 –你可能拥有适用于单个ML加速器HBM的模型，因此不需要多个加速器。
- 性能和FM推断延迟 –您可能有一些生成式人工智能应用程序，可以容忍在请求模型时的冷启动延迟。
- 工作负载隔离 –考虑让所有模型共享同一个容器。
- 可扩展性 –考虑以下内容：
- 您可以将多个模型打包到单个终端节点中，并根据模型和ML实例进行扩展。
- 您可以根据工作负载模式启用基于实例级的自动扩展。
- MME（模型托管环境）支持每个终端节点扩展到数千个模型。您无需维护每个模型的自动扩展和部署配置。
- 您可以在推断请求时使用热部署。
- 您可以根据推断请求动态加载模型，并在内存压力增加时卸载模型。
- 您可以与模型共享基础资源的时间。
- 成本效益 –通过动态加载和卸载模型，考虑在模型之间共享资源的时间，从而节省成本。
使用InferenceComponents的SageMaker推断终端节点
新的SageMaker推断终端节点与InferenceComponents提供了一种托管多个FM的可扩展方法，可以在单个终端节点中进行模型打包和模型扩展。它为您提供了细粒度的控制，以分配资源（加速器，内存，CPU），并在每个模型的基础上设置自动扩展策略，以获得可确保吞吐量和可预测性能，您可以单独管理计算的利用率。如果您有很多不同大小和流量模式的模型需要托管，并且这些模型的大小不能适合单个加速器的内存中，这是最佳选择。它还允许您实现零扩展以节省成本，但是您的应用程序的延迟要求必须足够灵活，以适应模型的冷启动时间。只要每个客户或FM的容器级隔离足够就可以在灵活利用您的计算资源方面给您提供最大的灵活性。有关使用InferenceComponents的新SageMaker终端节点更多详细信息，请参见详细的减少使用亚马逊SageMaker最新功能的模型部署成本平均为50%。
在确定何时使用具有InferenceComponents的终端节点时，请考虑以下内容：
- 基础模型的尺寸 –这适用于无法适应单个ML加速器内存的模型，因此需要多个加速器。
- 性能和FM推断延迟 –这适用于对延迟敏感的生成式人工智能应用程序。
- 工作负载隔离 –您可能有一些应用程序，其中容器级隔离足够。
- 可扩展性 –考虑以下内容：
- 您可以将多个FM打包到单个终端节点中，并按模型进行扩展。
- 您可以根据工作负载模式启用基于实例和模型容器的扩展。
- 此方法支持每个终端节点扩展到数百个FM。您无需为每个模型或容器配置自动扩展策略。
- 它支持在机群中初始化模型的位置，并处理加速器不足。
- 成本效益 –您可以根据各个模型的流量将各个模型缩减到零以节省成本。
在同一终端节点上打包多个FM：模型分组
在选择在SageMaker上使用什么推断架构策略时，取决于您的应用程序优先级和要求。一些SaaS提供商正在销售到受监管环境，这些环境对隔离要求严格他们需要有一种选择，使他们能够为其某些或所有FM提供专用模型部署的选项。但为了优化成本并取得规模经济，SaaS提供商还需要拥有多租户环境，在此环境中，他们在共享的一组SageMaker资源上托管多个FM。大多数组织可能会同时具有单模型终端节点和多模型或多容器终端节点，作为其SageMaker架构的一部分。
在构建此分布式推断环境时，您需要进行的关键任务之一是为每种类型的架构将模型进行分组，然后在您的SageMaker终端节点中进行设置。您需要进行关于工作负载隔离要求的第一个决策-您需要为需要在其专用终端节点中的FM进行隔离，无论是出于安全原因，减少冲击范围和噪音邻居风险，还是满足严格的延迟SLA要求。
第二，您需要确定FM是否适用于单个ML加速器或需要多个加速器，模型尺寸如何以及其流量模式是什么。相似大小的模型可以逻辑地通过在端点上共同托管多个模型进行分组，因为它们将成为由中央团队管理的单个业务应用程序的一部分。对于在同一端点上共同托管多个模型，需要进行分组以确定哪些模型可以位于单个实例、单个容器或多个容器中。
为MME分组模型
MME最适合较小的模型（参数少于10亿且适合单个加速器），它们的大小和调用延迟相似。模型大小的一些变化是可以接受的；例如，Zendesk的模型大小范围为10到50MB，这是可以接受的，但大小变化为10、50或100倍的模型不适合。较大的模型可能导致较多的加载和卸载较小的模型以适应足够的内存空间，这可能导致终端的延迟增加。较大模型的性能特征差异也可能不均匀地消耗像CPU这样的资源，这可能影响实例上的其他模型。
在MME上分组的模型需要具有错开的流量模式，以便可以在推理过程中共享计算资源。您的访问模式和推理延迟还需要允许一些冷启动时间，以在模型之间切换。
以下是为MME分组模型的一些推荐标准：
- 较小的模型 – 使用少于10亿个参数的模型
- 模型大小 – 分组相似大小的模型，并共同托管在同一端点上
- 调用延迟 – 分组具有相似调用延迟要求并且可以容忍冷启动的模型
- 硬件 – 使用相同的底层EC2实例类型来分组模型
为带有InferenceComponents的端点分组模型
在EC2实例上以规模部署较大的FM模型（超过10亿个参数）并需要多个ML加速器或设备的情况下，SageMaker端点配备InferenceComponents是最适合的选择。此选项适用于对延迟敏感的工作负载和需要容器级别隔离的应用程序。以下是为具有多个InferenceComponents的端点分组模型的一些推荐标准：
- 硬件 – 使用相同的底层EC2实例类型来分组模型
- 模型大小 – 基于模型大小进行分组是推荐的，但不强制要求
总结
在本文中，我们讨论了SageMaker中三种实时ML推断选项（单个端点、多模型端点和带有InferenceComponents的端点），以便在规模上高效地、具有成本效益地托管FM。您可以使用五个适应性函数来帮助您选择适合规模FM的正确SageMaker托管选项。使用推荐的分组标准将FM分组并在SageMaker推断端点上共同托管它们。除了我们讨论的适应性函数外，您还可以使用以下表格来决定哪个共享的SageMaker托管选项最适合您的用例。您可以在以下GitHub存储库中找到每个FM托管选项的代码示例：单个SageMaker端点，多模型端点和InferenceComponents端点。
| . | 单个模型端点 | 多模型端点 | 带有InferenceComponents的端点 |
| 模型生命周期 | 管理API | 通过Amazon S3路径动态处理 | 管理API |
| 支持的实例类型 | CPU、单个和多个GPU、基于AWS Inferentia的实例 | CPU、基于单个GPU的实例 | CPU、单个和多个GPU、基于AWS Inferentia的实例 |
| 度量粒度 | 端点 | 端点 | 端点和容器 |
| 扩展粒度 | ML实例 | ML实例 | 容器 |
| 扩展行为 | 独立的ML实例扩展 | 模型从内存中加载和卸载 | 独立的容器扩展 |
| 模型固定 | . | 可以根据内存卸载模型 | 每个容器可以配置为始终加载或卸载 |
| 容器要求 | SageMaker预构建、与SageMaker兼容的自定义容器（BYOC） | MMS、Triton、具有MME合同的BYOC | SageMaker预构建、与SageMaker兼容的BYOC |
| 路由选项 | 随机或最小连接 | 随机、带有流行度窗口的粘性连接 | 随机或最小连接 |
| 模型的硬件分配 | 专用于单个模型 | 共享 | 每个容器专用 |
| 支持的模型数量 | 单个 | 数千个 | 数百个 |
| 响应流式传输 | 支持 | 不支持 | 支持 |
| 数据捕获 |