SageMaker Inference 支持 NVIDIA MIG GPU 分区，提升模型端点 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 支持将为 enterprise 客户带来切实的技术和商业价值。”

— 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 配置文件是值得了解的一个，因为它的两个维度并不匹配：它占用七个计算单元中的三个，却占用八个内存单元中的四个。两个 3g 分区会占满 GPU，其余任何配置都无法再放进去。

高层规则：布局中的每个配置文件都必须是你的 GPU 所提供的，且各配置文件占用的计算和内存单元之和不得超过单个设备所提供的数量。这两点都会在创建端点配置时进行检查，任一不满足都会被拒绝，而不是回退到整个加速器。

P4d 驱动程序说明： mig-1g.10gb 需要 R525 或更新的 NVIDIA 驱动，而默认的 P4d 镜像自带 470.256.02。在默认镜像上请求它时，划分会失败且报错信息不会指明该配置档。将生产变体的 InferenceAmiVersion 设为 al2023-ami-sagemaker-inference-gpu-4-1，以获得 580 驱动系列的镜像，该驱动支持它。

为你的工作负载选择划分方式

选择得好不好是一回事，选择一个仅仅被接受的划分是另一回事。一个分区以固定比例提供计算和内存，而这两者在推理过程中承担不同的任务。

计算单元是 prefill（预填充）所需的。 Prefill 读取提示词并构建其表示。这是计算密集型阶段，其扩展能力取决于分区所拥有的流式多处理器数量，也就是 TFLOPs。输入越长、同时到达的提示越多，这一阶段就越决定你返回首个 token 的速度。

内存单元是 decode（解码）和容量所需的。 生成 token 时每一步都要重新读取模型权重，因此 decode 受内存带宽而非算力限制，同时内存也决定了你能容纳多少 KV cache。这个上限进而决定你能服务的上下文长度以及可并发服务的序列数量。

几乎没有真实工作负载只用到其中一方面，所以目标不是选某个维度，而是选择一种能支撑你用例的组合。 选择一个比例能覆盖你最重负载阶段、同时另一面也得到充分保障的配置档。在计算方面，关键是提示词有多长、一次到达多少条。在内存方面，关键则是输出长度、上下文窗口和并发数。

内存是两者中更容易被低估的，因为一个分区要容纳的不只是模型，而是三样东西：权重——一个 FP16 的 8B 模型约 16 GB；KV cache——按你打算允许的上下文长度和并发序列数来定，这是人们常常遗漏、且随流量增长的一项；还有 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 是更便宜的单位。这些价格均为按需价格，分析时的测量值为：ml.p4d.24xlarge 每小时 $25.251286，ml.p5.48xlarge 每小时 $63.296000，均位于 AWS 美国西部（俄勒冈）区域。纯粹出于我们自己的分析，我们用整实例成本除以其上的单元数来推导单位成本：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 的整台加速器作为合适的单元，已不再是一个只能向上取整来回答的问题，而是可以实测的问题。

关于作者