在 Amazon SageMaker JumpStart 中进行基准测试并优化终端节点部署 |亚马逊网络服务

在部署大型语言模型 (LLM) 时，机器学习 (ML) 从业者通常关心模型服务性能的两个衡量标准：延迟（由生成单个令牌所需的时间定义）和吞吐量（由生成的令牌数量定义）每秒。尽管对已部署端点的单个请求所表现出的吞吐量大约等于模型延迟的倒数，但当多个并发请求同时发送到端点时，情况不一定如此。由于模型服务技术（例如客户端连续批处理并发请求），延迟和吞吐量具有复杂的关系，该关系根据模型架构、服务配置、实例类型硬件、并发请求数量以及输入负载的变化而显着变化，例如作为输入令牌和输出令牌的数量。

本文通过对 Amazon SageMaker JumpStart 中提供的 LLM（包括 Llama 2、Falcon 和 Mistral 变体）进行全面基准测试来探讨这些关系。借助 SageMaker JumpStart，机器学习从业者可以从多种公开可用的基础模型中进行选择，并将其部署到专用的 亚马逊SageMaker 网络隔离环境中的实例。我们提供有关加速器规格如何影响法学硕士基准测试的理论原则。我们还演示了在单个端点后面部署多个实例的影响。最后，我们提供了定制 SageMaker JumpStart 部署流程的实用建议，以满足您对延迟、吞吐量、成本和可用实例类型限制的要求。所有基准测试结果和建议均基于通用的 笔记本 您可以适应您的用例。

已部署端点基准测试

下图显示了各种模型类型和实例类型的部署配置的最低延迟（左）和最高吞吐量（右）值。重要的是，在给定部署所需的模型 ID 和实例类型的情况下，每个模型部署都使用 SageMaker JumpStart 提供的默认配置。

这些延迟和吞吐量值对应于具有 256 个输入令牌和 256 个输出令牌的有效负载。最低延迟配置将模型服务限制为单个并发请求，而最高吞吐量配置则最大化可能的并发请求数量。正如我们在基准测试中所看到的，增加并发请求会单调增加吞吐量，而大并发请求的改进则递减。此外，模型在支持的实例上完全分片。例如，由于 ml.g5.48xlarge 实例有 8 个 GPU，因此使用该实例的所有 SageMaker JumpStart 模型都会在所有八个可用加速器上使用张量并行性进行分片。

我们可以从这个图中注意到一些要点。首先，并非所有实例都支持所有模型；一些较小的模型，例如Falcon 7B，不支持模型分片，而较大的模型对计算资源要求更高。其次，随着分片的增加，性能通常会提高，但对于小型模型来说不一定会提高. 这是因为 7B 和 13B 等小型模型在跨过多加速器进行分片时会产生大量通信开销。我们稍后会更深入地讨论这个问题。最后，由于 A4 相对于 A24G GPU 的内存带宽改进，ml.p100d.10xlarge 实例往往具有显着更好的吞吐量。正如我们稍后讨论的，使用特定实例类型的决定取决于您的部署要求，包括延迟、吞吐量和成本限制。

如何获得这些最低延迟和最高吞吐量的配置值？首先，我们针对具有 2 个输入令牌和 7 个输出令牌的负载，绘制 ml.g5.12xlarge 实例上 Llama 256 256B 端点的延迟与吞吐量的关系，如下图所示。每个部署的 LLM 端点都存在类似的曲线。

随着并发量的增加，吞吐量和延迟也会单调增加。因此，最低延迟点出现在并发请求值为 1 时，您可以通过增加并发请求来经济高效地提高系统吞吐量。该曲线存在明显的“拐点”，很明显，与额外并发相关的吞吐量增益不会超过相关的延迟增加。该膝盖的确切位置取决于具体使用情况；一些从业者可能将拐点定义为超出预先指定的延迟要求（例如，100 ms/令牌）的点，而其他从业者可能会使用负载测试基准和排队论方法（例如半延迟规则），而其他从业者可能会使用理论加速器规格。

我们还注意到，并发请求的最大数量是有限的。在上图中，线路跟踪以 192 个并发请求结束。此限制的根源在于 SageMaker 调用超时限制，其中 SageMaker 端点在 60 秒后使调用响应超时。此设置是特定于帐户的，不可针对单个端点进行配置。对于法学硕士来说，生成大量输出令牌可能需要几秒钟甚至几分钟的时间。因此，较大的输入或输出有效负载可能会导致调用请求失败。此外，如果并发请求数量非常大，那么许多请求将经历较长的排队时间，从而导致 60 秒的超时限制。出于本研究的目的，我们使用超时限制来定义模型部署可能的最大吞吐量。重要的是，尽管 SageMaker 终端节点可以处理大量并发请求而不会观察到调用响应超时，但您可能需要根据延迟-吞吐量曲线中的拐点定义最大并发请求。这可能是您开始考虑水平扩展的时刻，其中单个端点使用模型副本配置多个实例，并在副本之间对传入请求进行负载平衡，以支持更多并发请求。

更进一步，下表包含 Llama 2 7B 模型不同配置的基准测试结果，包括不同数量的输入和输出令牌、实例类型和并发请求数量。请注意，上图仅绘制了该表的一行。

我们在这些数据中观察到一些其他模式。当上下文大小增加时，延迟会增加并且吞吐量会降低。例如，在并行度为 5.2 的 ml.g1xlarge 上，当令牌总数为 30 时，吞吐量为 512 个令牌/秒；而当令牌总数为 20 个时，吞吐量为 4,096 个令牌/秒。这是因为处理较大的输入需要更多的时间。我们还可以看到，增加 GPU 功能和分片会影响最大吞吐量和支持的最大并发请求。该表显示，Llama 2 7B 对于不同的实例类型具有显着不同的最大吞吐量值，并且这些最大吞吐量值出现在不同的并发请求值上。这些特征将促使机器学习从业者证明一个实例相对于另一个实例的成本是合理的。例如，考虑到低延迟要求，从业者可能会选择 ml.g5.12xlarge 实例（4 个 A10G GPU），而不是 ml.g5.2xlarge 实例（1 个 A10G GPU）。如果给出高吞吐量要求，则只有在高并发情况下才合理使用具有完全分片的 ml.p4d.24xlarge 实例（8 个 A100 GPU）。但请注意，在单个 ml.p7d.4xlarge 实例上加载 24B 模型的多个推理组件通常是有益的；本文稍后将讨论这种多模型支持。

前面的观察是针对 Llama 2 7B 模型进行的。然而，类似的模式也适用于其他模型。主要要点是延迟和吞吐量性能数据取决于负载、实例类型和并发请求数量，因此您需要为您的特定应用程序找到理想的配置。要为您的用例生成前面的数字，您可以运行链接的 笔记本，您可以在其中为您的模型、实例类型和负载配置此负载测试分析。

了解加速器规格

为 LLM 推理选择合适的硬件在很大程度上取决于特定的用例、用户体验目标和所选的 LLM。本节尝试根据基于加速器规范的高级原则来了解延迟-吞吐量曲线的拐点。仅这些原则不足以做出决定：真正的基准是必要的。期限 设备 此处包含所有 ML 硬件加速器。我们断言延迟-吞吐量曲线的拐点是由以下两个因素之一驱动的：

• 加速器已耗尽内存来缓存 KV 矩阵，因此后续请求将排队
• 加速器仍然有用于 KV 缓存的备用内存，但使用足够大的批处理大小，处理时间由计算操作延迟而不是内存带宽决定

我们通常更愿意受到第二个因素的限制，因为这意味着加速器资源已经饱和。基本上，您正在最大化您所支付的资源。让我们更详细地探讨这个断言。

KV缓存和设备内存

标准变压器注意力机制根据所有先前的令牌计算每个新令牌的注意力。大多数现代机器学习服务器将注意力键和值缓存在设备内存 (DRAM) 中，以避免每一步都重新计算。这就是所谓的 KV缓存，并且它随着批量大小和序列长度而增长。它定义了可以并行服务多少个用户请求，并且在给定可用 DRAM 的情况下，如果尚未满足前面提到的第二种情况中的计算限制状态，则将确定延迟吞吐量曲线的拐点。以下公式是最大 KV 缓存大小的粗略近似值。

在此公式中，B 是批量大小，N 是加速器数量。例如，在 A2G GPU (7 GB DRAM) 上运行的 FP16 中的 Llama 2 10B 模型（24 字节/参数）消耗大约 14 GB，为 KV 缓存留下 10 GB。代入模型的完整上下文长度 (N = 4096) 和剩余参数（n_layers=32、n_kv_attention_heads=32 和 d_attention_head=128），此表达式表明由于 DRAM 限制，我们只能并行服务四个用户的批量大小。如果您观察上表中的相应基准，就会发现这是延迟-吞吐量曲线中观察到的拐点的良好近似值。方法如 分组查询注意力 (GQA) 可以减少 KV 缓存大小，在 GQA 的情况下，它会以相同的因子减少 KV 头的数量。

算术强度和设备内存带宽

机器学习加速器计算能力的增长已经超过了它们的内存带宽，这意味着它们可以在访问该字节所需的时间内对每个数据字节执行更多的计算。

算术强度，或计算操作与内存访问的比率，对于一个操作决定它是否受到所选硬件上的内存带宽或计算容量的限制。例如，具有 10 TFLOPS FP5 和 70 GB/秒带宽的 A16G GPU（g600 实例类型系列）可以计算大约 116 操作/字节。 A100 GPU（p4d 实例类型系列）可以计算大约 208 个操作/字节。如果 Transformer 模型的算术强度低于该值，则它是受内存限制的；如果在上面，则它是受计算限制的。对于批量大小 2，Llama 7 62B 的注意力机制需要 1 个操作/字节（有关说明，请参阅 LLM 推理和表现指南），这意味着它是受内存限制的。当注意力机制受内存限制时，昂贵的 FLOPS 就未被利用。

有两种方法可以更好地利用加速器并提高运算强度：减少操作所需的内存访问（这就是 闪光灯 重点）或增加批量大小。然而，如果我们的 DRAM 太小而无法容纳相应的 KV 缓存，我们可能无法将批量大小增加到足以达到计算限制的状态。以下表达式描述了将标准 GPT 解码器推理的计算限制与内存限制机制分开的临界批量大小 B* 的粗略近似值，其中 A_mb 是加速器内存带宽，A_f 是加速器 FLOPS，N 是数量加速器。这个临界批量大小可以通过查找内存访问时间等于计算时间的位置来得出。参考 这个博文 更详细地理解公式 2 及其假设。

这与我们之前为 A10G 计算的操作/字节比率相同，因此该 GPU 上的临界批量大小为 116。实现这一理论临界批量大小的一种方法是增加模型分片并将缓存拆分到更多 N 个加速器上。这有效地增加了 KV 缓存容量以及内存限制的批量大小。

模型分片的另一个好处是在 N 个加速器上拆分模型参数和数据加载工作。这种类型的分片是一种模型并行性，也称为 张量并行。简单来说，内存带宽和计算能力的总和是 N 倍。假设没有任何类型的开销（通信、软件等），如果我们受内存限制，这会将每个令牌的解码延迟减少 N，因为这种情况下的令牌解码延迟受到加载模型所需时间的限制权重和缓存。然而，在现实生活中，增加分片程度会增加设备之间的通信，以在每个模型层共享中间激活。该通信速度受到设备互连带宽的限制。很难准确估计其影响（详情请参见 模型并行），但这最终可能会停止产生好处或降低性能 - 对于较小的模型尤其如此，因为较小的数据传输会导致较低的传输速率。

为了根据规格比较机器学习加速器，我们建议如下。首先，根据第二个方程计算每种加速器类型的近似关键批量大小，并根据第一个方程计算关键批量大小的 KV 缓存大小。然后，您可以使用加速器上的可用 DRAM 来计算适合 KV 缓存和模型参数所需的最小加速器数量。如果在多个加速器之间做出选择，请按照每 GB/秒内存带宽成本最低的顺序确定加速器的优先级。最后，对这些配置进行基准测试，并验证您所需延迟上限的最佳成本/令牌是什么。

选择端点部署配置

SageMaker JumpStart 分发的许多 LLM 使用 文本生成推理 （TGI） SageMaker 容器 用于模型服务。下表讨论了如何调整各种模型服务参数，以影响模型服务（从而影响延迟吞吐量曲线）或保护端点免受导致端点过载的请求的影响。这些是可用于为您的用例配置端点部署的主要参数。除非另有说明，我们使用默认值 文本生成负载参数 和 TGI环境变量.

TGI 服务器使用连续批处理，动态地将并发请求一起批处理以共享单个模型推理前向传递。前向传递有两种类型：预填充和解码。每个新请求必须运行单个预填充前向传递，以填充输入序列令牌的 KV 缓存。填充 KV 缓存后，解码前向传递会对所有批处理请求执行单个下一个令牌预测，该预测会迭代重复以生成输出序列。当新请求发送到服务器时，下一个解码步骤必须等待，以便预填充步骤可以针对新请求运行。这必须在这些新请求包含在后续连续批处理解码步骤中之前发生。由于硬件限制，用于解码的连续批处理可能不包括所有请求。此时，请求进入处理队列，推理延迟开始显着增加，而吞吐量仅略有增加。

可以将 LLM 延迟基准分析分为预填充延迟、解码延迟和队列延迟。每个组件消耗的时间本质上是不同的：预填充是一次性计算，解码对于输出序列中的每个令牌发生一次，而排队涉及服务器批处理过程。当处理多个并发请求时，很难从这些组件中分离出延迟，因为任何给定客户端请求所经历的延迟涉及由预填充新并发请求的需要驱动的队列延迟以及由包含驱动的队列延迟批量解码过程中的请求。因此，本文重点讨论端到端处理延迟。延迟-吞吐量曲线的拐点出现在队列延迟开始显着增加的饱和点。这种现象发生在任何模型推理服务器上，并且是由加速器规格驱动的。

部署期间的常见要求包括满足所需的最低吞吐量、允许的最大延迟、每小时的最大成本以及生成 1 万个代币的最大成本。您应该根据代表最终用户请求的有效负载来调整这些要求。满足这些要求的设计应考虑许多因素，包括具体的模型架构、模型的大小、实例类型和实例数量（水平扩展）。在以下部分中，我们重点介绍如何部署端点以最小化延迟、最大化吞吐量并最小化成本。此分析考虑了 512 个总令牌和 256 个输出令牌。

最大限度地减少延迟

延迟是许多实时用例中的重要要求。在下表中，我们查看了每个模型和每个实例类型的最小延迟。您可以通过设置实现最小延迟 MAX_CONCURRENT_REQUESTS = 1.

要实现模型的最小延迟，您可以使用以下代码，同时替换所需的模型 ID 和实例类型：

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

请注意，延迟数字根据输入和输出令牌的数量而变化。但是，除了环境变量之外，部署过程保持不变 MAX_INPUT_TOKENS 和 MAX_TOTAL_TOKENS。这里，设置这些环境变量是为了帮助保证端点延迟要求，因为较大的输入序列可能会违反延迟要求。请注意，SageMaker JumpStart 在选择实例类型时已经提供了其他最佳环境变量；例如，使用 ml.g5.12xlarge 将设置 SM_NUM_GPUS 在模型环境中为 4。

最大化吞吐量

在本节中，我们最大化每秒生成的令牌数量。这通常是在模型和实例类型的最大有效并发请求数下实现的。在下表中，我们报告了在遇到任何请求的 SageMaker 调用超时之前达到的最大并发请求值所实现的吞吐量。

要实现模型的最大吞吐量，您可以使用以下代码：

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

请注意，最大并发请求数取决于模型类型、实例类型、最大输入令牌数和最大输出令牌数。因此，在设置之前应该先设置这些参数 MAX_CONCURRENT_REQUESTS.

另请注意，对最小化延迟感兴趣的用户通常与对最大化吞吐量感兴趣的用户不一致。前者对实时响应感兴趣，而后者对批处理感兴趣，以便端点队列始终饱和，从而最大限度地减少处理停机时间。想要根据延迟要求最大化吞吐量的用户通常对在延迟-吞吐量曲线的拐点处运行感兴趣。

成本最小化

最小化成本的第一个选择是最小化每小时成本。这样，您就可以以最低的每小时成本在 SageMaker 实例上部署选定的模型。有关 SageMaker 实例的实时定价，请参阅 Amazon SageMaker定价。一般来说，SageMaker JumpStart LLM 的默认实例类型是成本最低的部署选项。

最小化成本的第二个选项涉及最小化生成 1 万个代币的成本。这是我们之前讨论的表的简单转换，以最大化吞吐量，您可以首先计算生成 1 万个令牌所需的时间（以小时为单位）（1e6 / 吞吐量 / 3600）。然后，您可以将此时间乘以指定 SageMaker 实例每小时的价格，生成 1 万个代币。

请注意，每小时成本最低的实例与生成 1 万个令牌的成本最低的实例不同。例如，如果调用请求是零星的，每小时成本最低的实例可能是最佳的，而在限制场景中，生成一百万个令牌的最低成本可能更合适。

张量并行与多模型权衡

在之前的所有分析中，我们考虑部署单个模型副本，其张量并行度等于部署实例类型上的 GPU 数量。这是默认的 SageMaker JumpStart 行为。然而，如前所述，对模型进行分片只能在一定限度内改善模型延迟和吞吐量，超出该限度，设备间通信需求将主导计算时间。这意味着在单个实例上部署具有较低张量并行度的多个模型通常比部署具有较高张量并行度的单个模型更有利。

在这里，我们在张量并行 (TP) 度为 2、7、13 和 4 的 ml.p24d.1xlarge 实例上部署 Llama 2 4B 和 8B 端点。为了清楚地说明模型行为，每个端点仅加载一个模型。

我们之前的分析已经表明，ml.p4d.24xlarge 实例具有显着的吞吐量优势，这通常意味着在高并发请求负载条件下，与 g1 实例系列相比，生成 5 万个令牌的成本更高。此分析清楚地表明您应该考虑单实例内模型分片和模型复制之间的权衡；也就是说，完全分片模型通常不是 4B 和 24B 模型系列的 ml.p7d.13xlarge 计算资源的最佳使用方式。事实上，对于 7B 模型系列，您可以通过张量并行度为 4 而不是 8 的单个模型副本获得最佳吞吐量。

从这里，您可以推断出 7B 模型的最高吞吐量配置涉及张量并行度 1、八个模型副本，而 13B 模型的最高吞吐量配置可能是张量并行度 2、四个模型副本。要了解有关如何实现此目的的更多信息，请参阅 使用 Amazon SageMaker 的最新功能将模型部署成本平均降低 50%，它演示了基于推理组件的端点的使用。由于负载平衡技术、服务器路由和 CPU 资源共享，您可能无法完全实现完全等于副本数量乘以单个副本吞吐量的吞吐量改进。

水平缩放

如前所述，每个端点部署对并发请求的数量都有限制，具体取决于输入和输出令牌的数量以及实例类型。如果这不能满足您的吞吐量或并发请求要求，您可以进行扩展以利用已部署端点后面的多个实例。 SageMaker 自动执行实例之间查询的负载平衡。例如，以下代码部署由三个实例支持的端点：

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

下表显示了 Llama 2 7B 模型的吞吐量增益与实例数量的关系。

值得注意的是，延迟-吞吐量曲线的拐点向右移动，因为较高的实例计数可以处理多实例端点内的大量并发请求。对于此表，并发请求值适用于整个端点，而不是每个单独实例接收的并发请求数。

您还可以使用自动缩放功能来监控工作负载并动态调整容量，以尽可能低的成本保持稳定且可预测的性能。这超出了本文的范围。要了解有关自动缩放的更多信息，请参阅 在 Amazon SageMaker 中配置自动缩放推理终端节点.

使用并发请求调用端点

假设您有大量查询，您希望使用它们在高吞吐量条件下从已部署的模型生成响应。例如，在下面的代码块中，我们编译了 1,000 个有效负载的列表，每个有效负载请求生成 100 个令牌。总之，我们请求生成 100,000 个代币。

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

向 SageMaker 运行时 API 发送大量请求时，您可能会遇到限制错误。为了缓解这种情况，您可以创建一个自定义 SageMaker 运行时客户端来增加重试尝试的次数。您可以将生成的 SageMaker 会话对象提供给 JumpStartModel 构造函数或 sagemaker.predictor.retrieve_default 如果您想将新的预测器附加到已部署的端点。在以下代码中，我们在使用默认 SageMaker JumpStart 配置部署 Llama 2 模型时使用此会话对象：

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

这个部署的端点有 MAX_CONCURRENT_REQUESTS = 128 默认情况下。在下面的块中，我们使用并发 futures 库迭代调用具有 128 个工作线程的所有有效负载的端点。端点最多会处理128个并发请求，每当请求返回响应时，执行器就会立即向端点发送新的请求。

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

这会导致在单个 ml.g100,000xlarge 实例上生成总共 1255 个令牌，吞吐量为 5.2 个令牌/秒。处理过程大约需要 80 秒。

请注意，此吞吐量值与本文前面的表中 ml.g2xlarge 上 Llama 7 5.2B 的最大吞吐量（486 个并发请求时为 64 个令牌/秒）明显不同。这是因为输入有效负载使用 8 个令牌而不是 256 个，输出令牌计数是 100 个而不是 256 个，并且较小的令牌计数允许 128 个并发请求。最后提醒您，所有延迟和吞吐量数字均取决于有效负载！更改有效负载令牌计数将影响模型服务期间的批处理过程，进而影响应用程序的紧急预填充、解码和排队时间。

结论

在这篇文章中，我们介绍了 SageMaker JumpStart LLM 的基准测试，包括 Llama 2、Mistral 和 Falcon。我们还提供了优化端点部署配置的延迟、吞吐量和成本的指南。您可以通过运行以下命令开始 相关笔记本 对您的用例进行基准测试。

作者简介

 凯尔乌尔里希博士 是 Amazon SageMaker JumpStart 团队的应用科学家。 他的研究兴趣包括可扩展的机器学习算法、计算机视觉、时间序列、贝叶斯非参数和高斯过程。 他拥有杜克大学博士学位，并在 NeurIPS、Cell 和 Neuron 上发表过论文。

Dr。维韦克·马丹 是 Amazon SageMaker JumpStart 团队的一名应用科学家。 他在伊利诺伊大学厄巴纳-香槟分校获得博士学位，并且是乔治亚理工学院的博士后研究员。 他是机器学习和算法设计方面的活跃研究员，并在 EMNLP、ICLR、COLT、FOCS 和 SODA 会议上发表过论文。

Ashish Khetan 博士 是 Amazon SageMaker JumpStart 的高级应用科学家，帮助开发机器学习算法。 他在伊利诺伊大学厄巴纳-香槟分校获得博士学位。 他是机器学习和统计推断领域的活跃研究员，并在 NeurIPS、ICML、ICLR、JMLR、ACL 和 EMNLP 会议上发表了多篇论文。

若昂·莫拉 是 AWS 的高级 AI/ML 专家解决方案架构师。 João 帮助 AWS 客户（从小型初创公司到大型企业）高效地训练和部署大型模型，并在 AWS 上更广泛地构建 ML 平台。

• SEO 支持的内容和 PR 分发。 今天得到放大。
• PlatoData.Network 垂直生成人工智能。 赋予自己力量。 访问这里。
• 柏拉图爱流。 Web3 智能。 知识放大。 访问这里。
• 柏拉图ESG。 碳， 清洁科技, 能源， 环境， 太阳能， 废物管理。 访问这里。
• 柏拉图健康。 生物技术和临床试验情报。 访问这里。
• Sumber: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/