机器学习 (ML) 应用程序部署起来很复杂,通常需要超大规模的能力,并且具有超低延迟要求和严格的成本预算。 欺诈检测、产品推荐和流量预测等用例是毫秒很重要并且对业务成功至关重要的示例。 需要满足严格的服务水平协议(SLA),一个典型的请求可能需要预处理、数据转换、特征工程、模型选择逻辑、模型聚合和后处理等多个步骤。
以优化的成本和计算效率大规模部署 ML 模型可能是一项艰巨而繁琐的任务。 基于外部数据源以及运行时环境(例如底层计算资源的 CPU/GPU 能力),每个模型都有自己的优点和依赖性。 一个应用程序可能需要多个 ML 模型来服务于单个推理请求。 在某些情况下,一个请求可能会流经多个模型。 没有放之四海而皆准的方法,对于机器学习从业者来说,寻找久经考验的方法来解决反复出现的机器学习托管挑战非常重要。 这导致了 ML 模型托管设计模式的发展。
在这篇文章中,我们探索了构建 ML 应用程序的常见设计模式 亚马逊SageMaker.
用于构建 ML 应用程序的设计模式
让我们看看以下用于托管 ML 应用程序的设计模式。
基于单模型的 ML 应用程序
当您的 ML 用例需要单个模型来处理请求时,这是一个很好的选择。 该模型部署在专用计算基础设施上,能够根据输入流量进行扩展。 当客户端应用程序具有低延迟(以毫秒或秒为单位)推理要求时,此选项也是理想选择。
基于多模型的 ML 应用程序
为了使托管更具成本效益,此设计模式允许您在同一租户基础设施上托管多个模型。 多个 ML 模型可以共享主机或容器资源,包括将最常用的 ML 模型缓存在内存中,从而更好地利用内存和计算资源。 根据您选择部署的模型类型,模型共同托管可能使用以下方法:
- 多模型托管 – 此选项允许您在单个端点上使用共享服务容器托管多个模型。 当您有大量可通过共享服务容器提供服务且不需要同时访问所有模型的相似模型时,此功能非常理想。
- 多容器托管 – 当您有多个模型在具有相似资源需求的不同服务堆栈上运行时,并且当各个模型没有足够的流量来利用端点实例的全部容量时,此选项是理想的选择。 多容器托管允许您在单个端点上部署使用不同模型或框架的多个容器。 这些模型可以是完全异构的,具有自己独立的服务堆栈。
- 模型合奏 – 在许多生产用例中,通常会有许多上游模型将输入提供给给定的下游模型。 这是合奏有用的地方。 集成模式涉及混合来自一个或多个基本模型的输出,以减少 泛化误差 的预测。 基础模型可以是多种多样的,并由不同的算法训练。 模型集成可以胜过单个模型,因为使用集成方法时模型的预测误差会降低。
以下是集成模式的常见用例及其对应的设计模式图:
- 分散聚集 – 在分散-聚集模式中,推理请求被路由到多个模型。 然后使用聚合器收集响应并将它们提炼成单个推理响应。 例如,图像分类用例可能使用三种不同的模型来执行任务。 分散-聚集模式允许您组合在三个不同模型上运行的推理结果,并选择最可能的分类模型。
- 模型聚合 – 在聚合模式中,多个模型的输出被平均。 对于分类模型,评估多个模型的预测以确定获得最多选票的类别,并将其视为集成的最终输出。 例如,在将一组水果分类为橙子或苹果的二分类问题中,如果两个模型投票给橙子,一个模型投票给苹果,则聚合输出将是橙子。 聚合有助于消除单个模型中的不准确性,并使输出更加准确。
- 动态选择 – 集成模型的另一种模式是为给定的输入属性动态执行模型选择。 例如,在给定的水果图像输入中,如果输入包含橙子,则将使用模型 A,因为它专用于橙子。 如果输入包含苹果,则将使用模型 B,因为它专用于苹果。
- 串行推理 ML 应用程序 – 使用串行推理模式(也称为推理管道),用例需要在调用预训练的 ML 模型以生成推理之前预处理传入数据。 此外,在某些情况下,生成的推论可能需要进一步处理,以便下游应用程序可以轻松使用它们。 推理管道允许您重复使用模型训练期间使用的相同预处理代码来处理用于预测的推理请求数据。
- 商业逻辑 – 生产化 ML 总是涉及业务逻辑。 业务逻辑模式涉及执行不是 ML 模型推理的 ML 任务所需的一切。 这包括从加载模型 亚马逊简单存储服务 (Amazon S3),例如,数据库查找以验证输入,从特征存储中获取预先计算的特征,等等。 这些业务逻辑步骤完成后,输入将传递给 ML 模型。
机器学习推理选项
对于模型部署,重要的是从您的用例向后工作。 预测的频率是多少? 您是否期望应用程序的实时流量和对客户的实时响应? 您是否针对同一用例的不同数据子集训练了许多模型? 预测流量是否波动? 推理延迟是一个问题吗? 基于这些细节,可以使用以下部署选项来实现上述所有设计模式:
- 实时推断 – 实时推理非常适合您具有实时、交互式、低延迟要求的推理工作负载。 实时 ML 推理工作负载可能包括基于单模型的 ML 应用程序,其中应用程序只需要一个 ML 模型来服务单个请求,或基于多模型的 ML 应用程序,其中应用程序需要多个 ML 模型来服务单个请求要求。
- 近实时(异步)推理 – 通过近乎实时的推理,您可以对传入的请求进行排队。 这可用于对数百 MB 的输入进行推理。 它近乎实时地运行,允许用户使用输入进行推理,并从 S3 存储桶的端点读取输出。 在 NLP 和计算机视觉的情况下,它尤其方便,其中有大量有效负载需要更长的预处理时间。
- 批量推断 – 批量推理可用于在大型数据集上离线运行推理。 因为它是离线运行的,所以批量推理不会提供最低的延迟。 在这里,推理请求是通过批量推理作业的计划触发器或基于事件的触发器来处理的。
- 无服务器推理 – 无服务器推理非常适合在流量突增之间有空闲期的工作负载,并且可以容忍空闲期后首次调用的额外几秒延迟(冷启动)。 例如,用于处理表单或分析文档数据的聊天机器人服务或应用程序。 在这种情况下,您可能需要一个能够根据推理请求量自动配置和扩展计算容量的在线推理选项。 在空闲时间,它应该能够完全关闭计算能力,这样你就不会被收费。 无服务器推理通过自动启动计算资源并根据流量扩大和缩小它们,从而消除了选择和管理服务器的无差别繁重工作。
使用适应度函数选择正确的 ML 推理选项
确定正确的托管选项很重要,因为它会影响应用程序呈现的最终用户。 为此,我们借用了 适应度函数,这是由 Neal Ford 和他来自 AWS 合作伙伴 ThoughtWorks 的同事在他们的工作中创造的 构建进化架构. 适合度函数根据客户的目标对各种托管选项进行规范性评估。 适应度函数可帮助您获取必要的数据,以实现架构的计划演化。 他们设定可衡量的价值来评估您的解决方案与实现既定目标的接近程度。 适应度函数可以而且应该随着体系结构的发展而调整,以指导所需的变化过程。 这为架构师提供了一种工具来指导他们的团队,同时保持团队自主权。
在选择正确的 ML 推理选项来托管他们的 ML 模型和应用程序时,客户关心五个主要的适应度函数。
健身功能 | 课程描述 |
价格 |
在可扩展框架上部署和维护 ML 模型和 ML 应用程序是一个关键的业务流程,成本可能会因模型托管基础设施、托管选项、ML 框架、ML 模型特征、优化、扩展策略等方面的选择而有很大差异,和更多。 工作负载必须以最佳方式利用硬件基础设施,以确保成本保持在可控范围内。 该适应度函数特指基础设施成本,它是整体总拥有成本 (TCO) 的一部分。 基础设施成本是存储、网络和计算的综合成本。 了解 TCO 的其他组成部分也很重要,包括运营成本以及安全和合规成本。 运营成本是运营、监控和维护 ML 基础设施的综合成本。 运营成本是根据每个场景所需的工程师数量和工程师的年薪在特定时期内汇总计算得出的。 使用自我管理 ML 解决方案的客户 亚马逊弹性计算云 (亚马逊EC2), 亚马逊弹性容器服务 (亚马逊 ECS),以及 Amazon Elastic Kubernetes服务 (Amazon EKS) 需要自己构建操作工具。 使用 SageMaker 的客户产生的 TCO 显着减少。 SageMaker 推理是一项完全托管的服务,提供开箱即用的功能来部署用于推理的 ML 模型。 您无需配置实例、监控实例运行状况、管理安全更新或补丁、发布操作指标或为您的 ML 推理工作负载构建监控。 它具有确保高可用性和弹性的内置功能。 SageMaker 通过静态和传输中的端到端加密支持安全性,包括根卷加密和 Amazon Elastic Block商店 (亚马逊 EBS)数量, 亚马逊虚拟私有云 (亚马逊 VPC)支持, AWS私有链接, 客户管理的密钥, AWS身份和访问管理 (IAM) 细粒度访问控制, AWS 云跟踪 审计、用于训练的节点间加密、基于标签的访问控制、网络隔离和交互式应用程序代理。 SageMaker 中提供了所有这些开箱即用的安全功能,并且可以在 3 年的时间内为企业节省数十个月的开发工程工作。 SageMaker 是一项符合 HIPAA 资格的服务,并通过了 PCI、SOC、GDPR 和 ISO 认证。 SageMaker 还支持 FIPS 端点。 有关 TCO 的更多信息,请参阅 Amazon SageMaker 的总拥有成本. |
推理延迟 | 许多 ML 模型和应用程序对延迟至关重要,其中推理延迟必须在服务级别目标指定的范围内。 推理延迟取决于多种因素,包括模型大小和复杂性、硬件平台、软件环境和网络架构。 例如,更大、更复杂的模型可能需要更长的时间来运行推理。 |
吞吐量(每秒事务数) | 对于模型推理,优化吞吐量对于性能调整和实现 ML 应用程序的业务目标至关重要。 随着我们在 ML 的各个方面继续快速发展,包括芯片设计中数学运算的低级实现,特定于硬件的库在性能优化方面发挥着更大的作用。 负载大小、网络跃点、跃点性质、模型图特征、模型中的运算符以及模型托管实例的 CPU、GPU 和内存配置文件等各种因素都会影响 ML 模型的吞吐量。 |
缩放配置复杂性 | 对于 ML 模型或应用程序而言,在可处理不同流量需求的可扩展框架上运行至关重要。 它还允许最大限度地利用 CPU 和 GPU 资源,并防止计算资源的过度配置。 |
预期流量模式 | ML 模型或应用程序可以有不同的流量模式,从连续的实时实时流量到每秒数千个请求的周期性峰值,从不频繁、不可预测的请求模式到对更大数据集的离线批量请求。 建议从预期的流量模式向后工作,以便为您的 ML 模型选择正确的托管选项。 |
使用 SageMaker 部署模型
SageMaker 是一项完全托管的 AWS 服务,可为每位开发人员和数据科学家提供大规模快速构建、训练和部署 ML 模型的能力。 借助 SageMaker 推理,您可以在托管端点上部署 ML 模型并获得推理结果。 SageMaker 提供了广泛的硬件和功能选择来满足您的工作负载要求,让您可以选择 70 多种具有硬件加速功能的实例类型。 SageMaker 还可以使用名为 SageMaker Inference Recommender 的新功能提供推理实例类型推荐,以防您不确定哪个最适合您的工作负载。
您可以选择最适合您的用例的部署选项,例如实时推理、异步、批处理甚至无服务器端点。 此外,SageMaker 提供了多种部署策略,例如金丝雀、 蓝绿色, 阴影和用于模型部署的 A/B 测试,以及具有成本效益的多模型、多容器端点和弹性扩展部署。 借助 SageMaker 推理,您可以在 亚马逊CloudWatch, 自动缩放端点 基于流量,并在不损失任何可用性的情况下更新生产中的模型。
SageMaker 提供四个选项来部署您的模型,以便您可以开始进行预测:
- 实时推断 – 这适用于具有毫秒延迟要求、负载大小高达 6 MB 和处理时间长达 60 秒的工作负载。
- 批量转换 – 这非常适合对预先可用的大批量数据进行离线预测。
- 异步推理 – 这是为没有亚秒级延迟要求、负载大小高达 1 GB 和处理时间长达 15 分钟的工作负载而设计的。
- 无服务器推理 – 借助无服务器推理,您可以快速部署 ML 模型进行推理,而无需配置或管理底层基础设施。 此外,您只需为用于处理推理请求的计算容量付费,这非常适合间歇性工作负载。
下图可以帮助您了解 SageMaker 托管模型部署选项以及相关的适应度函数评估。
让我们更详细地探讨每个部署选项。
SageMaker 中的实时推理
如果您有持续的流量并且需要较低且一致的请求延迟(负载大小高达 6 MB,处理时间高达 60 秒),则建议使用 SageMaker 实时推理。 您将模型部署到 SageMaker 托管服务并获得可用于推理的端点。 这些端点是完全托管的并支持自动缩放。 实时推理在您期望具有可预测流量模式的低延迟同步响应的用例中很受欢迎,例如产品和服务的个性化推荐或交易欺诈检测用例。
通常,客户端应用程序将请求发送到 SageMaker HTTPS 端点,以从已部署的模型中获取推理。 您可以将一个模型的多个变体部署到同一个 SageMaker HTTPS 终端节点。 这对于测试生产中模型的变体很有用。 Auto Scaling 允许您动态调整为模型预置的实例数量,以响应工作负载的变化。
下表提供了有关基于适应度函数评估 SageMaker 实时推理的指南。
健身功能 | 课程描述 |
价格 |
实时端点提供对推理请求的同步响应。 由于端点始终处于运行状态并可提供实时同步推理响应,因此您需要为使用实例付费。 当您部署多个端点时,成本会迅速增加,尤其是在端点未充分利用底层实例的情况下。 为您的模型选择正确的实例有助于确保您以最低的成本为您的模型提供最高性能的实例。 建议使用 Auto Scaling 来根据流量动态调整容量,以尽可能低的成本保持稳定和可预测的性能。 SageMaker 扩展了对基于 Graviton2 和 Graviton3 的 ML 实例系列的访问。 AWS 引力子 处理器由 Amazon Web Services 使用 64 位 Arm Neoverse 内核定制构建,可为在 Amazon EC2 上运行的云工作负载提供最佳性价比。 使用基于 Graviton 的实例,在 SageMaker 上部署 ML 模型时,您有更多选项来优化成本和性能。 SageMaker 还支持 Inf1实例,提供高性能且具有成本效益的 ML 推理。 1–16 AWS Inferentia 芯片 对于每个实例,与基于 AWS GPU 的实例相比,Inf1 实例可以扩展性能并提供高达三倍的吞吐量和高达 50% 的推理成本。 要在 SageMaker 中使用 Inf1 实例,您可以使用 亚马逊SageMaker Neo 并选择 Inf1 实例以在 SageMaker 上部署编译后的模型。 您也可以探索 SageMaker 的储蓄计划 与按需价格相比,可节省高达 64% 的成本。 当您创建终端节点时,SageMaker 会将 EBS 存储卷附加到托管终端节点的每个 ML 计算实例。 存储卷的大小取决于实例类型。 实时端点的额外成本包括每月 GB 的预置存储成本,加上在端点实例中处理的 GB 数据和从端点实例中处理的 GB 数据。 |
推理延迟 | 当您需要具有毫秒延迟要求的持久端点时,实时推理是理想的选择。 它支持最大 6 MB 的负载大小和最长 60 秒的处理时间。 |
生产能力 |
推理吞吐量的理想值受模型、模型输入大小、批量大小和端点实例类型等因素的影响。 作为最佳实践,查看输入请求和资源利用率的 CloudWatch 指标,并选择适当的实例类型以实现最佳吞吐量。 业务应用程序可以是吞吐量优化的或延迟优化的。 例如,动态批处理可以帮助使用实时推理提高对延迟敏感的应用程序的吞吐量。 但是,批量大小有限制,否则推理延迟可能会受到影响。 随着您增加批处理大小以提高吞吐量,推理延迟会增加。 因此,实时推理是对延迟敏感的应用程序的理想选择。 SageMaker 提供异步推理和批量转换选项,如果业务应用程序可以容忍稍高的延迟,则这些选项经过优化可提供比实时推理更高的吞吐量。 |
缩放配置复杂性 |
SageMaker 实时端点支持 自动缩放 盒子外面。 当工作负载增加时,自动缩放会使更多实例联机。 当工作负载减少时,Auto Scaling 会删除不必要的实例,帮助您降低计算成本。 如果没有自动缩放,您需要为峰值流量或风险模型不可用性进行配置。 除非你的模型的流量全天稳定,否则就会有多余的未使用容量。 这导致利用率低和资源浪费。 借助 SageMaker,您可以根据预期的流量模式配置不同的扩展选项。 当您想要根据特定的 CloudWatch 指标进行扩展时,简单扩展或目标跟踪扩展是理想的选择。 您可以通过选择特定指标并设置阈值来做到这一点。 此选项的推荐指标是平均值 如果您需要高级配置,您可以设置一个步长扩展策略,根据警报违规的大小动态调整要扩展的实例数。 这有助于您在需求达到特定水平时配置更积极的响应。 当您知道需求在一天、一周、一个月或一年中遵循特定计划时,您可以使用计划扩展选项。 这有助于您指定一次性计划或重复计划或 cron 表达式以及开始和结束时间,它们构成了自动缩放操作开始和停止时间的边界。 有关更多详细信息,请参阅 在 Amazon SageMaker 中配置自动缩放推理终端节点 和 使用自动扩展对 Amazon SageMaker 终端节点进行负载测试和优化. |
交通格局 | 实时推理非常适合具有连续或常规流量模式的工作负载。 |
SageMaker 中的异步推理
SageMaker 异步推理是 SageMaker 中的一项新功能,可以对传入请求进行排队并异步处理它们。 此选项非常适合具有大负载大小(高达 1 GB)、处理时间长(长达 15 分钟)和近实时延迟要求的请求。 异步推理的示例工作负载包括医疗保健公司处理高分辨率生物医学图像或视频(如超声心动图)以检测异常。 这些应用程序在一天中的不同时间接收突发的传入流量,需要以低成本进行近乎实时的处理。 这些请求的处理时间可以在几分钟内,无需运行实时推理。 相反,可以使用自动排队和预定义的并发阈值从对象存储(如 Amazon S3)异步处理输入有效负载。 处理后,SageMaker 将推理响应放置在之前返回的 Amazon S3 位置。 您可以选择通过以下方式接收成功或错误通知 亚马逊简单通知服务 (亚马逊 SNS)。
下表提供了有关基于适应度函数评估 SageMaker 异步推理的指南。
健身功能 | 课程描述 |
价格 | 异步推理是具有大负载和突发流量的成本敏感型工作负载的绝佳选择。 异步推理使您能够通过在没有请求要处理时将实例计数自动缩放为零来节省成本,因此您只需在端点处理请求时付费。 实例数为零时收到的请求在端点扩展后排队等待处理。 |
推理延迟 | 异步推理非常适合近实时延迟要求。 请求被放入队列中,并在计算可用时立即处理。 这通常会导致数十毫秒的延迟。 |
生产能力 | 异步推理是非延迟敏感用例的理想选择,因为应用程序不必在吞吐量上做出妥协。 在流量高峰期间不会丢弃请求,因为异步推理端点将请求排队而不是丢弃它们。 |
缩放配置复杂性 |
SageMaker 支持 自动缩放 对于异步端点。 与实时托管端点不同,异步推理端点支持通过将最小容量设置为零来将实例缩减为零。 对于异步端点,SageMaker 强烈建议您为已部署模型(变体)的目标跟踪扩展创建策略配置。 对于可以容忍几分钟的冷启动惩罚的用例,您可以选择在没有未完成的请求时将端点实例计数缩减至零,并在新请求到达时缩减,这样您只需为端点正在积极处理请求。 |
交通格局 | 异步端点对传入请求进行排队并异步处理它们。 对于间歇性或不频繁的流量模式,它们是一个不错的选择。 |
SageMaker 中的批量推理
SageMaker 批量转换非常适合对预先可用的大批量数据进行离线预测。 批量转换特征是一种用于转换数据和生成推理的高性能和高吞吐量方法。 它非常适合处理大批量数据、不需要亚秒级延迟或需要预处理和转换训练数据的场景。 广告和营销或医疗保健等特定领域的客户通常需要对超大规模数据集进行离线预测,其中高吞吐量通常是用例的目标,而延迟不是问题。
当批量转换作业开始时,SageMaker 会初始化计算实例并在它们之间分配推理工作负载。 它会在作业完成时释放资源,因此您只需为作业运行期间使用的资源付费。 作业完成后,SageMaker 将预测结果保存在您指定的 S3 存储桶中。 批量推理任务通常是水平缩放的良好候选者。 集群中的每个工作人员都可以对不同的数据子集进行操作,而无需与其他工作人员交换信息。 AWS 提供多种支持水平扩展的存储和计算选项。 SageMaker 批量转换的示例工作负载包括离线应用程序,例如用于预测客户流失的银行应用程序,其中可以安排离线作业定期运行。
下表提供了有关根据适应度函数评估 SageMaker 批量转换的指南。
健身功能 | 课程描述 |
价格 | SageMaker 批量转换允许您对大型或小型批量数据集运行预测。 根据使用时长,您需要为所选的实例类型付费。 SageMaker 在作业开始时管理资源配置,并在作业完成时释放它们。 没有额外的数据处理成本。 |
推理延迟 | 您可以使用基于事件或计划的调用。 延迟可能因推理数据的大小、作业并发性、模型的复杂性和计算实例容量而异。 |
生产能力 |
批量转换作业可以在一系列数据集上完成,从 PB 级数据到非常小的数据集。 无需将较大的数据集调整为小数据块。 您可以通过使用参数的最佳值来加速批量转换作业,例如 最大有效负载(以MB为单位), 最大并发转换或 批量策略. 的理想值 批处理可以提高吞吐量并优化您的资源,因为它有助于在一定时间内以延迟为代价完成大量推理。 为了优化模型部署以获得更高的吞吐量,一般准则是增加批处理大小直到吞吐量下降。 |
缩放配置复杂性 | SageMaker 批量转换用于对延迟不敏感的离线推理。 |
交通格局 | 对于离线推理,使用基于事件的触发器安排或启动批量转换作业。 |
SageMaker 中的无服务器推理
SageMaker 无服务器推理允许您部署 ML 模型进行推理,而无需配置或管理底层基础设施。 根据您的模型收到的推理请求量,SageMaker 无服务器推理会自动配置、扩展和关闭计算容量。 因此,您只需为运行推理代码的计算时间和处理的数据量付费,而不是为空闲时间付费。 您可以使用 SageMaker 的内置算法和 ML 框架服务容器将您的模型部署到无服务器推理端点或选择自带容器。 如果流量变得可预测且稳定,您可以轻松地从无服务器推理端点更新到 SageMaker 实时端点,而无需更改容器映像。 借助无服务器推理,您还可以从其他 SageMaker 功能中受益,包括 CloudWatch 中的调用计数、故障、延迟、主机指标和错误等内置指标。
下表提供了有关根据适应度函数评估 SageMaker 无服务器推理的指南。
健身功能 | 课程描述 |
价格 | 使用按需付费模式,如果您的流量模式不频繁或断断续续,无服务器推理是一种经济高效的选择。 您只需为端点处理请求的持续时间付费,因此如果流量模式是间歇性的,则可以节省成本。 |
推理延迟 |
无服务器端点提供低推理延迟(毫秒到秒的数量级),能够根据使用模式在几秒内立即从数十个推理扩展到数千个推理,使其成为具有间歇性或不可预测流量的 ML 应用程序的理想选择。 由于无服务器端点按需提供计算资源,因此您的端点可能会在空闲期后的第一次调用中经历几秒的额外延迟(冷启动)。 冷启动时间取决于您的模型大小、下载模型所需的时间以及容器的启动时间。 |
生产能力 | 配置无服务器端点时,您可以指定内存大小和最大并发调用数。 SageMaker 无服务器推理会根据您选择的内存按比例自动分配计算资源。 如果您选择更大的内存大小,您的容器可以访问更多的 vCPU。 作为一般规则,内存大小应至少与模型大小一样大。 您可以选择的内存大小有 1024 MB、2048 MB、3072 MB、4096 MB、5120 MB 和 6144 MB。 无论您选择何种内存大小,无服务器端点都有 5 GB 的临时磁盘存储可用。 |
缩放配置复杂性 | 无服务器端点自动启动计算资源并根据流量扩展和扩展它们,无需选择实例类型或管理扩展策略。 这消除了选择和管理服务器的无差别繁重工作。 |
交通格局 | 无服务器推理非常适合具有不频繁或间歇性流量模式的工作负载。 |
SageMaker 中的模型托管设计模式
SageMaker 推理端点使用 Docker 容器来托管 ML 模型。 容器允许您将软件打包成标准化单元,这些单元可以在支持 Docker 的任何平台上一致运行。 这确保了跨平台的可移植性、不可变的基础架构部署以及更轻松的变更管理和 CI/CD 实施。 SageMaker 为 Apache MXNet、TensorFlow、PyTorch、Sklearn 和 Hugging Face 等流行框架提供预构建的托管容器。 有关可用 SageMaker 容器映像的完整列表,请参阅 可用的深度学习容器镜像. 如果 SageMaker 没有受支持的容器,您还可以构建自己的容器 (BYOC) 并推送您自己的自定义映像,安装您的模型所需的依赖项。
要在 SageMaker 上部署模型,您需要一个容器(SageMaker 托管框架容器或 BYOC)和一个用于托管容器的计算实例。 SageMaker 支持常见 ML 模型托管设计模式的多个高级选项,其中模型可以托管在单个容器上或共同托管在共享容器上。
实时 ML 应用程序可以使用单个模型或多个模型来为单个预测请求提供服务。 下图显示了 ML 应用程序的各种推理场景。
让我们为上述每个推理场景探索合适的 SageMaker 托管选项。 您可以参考适应度函数来评估它是否是给定用例的正确选择。
托管基于单一模型的 ML 应用程序
根据部署场景,有多种选项可以使用 SageMaker 托管服务来托管基于单模型的 ML 应用程序。
单模型端点
SageMaker 单模型端点允许您在专用实例上托管的容器上托管一个模型,以实现低延迟和高吞吐量。 这些端点是完全托管的并支持自动缩放。 您可以将单模型端点配置为预配置端点,您可以在其中传入端点基础设施配置(例如实例类型和计数),也可以将单模型端点配置为无服务器端点,在该端点中,SageMaker 会自动启动计算资源并根据流量扩大和缩小它们,从而消除了需要选择实例类型或管理扩展策略。 无服务器端点适用于具有间歇性或不可预测流量的应用程序。
下图显示了单模型端点推理场景。
下表提供了有关评估已配置单模型端点的适应度函数的指南。 对于无服务器端点适应度函数评估,请参阅本文中的无服务器端点部分。
健身功能 | 课程描述 |
价格 | 您需要为使用您选择的实例类型付费。 由于端点始终在运行且可用,因此成本会迅速增加。 为您的模型选择正确的实例有助于确保您以最低的成本为您的模型提供最高性能的实例。 建议使用 Auto Scaling 来根据流量动态调整容量,以尽可能低的成本保持稳定和可预测的性能。 |
推理延迟 | 单一模型端点提供具有毫秒级延迟要求的实时、交互式、同步推理。 |
生产能力 | 吞吐量会受到多种因素的影响,例如模型输入大小、批量大小、端点实例类型等。 建议查看输入请求和资源利用率的 CloudWatch 指标,并选择适当的实例类型以实现最佳吞吐量。 SageMaker 提供在部署 ML 模型时管理资源和优化推理性能的功能。 你可以 使用 Neo 优化模型性能,或使用 Inf1 实例为您的端点使用 GPU 实例来提高 SageMaker 托管模型的吞吐量。 |
缩放配置复杂性 | 开箱即用地支持自动缩放。 SageMaker 建议选择合适的 缩放配置 通过表演 负载测试. |
交通格局 | 单一模型端点非常适合具有可预测流量模式的工作负载。 |
共同主持多个模型
当您处理大量模型时,使用专用容器和实例将每个模型部署在单个端点上可能会导致成本显着增加。 此外,在生产中管理如此多的模型也变得困难,特别是当您不需要同时调用所有模型但仍需要它们始终可用时。 在相同的底层计算资源上共同托管多个模型,可以轻松地大规模管理 ML 部署,并通过增加端点及其底层计算资源的使用来降低托管成本。 SageMaker 支持高级模型共同托管选项,例如用于同质模型的多模型终端节点 (MME) 和用于异构模型的多容器终端节点 (MCE)。 同类模型在共享服务容器上使用相同的 ML 框架,而异构模型允许您在单个端点上部署使用不同模型或框架的多个服务容器。
下图显示了使用 SageMaker 的模型共同托管选项。
SageMaker 多模型端点
SageMaker 微机电系统 允许您在单个端点上使用共享服务容器托管多个模型。 这是一种可扩展且经济高效的解决方案,可部署大量模型以满足相同的用例、框架或推理逻辑。 MME 可以根据调用者调用的模型动态地为请求提供服务。 它还减少了部署开销,因为 SageMaker 管理内存中的加载模型并根据它们的流量模式扩展它们。 当您有大量可通过共享服务容器提供服务且不需要同时访问所有模型的相似模型时,此功能非常理想。 多模型端点还支持跨模型共享内存资源。 当模型在大小和调用延迟方面非常相似时,这种方法效果最好,允许 MME 有效地跨所有模型使用实例。 SageMaker MME 支持托管 CPU 和 GPU 支持的模型。 通过使用 GPU 支持的模型,您可以通过增加端点及其底层加速计算实例的使用来降低模型部署成本。 有关 MME 的真实世界用例,请参阅 如何为多租户 SaaS 用例扩展机器学习推理.
下表提供了评估 MME 适应度函数的指导。
健身功能 | 课程描述 |
价格 |
MME 支持使用共享服务容器在单个端点上托管数千个模型。 与使用单一模型端点相比,这通过提高端点利用率显着降低了托管成本。 例如,如果您有 10 个模型要使用 ml.c5.large 实例部署,基于 SageMaker 定价,拥有 10 个单一模型持久端点的成本为:10 * 0.102 USD = 1.02 USD/小时。 而通过一个 MME 托管 10 个模型,我们实现了 10 倍的成本节省:1 * 0.102 美元 = 0.102 美元/小时。 |
推理延迟 |
默认情况下,MME 在内存和磁盘中缓存常用模型以提供低延迟推理。 只有当容器用完内存或磁盘空间来容纳新的目标模型时,缓存的模型才会从磁盘中卸载或删除。 MME 允许延迟加载模型,这意味着模型在第一次调用时加载到内存中。 这优化了内存利用率; 但是,它会在首次加载时导致响应时间激增,从而导致冷启动问题。 因此,MME 也非常适合能够容忍在调用不常用模型时偶尔发生的与冷启动相关的延迟惩罚的场景。 为了满足 ML 应用程序的延迟和吞吐量目标,GPU 实例优先于 CPU 实例(考虑到 GPU 提供的计算能力)。 借助 MME 对 GPU 的支持,您可以在一个 SageMaker 端点后面部署数千个深度学习模型。 MME 可以在一个 GPU 核心上运行多个模型,在多个模型的端点后面共享 GPU 实例,并根据传入流量动态加载和卸载模型。 这样,您可以显着节省成本并获得最佳性价比。 如果您的用例需要显着更高的每秒事务处理 (TPS) 或延迟要求,我们建议在专用端点上托管模型。 |
生产能力 |
MME 推理吞吐量的理想值取决于模型、负载大小和端点实例类型等因素。 更多的实例内存使您能够加载更多模型并准备好为推理请求提供服务。 您无需浪费时间加载模型。 更高数量的 vCPU 使您能够同时调用更多独特的模型。 MME 动态地将模型加载到实例内存或从实例内存卸载模型,这可能会影响 I/O 性能。 带有 GPU 的 SageMaker MME 使用 NVIDIA Triton 推理服务器,这是一款开源推理服务软件,可简化推理服务流程并提供高推理性能。 SageMaker 将模型加载到 GPU 加速实例上的 NVIDIA Triton 容器内存中,并为推理请求提供服务。 GPU 核心由一个实例中的所有模型共享。 如果模型已加载到容器内存中,后续请求的服务速度会更快,因为 SageMaker 不需要再次下载和加载它。 建议在成功的生产部署中进行适当的性能测试和分析。 SageMaker 为多模型终端节点提供 CloudWatch 指标,因此您可以确定终端节点使用情况和缓存命中率,以帮助优化您的终端节点。 |
缩放配置复杂性 | SageMaker 多模型端点完全支持自动扩展,它管理模型的副本以确保模型根据流量模式进行扩展。 但是,建议进行适当的负载测试以确定用于自动缩放端点的实例的最佳大小。 调整 MME 车队的规模对于避免卸载太多模型非常重要。 在一些较大的实例上加载数百个模型在某些情况下可能会导致节流,并且可能首选使用更多和较小的实例。 要利用 SageMaker 中的自动模型缩放,请确保您拥有 实例自动缩放设置 提供额外的实例容量。 使用自定义参数或每分钟调用次数(推荐)设置端点级扩展策略,以向端点队列添加更多实例。 用于触发自动缩放事件的调用率基于端点所服务的整套模型中的聚合预测集。 |
交通格局 | 当您有大量相似大小的模型可以通过共享服务容器提供服务并且不需要同时访问所有模型时,MME 是理想的选择。 |
SageMaker 多容器端点
SageMaker MCE 支持在单个端点上部署多达 15 个使用不同模型或框架的容器,并独立或顺序调用它们以实现低延迟推理和成本节约。 这些模型可以是完全异构的,具有自己独立的服务堆栈。 在单个实例上安全地托管来自不同框架的多个模型可以为您节省高达 90% 的成本。
MCE调用模式如下:
- 推理管道 – MME 中的容器可以线性顺序调用,也称为 串行推理管道. 它们通常用于将预处理、模型推理和后处理分离到独立的容器中。 当前容器的输出作为输入传递给下一个容器。 它们在 SageMaker 中表示为单个管道模型。 推理管道可以部署为 MME,其中管道中的容器之一可以根据被调用的模型动态地为请求提供服务。
- 直接调用 –与 直接调用,可以将请求发送到托管在 MCE 上的特定推理容器。
下表提供了有关评估 MCE 适应度函数的指导。
健身功能 | 课程描述 |
价格 | MCE 使您能够在单个端点上运行多达 15 个不同的 ML 容器并独立调用它们,从而节省成本。 当您有多个模型在具有相似资源需求的不同服务堆栈上运行时,并且当各个模型没有足够的流量来利用端点实例的全部容量时,此选项是理想的选择。 因此,MCE 比单一模型端点更具成本效益。 MCE 提供同步推理响应,这意味着端点始终可用,您需要为实例的正常运行时间付费。 成本可能会增加,具体取决于实例的数量和类型。 |
推理延迟 | MCE 非常适合运行具有不同 ML 框架和算法的 ML 应用程序,适用于不经常访问但仍需要低延迟推理的每个模型。 这些模型始终可用于低延迟推理,并且不存在冷启动问题。 |
生产能力 | MCE 在多容器端点上限制为最多 15 个容器,并且由于资源争用不支持 GPU 推理。 对于使用直接调用模式的多容器端点,SageMaker 不仅像其他常见端点一样提供实例级指标,而且还支持每个容器的指标。 作为最佳实践,查看输入请求和资源利用率的 CloudWatch 指标,并选择适当的实例类型以实现最佳吞吐量。 |
缩放配置复杂性 | MCE 支持自动缩放。 但是,为了配置自动缩放,建议每个容器中的模型在每个推理请求上表现出相似的 CPU 利用率和延迟。 建议这样做,因为如果到多容器端点的流量从低 CPU 使用率模型转移到高 CPU 使用率模型,但整体调用量保持不变,则端点不会横向扩展,并且可能没有足够的实例处理对高 CPU 使用率模型的所有请求。 |
交通格局 | MCE 非常适合具有连续或常规流量模式的工作负载,适用于跨不同框架(例如 TensorFlow、PyTorch 或 Sklearn)托管模型,这些框架可能没有足够的流量来饱和端点实例的全部容量。 |
托管基于多模型的 ML 应用程序
许多业务应用程序需要使用多个 ML 模型来向其消费者提供单个预测请求。 例如,一家想要向其用户提供推荐的零售公司。 此用例中的 ML 应用程序可能希望使用不同的自定义模型来推荐不同类别的产品。 如果公司想通过使用个人用户信息为推荐添加个性化,定制模型的数量会进一步增加。 在不同的计算实例上托管每个自定义模型不仅成本高昂,而且如果不是所有模型都经常使用,还会导致托管资源利用不足。 SageMaker 为基于多模型的 ML 应用程序提供高效的托管选项。
下图显示了使用 SageMaker 的单个终端节点的多模型托管选项。
串行推理管道
推理管道是一种 SageMaker 模型,由 2-15 个容器的线性序列组成,这些容器处理数据推理请求。 您可以使用推理管道来定义和部署预训练的 SageMaker 内置算法和打包在 Docker 容器中的您自己的自定义算法的任意组合。 您可以使用推理管道组合预处理、预测和后处理数据科学任务。 一个容器的输出作为输入传递给下一个容器。 为管道模型定义容器时,您还可以指定容器的运行顺序。 它们在 SageMaker 中表示为单个管道模型。 推理管道可以部署为 MME,其中管道中的容器之一可以根据被调用的模型动态地为请求提供服务。 您还可以运行一个 批量转换 使用推理管道的工作。 推理管道是完全托管的。
下表提供了有关使用串行推理管道评估 ML 模型托管的适应度函数的指南。
健身功能 | 课程描述 |
价格 | 串行推理管道使您能够在单个端点上运行多达 15 个不同的 ML 容器,从而提高托管推理容器的成本效益。 使用此功能无需支付额外费用。 您只需为端点上运行的实例付费。 成本可能会增加,具体取决于实例的数量和类型。 |
推理延迟 | 当 ML 应用程序部署为推理管道时,不同模型之间的数据不会离开容器空间。 特征处理和推理以低延迟运行,因为容器位于相同的 EC2 实例上。 |
生产能力 | 在推理管道模型中,SageMaker 将调用处理为一系列 HTTP 请求。 管道中的第一个容器处理初始请求,然后将中间响应作为请求发送到第二个容器,依此类推,对于管道中的每个容器。 SageMaker 将最终响应返回给客户端。 吞吐量受模型、模型输入大小、批量大小和端点实例类型等因素的影响。 作为最佳实践,查看输入请求和资源利用率的 CloudWatch 指标,并选择适当的实例类型以实现最佳吞吐量。 |
缩放配置复杂性 | 串行推理管道支持自动缩放。 但是,为了配置自动缩放,建议每个容器中的模型在每个推理请求上表现出相似的 CPU 利用率和延迟。 建议这样做,因为如果到多容器端点的流量从低 CPU 利用率模型转移到高 CPU 利用率模型,但整体调用量保持不变,则端点不会横向扩展,并且可能没有足够的实例来处理对高 CPU 使用率模型的所有请求。 |
交通格局 |
串行推理管道非常适合可预测的流量模式,模型在同一端点上按顺序运行。 |
部署模型集成 (Triton DAG):
SageMaker 提供与 NVIDIA Triton 推理服务器 通过 Triton 推理服务器容器. 这些容器包括 NVIDIA Triton 推理服务器、对常见 ML 框架的支持以及可让您优化 SageMaker 性能的有用环境变量。 借助 NVIDIA Triton 容器映像,您可以轻松地为 ML 模型提供服务,并受益于 NVIDIA Triton 提供的性能优化、动态批处理和多框架支持。 Triton 有助于最大限度地提高 GPU 和 CPU 的利用率,进一步降低推理成本。
在 ML 应用程序使用多个模型来处理预测请求的业务用例中,如果每个模型使用不同的框架或托管在单独的实例上,则可能会导致工作量和成本增加以及整体延迟增加。 SageMaker NVIDIA Triton 推理服务器支持部署来自所有主要框架的模型,例如 TensorFlow GraphDef、TensorFlow SavedModel、ONNX、PyTorch TorchScript、TensorRT 和 Python/C++ 模型格式等。 Triton 模型集成表示一个或多个模型或预处理和后处理逻辑的管道,以及它们之间的输入和输出张量的连接。 对集成的单个推理请求会触发整个管道的运行。 Triton 还具有多个内置的调度和批处理算法,这些算法结合了各个推理请求以提高推理吞吐量。 这些调度和批处理决策对于请求推理的客户端是透明的。 这些模型可以在 CPU 或 GPU 上运行,以获得最大的灵活性并支持异构计算需求。
通过以下方式支持在多模型端点上托管多个 GPU 支持的模型 SageMaker Triton 推理服务器. NVIDIA Triton 推理服务器已扩展以实现 MME API 合约, 与 MME 集成。 您可以使用 NVIDIA Triton 推理服务器(它为不同的框架后端创建模型存储库配置)来部署具有自动缩放功能的 MME。 此功能允许您扩展数百个超个性化模型,这些模型经过微调以满足 AI 应用程序中独特的最终用户体验。 您还可以使用此功能为使用小数 GPU 的推理应用程序实现所需的性价比。 要了解更多信息,请参阅 使用 Amazon SageMaker 多模型终端节点在 GPU 上运行多个深度学习模型.
下表提供了有关在 Triton 推理容器上使用具有 GPU 支持的 MME 托管 ML 模型评估适应度函数的指南。 对于单模型端点和无服务器端点适应度函数评估,请参阅本文前面的部分。
健身功能 | 课程描述 |
价格 | 具有 GPU 支持的 SageMaker MME 使用 Triton 推理服务器提供了一种可扩展且经济高效的方式来在一个 SageMaker 端点后面部署大量深度学习模型。 使用 MME,多个模型共享端点后面的 GPU 实例。 这使您能够打破托管多个模型并在所有模型中重用基础设施的线性增加的成本。 您为实例的正常运行时间付费。 |
推理延迟 |
配备 Triton 推理服务器的 SageMaker 专为最大限度地提高吞吐量和硬件利用率而设计,具有超低(个位数毫秒)推理延迟。 它具有广泛的受支持 ML 框架(包括 TensorFlow、PyTorch、ONNX、XGBoost 和 NVIDIA TensorRT)和基础设施后端,包括 NVIDIA GPU、CPU 和 AWS 推理. 通过使用 SageMaker Triton 推理服务器的 MME 对 GPU 的支持,您可以在一个 SageMaker 端点后面部署数千个深度学习模型。 SageMaker 将模型加载到 GPU 加速实例上的 NVIDIA Triton 容器内存中,并为推理请求提供服务。 GPU 核心由一个实例中的所有模型共享。 如果模型已加载到容器内存中,后续请求的服务速度会更快,因为 SageMaker 不需要再次下载和加载它。 |
生产能力 |
MME 提供在 GPU 上同时运行多个深度学习或 ML 模型的功能,以及 Triton 推理服务器。 这使您可以轻松地将 NVIDIA Triton 多框架、高性能推理服务与 SageMaker 完全托管模型部署结合使用。 Triton 支持所有基于 NVIDIA GPU、x86、Arm® CPU 和 AWS Inferentia 的推理。 它提供动态批处理、并发运行、最佳模型配置、模型集成以及流式音频和视频输入,以最大限度地提高吞吐量和利用率。 网络和有效载荷大小等其他因素可能在与推理相关的开销中发挥最小的作用。 |
缩放配置复杂性 |
MME 可以使用自动扩展策略进行水平扩展,并根据以下指标提供额外的 GPU 计算实例 借助 Triton 推理服务器,您可以使用 Triton 轻松构建包含您的模型的自定义容器,并将其带到 SageMaker。 SageMaker Inference 将处理请求并随着使用量的增加自动扩展容器,从而更轻松地在 AWS 上使用 Triton 部署模型。 |
交通格局 |
MME 是可预测流量模式的理想选择,模型在同一端点上作为 DAG 运行。 SageMaker 负责对 MME 端点的流量整形,并在 GPU 实例上维护最佳模型副本以实现最佳性价比。 它继续将流量路由到加载模型的实例。 如果实例资源由于利用率高而达到容量,SageMaker 会从容器中卸载最少使用的模型,以释放资源以加载更频繁使用的模型。 |
最佳实践
考虑以下最佳实践:
- 模型间高内聚低耦合 – 将模型托管在具有高内聚性(驱动单一业务功能)的同一容器中,并将它们封装在一起以便于升级和管理。 同时,将这些模型彼此解耦(将它们托管在不同的容器中),以便您可以轻松升级一个模型而不影响其他模型。 在一个端点后面托管多个使用不同容器的模型,然后独立调用或添加模型预处理和后处理逻辑作为串行推理管道。
- 推理延迟 – 将单一业务功能驱动的模型分组并将它们托管在单个容器中,以最大限度地减少跃点数,从而最大限度地减少整体延迟。 还有其他注意事项,例如分组模型是否使用多个框架; 您也可以选择托管在多个容器中,但在同一主机上运行以减少延迟并最大限度地降低成本。
- 以逻辑方式对具有高内聚性的 ML 模型进行分组 – 逻辑组可能由同类模型(例如,所有 XGBoost 模型)或异构模型(例如,一些 XGBoost 和一些 BERT)组成。 它可能包含在多个业务功能之间共享的模型,或者可能特定于仅实现一个业务功能。
- 共享模型 – 如果逻辑组由共享模型组成,则模型升级的便利性和延迟将在构建 SageMaker 端点时发挥重要作用。 例如,如果延迟是一个优先事项,最好将所有模型放在单个 SageMaker 端点后面的单个容器中,以避免多跃点。 缺点是,如果需要升级任何模型,将导致升级托管该模型的所有相关 SageMaker 端点。
- 非共享模型 – 如果逻辑组仅包含业务特征特定模型并且不与其他组共享,则打包复杂性和延迟维度将成为实现的关键。 建议将这些模型托管在单个 SageMaker 端点后面的单个容器中。
- 有效利用硬件(CPU、GPU) – 将基于 CPU 的模型组合在一起并将它们托管在同一台主机上,以便您可以高效地使用 CPU。 同样,将基于 GPU 的模型组合在一起,以便您可以高效地使用和扩展它们。 有些混合工作负载需要在同一台主机上同时使用 CPU 和 GPU。 在同一台主机上托管仅 CPU 和仅 GPU 模型应该由高内聚和应用程序延迟要求驱动。 此外,成本、扩展能力和发生故障时影响的爆炸半径是需要研究的关键维度。
- 健身功能 – 使用适应度函数作为选择 ML 托管选项的指南。
结论
谈到 ML 托管,没有一种放之四海而皆准的方法。 ML 从业者需要选择正确的设计模式来解决他们的 ML 托管挑战。 评估适应度函数为选择正确的 ML 托管选项提供了规范性指导。
有关每个托管选项的更多详细信息,请参阅本系列中的以下帖子:
关于作者
达瓦尔·帕特尔 是 AWS 的首席机器学习架构师。 他曾与从大型企业到中型初创公司的组织合作,解决与分布式计算和人工智能相关的问题。 他专注于深度学习,包括 NLP 和计算机视觉领域。 他帮助客户在 SageMaker 上实现高性能模型推理。
迪帕里•拉贾莱 是 Amazon Web Services 的 AI/ML 专家技术客户经理。 她与企业客户合作,提供有关通过最佳实践实施机器学习解决方案的技术指导。 在业余时间,她喜欢徒步旅行、看电影以及与家人和朋友一起出去玩。
索拉布·特里坎德 是 Amazon SageMaker Inference 的高级产品经理。 他热衷于与客户合作,并以机器学习民主化的目标为动力。 他专注于与部署复杂的 ML 应用程序、多租户 ML 模型、成本优化以及使深度学习模型的部署更易于访问相关的核心挑战。 在业余时间,Saurabh 喜欢徒步旅行、学习创新技术、关注 TechCrunch 以及与家人共度时光。
- SEO 支持的内容和 PR 分发。 今天得到放大。
- 柏拉图区块链。 Web3 元宇宙智能。 知识放大。 访问这里。
- Sumber: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- 对,能力--
- Able
- 关于
- 加速
- ACCESS
- 访问
- 无障碍
- 容纳
- 账号管理
- 精准的
- 实现
- 横过
- 操作
- 积极地
- 增加
- 额外
- 另外
- 地址
- 推进
- 高级
- 优点
- 广告
- 影响
- 后
- 聚合
- 聚合
- 侵略性
- 协议
- AI
- AI / ML
- 报警
- 算法
- 所有类型
- 允许
- 允许
- 已经
- 时刻
- Amazon
- Amazon EC2
- 亚马逊SageMaker
- 亚马逊网络服务
- 量
- 分析
- 分析
- 和
- 和基础设施
- 全年
- 另一个
- 阿帕奇
- API
- Apple
- 应用领域
- 应用领域
- 的途径
- 适当
- 应用
- 架构
- ARM
- 人造的
- 人工智能
- 方面
- 评定
- 相关
- 属性
- 音频
- 审计
- 汽车
- 自动化
- 自动表
- 自动
- 可用性
- 可使用
- AWS
- 背部
- 已备份
- 银行业
- 基地
- 基于
- 因为
- 成为
- 成为
- before
- 背后
- 作为
- 得益
- 最佳
- 最佳实践
- 更好
- 之间
- 生物医学
- 阻止
- 借贷
- 边界
- 盒子
- 违反
- 午休
- 带来
- 带来
- 预算
- 建立
- 建筑物
- 建
- 内建的
- 商业
- 商业应用
- 业务流程
- 企业
- 缓存
- 计算
- 呼叫
- 被称为
- 呼叫者
- 候选人
- 能力
- 容量
- 关心
- 案件
- 例
- 类别
- 原因
- 一定
- 认证
- 挑战
- 更改
- 更改
- 特点
- 带电
- 聊天机器人
- 查
- 芯片
- 选择
- 选择
- 选择
- 程
- 分类
- 分类
- 客户
- 客户
- 关闭
- 云端技术
- 簇
- 码
- 创造
- 同事
- 收集
- 打击
- 组合
- 结合
- 结合
- 相当常见
- 公司
- 公司
- 相比
- 完成
- 完全
- 复杂
- 复杂
- 符合
- 组件
- 由
- 妥协
- 计算能力
- 计算
- 一台
- 计算机视觉
- 计算
- 概念
- 关心
- 并发
- 配置
- 地都
- 一贯
- 消费
- 消费者
- 容器
- 集装箱
- 包含
- 继续
- 继续
- 连续
- 控制
- 核心
- 相应
- 价格
- 节约成本
- 经济有效
- 成本
- 可以
- 创建信息图
- 创建
- 危急
- 关键
- 电流
- 习俗
- 顾客
- 合作伙伴
- DAG
- data
- 数据处理
- 数据科学
- 数据科学家
- 数据库
- 数据集
- 天
- 处理
- 决定
- 专用
- 深
- 深入学习
- 默认
- 定义
- 交付
- 需求
- 需求
- 民主化
- 根据
- 依靠
- 部署
- 部署
- 部署
- 部署
- 部署
- 设计
- 设计模式
- 设计
- 细节
- 详情
- 检测
- 确定
- 开发商
- 研发支持
- 图
- 不同
- 难
- 尺寸
- 直接
- 不同
- 分布
- 分布式计算
- 不同
- 码头工人
- 文件
- 不会
- 域名
- 别
- 向下
- 下载
- 缺点
- 驱动
- 下降
- 删除
- ,我们将参加
- 动态
- 每
- 此前
- 更容易
- 容易
- 有效
- 只
- 效用
- 效率
- 高效
- 有效
- 努力
- 或
- 消除
- enable
- 使
- 加密
- 端至端
- 端点
- 工程师
- 工程师
- 更多
- 确保
- 确保
- 企业
- 企业
- 整个
- 环境
- 错误
- 故障
- 特别
- 评估
- 评价
- 甚至
- 活动
- 一切
- 进化
- 例子
- 例子
- 交换
- 展品
- 期望
- 预期
- 体验
- 体验
- 探索
- 表达式
- 外部
- 额外
- 面部彩妆
- 因素
- 失败
- 相当
- 家庭
- 家庭
- 快
- 专栏
- 特征
- 喂养
- 少数
- 最后
- 姓氏:
- 第一次
- 运动健身
- 舰队
- 高度灵活
- 流
- 波动
- 重点
- 以下
- 如下
- 涉
- 申请
- 形式
- 部分的
- 骨架
- 框架
- 骗局
- 欺诈检测
- Free
- 频率
- 频繁
- 朋友
- 止
- 水果
- ,
- 充分
- 功能
- 功能
- 功能
- 功能
- 进一步
- 《通用数据保护条例》(GDPR)
- 其他咨询
- 产生
- 发电
- 得到
- 给
- 特定
- 目标
- 理想中
- 非常好
- GPU
- 图形处理器
- 图形
- 大
- 更大的
- 非常
- 团队
- 组的
- 增长
- 指南
- 处理
- 手柄
- 便利
- 硬件
- 有
- 健康管理
- 医疗保健
- 帮助
- 帮助
- 帮助
- 相关信息
- 高
- 高性能
- 高分辨率
- 更高
- 击中
- 横
- 主持人
- 托管
- 托管
- 托管费用
- 托管服务
- 创新中心
- 但是
- HTML
- HTTPS
- 数百
- 杂交种
- 理想
- 身分
- 空闲
- 图片
- 图像分类
- 图片
- 一成不变
- 影响力故事
- 影响
- 影响
- 实施
- 实施
- 实施
- 重要
- 改善
- 改善
- in
- 包括
- 包括
- 包含
- 来电
- 增加
- 增加
- 增加
- 增加
- 独立
- 独立地
- 个人
- 信息
- 基础设施
- 初始
- 创新
- 创新技术
- 输入
- 安装
- 例
- 代替
- 整合
- 积分
- 房源搜索
- 互动
- 涉及
- ISO
- 隔离
- IT
- 工作
- 工作机会
- 键
- 键
- 知道
- 已知
- 大
- 大
- 潜伏
- 发射
- 启动
- 发射
- 铅
- 领导
- 信息
- 学习用品
- 学习
- 离开
- 导致
- Level
- 库
- 翻新
- 有限
- 范围
- 清单
- 生活
- 加载
- 装载
- 负载
- 圖書分館的位置
- 长
- 不再
- 看
- 失去
- 占地
- 低
- 机
- 机器学习
- 制成
- 主要
- 保持
- 维护
- 主要
- 使
- 制作
- 制作
- 管理
- 管理
- 颠覆性技术
- 经理
- 管理
- 管理的
- 许多
- 营销
- 数学的
- 问题
- 生产力
- 最多
- 手段
- 满足
- 内存
- 方法
- 方法
- 公
- 指标
- 可能
- 最小
- 最低限度
- 分钟
- 搅和
- ML
- 时尚
- 模型
- 模型
- 显示器
- 监控
- 月
- 个月
- 更多
- 最先进的
- 动机
- 电影
- 多模型端点
- 多
- 多数
- 自然
- 必要
- 需求
- 需要
- 网络
- 全新
- 下页
- NLP
- 通知
- 通知
- 数
- Nvidia公司
- 对象
- 目标
- 目标
- 获得
- 偶然
- 提供
- 优惠精选
- 这一点在线下监测数字化产品的影响方面尤为明显。
- 一
- 在线
- 开放源码
- 操作
- 运营
- 操作
- 操作
- 运营
- 运营商
- 最佳
- 优化
- 优化
- 优化
- 优化
- 追求项目的积极优化
- 附加选项
- 附加选项
- 橘色
- 秩序
- 组织
- 其他名称
- 优秀
- 最划算
- 己
- 所有权
- 包
- 包装
- 参数
- 部分
- 特别
- 合伙人
- 通过
- 多情
- 补丁
- 模式
- 模式
- 高峰
- 演出
- 性能
- 执行
- 期间
- 定期
- 期
- 个性化
- 个性化你的
- 挑
- 管道
- 地方
- 地方
- 计划
- 计划
- 平台
- 平台
- 柏拉图
- 柏拉图数据智能
- 柏拉图数据
- 播放
- 加
- 政策
- 政策
- 热门
- 可能
- 帖子
- 帖子
- 功率
- 在练习上
- 做法
- 可预见
- 预测
- 预测
- 预测
- 首选
- 先前
- 车资
- 校长
- 优先
- 私立
- 市场问题
- 问题
- 过程
- 处理
- 过程
- 处理
- 处理器
- 产品
- 产品经理
- 生产
- 核心产品
- 本人简介
- 正确
- 提供
- 提供
- 提供
- 优
- 规定
- 代理
- 目的
- 推
- pytorch
- 很快
- 范围
- 范围
- 急速
- 率
- 价格表
- 达到
- 上游
- 阅读
- 准备
- 真实
- 真实的世界
- 实时的
- 接收
- 收到
- 接收
- 建议
- 推荐
- 建议
- 建议
- 建议
- 建议
- 经常性
- 减少
- 减少
- 指
- 而不管
- 定期
- 有关
- 发布
- 相应
- 遗迹
- 知识库
- 代表
- 代表
- 请求
- 要求
- 要求
- 必须
- 需求
- 岗位要求
- 需要
- 资源
- 资源
- 响应
- REST的
- 导致
- 导致
- 成果
- 零售
- 回报
- 检讨
- 风险
- 角色
- 根
- 路线
- 第
- 运行
- 运行
- SaaS的
- sagemaker
- SageMaker 推理
- 薪水
- 同
- 保存
- 保存
- 储
- 可扩展性
- 鳞片
- 秤
- 缩放
- 情景
- 始你
- 预定
- 科学
- 科学家
- 其次
- 秒
- 部分
- 部分
- 安全
- 保安
- 选择
- 选择
- 前辈
- 敏感
- 序列
- 串行
- 系列
- 服务
- 无服务器
- 服务器
- 服务
- 服务
- 特色服务
- 服务
- 集
- 设置
- 几个
- 成型
- Share
- 共用的,
- 转移
- 应该
- 作品
- 显著
- 显著
- 类似
- 同样
- 简易
- 单
- 尺寸
- 尺寸
- 小
- 小
- So
- 软件
- 方案,
- 解决方案
- 一些
- 来源
- 太空
- 专家
- 专门
- 具体的
- 特别是
- 指定
- 速度
- 花费
- 钉鞋
- 稳定
- 堆
- 堆栈
- 开始
- 开始
- 启动
- 启动
- 初创企业
- 稳定
- 步
- 步骤
- 仍
- 车站
- 存储
- 商店
- 策略
- 流
- 监督
- 非常
- 随后
- 成功
- 成功
- 这样
- 足够
- 合适的
- SUPPORT
- 支持
- 支持
- 浪涌
- 表
- 采取
- 需要
- 目标
- 针对
- 任务
- 任务
- 团队
- 队
- TechCrunch
- 文案
- 技术
- 承租人
- tensorflow
- test
- 测试
- 其
- 他们自己
- 从而
- 因此
- 数千
- 三
- 门槛
- 通过
- 始终
- 吞吐量
- 次
- 时
- 至
- 一起
- 也有
- 工具
- 合计
- TPS
- 跟踪
- 交通
- 培训
- 熟练
- 产品培训
- 交易
- 交易
- 改造
- 转型
- 转型
- 过境
- 透明
- 触发
- 海卫一
- 转
- 类型
- 普遍
- 一般
- 下
- 相关
- 理解
- 独特
- 单位
- 变幻莫测
- 未使用
- 更新
- 最新动态
- 升级
- 升级
- 正常运行时间
- 用法
- 使用
- 用例
- 用户
- 用户
- 平时
- 利用
- 利用
- 验证
- 折扣值
- 价值观
- 变种
- 各个
- 通过
- 视频
- 视频
- 查看
- 在线会议
- 愿景
- 体积
- 投票
- 票
- 废物回收
- 卷筒纸
- Web服务
- 周
- 什么是
- 什么是
- 这
- 而
- 宽
- 大范围
- 将
- 中
- 也完全不需要
- 工作
- 工作
- 工人
- 工人
- 加工
- 合作
- 世界
- 将
- XGBoost
- 年
- 完全
- 您一站式解决方案
- 和风网
- 零