SageMaker推理端点支持MIG：一块GPU切给多个模型，怎么选分区

AWS在2026年11月6日的官方博客中宣布，Amazon SageMaker Inference 开始支持基于 NVIDIA Multi-Instance GPU（MIG）的 GPU 分区：一块物理 GPU 可以在硬件层面切成多个相互隔离的分区，每个分区运行一个模型，或只取新一代加速器的一小份算力。这条更新对在 AWS 上部署多个中小模型推理服务的开发者最直接——不必再为每个模型独占整块 GPU。但它只适用于使用推理组件（inference components）的实时端点，单模型端点、Serverless 端点和异构实例池都不支持，选型前要先确认自己的部署形态。

MIG 是什么，对推理部署意味着什么

MIG 是 NVIDIA 在硬件层把一块 GPU 切成若干独立实例的能力。每个分区拿到固定的计算单元份额、独立的显存块和显存带宽，隔离由硬件保证，而不是靠软件调度分时复用。落到推理上，它改变两件事：一是一块卡能同时放几个模型，二是你可以只买一块新卡的一部分，而不是整块。

和常见的多模型端点相比，差别在隔离和加载方式。多模型端点按需从共享 GPU 加载、卸载模型，适合稀疏突发的流量，但模型之间没有硬件隔离，一个重请求会影响同卡上的其他模型，冷加载还会带来首次调用延迟。MIG 分区则让每个模型常驻自己的分区，互不抢占显存带宽，一个分区内的崩溃或显存错误也不会扩散到整卡。

需要说清楚边界：分区隔离只发生在 GPU 层面。同一实例上的模型仍然共享主机 CPU、系统内存、存储、网络和端点路由，所以它不等于完整的多租户隔离，强合规场景不能只靠 MIG 划边界。

发布之前的三条老路，各自卡在哪

少开几个大端点、加大批处理：能提高利用率，但前提是模型可以互换。一堆微调变体或按客户拆分的模型并不满足这个前提。
多模型端点：适合流量稀疏、突发的场景，代价是共享设备、相互干扰，以及首次调用的加载惩罚。
自建 Kubernetes 跑 MIG：隔离能力是有的，但要自己管驱动版本、分区配置、设备插件、调度，还要保证整个集群一致，运维成本不低。

SageMaker 这次做的事，是把上面第三条里的平台工作接过去：你选分区档位，GPU 配置、放置和扩缩由托管端点处理。

API 只多了两个可选字段

按官方博客的描述，这次没有新增 API 操作、资源类型或 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"]
        }
      ]
    }
  ]
}

要点有三个。一个布局条目描述的是单块加速器如何切分，同一变体内所有实例上的所有加速器都按同一方式切；列表不按位置对应某块具体 GPU；A100 有 7 个计算切片，上面这个布局用满了 7 个，所以一台 8 卡的 p4d 上每块卡带 3 个分区，整个端点提供 24 个分区，每种档位 8 个。

第二个字段 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
  }
}

每个组件副本占一个所请求档位的分区。设置了分区类型后，NumberOfAcceleratorDevicesRequired 固定为 1，含义是「一个分区」而不是「一块整卡」；NumberOfCpuCoresRequired 和 MinMemoryRequiredInMb 描述的仍是主机 CPU 和主机内存，显存由分区档位决定。调用方式不变，InvokeEndpoint 按推理组件名寻址，分区不出现在请求里。

分区在端点预置时完成。端点进入 InService 后所有加速器已经切好、分区为空，这是合法状态，组件随后落进去。官方称测试中切分加速器让预置时间增加约 17 秒，其余是常规的实例启动和容器拉取。

哪些实例和分区档位可用

可用档位由 GPU 本身决定。官方博客给出的对照如下，完整档位组合以 NVIDIA 的 MIG 支持文档为准：

实例族	加速器	显存	切分粒度（计算/显存）	可用分区档位	每卡最多分区
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

档位名的读法是「计算单元数 + 显存」，例如 mig-3g.40gb 占 3 个计算单元和 40 GB 显存。粒度列决定了布局的边界：A100 和 H100 的计算按七分之一切、显存按八分之一切，G7 按二分之一，G7e 按四分之一。档位名在不同 GPU 之间并不通用，把一套布局从 P4d 搬到 P5 之前必须重新核对。

3g 档位值得单独记住，因为它的两个维度不对齐：占 7 个计算单元中的 3 个，却占 8 份显存中的 4 份。两块 3g 就把整卡占满，旁边放不下别的档位。规则本身简单：布局里每个档位必须是该 GPU 支持的，所有档位加起来不能超过一块设备提供的计算和显存。两项都在创建端点配置时校验，任何一项不通过是直接拒绝，不会退化成整卡。

P4d 有一个驱动限制：mig-1g.10gb 需要 R525 或更新的 NVIDIA 驱动，而 P4d 默认镜像带的是 470.256.02。在默认镜像上请求这个档位，切分会失败，而且报错不会点出档位名。解决办法是在生产变体上把 InferenceAmiVersion 设为 al2023-ami-sagemaker-inference-gpu-4-1，获得 580 驱动线的镜像。

按负载选分区：先算显存，再看算力

分区按固定比例给你计算和显存，这两样在推理的不同阶段干活。计算单元主要服务预填充（prefill）：读入提示词、构建表示，是计算密集阶段，随分区持有的流式多处理器数量和算力走。输入越长、同时到达的提示越多，它越决定首 token 返回快慢。显存主要服务解码（decode）和容量：每生成一个 token 都要重读模型权重，所以解码受显存带宽约束而不是算力；显存还决定能放多少 KV 缓存，进而决定可服务的上下文长度和并发序列数。

显存是最容易被低估的一项，因为一个分区要装的不只是模型：

模型权重。官方举例，8B 模型 FP16 约 16 GB。
KV 缓存。按你打算支持的上下文长度和并发序列数计算，这一项会随流量增长。
1–2 GB 运行时开销，用于 CUDA 上下文和服务进程。

三项加完再选档位。只按权重算出来的分区能加载模型，但一上负载就出问题，或者实际能服务的上下文远短于配置值。官方给的参考是：同一个 8B FP16 模型在 40 GB 分区上可以较宽裕地服务 8000 token 上下文。

选型顺序可以这样走：先按「权重 + KV 缓存 + 1–2 GB 开销」定显存下限；再按提示长度和并发估计算力需求；然后对照上表挑一个组合，让比例覆盖最重的那一阶段，同时给另一阶段留够余量。

官方对比测试说明了什么，没说明什么

官方做了一个对比：一个 H100 的 mig-3g.40gb 分区，对一整块未切分的 A100-40GB。两者显存相近，用来观察新一代实例的一个切片能做到什么程度。测试用 genai-bench 从同一客户端给两个端点加压，两边都跑 Llama-3.1-8B-Instruct，各一个模型副本，容器镜像、分词器和客户端配置一致，走 SageMaker 的 OpenAI 兼容接口。

这个设计的价值在于把 GPU 变成唯一变量，回答的是「新卡的一小份和老卡整块怎么比」。局限也要看清：这是 AWS 自己执行、自己发布的测试，没有第三方复现；摘要层面没有给出具体吞吐和延迟数值，需要看原文表格；结论只适用于该模型、该负载生成方式和该配置，不能外推成通用性能排序。

适合与不适合的场景

适合的情况：

一批中小模型：微调变体、embedding、rerank、分类器，每个都用不满一块加速器，现在可以共享一台实例。
按客户托管模型：MIG 在客户之间提供硬件边界，一个分区里的进程读不到另一个分区的显存，也抢不走它的吞吐。但如前所述，主机资源仍共享。
一条多阶段流水线：转写、说话人分离、语言模型，或 embedding、rerank、生成，每个阶段是独立寻址的组件、各占一个分区，阶段之间的网络跳转也省了。
请求路径上的小模型：安全分类器或护栏模型每个请求都要跑，但不值得占一块卡，独立分区还能保证延迟不被主模型挤占。
灰度与候选模型：把候选模型放在小分区上，和生产模型并行跑，不用另起一个端点。

不适合或要注意的情况：

单模型就需要多块 GPU 的，仍然要整卡。
单模型端点、Serverless 端点、异构实例池不支持分区。
分区布局在创建端点时确定，MIG 只允许在分区空闲时改布局，所以后期调整基本等于重建端点。
分区数上限不超过 7，具体取决于加速器。

给准备上手的团队的行动清单

确认部署形态是使用推理组件的实时端点，而不是单模型端点或 Serverless。
按「权重 + KV 缓存 + 1–2 GB 开销」估显存，按提示长度和并发估算力，写出目标档位的上下限。
对照实例族的分区档位表挑组合，注意 3g 档位算力占 3/7、显存占 4/8，两块就占满整卡。
核对目标实例族和地域是否可用，以及账号配额是否够用。这些信息以 AWS 控制台和官方文档为准。
P4d 上若要用 mig-1g.10gb，显式指定较新的推理镜像版本，否则切分失败且报错不提示档位名。
上线前压测，重点看首 token 延迟、并发下的 p99 和显存占用，验证分区档位是否真的匹配负载。
计费口径单独确认。分区是按分区计价还是按整实例计价，官方博客没有说明，需要查 AWS 定价页后再做成本判断。

对不在 AWS 上、正在评估其他云厂商 GPU 推理产品的读者，这次更新提供了一个可复用的选型思路：把「最小可购单位」和「隔离级别」和显存、带宽放在一起比较。能按算力份额采购，往往比整卡租用更贴近中小模型的真实需求；但份额越小，越要提前算清显存和并发的余量。

常见问题

MIG 分区和普通的多模型端点有什么区别？

多模型端点让模型共享同一块 GPU，按需加载卸载，模型之间没有硬件隔离，适合稀疏突发流量。MIG 分区在硬件层切分，每个分区有独立的计算单元和显存块，模型常驻、互不干扰，也没有首次调用的加载惩罚。

一块卡最多能切几个分区？

取决于加速器，上限是 7 个。官方给出的实例中，P4d 和 P5 最多 7 个，G7 最多 2 个，G7e 最多 4 个。具体可用档位组合以 NVIDIA 的 MIG 支持文档为准。

分区之后能改布局吗？

MIG 只允许在分区空闲时更改布局，在 SageMaker 上等于创建端点时就要选定。要换布局，实际做法是重建端点配置和端点。

分区能当多租户隔离用吗？

只能算 GPU 层面的隔离。同一实例上的模型仍共享主机 CPU、系统内存、存储、网络和端点路由，强合规场景需要额外的隔离手段。

为什么按权重算好的显存，一上负载就不够？

因为分区显存还要装 KV 缓存和 1–2 GB 运行时开销。KV 缓存随上下文长度和并发序列数增长，是最容易漏算的一项。先按三项之和选档位，再压测验证。

本文由网上采集发布，不代表我们立场，转载联系作者并注明出处：https://www.uuccloud.com/11854.html