SageMaker Inference 支持 NVIDIA MIG GPU 分区

当你将模型部署到 GPU 端点时，你能请求的最小 GPU 单位是一整块加速器。

这一限制会让你付出双重代价。首先，在一个实例上能承载的模型数量不能超过其加速器数量。一台 ml.p4d.24xlarge 有八块 A100，因此最多承载八个模型，无论每个模型需要 40 GB 还是 14 GB。其次，且不那么明显的是，它让每次部署都归结为选择部署到哪一整块 GPU 上。随着并发量和提示长度增长，旧实例上的一整块 GPU 不再够用，而新实例上的一整块 GPU 又超出模型所需。最终你要么服务不足，要么为永远用不到的能力付费。

如今，Amazon SageMaker Inference 支持 GPU 分区，它利用 NVIDIA Multi-Instance GPU（MIG）将一块物理 GPU 划分为多个独立分区。每个分区获得 GPU 计算单元的固定份额和一块专用内存，隔离由硬件强制执行。这改变了上述两个限制：你可以在每个分区中放置不同的模型，也可以选择使用较新加速器的一部分，而不是任一世代的一整块。

本文涵盖这两方面。第一部分是直接收益：部署的模型数量可以多于 GPU 数量，且彼此隔离。第二部分是客户在谈到成本时关心的问题：分区的粒度如何帮助你选择合适大小的单元，以及我们实测的结果。

在继续阅读之前需要了解一点：GPU 分区适用于使用 推理组件 的端点，推理组件是你用来将多个模型部署到一个端点并设置每个模型所获算力的构造。分区直接构建在其之上。分区是组件请求的一种资源，请求位置与它请求 CPU 和内存的位置相同。如果你尚未使用过推理组件，这篇文章 对其做了介绍。单模型端点、无服务器端点和异构实例池无法进行分区。

客户目前的做法，以及每种方案的不足

如果你的模型数量多于加速器数量，你一直有三种选择。

运行更少、更大的端点并加大批处理 – 这能提高利用率，但前提是模型可以互换。一组微调变体或按租户划分的模型则不行。

使用多模型端点 – 这些端点按需从共享 GPU 加载和卸载模型，适合稀疏、突发性的流量。但模型共享设备且没有隔离，因此对某个模型的重请求会影响其他模型。未加载的模型在首次使用时还要承担加载惩罚。

迁移到自管理的 Kubernetes – 需要真正 GPU 分区的客户正是走了这条路。MIG 在那里可以工作，但你需要承担驱动版本管理、分区配置、设备插件、调度，以及在整批机器上保持一致性。对于你的实例本就具备的硬件能力来说，这是大量工作。

为什么选择 MIG

NVIDIA Multi-Instance GPU（MIG）将一块 GPU 拆分为最多七个实例，具体取决于 GPU。每个实例拥有自己的计算、缓存、内存和内存带宽。由于拆分是在硬件而非软件层面完成的，你能获得其他共享方式无法提供的保证：

1. 可预测的延迟 – 每个分区拥有专用内存带宽，因此一个模型的流量高峰不会出现在另一个模型的 p99 中。
2. 故障隔离 – 崩溃或内存错误会留在其分区内，而不会导致 GPU 上的所有模型一起宕机。
3. 容量适配 – 中小型模型获得适合它们的切片，而不是占用整个 GPU。你可以在同一设备上混合使用不同大小的切片。
4. 无冷启动 – 每个模型保留自己的分区并保持加载状态，没有加载开销，也不会被驱逐。
5. 租户隔离 – 分区之间的内存保护由硬件强制执行，这使安全与合规审查更加简单。
6. 可靠的规划与计费 – 分区的性能不受相邻分区影响，因此负载测试可以预测生产环境表现。GPU 成本也能清晰地对应到模型、团队或租户。

分区有一些值得提前了解的边界。最大分区数取决于加速器，且永远不超过七个。MIG 本身只允许在分区空闲时更改布局，而在 SageMaker AI 上，这意味着在创建端点时选择布局。需要多个 GPU 的模型仍然需要整台设备。在这些边界之内，你可以获得独立 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 内存：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 的任意多或任意少，而不是为整个加速器付费。

为了看看这是否划算，我们将 H100 的一个 mig-3g.40gb 分区与一整块未切分的 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 区域中一个 ml.p4d.24xlarge 为每小时 $25.251286，一个 ml.p5.48xlarge 为每小时 $63.296000。仅为我们自己的分析，我们通过将整实例成本除以其上的单元数来推导单位成本：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 的一个分区，还是较旧加速器的一整块，才是合适的单元，这不再是一个需要靠向上取整来回答的问题。这是一个你可以测量的问题。

关于作者

Shantanu Tripathi

Shantanu 是 AWS 的软件开发工程师，拥有构建大规模 AI/ML 基础设施的经验。作为 Amazon SageMaker 的核心工程师，他参与设计和优化面向高性能 AI 工作负载的可扩展推理解决方案。他的广泛经验涵盖分布式 AI 训练库、深度学习容器（DLC）、深度学习 AMI 以及生成式 AI 解决方案。工作之余，他喜欢戏剧和游泳。

Apoorva Chandra

Apoorva 是 Amazon SageMaker AI 推理团队的产品经理，专注于端点体验和托管体验。她与在生产环境中部署生成式 AI 模型的客户合作，让加速计算更易获取、运行更具成本效益、运营更可预测。工作之余，Apoorva 喜欢徒步、探索咖啡店以及与朋友共度时光。

Dmitry Soldatkin

Dmitry 是 SageMaker 推理领域的全球专家解决方案架构负责人。在这一职位上，Dmitry 帮助客户设计、构建和优化生成式 AI 及 AI/ML 解决方案。Dmitry 的工作涵盖广泛的 ML 用例，主要兴趣在于生成式 AI、深度学习以及在企业范围内扩展 ML。他曾帮助金融服务、保险和电信等多个行业的公司。