SageMaker 支持 GPU 分区部署模型

GPU 推理的浪费，常常从「最少买一整张卡」开始。模型只用掉部分显存和算力，也得占住完整 GPU。AWS 这次给 SageMaker Inference 加入 NVIDIA Multi-Instance GPU（MIG）支持，让多个模型分别占用硬件隔离的分区，也让新一代 GPU 的一部分成为部署选项。

值得读的不是「一张卡能放更多模型」，而是容量选择变细之后，成本该怎么算。作者测出了 H100 分区胜过完整 A100 的场景，也给出了反例：输入短、并发低时，完整 A100 依然更便宜。

分区解决的不只是模型放不下

原文以 ml.p4d.24xlarge 为例：它有八张 A100。按文中讨论的整卡分配方式，无论一个模型需要 40 GB 还是 14 GB，都占一张卡，实例只能容纳八个模型。

MIG 把一张 GPU 切成独立分区，每个分区拥有固定的计算资源，以及独立的缓存、显存和显存带宽。上限取决于 GPU，最多七个。模型分别常驻自己的分区，不需要为了腾位置反复加载、卸载。

这与 multi-model endpoints 的取舍不同。后者按需装卸模型，适合稀疏、突发流量，但共享 GPU，未加载的模型还要承担首次加载开销。MIG 更适合持续在线、各自又吃不满整卡的微调模型、embedding 模型、reranker 和分类器。

硬件隔离也让资源争抢更可控。作者强调，一个分区的流量尖峰不会抢走另一个分区的显存带宽，故障也能限制在分区内。不过，文中没有给出邻居干扰或故障注入的测试数据，这部分属于能力说明。

GPU 分区隔离不等于完整的租户隔离。

同一实例上的模型仍共享主机 CPU、系统内存、存储、网络和端点路由。它能提供 GPU 层面的边界，不能单独承担整套多租户安全设计。

接入只加两个字段，布局却要提前定好

功能建立在 inference components 之上。它是 SageMaker 在同一端点部署多个模型、分别声明资源需求的部署单元。此次没有新增 API 操作、资源类型或 IAM 动作；两个新字段都不填，原有行为不变。

下面通过 CreateEndpointConfig 中的 AcceleratorPartitionLayouts 声明每张 GPU 的切法：

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

注意 AcceleratorPartitionTypes：4g、2g、1g 合计用完 A100 的七份计算资源，每张卡得到三个分区，八张卡共 24 个，每种规格八个。这个布局统一应用于 variant 内所有实例的所有 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 }
}

注意 NumberOfAcceleratorDevicesRequired：这里始终是 1，含义变成一个分区。CPU 和内存字段仍指主机资源，GPU 显存由分区规格决定。增加 CopyCount，会把额外副本放到空闲的同规格分区。

调用仍通过 InvokeEndpoint 按组件名寻址，不需要传分区信息。作者测试中，切分使端点供应时间增加约 17 秒；进入 InService 时，分区可以先空着，随后再部署组件。

限制则需要提前接受：组件规格终身固定，换规格要新建组件；修改切分布局要新建端点并迁移流量，更新配置不会重新切分运行中的主机。请求不存在的规格会被拒绝，也不会退回整卡。

分区怎么选，不能只看模型权重

mig-3g.40gb 表示三份计算资源、40 GB 显存，但计算与显存并非同比例分配。A100、H100 的计算粒度是七分之一，显存粒度是八分之一；3g 占三份计算、四份显存，两个 3g 就用完显存，余下的一份计算不能再塞模型。G7 的粒度是二分之一，G7e 是四分之一，布局不能直接跨家族照搬。

长输入的 prefill 阶段负责处理提示词、建立表示，更吃计算资源，影响首 token 延迟。decode 阶段逐步生成 token，需要不断读取权重，更受显存带宽影响；显存容量还决定 KV cache 能容纳多少上下文和并发序列。具体瓶颈仍应实测。

因此，显存预算要加上三项：权重、KV cache、运行时开销。作者给出的参考是：8B 模型的 FP16 权重约 16 GB，CUDA 上下文和服务进程另需 1–2 GB；同一模型在 40 GB 分区上可较宽裕地服务 8,000-token 上下文，但没有给出这句话对应的并发条件。

驱动也会卡住部署。P4d 默认镜像的 NVIDIA 驱动为 470.256.02，mig-1g.10gb 要求 R525 或更新版本。原文要求在 production variant 设置 InferenceAmiVersion 为 al2023-ami-sagemaker-inference-gpu-4-1，使用 580 驱动系列，否则切分可能失败，且错误不直接指出规格问题。

我的判断

我认同作者把「新卡的一部分」当作独立候选规格来测，而不是只比较整卡代际。

他们使用 genai-bench，在生产 SageMaker 实时端点上比较 H100 的一个 mig-3g.40gb 分区与完整 A100-40GB。两侧都是一个 Llama-3.1-8B-Instruct 副本，使用相同容器、tokenizer、客户端配置，并走 SageMaker AI 原生 OpenAI-compatible 路由。测试覆盖五种 D(输入 token 数，输出 token 数) 流量，并发从 2 到 512。

分区在全部测试点的输出吞吐更高。在各场景成本收益最大的负载点，吞吐高 53%–89%，token 间延迟低 8.9%–42.1%；各场景首 token 延迟低 5.6%–47.5%。超过成本交叉点后，每百万输出 token 便宜 18%–34%。100-token 输入要到并发 64，8,000-token 输入则在并发 4 达到交叉点，低于交叉点时 A100 更便宜。

长上下文的最高负载下，A100 在 6,000 和 8,000-token 场景中有三分之一到一半请求超过服务路径截止时间，H100 分区没有失败。但原文没列出全部输入输出组合、截止时间和完整服务配置，不能照抄为自己的容量结论。

这里的分区单价是分析分摊价，账单仍按整台实例收取。

作者采用分析时 US West（Oregon）的按需价格：ml.p4d.24xlarge 为每小时 $25.251286，除以八个整卡单元；ml.p5.48xlarge 为 $63.296000，除以 16 个半卡分区。只有剩余分区也被有效利用，这种单位成本优势才容易落实。

相较自管 Kubernetes，托管方案省掉驱动、设备插件、调度和分区配置维护，适合模型组合稳定的团队。若流量稀疏、模型经常轮换，multi-model endpoints 仍有价值。Salesforce 参与了需求定义和初版验证，但原文说代表性生产负载验证还在准备中，不能当作生产收益证明。

能拿来做什么

• 如果你维护多个常驻的 embedding、reranker 或分类模型，可以先统计各自的显存、并发和延迟需求，再评估合并到分区端点；需要整卡或多卡的模型继续使用完整 GPU，分区不能跨卡。
• 如果现有 SageMaker 应用要接入，应先确认端点使用 inference components。单模型端点、serverless、heterogeneous instance pools 不支持，异步调用也无法寻址组件。原文列出的家族为 P4d、P5、G7、G7e，区域包括北弗吉尼亚、俄亥俄、俄勒冈、新加坡、东京、法兰克福和爱尔兰，还需确认实例供应和配额。
• 如果准备做成本比较，应拿真实的输入长度、输出长度和并发压测，同时计算空闲分区成本。不要仅凭「每百万 token 便宜」就升级到更贵的整机。
• 如果请求链路包含 embedder、reranker、generator，可以评估让各阶段成为同一实例上的独立组件，减少跨实例网络跳转；也可以给候选模型留小分区，但要把未来调整布局的迁移成本算进去。