AWS为SageMaker实时推理端点加入NVIDIA MIG GPU分区支持，让多个模型或副本使用独立计算与显存资源，提高部署密度，但仍按完整实例计费。实际成本收益取决于负载和分区利用率；分区布局无法在线重切，GPU资源隔离也不等于完整租户隔离。
亚马逊云服务（AWS）于2026年11月6日宣布，Amazon SageMaker Inference支持基于NVIDIA Multi-Instance GPU（MIG）的GPU分区。对于使用推理组件的实时端点，开发者可以把一块物理GPU划分为多个拥有独立计算资源和显存的分区，分别部署模型或模型副本，不必再为每个小模型分配整块加速器。
但这不是按“GPU切片”单独出租的新计费服务。AWS公告明确表示，用户仍为完整GPU实例付费，实例小时价格不因分区而改变。它提供的是更细的资源配置颗粒度：如果能把原本闲置的容量用起来，单位推理成本才有机会下降。
解决的是模型装不满GPU的问题
小型分类器、嵌入模型、重排序模型，以及面向不同客户的微调模型，未必能用满一块GPU。在按完整加速器分配资源的部署方式下，显存和计算能力可能被闲置；把多个模型放到共享设备上，又需要处理彼此争抢资源的问题。
MIG的区别在于硬件分区，而不是简单轮流使用同一块GPU。NVIDIA技术文档说明，各分区拥有独立分配的计算资源，并在缓存、内存控制器和显存访问路径上进行隔离，以降低其他分区负载变化对自身吞吐量和延迟的影响。
AWS此次增加的，是在托管推理端点中配置、放置和管理这些分区的能力，而不是发明一种新的GPU硬件技术。对原本需要自行管理Kubernetes、驱动、设备插件和调度的团队而言，它试图减少获得GPU分区能力所需的平台运维工作。
具体部署依赖SageMaker的“推理组件”（inference components）：端点配置声明GPU如何切分，组件再申请其中一种分区。应用调用模型时仍使用推理组件名称，不需要在每次请求中指定底层GPU分区。
分区数量也不是一律为七个。按AWS列出的支持范围，P4d上的A100和P5上的H100最多可划分为七个分区，G7上的RTX PRO 4500最多两个，G7e上的RTX PRO 6000最多四个。实际能放下多少模型，还取决于所选分区规格以及计算、显存两方面的约束。
例如，AWS展示的P4d配置把每块A100划分为三个不同大小的分区；一台拥有八块GPU的实例由此提供24个分区。这个例子说明的是部署密度可以提高，并不意味着任意24个模型都能在同一实例上满足性能要求。
“成本降低18%至34%”有明确前提
AWS用Llama-3.1-8B-Instruct进行了一组对照测试：一侧是H100的一个mig-3g.40gb分区，另一侧是一块完整、未分区的A100-40GB。两侧显存容量相近，但GPU代际和计算资源不同。这不是把同一块GPU分区前后进行的比较。
按照公告，两侧使用相同的容器镜像、分词器和客户端配置，各运行一个模型副本；测试覆盖五种输入、输出长度组合，并把并发从2逐步提高到512。AWS报告，在超过相应负载交叉点后，H100分区的每百万输出token成本比完整A100低18%至34%。对于100-token输入，成本交叉点在并发64；对于8,000-token输入，交叉点提前到并发4。
这意味着，“分区更快”并不自动等于“分区更便宜”。AWS同时指出，在短输入或低并发场景中，完整A100仍可能是成本更低的选择。
更关键的是这组成本数字的计算口径。AWS采用分析时美国西部俄勒冈区域的按需整机价格，再按可用资源单元分摊：P4d实例费用除以八，P5实例费用除以十六，后者对应每块H100放置两个40GB分区。这是用于比较的费用分摊方法，不是AWS对单个分区开出的账单。如果其余分区空置，企业仍需支付整台实例的费用。
这些结果来自AWS自己的基准测试，并非独立复测，也不能直接作为所有业务的节省承诺。采购决策需要同时考虑真实流量、可接受延迟、模型组合，以及剩余分区能否被持续利用。
显存预算不能只看模型权重
分区选择同时受计算和显存约束。处理输入提示词的预填充阶段需要计算能力；生成输出时的解码阶段则往往受到显存带宽制约。上下文越长、同时处理的序列越多，KV缓存占用也越大。
AWS举例称，一个80亿参数模型采用FP16精度时，权重本身约占16GB，但实际部署还要为KV缓存以及CUDA上下文、服务进程等运行开销留出空间。仅按权重大小选择分区，可能导致模型能够加载，却在并发增加时显存不足，或者只能支持比预期更短的上下文。
对于同时运行嵌入、重排序和生成模型的检索增强生成系统，分区提供了一种在同一实例上为各阶段分配资源的办法；对于客户专属模型，则可以把不同副本放进不同GPU分区。不过，是否值得这样部署，仍取决于各阶段的峰值负载能否匹配，而非模型数量越多越好。
这也与本站此前报道的SageMaker前缀感知路由有所不同：前者在硬件资源分配层面提高部署密度，后者通过请求路由增加已有KV缓存的复用。两者处理的是推理服务中不同层次的问题，不能把各自测试中的收益直接相加。
GPU隔离不是完整租户隔离，布局也不能随时重切
AWS开发者指南强调，GPU分区隔离的是GPU计算资源和显存。同一实例上的模型仍共享主机CPU、系统内存、存储和网络，公告还指出端点路由也是共享的。因此，MIG可以成为多租户架构的一项隔离机制，却不能单独证明整个服务已经实现完整的租户安全边界。
资源调整也有固定边界。分区布局在端点创建时确定，不能在运行中的端点上随负载即时重新划分。指南明确写明，若更新请求试图改用不同布局，会返回400错误；改变布局需要创建新端点并迁移流量。组件若要使用另一种分区规格，也需要创建新组件。副本可以利用已有空闲分区扩展，但这不同于动态改变GPU切分方式。
当前支持范围是使用推理组件的实时端点，不包括单模型端点、无服务器端点和异构实例池；异步调用不能寻址推理组件，因此也不在范围内。需要多块GPU的模型仍应使用完整设备，单个分区不能跨越多块加速器。
部署团队还需注意可观测性限制：开发者指南称，分区端点及其推理组件不发布GPU、CPU或内存利用率指标，CloudWatch监控应使用端点发布的调用和延迟指标。对于以提高利用率为目标的改造，这意味着还要提前明确怎样验证容量配置是否合理。
AWS列出的开放区域包括美国北弗吉尼亚、俄亥俄、俄勒冈，以及新加坡、东京、法兰克福和爱尔兰；具体实例可用性和端点配额仍需逐区确认。
公告中的Salesforce证言也应按验证阶段理解：该公司参与了需求定义和初始方案验证，并表示正准备使用有代表性的生产负载继续验证。这不是已经完成大规模生产部署并证明节省比例的证据。
对拥有稳定模型组合、能够填满多个分区的团队而言，新能力增加了资源配置选择，也减少了自行维护MIG平台的工作。对于流量稀疏、模型频繁更换或需要整块GPU的服务，收益则没有那么直接。最终需要验证的，不是GPU能否被切开，而是在满足延迟、隔离和运维要求之后，整台实例能否比原来承载更多有效工作。