人工智能
SageMaker Inference 现已支持多实例 GPU，以最大化模型端点的 GPU 利用率当你将模型部署到 GPU 端点时，你能请求的最小 GPU 单位是一整块加速器。
这一限制会给你带来双重代价。首先，你无法在实例上托管超过其加速器数量的模型。一台 ml.p4d.24xlarge 拥有八块 A100，因此它只能承载八个模型，无论每个模型需要 40 GB 还是 14 GB。其次，而且不那么显而易见的是，它使每次部署都归结为选择部署到哪一整块 GPU 上。随着你的并发量和提示长度增长，旧实例上的一整块 GPU 不再够用，而新实例上的一整块 GPU 又超出了模型所能利用的范围。最终你要么服务不足，要么为永远达不到的能力付费。
今天，Amazon SageMaker Inference 支持 GPU 分区，它使用 NVIDIA 多实例 GPU （MIG）将一块物理 GPU 划分为独立的分区。每个分区获得 GPU 计算单元的固定份额和一块专用内存，隔离在硬件层面强制执行。这改变了上述两项限制：你可以在每个分区中放置不同的模型，也可以选择较新加速器的一部分，而不是两代产品中任一整块。
本文涵盖这两方面。第一部分是直接收益：部署比 GPU 数量更多的模型，并在它们之间实现隔离。第二部分是客户在谈到成本时最关心的问题：分区的粒度如何帮助你选择合适大小的单元，以及我们实测的结果。
在继续阅读之前需要了解一点：GPU 分区适用于使用 推理组件的端点，这是你用来将多个模型部署到一个端点并设置每个模型所获算力的构造。分区直接构建在其之上。分区是组件请求的一种资源，与它已经请求 CPU 和内存的位置相同。如果你尚未使用过推理组件，这篇 文章 对它们做了介绍。单模型端点、无服务器端点和异构实例池无法进行分区。
客户目前的做法，以及每种方案为何不够用
如果你的模型数量多于加速器数量，你一直有三种选择。
运行更少、更大的端点并加大批处理 – 这提高了利用率，但仅在模型可互换时有效。一组微调变体或按租户划分的模型则不是。
使用多模型端点 – 这些端点按需从共享 GPU 加载和卸载模型，适合稀疏、突发性的流量。但模型共享设备而没有隔离，因此对某个模型的重请求会影响其他模型。未加载的模型在首次使用时还要承担加载惩罚。
迁移到自管理 Kubernetes – 这正是需要真正 GPU 分区的客户所采取的做法。MIG 在那里可以工作，但你需要承担驱动版本管理、分区配置、设备插件、调度，以及在整支机群中保持这一切一致的工作。对于你的实例已经具备的硬件能力来说，这是大量的工作。
为什么选择 MIG
NVIDIA 多实例 GPU（MIG）将一块 GPU 拆分为最多七个实例，具体取决于 GPU。每个实例拥有自己的计算、缓存、内存和内存带宽。由于拆分是在硬件而非软件层面进行的，你能获得其他共享方式无法提供的保证：
- 可预测的延迟 – 每个分区拥有专用内存带宽，因此一个模型的流量高峰不会出现在另一个模型的 p99 中。
- 故障隔离 – 崩溃或内存错误会留在其分区内，而不会导致 GPU 上的所有模型宕机。
- 大小合适的容量 – 中小型模型获得适合它们的切片，而不是一整块 GPU。你可以在一个设备上混合使用不同大小的切片。
- 无冷启动 – 每个模型保留自己的分区并保持加载状态，没有加载惩罚，也没有驱逐。
- 租户隔离 – 分区之间的内存保护在硬件层面强制执行，这使安全和合规审查更加简单。
- 可靠的规划与成本分摊 – 一个分区的性能表现与其邻居无关，因此负载测试可以预测生产环境。GPU 成本也能清晰地映射到模型、团队或租户。
分区有一些值得事先了解的边界。最大分区数取决于加速器，且从不超过七个。MIG 本身只允许在其分区空闲时更改布局，而在 SageMaker AI 上，这意味着在创建端点时选择布局。需要多于一块 GPU 的模型仍然需要整块设备。在这些边界之内，你可以获得独立 GPU 的隔离，而无需为每个模型专门分配一块。
无需平台工作的分区
到目前为止，获得 MIG 意味着自己运行 Kubernetes 栈。Amazon SageMaker AI 上的 GPU 分区消除了这一步：你为模型选择一个分区配置文件，SageMaker AI 负责 GPU 配置、放置和扩缩。你在托管端点上获得硬件隔离的 GPU 共享，而无需运行其底层平台。
Salesforce 从一开始就参与了这项工作，帮助定义需求并验证初始实现。
“NVIDIA MIG 将单块 GPU 划分为多个隔离实例，每个实例拥有专用的计算和内存资源。Salesforce 认为这是一项重要能力，因为许多推理工作负载并不需要整块 GPU。MIG 将使我们能够安全地整合工作负载，显著提高 GPU 利用率，降低推理成本，并保持可预测的性能和强大的隔离性。
这项能力将帮助我们在不同用例中更高效地扩展 AI 推理。Salesforce 帮助定义了需求，验证了初始解决方案。我们现在正准备用具有代表性的生产工作负载验证该解决方案，并向 AWS 展示强劲的客户需求。我们相信 MIG 支持将为企业客户带来有意义的技术和商业价值。”
— Richard Chang，Salesforce 软件工程架构师
工作原理
GPU 分区会为你已有的 API 调用增加两个可选字段。没有新的 API 操作、没有新的资源类型、也没有新的 AWS Identity and Access Management (IAM) 操作，而省略这两个字段的端点行为与现在完全一致。
AcceleratorPartitionLayouts 放在生产变体上， CreateEndpointConfig 并声明每个加速器如何划分：
{
"EndpointConfigName": "multi-model-partitioned",
"ExecutionRoleArn": "<execution-role-arn>",
"ProductionVariants": [
{
"VariantName": "AllTraffic",
"InstanceType": "ml.p4d.24xlarge",
"InitialInstanceCount": 1,
"AcceleratorPartitionLayouts": [
{ "AcceleratorPartitionTypes": ["mig-4g.20gb", "mig-2g.10gb", "mig-1g.5gb"] }
]
}
]
}一块 A100 有七个计算切片可供划分。上述布局用满了全部七个，因此 p4d 实例上的八块 A100 每块承载三个分区，端点共提供 24 个分区，每种类型各八个。
这种切分是统一应用的。一个布局条目描述一个加速器如何划分，而该变体中每个实例上的每个加速器都按相同方式划分。该列表不是按位置对应的，因此一个条目并不映射到某块特定的 GPU。
AcceleratorPartitionType 放在推理组件上，并选择模型运行在哪个分区上：
{
"InferenceComponentName": "summarizer",
"EndpointName": "multi-model-partitioned",
"VariantName": "AllTraffic",
"Specification": {
"ModelName": "summarizer-model",
"ComputeResourceRequirements": {
"AcceleratorPartitionType": "mig-4g.20gb",
"NumberOfAcceleratorDevicesRequired": 1,
"NumberOfCpuCoresRequired": 1,
"MinMemoryRequiredInMb": 2048
}
},
"RuntimeConfig": { "CopyCount": 1 }
}每个组件副本占用一个所请求类型的分区。实例上每种类型有八个分区，提高 CopyCount 会将额外副本放置到空闲分区上。这对于服务高并发的小模型很有用，因为单个进程会让 GPU 等待请求。
NumberOfAcceleratorDevicesRequired 在这里始终为 1。设置了分区类型后，它表示一个分区而非一个加速器。 NumberOfCpuCoresRequired 和 MinMemoryRequiredInMb 仍然描述主机 CPU 和主机内存，因为 GPU 内存来自分区类型。
调用方式不变。 InvokeEndpoint 通过推理组件名称来寻址模型，而它所占用的分区从不出现在请求中。
分区在端点预置时进行。当端点达到 InService 时，每个加速器都已完成切分，且分区为空，这是一个有效状态，因为组件随后会落到这些分区上。在我们的测试中，切分加速器使预置时间增加了约 17 秒。其余时间则是通常的实例启动和容器拉取。
按 GPU 划分的分区配置文件
你可用的配置文件是 GPU 的属性，因此首先查明你的实例类型搭载哪种 GPU，并在 NVIDIA 支持的 MIG 配置文件中查找它，该文档是完整配置文件集合以及单设备上有效组合的权威来源。
| 实例系列 | 加速器 | GPU 内存 | 粒度（计算 / 内存） | 可用分区配置文件 | 每 GPU 最大分区数 |
| P4d | NVIDIA A100 | 40 GB | 7 / 8 | mig-1g.5gb, mig-1g.10gb （见驱动说明）, mig-2g.10gb, mig-3g.20gb, mig-4g.20gb, mig-7g.40gb | 7 |
| P5 | NVIDIA H100 | 80 GB | 7 / 8 | mig-1g.10gb, mig-1g.20gb, mig-2g.20gb, mig-3g.40gb, mig-4g.40gb, mig-7g.80gb | 7 |
| G7 | NVIDIA RTX PRO 4500 Blackwell | 32 GB | 2 / 2 | mig-1g.16gb, mig-2g.32gb | 2 |
| G7e | NVIDIA RTX PRO 6000 Blackwell Server Edition | 96 GB | 4 / 4 | mig-1g.24gb, mig-2g.48gb, mig-4g.96gb | 4 |
将配置文件名称读作计算单元后跟 GPU 内存： mig-3g.40gb 占用三个计算单元和 40 GB。粒度列是限制布局的因素。A100 和 H100 在计算上分为七份、在内存上分为八份，而 G7 分为两份、G7e 分为四份。即使切片数量相同，不同 GPU 之间的配置文件名称也不同，因此不要未经对照此表就将布局从一个实例系列套用到另一个实例系列。
在这些限制之内，你有真正的选择。在 P4d 或 P5 上，你可以切出七个最小配置文件，或两个 3g 分区，或前面示例中使用的 4g 加 2g 加 1g 布局，或将整个设备作为一个分区。在 G7e 上，你可以取四个最小分区，或两个 1g 加一个 2g，或两个 2g，或一个整设备。在 G7 上，要么两个分区，要么一个。
3g 配置文件是必须了解的一个，因为它的两个维度并不匹配：它占用七个计算单元中的三个，但占用八个内存单元中的四个。两个这样的分区就填满了 GPU，其他任何分区都无法再放在旁边。
高层规则： 你布局中的每个配置文件都必须是你的 GPU 所提供的，并且你的配置文件加起来所占用的计算单元和内存单元不得超过单个设备所提供的量。这两项都会在你创建端点配置时进行检查，任何一项不通过都是拒绝，而不是回退到整个加速器。
P4d 的驱动说明： mig-1g.10gb 需要 R525 或更新的 NVIDIA 驱动，而默认的 P4d 镜像搭载的是 470.256.02。在默认镜像上请求它，切分会失败，且不会给出指明该配置文件的错误。在生产变体上将 InferenceAmiVersion 设置为 al2023-ami-sagemaker-inference-gpu-4-1 ，以获得 580 驱动系列的镜像，该镜像提供此配置文件。
为你的工作负载选择布局
选得好与仅仅选择一个被接受的布局是不同的问题。分区以固定比例为你提供计算和内存，而这两者在推理期间承担不同的任务。
计算单元是预填充所需要的。 预填充读取提示并构建其表示。这是计算密集的阶段，它随你的分区所拥有的流式多处理器数量（也就是 TFLOPs）而扩展。你的输入越长、同时到达的提示越多，它就越决定你返回首个 token 的速度。
内存单元是解码和容量所需要的。 生成 token 会在每一步重新读取模型权重，因此解码受内存带宽而非数学运算的限制，内存还限制了你所能持有的 KV 缓存量。该上限反过来决定了你可以服务的上下文长度以及可以并发服务的序列数量。
几乎没有真实工作负载只用到其中一项，因此目标不是挑选一个维度，而是选择一种支持你用例的组合。 选择一个比例能覆盖你最重阶段、同时让另一项得到充分服务的配置文件。在计算方面，重要的是你的提示有多长以及同时到达多少。在内存方面，则是你的输出长度、上下文窗口和并发度。
内存是两者中更容易被低估的，因为一个分区必须容纳三样东西，而不仅仅是模型：权重，对于 FP16 的 8B 模型来说约为 16 GB；KV 缓存，其大小取决于上下文长度和你打算允许的并发序列数——这是人们常忽略的一项，也是随流量增长的一项；以及 1–2 GB 的运行时开销，用于 CUDA 上下文和服务进程。在选择配置文件之前先把这些加起来，因为仅按权重确定大小的分区会加载模型，然后在负载下失败，或者悄悄提供比你配置短得多的上下文。作为一个具体的参考点，同一个 FP16 的 8B 模型在 40 GB 分区上可以轻松服务 8,000 token 的上下文。
MIG 带来最大价值的场景
由小型和中型模型组成的组合 – 最直接的情况。微调变体、嵌入模型、重排器和分类器各自都会让加速器的大部分处于闲置状态，现在它们可以共享一个加速器。
多租户模型服务 – 当你为每个客户托管一个模型时，MIG 在它们之间提供了硬件边界：一个分区中的进程无法读取另一个分区的内存，也无法占用其吞吐量。不过，要准确界定这一说法。同一实例上的模型仍然共享主机 CPU、系统内存、存储、网络和端点路由，因此分区是 GPU 的隔离机制，而不是完整的租户边界。
单实例上的多阶段流水线 – 一个转录模型、一个说话人分离模型和一个语言模型，或者一个嵌入器、一个重排器和一个生成器。每个阶段都是各自分区上可单独寻址的组件，阶段之间的网络跳转也随之消失。
请求路径中的小型模型 – 一个安全分类器或护栏模型，它必须在每个请求上运行，但不足以证明需要一整个加速器，并且由于它不与主模型进行时间分片，因此具有可预测的延迟。
挑战者与金丝雀 – 在服务生产流量的模型旁边的小分区上运行候选模型，而不是搭建第二个端点。
性能：较新 GPU 的一个切片对比较旧 GPU 的完整实例
除了装箱之外，你获得的另一个好处是高端 GPU 上的粒度：有更多 GPU 选项可用于部署模型，并且可以选择哪一个属于你。每个受支持的加速器都变成多个规格而不是一个，因此实际的思考方式是，每个配置文件本身就是一个 GPU 选项，与你已经在其中做选择的完整加速器并列。当你考虑更大或更新的实例类型时，这一点最为重要，因为升级不再是全有或全无：你可以按工作负载的需要，以它发布的任何规格，取用那块更大 GPU 的多或少，而不必为整个加速器付费。
为了看看这是否划算，我们比较了一个 mig-3g.40gb H100 分区与一个完整的、未切分的 A100-40GB。两者的 GPU 内存相当，这使它成为观察更先进实例的一个切片能有多强大的清晰方式。
我们使用 genai-bench 生成负载，从同一个客户端驱动两个端点，因此 GPU 是唯一的变量。双方都在生产 SageMaker 实时端点上运行 Llama-3.1-8B-Instruct，各有一个模型副本，容器镜像、分词器和客户端配置完全相同。两者都通过 SageMaker AI 原生 OpenAI 兼容路由调用。我们扫描了五种流量形态，记为 D(输入 token, 输出 token)，从短提示到长上下文摘要，每种都在从 2 到 512 的并发阶梯上进行测试。
图 1：一个 H100 的 mig-3g.40gb 分区与一个完整 A100-40GB 在五种流量形态和从 2 到 512 的并发阶梯下的每秒聚合输出 token 数
图 2：同样五种流量形态下，每百万输出 token 的分区成本收益随并发的变化
有四点很突出。
- 该分区在所有方面都更快 – 它在每个场景、每种并发下都提供了更高的每秒输出 token 数，在每个场景成本收益最大的负载下高出 53% 到 89%，并且在每个场景中 token 间延迟也更低，低了 8.9% 到 42.1%。差距随负载增大而扩大。
- 每种情况下的首 token 时间都更低，低了 5.6% 到 47.5%。
- 在成本上，每百万输出 token 便宜 18–34%，高于一个随提示变长而提前出现的交叉点。 100 token 提示的并发为 64，8,000 token 提示的并发为 4。低于交叉点时，完整的 A100 是更便宜的单位。这些价格均为按需价格，分析时在美国西部（俄勒冈）AWS 区域测得为每小时 $25.251286（
ml.p4d.24xlarge）和每小时 $63.296000（ml.p5.48xlarge）。纯粹为了我们自己的分析，我们通过将整个实例成本除以其上的单元数来推导单位成本：p4d 上为 8，p5 上为 16，而我们的分区是半个 GPU。 - 在长上下文流量的阶梯顶端，A100 停止了服务。 在 6,000 和 8,000 token 的工作负载上，它都有三分之一到一半的请求未能满足服务路径的截止时间，而该分区没有失败任何请求。这就是为什么这两个面板比其他面板结束得更早。
请将此视为逐案比较，而非定论。 有用的心智模型是将可用的 GPU 分数视为独立的 GPU 类型。将它们与完整加速器并列列出，弄清你的流量对计算和内存的实际需求，并在你自己的工作负载上进行比较。对于高并发、长输入流量，该分区在这里在性能和成本上都胜出。对于短输入或低并发工作负载，完整的 A100 仍然更便宜。分区并非放之四海而皆准的答案。它为你提供了更多规格可供选择，因此你可以挑选适合你工作负载的那一个。
在确定布局之前需要了解的事项
分区改变了端点的形态，在设计之前有几项特性值得理解。
组件的分区类型在该组件的整个生命周期内固定不变。将模型迁移到不同的配置文件意味着要创建新的组件。更改端点的切分方式意味着要新建端点并进行流量迁移，因为更新端点配置不会重新切分已在运行的主机。因此，分区适合稳定的组合，而不适合每天重新调整的混合组合。
请求的配置文件必须存在于端点的布局中。不会回退到整个加速器，因此请求变体未声明配置文件的组件会被拒绝。
分区适用于推理组件端点上的实时推理。不支持无服务器端点和异构实例池，异步调用无法寻址推理组件，因此异步工作负载不在范围内。
您需要为整个 GPU 实例付费，与现在一样。分区提高了您可以使用该实例的比例，但不会改变其每小时价格。
最后，确实需要完整加速器或不止一个加速器的模型应继续拥有一个。任何分区都不会跨加速器。
支持的实例和区域
GPU 分区在 P4d、P5、G7 和 G7e 实例系列上可用。支持是在系列级别，因此系列内较小的规格也涵盖在内。
它在以下 AWS 区域可用：美国东部（弗吉尼亚北部）、美国东部（俄亥俄）、美国西部（俄勒冈）、亚太地区（新加坡）、亚太地区（东京）、欧洲（法兰克福）和欧洲（爱尔兰）。
实例可用性因区域而异，因此请确认您选择的实例类型在您的区域中提供，并且您拥有该实例的端点使用配额。
开始使用
要对 GPU 端点进行分区，请计算您的模型各自的内存和计算需求，选择适合的配置文件，在端点配置上声明布局，并将每个模型部署为请求该布局中配置文件的推理组件。调用模型的方式没有任何变化。
有关 API 参考、每个实例系列的完整配置文件表以及分步演练，请参阅 Amazon SageMaker AI 开发人员指南中的 GPU 分区 。
要自行尝试，请运行 GPU 分区示例笔记本，它将多个模型部署到单个 GPU 端点的分区上。
在规划容量时，值得记住更广泛的变化。现在每个受支持的加速器都有多个规格，而不是一个。对于给定模型，较新 GPU 的分区还是较旧 GPU 的完整加速器才是正确的单位，这不再是一个需要通过向上取整来回答的问题。这是一个可以衡量的问题。