摘要： AWS 在 2026 年 10 月 30 日宣布 SageMaker Inference 的即時端點支援 GPU 分區，靠 NVIDIA Multi-Instance GPU（MIG）把一張實體 GPU 切成最多七個硬體隔離的分區，每個分區各有自己的運算單元、記憶體和頻寬。對手上有一堆 fine-tuned 變體、embedding、reranker 或 classifier 的團隊，這代表不用再「一個模型吃一整張卡」，也不必為了拿到 MIG 自建一套 Kubernetes 平台。下面整理機制、切法、限制，以及我認為上線前該先驗證的事。
過去的問題：最小單位是一整張卡
在 GPU 端點上部署模型，你能申請的最小單位一直是一個完整加速器。一台 ml.p4d.24xlarge 有八張 A100，就只能放八個模型——不管每個模型實際只需要 14 GB 還是真用滿 40 GB。資料來源指出，這個限制的代價有兩層：模型數量被卡的張數綁死，而且隨著流量和 prompt 長度變大，舊一代的整卡不夠用、新一代的整卡又用不滿，你只能在「效能不足」和「付了用不到的錢」之間二選一。
AWS 官方文件提到客戶目前的三種繞法：把模型合併成更少更大的端點然後加大 batch、用 multi-model endpoints 讓模型共用 GPU（但沒有硬體隔離，一個重請求會拖累同卡的其他模型，首次載入還有冷啟動懲罰），或者搬到自管的 Kubernetes 上自己開 MIG。第三種能拿到真正的分區，但代價是驅動版本、分區設定、device plugin、排程全都要自己顧。這次的功能本質上就是把這層平台工作收進 managed endpoint。
機制：兩個新欄位，不用新 API
實作上很克制。整個功能只加了兩個選填欄位，沒有新的 API 操作、資源類型或 IAM action，兩個欄位都不填的端點行為完全不變。前提是端點必須使用 inference components——也就是「一個端點掛多個模型、各自分配算力」的機制；單模型端點、serverless 端點和異質 instance pool 都不支援分區。
第一個欄位 AcceleratorPartitionLayouts 放在 CreateEndpointConfig 的 production variant 上，宣告每張卡怎麼切：
{
"ProductionVariants": [{
"InstanceType": "ml.p4d.24xlarge",
"AcceleratorPartitionLayouts": [
{ "AcceleratorPartitionTypes": ["mig-4g.20gb", "mig-2g.10gb", "mig-1g.5gb"] }
]
}]
}這個切法用滿 A100 的七個運算切片，所以八張 A100 各自變成三個分區，整台機器提供 24 個分區。切法是全體一致的：一條 layout 描述一張卡，variant 內每一張卡都照同樣方式切。第二個欄位 AcceleratorPartitionType 放在 inference component 的 ComputeResourceRequirements 裡，指定模型落在哪種分區；把 CopyCount 調高，副本就會自動填進同型別的空分區。呼叫端完全不用改——InvokeEndpoint 還是用 inference component 名字找模型，分區位置不出現在請求裡。
切法上限由 GPU 決定，而且切錯是直接被拒
分區數量上限取決於加速器，最高不超過七：P4d（A100，40 GB）和 P5（H100，80 GB）最多七個分區，G7（RTX PRO 4500 Blackwell，32 GB）只有兩個，G7e（RTX PRO 6000 Blackwell Server Edition，96 GB）四個。profile 名稱讀法是運算單元加記憶體：mig-3g.40gb 就是三個運算單元、40 GB。值得注意的是 3g profile 的比例不對稱——A100/H100 上它佔七分之三的運算卻吃掉八分之四的記憶體，放兩個就把整張卡填滿，旁邊塞不下任何東西。
有幾條硬邊界值得先記住。MIG 只允許分區閒置時改 layout，落到 SageMaker 上就是：layout 在建立端點時就要定死，之後不能換。需要的運算和記憶體加總超出一張卡，或用了該 GPU 不存在的 profile，都會在建立 endpoint config 時被直接拒絕，而不是退化成整卡。還有一個坑：P4d 的 mig-1g.10gb 需要 R525 以上的 NVIDIA 驅動，但預設 P4d 映像帶的是 470.256.02——用預設映像去要這個 profile，切卡會失敗，而且錯誤訊息不會指出是 profile 的問題。要在 production variant 上把 InferenceAmiVersion 設成 al2023-ami-sagemaker-inference-gpu-4-1（580 驅動線）才拿得到。官方的教訓很明確：不要把 layout 從一個 instance family 直接搬到另一個。
成本與適用場景：誰該認真看這個功能
最直接的受眾是 AWS 自己點名的那批工作負載：fine-tuned 變體、embedding 模型、reranker、classifier 這類小到中型模型。分區的好處不只是塞更多模型，還包括可預測的延遲（每個分區有專屬記憶體頻寬，別人的流量尖峰不會出現在你的 p99）、故障隔離（crash 不會帶倒同卡其他模型）、沒有冷啟動（分區常駐不驅逐），以及乾淨的 chargeback——GPU 成本能對到特定模型、團隊或租戶。Saleforce 的軟體工程架構師 Richard Chang 在 AWS 的公告文章中表示，許多推論工作負載本來就用不滿一整張 GPU，MIG 讓他們能安全地整合工作負載、提升利用率並降低推論成本；Salesforce 參與了需求定義和初期驗證，目前正準備用具代表性的生產工作負載做進一步驗證。
支援的機型是 P4d、P5、G7、G7e，區域涵蓋 US East（N. Virginia、Ohio）、US West（Oregon）、Asia Pacific（Singapore、Tokyo）、Europe（Frankfurt、Ireland）。佈建成本方面，官方測試數字是切卡為端點佈建增加約 17 秒，其餘仍是平常的開機加拉 container。
一句話提醒資料完整性：這篇 AWS 部落格原文在「如何為你的工作負載選 layout」一節中途被截斷，官方聲稱做過的量測細節我手上並不完整；除了那 17 秒佈建開銷，材料裡沒有提供實際的成本節省或延遲改善數字，這點不要自行腦補。
你接下來該檢查的事
這個功能延續了我之前寫過的整條脈絡——SageMaker Inference 2026 上半年這波更新把 GPU 推論從黑盒子拉回可調參數，分區是同方向的下一步。落地前建議按順序確認三件事：先查出你的 instance family 背後是哪顆 GPU，對照 NVIDIA 的支援 MIG profile 清單，列出可行的 layout；再算清楚每個模型的運算與記憶體需求該對到哪個 profile——文章裡的分工原則是運算單元對應 prefill（讀 prompt、算 representation），記憶體對應 decode 和模型容量，輸入越長、併發越高越吃運算；最後在建立端點前就把 layout 定案，因為之後改不了。別忘了那次驗證的最無聊但最關鍵的一步：跑一輪延遲對比，確認分區後的 p99 真的符合你對「硬體隔離」的預期，而不是只看帳單變小。
參考來源
- SageMaker Inference now supports Multi-Instance GPU to maximize GPU utilization for model endpoints | Amazon Web Services
- Amazon SageMaker AI inference now supports GPU partitioning for real-time endpoints - AWS
在 X 上查看原貼文