这篇文章是与 Forethought Technologies, Inc. 的工程总监 Jad Chamoun 和 Forethought Technologies, Inc. 的高级 ML 工程师 Salina Wu 共同撰写的。
前瞻性的 是领先的客户服务生成人工智能套件。 其套件的核心是创新 支持GPT™ 使用机器学习来改变客户支持生命周期的技术——增加偏差、提高 CSAT 和提高座席生产力。 SupportGPT™ 利用最先进的信息检索 (IR) 系统和大型语言模型 (LLM) 每年为超过 30 万次客户交互提供支持。
SupportGPT 的主要用例是提高客户支持交互和运营的质量和效率。 通过使用由嵌入和排名模型提供支持的最先进的 IR 系统,SupportGPT 可以快速搜索相关信息,为客户查询提供准确简洁的答案。 Forethought 使用针对每个客户的微调模型来检测客户意图,以解决客户交互问题。 大型语言模型的集成有助于使与自动化代理的交互更加人性化,从而创造更具吸引力和令人满意的支持体验。
SupportGPT 还通过提供自动完成建议和根据以前的答复对客户工单做出与公司一致的适当答复来协助客户支持代理。 通过使用先进的语言模型,代理可以更快、更准确地解决客户的问题,从而提高客户满意度。
此外,SupportGPT 的架构能够检测支持知识库中的差距,这有助于代理向客户提供更准确的信息。 一旦发现这些差距,SupportGPT 就可以自动生成文章和其他内容来填补这些知识空白,确保支持知识库始终以客户为中心并保持最新。
在这篇文章中,我们分享 Forethought 如何使用 亚马逊SageMaker 生成 AI 用例中的多模型端点可节省超过 66% 的成本。
基础设施挑战
为了帮助将这些功能推向市场,Forethought 有效地扩展了其 ML 工作负载,并提供了针对每个客户的特定用例量身定制的超个性化解决方案。 这种超个性化是通过微调客户数据的嵌入模型和分类器实现的,确保准确的信息检索结果和领域知识,以满足每个客户的独特需求。 定制的自动完成模型还根据客户数据进行了微调,以进一步提高生成的响应的准确性和相关性。
人工智能处理的重大挑战之一是有效利用 GPU 等硬件资源。 为了应对这一挑战,Forethought 使用 SageMaker 多模型端点 (MME) 在单个推理端点和规模上运行多个 AI 模型。 由于模型的超个性化需要训练和部署独特的模型,因此模型的数量与客户的数量成线性比例关系,这可能会变得昂贵。
为了在实时推理和成本之间取得适当的性能平衡,Forethought 选择使用支持 GPU 加速的 SageMaker MME。 SageMaker MME 使 Forethought 能够提供具有亚秒级延迟的高性能、可扩展且经济高效的解决方案,从而大规模解决多个客户支持场景。
SageMaker 和 Forethought
SageMaker 是一项完全托管的服务,可为开发人员和数据科学家提供快速构建、训练和部署 ML 模型的能力。 SageMaker MME 提供可扩展且经济高效的解决方案,用于部署大量模型以进行实时推理。 MME 使用共享服务容器和一组资源,这些资源可以使用 GPU 等加速实例来托管您的所有模型。 与使用单一模型端点相比,这通过最大化端点利用率来降低托管成本。 它还减少了部署开销,因为 SageMaker 管理在内存中加载和卸载模型并根据端点的流量模式扩展它们。 此外,所有 SageMaker 实时端点都受益于管理和监控模型的内置功能,例如包括 阴影变体, 自动缩放, 和本机集成 亚马逊CloudWatch (有关更多信息,请参阅 多模型终端节点部署的 CloudWatch 指标).
随着 Forethought 发展到托管数百个也需要 GPU 资源的模型,我们看到了通过 SageMaker MME 创建更具成本效益、可靠和可管理的架构的机会。 在迁移到 SageMaker MME 之前,我们的模型部署在 Kubernetes 上 Amazon Elastic Kubernetes服务 (亚马逊 EKS)。 尽管 Amazon EKS 提供了管理功能,但很明显,我们正在管理并非专门为推理量身定制的基础设施。 Forethought 必须自己管理 Amazon EKS 上的模型推理,这对工程效率造成了负担。 例如,为了在多个模型之间共享昂贵的 GPU 资源,我们负责将刚性内存部分分配给在部署期间指定的模型。 我们希望解决现有基础架构的以下关键问题:
- 成本高 – 为了确保每个模型都有足够的资源,我们在每个实例适合多少个模型方面会非常保守。 这导致模型托管的成本比必要的高得多。
- 可靠性低 – 尽管我们在内存分配方面比较保守,但并非所有模型都有相同的要求,有时某些模型会抛出内存不足 (OOM) 错误。
- 管理效率低下 – 我们必须为每种类型的模型(例如分类器、嵌入和自动完成)管理不同的部署清单,这既耗时又容易出错。 我们还必须维护逻辑以确定不同模型类型的内存分配。
最终,我们需要一个推理平台来承担在运行时管理模型的繁重工作,以提高模型服务的成本、可靠性和管理。 SageMaker MME 让我们能够满足这些需求。
通过其智能和动态的模型加载和卸载及其扩展功能,SageMaker MME 为托管我们的模型提供了一种成本显着降低且更可靠的解决方案。 我们现在能够为每个实例拟合更多模型,并且不必担心 OOM 错误,因为 SageMaker MME 会动态处理加载和卸载模型。 此外,部署现在就像调用 Boto3 SageMaker API 和附加适当的自动缩放策略一样简单。
下图说明了我们的旧架构。
为了开始向 SageMaker MME 的迁移,我们确定了 MME 的最佳用例,以及我们的哪些模型将从这一变化中获益最多。 MME 最适用于以下情况:
- 预期具有低延迟但可以承受冷启动时间(首次加载时)的模型
- 经常被一致调用的模型
- 需要部分GPU资源的模型
- 共享共同需求和推理逻辑的模型
我们将嵌入模型和自动完成语言模型确定为迁移的最佳候选者。 为了在 MME 下组织这些模型,我们将为每个模型类型或任务创建一个 MME,一个用于我们的嵌入模型,另一个用于自动完成语言模型。
我们已经在我们的模型之上有了一个 API 层,用于模型管理和推理。 我们手头的任务是重新设计此 API 如何使用 SageMaker 在后台部署和处理模型推理,同时对客户和产品团队与 API 交互的方式进行最小的更改。 我们还需要打包我们的模型和自定义推理逻辑,以使用 SageMaker MME 与 NVIDIA Triton 推理服务器兼容。
下图说明了我们的新架构。
自定义推理逻辑
在迁移到 SageMaker 之前,Forethought 的自定义推理代码(预处理和后处理)在调用模型时在 API 层中运行。 目标是将此功能转移到模型本身,以明确职责分离,模块化和简化代码,并减少 API 的负载。
的嵌入
Forethought 的嵌入模型由两个 PyTorch 模型工件组成,推理请求决定调用哪个模型。 每个模型都需要预处理文本作为输入。 主要挑战是集成预处理步骤并为每个模型定义容纳两个模型工件。 为了解决推理逻辑中对多个步骤的需求,Forethought 开发了一个包含两个步骤的 Triton 集成模型:Python 后端预处理过程和 PyTorch 后端模型调用。 集成模型允许在推理逻辑中定义和排序步骤,每个步骤由任何后端类型的 Triton 模型表示。 为了确保与 Triton PyTorch 后端的兼容性,现有模型工件已转换为 TorchScript 格式。 为每个模型定义创建单独的 Triton 模型,Forethought 的 API 层负责确定适当的 TargetModel
根据传入的请求进行调用。
自动完成
自动完成模型(序列到序列)提出了一组不同的要求。 具体来说,我们需要启用循环多个模型调用并为每个调用缓存大量输入的功能,同时保持低延迟。 此外,这些模型需要预处理和后处理步骤。 为了满足这些要求并实现所需的灵活性,Forethought 利用 Triton Python 后端开发了自动完成 MME 模型,这提供了将模型编写为 Python 代码的优势。
标杆测试
确定 Triton 模型形状后,我们将模型部署到暂存端点并进行资源和性能基准测试。 我们的主要目标是确定冷启动与内存模型的延迟,以及请求大小和并发性对延迟的影响。 我们还想知道每个实例可以容纳多少个模型,多少个模型会导致实例根据我们的自动扩展策略进行扩展,以及扩展的速度有多快。 为了与我们已经使用的实例类型保持一致,我们使用 ml.g4dn.xlarge 和 ml.g4dn.2xlarge 实例进行了基准测试。
成果
下表总结了我们的结果。
请求大小 | 冷启动延迟 | 缓存推理延迟 | 并发延迟(5 个请求) |
小型(30 个代币) | 12.7秒 | 0.03秒 | 0.12秒 |
中型(250 个代币) | 12.7秒 | 0.05秒 | 0.12秒 |
大(550 个代币) | 12.7秒 | 0.13秒 | 0.12秒 |
值得注意的是,冷启动请求的延迟明显高于缓存推理请求的延迟。 这是因为模型需要从磁盘加载或 亚马逊简单存储服务 (Amazon S3) 发出冷启动请求时。 并发请求的延迟也高于单个请求的延迟。 这是因为模型需要在并发请求之间共享,这会导致争用。
下表比较了旧模型和 SageMaker 模型的延迟。
请求大小 | 旧型号 | SageMaker 模型 |
小型(30 个代币) | 0.74秒 | 0.24秒 |
中型(250 个代币) | 0.74秒 | 0.24秒 |
大(550 个代币) | 0.80秒 | 0.32秒 |
总体而言,与传统模型相比,SageMaker 模型是托管自动完成模型的更好选择。 它们提供更低的延迟、可扩展性、可靠性和安全性。
资源使用
为了确定适合每个实例的最佳模型数量,我们进行了一系列测试。 我们的实验涉及使用 ml.g4dn.xlarge 实例类型将模型加载到我们的端点,没有任何自动缩放策略。
这些特定实例提供 15.5 GB 的内存,我们旨在实现每个实例大约 80% 的 GPU 内存使用率。 考虑到每个编码器模型工件的大小,我们设法找到最佳数量的 Triton 编码器加载到实例上以达到我们的目标 GPU 内存使用率。 此外,鉴于我们的每个嵌入模型对应于两个 Triton 编码器模型,我们能够为每个实例容纳一定数量的嵌入模型。 因此,我们计算了服务所有嵌入模型所需的实例总数。 这个实验对于优化我们的资源使用和提高我们模型的效率至关重要。
我们对我们的自动完成模型进行了类似的基准测试。 这些模型每个大约 292.0 MB。 当我们测试单个 ml.g4dn.xlarge 实例可以容纳多少个模型时,我们注意到在我们的实例开始卸载模型之前我们只能容纳四个模型,尽管这些模型的尺寸很小。 我们主要关心的是:
- CPU 内存利用率飙升的原因
- 当我们尝试加载另一个模型而不是仅加载最近最少使用 (LRU) 模型时模型被卸载的原因
我们能够查明在我们的 Python 模型中初始化我们的 CUDA 运行时环境导致内存利用率飙升的根本原因,这是将我们的模型和数据移入和移出 GPU 设备所必需的。 CUDA 在运行时初始化时将许多外部依赖项加载到 CPU 内存中。 因为 Triton PyTorch 后端处理和抽象掉在 GPU 设备上和从 GPU 设备上移动的数据,所以我们的嵌入模型没有遇到这个问题。 为了解决这个问题,我们尝试使用 ml.g4dn.2xlarge 实例,它具有相同数量的 GPU 内存但两倍于 CPU 内存。 此外,我们在 Python 后端代码中添加了一些小的优化,包括在使用后删除张量、清空缓存、禁用梯度和垃圾收集。 对于更大的实例类型,我们能够为每个实例拟合 10 个模型,并且 CPU 和 GPU 内存利用率变得更加一致。
下图说明了此体系结构。
自动缩放
我们将自动缩放策略附加到我们的嵌入和自动完成 MME。 我们的嵌入端点政策使用自定义指标将平均 GPU 内存利用率定为 80%。 我们的自动完成模型在工作时间内看到了高流量和夜间流量最小的模式。 正因为如此,我们创建了一个基于 InvocationsPerInstance
这样我们就可以根据流量模式进行扩展,在不牺牲可靠性的情况下节省成本。 根据我们的资源使用基准测试,我们将扩展策略配置为 225 InvocationsPerInstance
.
部署逻辑和管道
在 SageMaker 上创建 MME 非常简单,类似于在 SageMaker 上创建任何其他端点。 创建端点后,向端点添加其他模型就像将模型工件移动到端点目标的 S3 路径一样简单; 此时,我们可以对我们的新模型提出推理请求。
我们定义了接收模型元数据、根据元数据确定性地格式化端点并检查端点是否存在的逻辑。 如果没有,我们将创建端点并将 Triton 模型工件添加到端点的 S3 补丁中(也是确定性格式化的)。 例如,如果模型元数据表明它是一个自动完成模型,它将为自动完成模型创建一个端点,并为自动完成模型工件创建一个关联的 S3 路径。 如果端点存在,我们会将模型工件复制到 S3 路径。
现在我们已经有了 MME 模型的模型形状和将模型部署到 MME 的功能,我们需要一种自动化部署的方法。 我们的用户必须指定他们想要部署的模型; 我们处理模型的打包和部署。 与模型一起打包的自定义推理代码进行版本控制并推送到 Amazon S3; 在打包步骤中,我们根据指定的版本(或最新版本)拉取推理代码,并使用表示 Triton 模型文件结构的 YAML 文件。
我们的一个要求是我们所有的 MME 模型都将加载到内存中,以避免在生产推理请求加载模型期间出现任何冷启动延迟。 为实现这一目标,我们提供了足够的资源来适应我们所有的模型(根据前面的基准测试),并以每小时的节奏调用 MME 中的每个模型。
下图说明了模型部署管道。
下图说明了模型预热管道。
模型调用
我们现有的 API 层为调用者提供了一个抽象,以便对我们所有的 ML 模型进行推理。 这意味着我们只需向 API 层添加功能,即可根据推理请求使用正确的目标模型调用 SageMaker MME,而无需对调用代码进行任何更改。 SageMaker 推理代码接受推理请求,格式化我们 Triton 模型中定义的 Triton 输入,并使用 Boto3 调用 MME。
成本效益
由于迁移到 SageMaker MME,Forethought 在降低模型托管成本和减少模型 OOM 错误方面取得了重大进展。 在此更改之前,ml.g4dn.xlarge 实例在 Amazon EKS 中运行。 随着向 MME 的过渡,我们发现它可以在每个实例中容纳 12 个嵌入模型,同时实现 80% 的 GPU 内存利用率。 这导致我们每月的开支大幅下降。 从长远来看,我们实现了高达 80% 的成本节约。 此外,为了管理更高的流量,我们考虑扩大副本。 假设我们使用三个副本的场景,我们发现即使在这些条件下,我们的成本节省仍然很可观,徘徊在 43% 左右。
事实证明,使用 SageMaker MME 的旅程在经济上是有益的,它减少了我们的开支,同时确保了最佳的模型性能。 以前,我们的自动完成语言模型部署在 Amazon EKS 中,根据每个模型的内存分配需要不同数量的 ml.g4dn.xlarge 实例。 这导致了相当大的每月费用。 但是,随着我们最近迁移到 SageMaker MME,我们已经能够大幅降低这些成本。 我们现在将所有模型托管在 ml.g4dn.2xlarge 实例上,使我们能够更有效地打包模型。 这大大削减了我们的月度开支,现在我们已经实现了 66-74% 的成本节约。 此举展示了高效的资源利用如何通过使用 SageMaker MME 节省大量资金。
结论
在本文中,我们回顾了 Forethought 如何使用 SageMaker 多模型端点来降低实时推理的成本。 SageMaker 承担了无差别的繁重工作,因此 Forethought 可以提高工程效率。 它还允许 Forethought 显着降低实时推理的成本,同时保持关键业务操作所需的性能。 通过这样做,Forethought 能够使用超个性化模型为其客户提供差异化的产品。 使用 SageMaker MME 大规模托管您的模型并通过提高端点利用率来降低托管成本。 它还减少了部署开销,因为 Amazon SageMaker 管理内存中的加载模型并根据终端节点的流量模式扩展它们。 您可以在网站上找到有关使用 SageMaker MME 托管多个模型的代码示例 GitHub上.
作者简介
贾德夏蒙 是 Forethought 的核心工程总监。 他的团队专注于平台工程,涵盖数据工程、机器学习基础设施和云基础设施。 你可以在 LinkedIn.
吴莎莉娜 是 Forethought.ai 的高级机器学习基础架构工程师。 她与机器学习团队密切合作,以构建和维护他们的端到端培训、服务和数据基础架构。 她特别热衷于引入新方法来提高 ML 领域的效率和降低成本。 工作之余,Salina 喜欢冲浪、陶艺和亲近大自然。
詹姆斯公园 是 Amazon Web Services 的解决方案架构师。 他与 Amazon.com 合作,在 AWS 上设计、构建和部署技术解决方案,并且对人工智能和机器学习特别感兴趣。 在业余时间,他喜欢探索新文化、新体验,并紧跟最新的技术趋势。您可以在 LinkedIn.
苏尼尔·帕德马纳班 是 AWS 的启动解决方案架构师。 作为前创业公司创始人和首席技术官,他对机器学习充满热情,专注于帮助初创公司利用 AI/ML 实现业务成果,并大规模设计和部署 ML/AI 解决方案。
达瓦尔·帕特尔 是 AWS 的首席机器学习架构师。 他曾与从大型企业到中型初创公司的组织合作,解决与分布式计算和人工智能相关的问题。 他专注于深度学习,包括 NLP 和计算机视觉领域。 他帮助客户在 SageMaker 上实现高性能模型推理。
- SEO 支持的内容和 PR 分发。 今天得到放大。
- EVM财务。 去中心化金融的统一接口。 访问这里。
- 量子传媒集团。 IR/PR 放大。 访问这里。
- 柏拉图爱流。 Web3 数据智能。 知识放大。 访问这里。
- Sumber: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :具有
- :是
- :不是
- :在哪里
- $UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- 对,能力--
- Able
- 关于
- 抽象化
- 摘要
- 加速
- 根据
- 精准的
- 准确
- 实现
- 实现
- 横过
- 加
- 添加
- 添加
- 增加
- 额外
- 另外
- 地址
- 解决
- 高级
- 优点
- 后
- 经纪人
- 中介代理
- AI
- 人工智能用例
- AI / ML
- 针对
- 对齐
- 对齐的
- 所有类型
- 分配
- 让
- 允许
- 已经
- 还
- 尽管
- Amazon
- 亚马逊SageMaker
- 亚马逊网络服务
- Amazon.com
- 量
- an
- 和
- 每年
- 另一个
- 答案
- 任何
- API
- APIs
- 明显的
- 适当
- 约
- 架构
- 保健
- 围绕
- 刊文
- 人造的
- 人工智能
- AS
- 助攻
- 相关
- At
- 汽车
- 自动化
- 自动化
- 自动
- 避免
- 远离
- AWS
- 后端
- 当前余额
- 基地
- 基于
- BE
- 成为
- 因为
- 成为
- 很
- before
- 开始
- 作为
- 标杆
- 有利
- 得益
- 最佳
- 更好
- 之间
- 提高
- 都
- 带来
- 建立
- 内建的
- 负担
- 商业
- 但是
- by
- 缓存
- 计算
- 呼叫
- 被称为
- 调用
- 呼叫
- CAN
- 候选人
- 能力
- 案件
- 例
- 迎合
- 原因
- 挑战
- 挑战
- 更改
- 更改
- 查
- 选择
- 选择
- 客户
- 密切
- 云端技术
- 云基础设施
- 码
- 冷
- 收藏
- COM的
- 未来
- 相当常见
- 公司的
- 相比
- 兼容性
- 兼容
- 一台
- 计算机视觉
- 计算
- 关注
- 并发
- 条件
- 进行
- 配置
- 保守的
- 大量
- 考虑
- 考虑
- 容器
- 内容
- 转换
- 核心
- 正确
- 对应
- 价格
- 节约成本
- 经济有效
- 昂贵
- 成本
- 可以
- 覆盖
- 创建信息图
- 创建
- 创造
- 关键
- 首席技术官
- 习俗
- 顾客
- 客户数据
- 客户满意度
- 客户服务
- 客户支持
- 合作伙伴
- 定制
- data
- 日期
- 拒绝
- 减少
- 深
- 深入学习
- 定义
- 定义
- 交付
- 交付
- 证明
- 根据
- 部署
- 部署
- 部署
- 部署
- 部署
- 设计
- 期望
- 尽管
- 确定
- 决心
- 确定
- 确定
- 发达
- 开发
- 设备
- DID
- 不同
- 分化
- 副总经理
- 发现
- 不同
- 分布
- 分布式计算
- 做
- 域
- 域名
- 别
- 显着
- ,我们将参加
- 动态
- 动态
- 每
- 效率
- 高效
- 有效
- 嵌入
- enable
- 使
- 端至端
- 端点
- 从事
- 工程师
- 工程师
- 提高
- 加强
- 更多
- 确保
- 保证
- 企业
- 环境
- 故障
- 甚至
- 所有的
- 例子
- 现有
- 预期
- 开支
- 昂贵
- 体验
- 体验
- 实验
- 外部
- 快
- 文件
- 档
- 填
- 金融
- 经济
- 找到最适合您的地方
- (名字)
- 适合
- 舰队
- 高度灵活
- 重点
- 以下
- 针对
- 格式
- 前
- 发现
- 创办人
- 四
- 止
- 充分
- 功能
- 进一步
- 此外
- 差距
- 生成
- 产生
- 生成的
- 生成式人工智能
- 越来越
- GIF
- 特定
- 给予
- 目标
- GPU
- 图形处理器
- 渐变
- 民政事务总署
- 手
- 处理
- 手柄
- 处理
- 发生
- 硬件
- 有
- 有
- he
- 重
- 举重
- 帮助
- 帮助
- 帮助
- 高
- 高性能
- 更高
- 他
- 他的
- 兜帽
- 主持人
- 托管
- 托管费用
- HOURS
- 别墅
- 创新中心
- 但是
- HTML
- HTTP
- HTTPS
- 数百
- 确定
- if
- 说明
- 立即
- 改善
- 改善
- in
- 公司
- 包含
- 来电
- 增加
- 表明
- 表示
- 信息
- 基础设施
- 基础设施
- 创新
- 输入
- 输入
- 例
- 代替
- 整合
- 积分
- 房源搜索
- 相互作用
- 互动
- 兴趣
- 成
- 介绍
- 调用
- 所调用
- 参与
- 问题
- IT
- 它的
- 本身
- 旅程
- JPG
- 只是
- 保持
- 键
- 知道
- 知识
- 语言
- 大
- 大企业
- 大
- 潜伏
- 最新
- 层
- 铅
- 领导
- 学习
- 最少
- 导致
- 遗产
- 减
- 杠杆作用
- 杠杆
- 翻新
- 加载
- 装载
- 负载
- 逻辑
- 低
- 降低
- 机
- 机器学习
- 制成
- 主要
- 保持
- 维护
- 使
- 管理
- 管理
- 颠覆性技术
- 管理
- 管理的
- 许多
- 市场
- 最大化
- 意思
- 内存
- 元数据
- 指标
- 迁移
- 移民
- 百万
- 最小
- 未成年人
- 缓解
- ML
- 模型
- 模型
- 显示器
- 每月一次
- 更多
- 此外
- 最先进的
- 动机
- 移动
- 移动
- 许多
- 多模型端点
- 多
- 必须
- 本地人
- 自然
- 必要
- 需求
- 打印车票
- 需要
- 全新
- NLP
- 现在
- 数
- Nvidia公司
- 目标
- of
- 折扣
- 提供
- 提供
- 优惠精选
- 经常
- on
- 一旦
- 一
- 仅由
- 运营
- ZAP优势
- 最佳
- 追求项目的积极优化
- or
- 秩序
- 组织
- 其他名称
- 我们的
- 我们自己
- 输出
- 结果
- 超过
- 过夜
- 类型
- 包
- συσκευάζονται
- 包装
- 特别
- 尤其
- 多情
- 打补丁
- 径
- 模式
- 模式
- 性能
- 透视
- 管道
- 平台
- 柏拉图
- 柏拉图数据智能
- 柏拉图数据
- 点
- 政策
- 政策
- 帖子
- 功率
- 供电
- 呈现
- 以前
- 先前
- 小学
- 校长
- 先
- 问题
- 过程
- 处理
- 产品
- 生产
- 生产率
- 正确
- 成熟
- 提供
- 提供
- 提供
- 规定
- 放
- 蟒蛇
- pytorch
- 质量
- 查询
- 探索
- 很快
- 范围
- 范围
- 排行
- 达到
- 实时的
- 实现
- 最近
- 最近
- 减少
- 减少
- 减少
- 有关
- 相关性
- 相应
- 可靠性
- 可靠
- 遗迹
- 代表
- 请求
- 要求
- 必须
- 需求
- 岗位要求
- 需要
- 资源
- 资源
- 回复
- 责任
- 提供品牌战略规划
- 导致
- 导致
- 成果
- 审查
- 右
- 硬性
- 根
- 运行
- 运行
- 牺牲
- sagemaker
- SageMaker 推理
- 同
- 满意
- 保存
- 保存
- 储
- 锯
- 可扩展性
- 可扩展性
- 鳞片
- 放大
- 秤
- 缩放
- 脚本
- 情景
- 科学家
- 搜索
- 保安
- 寻求
- 前辈
- 分开
- 序列
- 系列
- 服务
- 服务
- 特色服务
- 服务
- 集
- 几个
- 阴影
- 形状
- Share
- 共用的,
- 她
- 显著
- 显著
- 类似
- 简易
- 简化
- 单
- 尺寸
- 小
- 智能
- So
- 方案,
- 解决方案
- 解决
- 一些
- 太空
- 具体的
- 特别是
- 指定
- 穗
- 分期
- 开始
- 开始
- 启动
- 初创企业
- 国家的最先进的
- 步
- 步骤
- 仍
- 存储
- 简单的
- 进步
- 大量
- 这样
- 套房
- SUPPORT
- 产品
- 表
- 滑车
- 量身定制
- 采取
- 需要
- 目标
- 针对
- 目标
- 任务
- 团队
- 队
- 技术
- 专业技术
- 测试
- 测试
- 比
- 谢谢
- 这
- 其
- 他们
- 博曼
- 他们
- Free Introduction
- 三
- 通过
- 门票
- 次
- 耗时的
- 至
- 令牌
- 最佳
- 合计
- 交通
- 培训
- 熟练
- 产品培训
- 转让
- 改造
- 过渡
- 趋势
- 尝试
- 海卫一
- 两次
- 二
- 类型
- 类型
- 下
- 独特
- us
- 用法
- 使用
- 用例
- 用过的
- 用户
- 使用
- 运用
- 利用
- 版本
- 非常
- 愿景
- vs
- 想
- 通缉
- 是
- 方法..
- 方法
- we
- 卷筒纸
- Web服务
- 为
- ,尤其是
- 是否
- 这
- 而
- 也完全不需要
- 工作
- 工作
- 合作
- 担心
- 将
- 写作
- wu
- 雅姆
- 完全
- 您一站式解决方案
- 和风网