SageMaker Inference 现已支持 Multi-Instance GPU，可提升模型端点的 GPU 利用率

AWS ML Blog 2026-11-07T02:01:00+08:00

Amazon SageMaker Inference 现在支持多实例 GPU（Multi-Instance GPU，MIG），用于提高模型端点的 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 数量，并且模型之间相互隔离。第二部分是客户在关心成本时最常问的：分区粒度如何帮你选到合适大小的算力单元，以及我们实测得到了什么结果。

阅读之前有一点需要知道：GPU 分区适用于使用推理组件（inference components）的端点。推理组件是你用来把多个模型部署到同一个端点、并为每个模型设定算力的构造。分区直接构建在它之上。分区是组件请求的一种资源，和组件请求 CPU、内存是同一个地方。如果你还没用过推理组件，本文会介绍它。单模型端点、无服务器端点和异构实例池不支持分区。

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

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

少跑大端点、加大批处理

这种方式能提升利用率，但前提是模型之间可以互换。如果是一批微调变体，或者每个租户各自的模型，就行不通。

使用多模型端点

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

转向自管理 Kubernetes

需要真正 GPU 分区的客户都走了这条路。MIG 在那里能用，但你要自己管驱动版本、分区配置、设备插件、调度，还要保证整个集群的一致性。为了一个实例本来就具备的硬件能力，这工作量太大了。

为什么选 MIG

NVIDIA 多实例 GPU（MIG）能把一块 GPU 拆成最多七个实例，具体数量取决于 GPU 型号。每个实例有独立的计算、缓存、显存和显存带宽。因为拆分在硬件层完成而非软件层，你能得到其他共享方式给不了的保障：

• 延迟可预测：每个分区有专属显存带宽，一个模型的流量高峰不会反映到另一个模型的 p99 上。
• 故障隔离：崩溃或显存错误被限制在分区内，不会拖垮 GPU 上的所有模型。
• 容量适配：中小模型拿到适合自己大小的切片，而不是整块 GPU。你可以在同一设备上混用不同大小的切片。
• 无冷启动：每个模型保留自己的分区并常驻加载，没有加载惩罚，也不会被驱逐。
• 租户隔离：分区之间的内存保护由硬件强制执行，安全和合规审查更简单。
• 规划与计费可靠：分区性能不受邻居影响，负载测试能预测生产表现。GPU 成本也能清晰地对应到模型、团队或租户。

分区有一些边界值得提前了解。最大分区数取决于加速器，且不超过七个。

MIG 本身只允许在分区空闲时更改布局，在 SageMaker AI 上，这意味着你需要在创建端点时选好布局。如果一个模型需要的显存超过单块 GPU 能提供的量，那它仍然要用整块设备。在这些限制之内，你能获得独立 GPU 那样的隔离效果，又不必为每个模型单独占用一块 GPU。

无需自建平台即可实现分区

在此之前，要用上 MIG 就得自己维护整套 Kubernetes 技术栈。Amazon SageMaker AI 上的 GPU 分区省掉了这一步：你只需为模型选一个分区配置（partition profile），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 里的一个生产变体（production variant）上，用来声明每块加速卡如何划分：

{

"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 有 7 个计算切片（compute slice）可以划分。上面的配置用满了全部 7 个切片，因此 p4d 实例上的 8 块 A100 每块都会承载 3 个分区，整个端点共提供 24 个分区，每种类型各 8 个。分区方式是统一套用的：一条布局条目描述的是“一块加速器怎么切分”，该变体下每台实例上的每块加速器都会按同样方式切分。这个列表不按位置对应，所以某一条目并不绑定到某块具体的 GPU。

AcceleratorPartitionType 则配置在推理组件（inference component）上，用来指定模型跑在哪个分区：

{
  "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 }

每个组件副本占用一个指定类型的分区。每种分区类型在实例上有 8 个，因此调大 CopyCount 就能把更多副本放到空闲分区上。这适合小模型应对高并发：单个进程会让 GPU 空等请求。这里 NumberOfAcceleratorDevicesRequired 始终为 1，一旦设置了分区类型，就代表一个分区而不是一整块加速器。NumberOfCpuCoresRequired 和 MinMemoryRequiredInMb 仍然描述宿主 CPU 和宿主内存，因为 GPU 显存来自分区类型。调用方式不变，InvokeEndpoint 按推理组件名称寻址模型，它占用的分区不会出现在请求里。分区在端点配置阶段完成，进入 InService 时每个加速器都已划分好、分区为空，这是正常状态，组件随后会落到这些分区上。测试中，划分加速器让配置时间增加了约 17 秒，其余时间花在常规的实例启动和容器拉取上。

按 GPU 划分的分区配置

可用配置由 GPU 决定，所以先确认实例类型用的是哪块 GPU，再到 NVIDIA 支持的 MIG 配置表里查——这份表是完整配置集合以及单设备合法组合的权威依据。

配置名称的读法是计算单元在前、GPU 显存在后：mig-3g.40gb 占用三个计算单元和 40 GB 显存。粒度这一列决定了布局上限。A100 和 H100 在计算上可切成 7 份、显存上切成 8 份，G7 只能切成两半，G7e 切成四份。

即使切片数量相同，不同 GPU 的配置档名称也不一样。把一种布局从某个实例族搬到另一个实例族之前，务必先对照这张表核对。在这些限制之内，你有相当大的选择空间。在 P4d 或 P5 上，你可以切出 7 个最小配置档，或两个 3g 分区，或前面例子里的 4g + 2g + 1g 布局，也可以把整块设备当成一个分区来用。在 G7e 上，可以取 4 个最小档，或两个 1g 加一个 2g，或两个 2g，或整块设备。在 G7 上，要么两个分区，要么一个。

最需要记住的是 3g 配置档，因为它两个维度并不对等：它占用 7 个计算单元中的 3 个，却占用 8 个显存单元中的 4 个。两个 3g 就能占满整块 GPU，旁边再也塞不下别的东西。概括性的规则是：布局里的每个配置档都必须是你的 GPU 支持的，且各配置档加起来占用的计算单元和显存单元，不能超过单块设备提供的总量。创建端点配置时这两项都会校验，任何一项不通过都会直接拒绝，而不会退回到整块加速器。

P4d 的驱动注意事项：mig-1g.10gb 需要 R525 或更新的 NVIDIA 驱动，而 P4d 默认镜像自带的是 470.256.02。如果在默认镜像上申请这个配置档，切分会失败，而且报错信息里根本不会指出是哪个配置档。在生产变体上把 InferenceAmiVersion 设为 al2023-ami-sagemaker-inference-gpu-4-1，就能用上 580 驱动系列的镜像，它支持这个配置档。

为你的工作负载选择布局

选得好，和选一个仅仅能通过校验的布局，是两个不同的问题。一个分区会按固定比例分给你计算资源和显存，而在推理过程中这两者承担的任务并不相同。

计算单元是预填充（prefill）阶段所需要的。预填充会读取提示词并构建其表示。这是计算密集的阶段，其速度随分区的流式多处理器（streaming multiprocessor）数量扩展，也就是随你分到的 TFLOPs 扩展。输入越长、同时到达的提示词越多，这一阶段就越决定你返回首个 token 的速度。显存单元则是解码（decode）阶段以及容量所需要的。

生成 token 时每一步都要重新读取模型权重，所以解码速度受内存带宽限制，而不是受算力限制；内存容量还决定了能容纳多少 KV cache，进而决定你能服务的上下文长度和并发序列数。几乎没有哪种真实负载只用得上其中一项，所以目标不是挑某一个维度，而是找到能覆盖你实际场景的组合。选一个配比能覆盖最重阶段、同时其余阶段也够用的 Profile。算力方面，关键看 prompt 有多长、同时到达多少；内存方面，看输出长度、上下文窗口和并发数。内存这项更容易被低估，因为一个分区不只要装模型，还得装三样东西：权重，8B 模型 FP16 约 16 GB；KV cache，按你要支持的上下文长度和并发序列数来算，这一项最常被漏掉，而且会随流量增长；以及 1–2 GB 的运行时开销，用于 CUDA 上下文和服务进程。选 Profile 前先把这些加起来，因为只按权重算出来的分区，模型能加载，一上负载就崩，或者悄悄只能服务比配置短得多的上下文。给个具体参考：同样是 8B FP16 模型，在 40 GB 分区上跑 8,000 token 上下文比较从容。

MIG 最能发挥价值的地方

中小模型组合——最直接的场景。 微调变体、embedding 模型、reranker、分类器，每个都只用到加速器的一小部分，现在可以共用一个。

多租户模型服务—— 每个客户一个模型时，MIG 能在它们之间提供硬件边界：一个分区里的进程读不到另一个分区的内存，也抢不走它的吞吐。不过这个说法要讲准确：同一实例上的模型仍然共享主机 CPU、系统内存、存储、网络和端点路由，所以分区只是 GPU 层面的隔离机制，不是完整的租户边界。

• 单实例上的多阶段流水线：一台实例上同时跑转录模型、说话人分离模型和语言模型，或者嵌入模型、重排模型和生成模型。每个阶段都是独立分区上可单独寻址的组件，阶段之间的网络跳转也消失了。
• 请求路径上的小模型：安全分类器或护栏模型（guardrail model）必须对每个请求执行，但又不足以单独占用一块加速卡。它的延迟可预测，因为它不需要和主模型抢时间片。
• 候选模型与金丝雀发布：把候选模型放在一个小分区上，与正在服务生产流量的模型并排运行，而不必再起一个端点。

性能：新 GPU 的一片 vs 旧 GPU 的整块

除了装箱（bin-packing），另一项好处是高端 GPU 上的粒度：可以部署模型的 GPU 选项更多了，选哪一个由你决定。每款受支持的加速卡都从一种规格变成多种规格，所以实际的理解方式是：每个 profile 本身就是一种 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：在五种流量形态和 2 到 512 的并发阶梯下，一个 H100 的 mig-3g.40gb 分区与一整块 A100-40GB 的每秒总输出 token 数对比。图 2：同样五种流量形态下，每百万输出 token 的分区成本收益随并发变化的情况。

有四点很突出。

分区在所有场景下都更快。 每个场景、每个并发级别，它每秒输出的 token 都更多；在各场景成本优势最大的负载点上，高出 53% 到 89%。token 间延迟也全面更低，降幅 8.9% 到 42.1%。

负载越高，差距越大。 首 token 时间在所有情况下都更低，降低 5.6% 到 47.5%。

成本上，每百万输出 token 便宜 18% 到 34%。 这里存在一个交叉点，提示词越长，交叉点来得越早：100 token 的提示词对应并发 64，8000 token 的提示词对应并发 4。低于交叉点时，整块 A100 的单位成本更低。

这些价格都是按需价格。分析时，美国西部（俄勒冈）区域的 ml.p4d.24xlarge 为每小时 25.251286 美元，ml.p5.48xlarge 为每小时 63.296000 美元。仅为分析方便，我们用整实例成本除以实例上的单元数来推算单位成本：p4d 上是 8 个单元，p5 上是 16 个，而我们用的分区是半块 GPU。

在长上下文流量的最高并发档位，A100 停止服务了。在 6000 和 8000 token 的负载上，它分别有三分之一到一半的请求没能赶在服务路径截止时间前完成，而分区一个都没失败。这也是那两个图面板比其余面板更早结束的原因。

把这当成逐案例的比较，而不是最终结论。一个有用的思维模型是：把可用的 GPU 分数当成独立的 GPU 类型来看。把它们和整卡加速器列在一起，弄清楚你的流量实际需要多少算力、多少内存，再在自己的负载上做比较。

高并发、长输入的流量下，这里的分区在性能和成本上都赢了。短输入或低并发的负载下，整块 A100 仍然更便宜。分区并非万能。

它提供了更多规格可选，你可以挑一个适合自己工作负载的。在确定布局前需要了解的事项：分区会改变端点的形态，设计之前有几项特性值得先弄清楚。组件的分区类型在该组件的整个生命周期内固定不变。要把模型换到另一个配置档，就得新建一个组件。改动端点的划分方式意味着要新建端点并做流量迁移，因为更新端点配置不会重新划分已在运行的宿主机。因此，分区适合稳定的模型组合，不适合每天重新洗牌的组合。请求的配置档必须存在于端点的布局中。系统不会回退到整块加速卡，所以组件请求了变体未声明的配置档会被拒绝。分区适用于推理组件端点上的实时推理。不支持无服务器端点和异构实例池，异步调用也无法寻址推理组件，因此异步工作负载不在支持范围内。你仍然按整台 GPU 实例计费，和现在一样。分区提升的是你能用到的实例算力比例，不会改变按小时计费的价格。最后，如果模型确实需要一整块加速卡甚至多块，那就该继续给它整块。没有哪个分区能跨多块加速卡。

支持的实例与区域：GPU 分区在 P4d、P5、G7 和 G7e 实例家族上可用。支持是按家族级别的，因此同一家族内较小规格也涵盖在内。以下 AWS 区域可用：美国东部（弗吉尼亚北部）、美国东部（俄亥俄）、美国西部（俄勒冈）、亚太地区（新加坡）、亚太地区（东京）、欧洲（法兰克福）和欧洲（爱尔兰）。实例可用性因区域而异，请确认所选实例类型在所在区域有售，并且有对应的端点使用配额。

开始使用：要为 GPU 端点做分区，先算清每个模型的内存和算力需求，选定合适的配置档，在端点配置上声明布局，然后把每个模型部署为请求该布局中某个配置档的推理组件。

调用模型的方式完全不变。API 参考、各实例系列的完整规格表，以及一步步的操作指南，请看 Amazon SageMaker AI 开发者指南中的 GPU 分区章节。想亲自试试，可以运行 GPU 分区示例 notebook，它会把多个模型部署到同一个 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 推理方向的全球专家解决方案架构负责人。在这个岗位上，他帮助客户设计、构建并优化生成式 AI 和 AI/ML 解决方案。他的工作覆盖广泛的机器学习场景，主要关注生成式 AI、深度学习，以及在企业范围内扩展机器学习。他曾帮助金融服务、保险、电信等多个行业的公司落地相关方案。

Amazon SageMaker 推理服务现在支持 NVIDIA 多实例 GPU（MIG）的 GPU 分区能力。MIG 可以把一块 GPU 切成多个硬件隔离的分区，每个分区既能跑不同的模型，也能从较新的加速卡上取用大小合适的算力份额。本文介绍如何用两个可选 API 字段让每个分区各跑一个模型，并给出与一整块旧款 GPU 的实测对比。

查看原文