隨著組織在生產中擴充套件生成式 AI 工作負載，確保可靠的 GPU 計算已成為最持久的運營挑戰之一。大型語言模型 (LLM) 和多模態架構需要特定的例項型別，當容量不可用時，端點在服務一個請求之前就會失敗。
在 Amazon SageMaker AI 上構建即時推理端點意味著在建立時承諾使用單一例項型別。當該型別容量不足時，端點無法達到執行狀態。您更新配置，選擇不同的例項型別，然後重試，重複迴圈直到配置嘗試成功。
今天，Amazon SageMaker AI 為新的和現有的推理端點引入了容量感知例項池。您定義優先順序列表的例項型別，當容量在建立、擴充套件和縮減期間受到限制時，SageMaker AI 會自動遍歷您的列表。您的端點可以在可用的 AI 基礎設施上自動配置，無需手動干預。此功能適用於單模型端點、基於推理元件的端點和非同步推理端點。
本文介紹了例項池的工作原理以及如何開始使用，無論是建立新端點還是遷移現有端點。
問題
當您將模型部署到 SageMaker AI 推理端點（無論是即時還是非同步）時，您指定單一例項型別。如果該型別沒有可用容量，端點建立失敗。此限制出現在端點生命週期的每個階段。
- 端點建立因容量而失敗。當您首選的例項型別不可用時，SageMaker AI 返回容量不足錯誤。要獲得執行中的端點，需要手動迭代替代方案，每次嘗試都花費大量時間才能知道結果。
- 自動縮放無法增長群組。當擴充套件事件觸發且您的例項型別容量不足時，自動縮放器會無限重試同一型別。流量持續增加，而端點保持在當前大小。
- 縮減沒有優先順序意識。使用單一例項型別，沒有首選與回退硬體的概念。每個例項都可以被移除，沒有區別。
- 可觀測性聚合且不可操作。Amazon CloudWatch 指標在端點級別彙總。在調查延遲或容量問題時，指標表明有問題，但不知道是哪個例項型別導致的。
工作原理：基於優先順序的例項池
您在端點配置中定義一個稱為例項池的排序例項型別列表。每當容量受限時，SageMaker AI 會自動遍歷該列表。
- 您的端點上線。SageMaker AI 首先嚐試您的首選例項型別。如果容量不可用，它會立即嘗試第二選擇，然後是第三選擇。無需手動重試。您的端點可在幾分鐘內在第一個可用的 AI 基礎設施上達到 InService 狀態。
- 您的端點保持執行。當自動縮放觸發且您首選的例項型別受限時，SageMaker AI 會在優先順序列表中的下一個可用型別上進行擴充套件，從而保持流量流動。
- 您的群組趨向於首選硬體。在縮減期間，SageMaker AI 首先移除最低優先順序（回退）例項。在後續擴充套件事件中，它再次首先嚐試最高優先順序型別。隨著首選硬體變得可用，您的群組自然地隨時間向它回移，無需手動干預。
- 您看到一切。每個現有的 CloudWatch 指標現在都包含一個 InstanceType 維度，因此您可以跟蹤單個端點內每個例項型別的延遲、吞吐量、GPU 利用率和例項計數。
要了解更多資訊，請參閱 Amazon SageMaker AI 文件並探索 GitHub 上的示例筆記本。
每個例項型別的正確模型
回退例項型別通常在 GPU 記憶體、計算能力和架構上有所不同。為高記憶體多 GPU 例項最佳化的模型不一定能在較小的單 GPU 回退上執行。有兩種方法可以將池列表中的每個例項型別與正確配置的模型匹配。
選項 1：自帶最佳化模型
如果您已經知道例項型別目標，請為每個目標準備模型工件。對於您的高階主例項，您可能會跨多個 GPU 使用張量並行。對於中端回退，您可以應用推測解碼來加速推理。對於最低優先順序的回退，您可以使用 INT4 量化以適應較小的記憶體預算。
為每個配置建立一個單獨的 SageMaker AI 模型，並使用 ModelNameOverride 在每個 InstancePools 條目中引用它（對於單模型端點）或在每個例項型別的 Specifications 中引用（對於基於推理元件的端點）。當 SageMaker AI 回退到較低優先順序的池時，它會部署您為該硬體準備的模型。
選項 2：使用 SageMaker AI 推理建議
如果您不想手動最佳化每個硬體目標，SageMaker AI 推理建議可以為您生成特定於硬體的配置。提供您的基礎模型，SageMaker AI 會使用推測解碼和量化等技術在您的目標例項型別中生成最佳化的配置。
建議作業為每個目標例項型別返回一個結果。每個結果在 AIRecommendationModelDetails 響應中包含一個 ModelPackageArn 和一個 InferenceSpecificationName，標識該特定硬體的配置。您使用這兩個欄位為每個結果建立一個 SageMaker AI 模型，然後在其對應的池條目中使用 ModelNameOverride 引用它——與選項 1 相同的模式，服務處理最佳化工作。
混合群組的自動縮放
自動縮放遵循您在建立時定義的相同優先順序邏輯。擴充套件首先嚐試最高優先順序的池，如果容量不可用則回退到下一個池。縮減首先移除最低優先順序的例項，在群組收縮時保留您的首選硬體。
構建加權縮放指標
因為您的群組包含具有不同吞吐量的例項型別，預設的聚合指標可能會錯誤地表示實際使用情況。考慮一個處理 18 個併發請求的 p5 例項和一個處理 7 個的 g6，將這些原始數字平均為 12.5 並不能準確反映任一型別上的負載。
您現在可以使用 CloudWatch 指標數學基於每種型別的利用率比率構建加權指標。每個項將型別觀察到的併發度除以其最大容量，產生一個介於 0.0–1.0 之間的值。平均這些比率給出群組級別的使用訊號，與 TargetValue 相同的 0.0–1.0 範圍。將 TargetValue 設定為 0.7 意味著：當加權平均值超過群組中所有例項型別容量的 70% 時進行擴充套件。
監控您的群組
所有現有的 CloudWatch 指標現在都包含一個新的 InstanceType 維度：ModelLatency、ConcurrentRequestsPerModel、GPUUtilization、InstanceCount 和 InvocationsPerInstance——按硬體型別在單個端點內細分。您可以構建儀表板和警報，獨立跟蹤每個例項型別。
DescribeEndpoint 返回每個池的當前例項計數，因此您始終知道您的群組組成。
流量路由
對於具有例項池的端點，我們建議透過在生產變體中設定 RoutingConfig 來啟用最少未完成請求 (LOR) 路由。LOR 將每個傳入請求路由到每個模型副本中飛行請求最少的例項。因為高容量例項處理請求更快，它們更快地排空佇列並在穩態下保持較低的飛行計數。這意味著它們自然接收比例更高的流量，無需任何手動權重配置。
更新和回滾
同時支援藍綠部署和滾動部署。
藍綠部署在轉移流量之前使用相同的基於優先順序的回退邏輯配置一個完整的新（綠色）群組。如果健康檢查透過，流量切換。如果失敗，自動回滾保留您的藍色群組，並且您的端點在整個過程中保持 InService。
滾動部署以可配置的批次（每次 5-50% 的例項）更新您的群組，比完整的藍綠群組需要更少的額外容量——對於大模型或高需求的 GPU 例項型別尤其有價值。SageMaker AI 在配置每個新批次時應用基於優先順序的回退邏輯。如果在烘烤期間 CloudWatch 警報觸發，流量自動回滾。
先決條件
在開始之前，請確保您擁有：
- 具有 sagemaker:CreateEndpointConfig、sagemaker:CreateEndpoint 和 sagemaker:UpdateEndpoint IAM 許可權的 AWS 賬戶
- 至少一個帶有 Amazon S3 中工件的 SageMaker 模型
- Boto3 版本 1.43.1 或更高（用於 Python SDK 中的 InstancePools 支援）
- （可選）每個目標例項型別的獨立最佳化模型工件，或來自 SageMaker AI 推理建議的 ModelPackage
例項池支援適用於所有商業 AWS 區域。您可以透過 AWS 管理控制台、AWS 命令列介面 (AWS CLI) 或 AWS SDK 開始使用。
配置端點的工作流程
有兩種方法可以配置例項池：用於新的 Amazon SageMaker AI 端點或用於您現有的 Amazon SageMaker AI 端點。
如果你是建立新端點，以下圖表解釋了工作流程：
- 選擇您的例項型別並分配優先順序（1 為最高）。
- 為每個例項型別準備最佳化模型，或執行 SageMaker AI 推理建議生成它們。
- 使用列出您優先順序的 InstancePools 建立端點配置。
- 建立端點。SageMaker AI 自動處理容量解析。
- 使用新的 InstanceType 維度設定每型別 CloudWatch 監控。
如果你是遷移現有端點，以下圖表解釋了工作流程：
- 建立新的端點配置：將 InstanceType 替換為 InstancePools，將您當前的例項型別保持在 Priority: 1。
- 呼叫 UpdateEndpoint，您的端點在藍綠過渡期間保持 InService。
- 可選地新增加權利用率縮放指標，如果您的回退例項型別在吞吐量上差異顯著。
設定
採用例項池需要對端點配置進行一個欄位更改：將 ProductionVariant 中的單個 InstanceType 欄位替換為 InstancePools 列表。您的模型、縮放策略和監控儀表板繼續工作，無需修改。
遷移現有端點
之前：單一例項型別：
import boto3 sm = boto3.client("sagemaker")
sm.create_endpoint_config( EndpointConfigName="my-config", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "InstanceType": "ml.g6e.48xlarge", # 單一型別 — 無容量回退 }], )
之後：優先順序排序的例項池：
sm.create_endpoint_config( EndpointConfigName="my-config-v2", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "VariantInstanceProvisionTimeoutInSeconds": 1200, # 見下面的說明 "InstancePools": [ {"InstanceType": "ml.g6e.48xlarge", "Priority": 1}, # 您當前的型別 {"InstanceType": "ml.g6.48xlarge", "Priority": 2}, # 相同系列，第一個回退 {"InstanceType": "ml.p4d.24xlarge", "Priority": 3}, # 更廣泛的回退 ], }], )
您的端點在藍綠過渡期間保持 InService。
sm.update_endpoint( EndpointName="my-endpoint", EndpointConfigName="my-config-v2", )
注意：VariantInstanceProvisionTimeoutInSeconds 是一個與例項池支援一起引入的新欄位。它設定了從池中獲取例項的總視窗：SageMaker AI 在此視窗內繼續重試容量不足錯誤，並在超時後移動到下一個池。有效範圍是 300-3600 秒。1200 秒對於大型 GPU 例項型別來說是合理的起始值。此計時器僅涵蓋例項獲取，模型下載和容器啟動時間由現有的 ModelDataDownloadTimeoutInSeconds 和 ContainerStartupHealthCheckTimeoutInSeconds 欄位分別管理。要在每個例項型別上部署不同的最佳化模型，請將 ModelNameOverride 新增到任何池條目。您可以在上一節中看到模型配置選項。
基於推理元件的端點
sm.create_inference_component( InferenceComponentName="my-ic", EndpointName="my-heterogeneous-endpoint", VariantName="primary", Specifications=[ { "InstanceType": "ml.p5.48xlarge", "ModelName": "my-model-p5-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 65536, }, }, { "InstanceType": "ml.g6.48xlarge", "ModelName": "my-model-g6-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 32768, }, }, ], RuntimeConfig={"CopyCount": 4}, )
非同步推理端點
例項池同樣適用於非同步推理端點。在您的 CreateEndpointConfig 呼叫中新增 AsyncInferenceConfig 塊以及 InstancePools 定義——基於優先順序的配置和回退邏輯同樣適用。這對於縮放到零例項的非同步工作負載特別有用：當端點重新向上縮放以處理排隊的請求時，SageMaker AI 首先使用您可用的最高優先順序池進行配置，為您提供無需手動干預的彈性冷啟動行為。
結論
Amazon SageMaker AI 例項池允許您為推理端點定義優先順序列表的例項型別，SageMaker AI 根據該順序自動管理容量。
在端點建立、擴充套件和縮減期間，SageMaker AI 會遍歷您首選的例項型別，因此當您的首選硬體不可用時，您無需手動重試部署。開始使用很簡單：將端點配置中的 InstanceType 替換為 InstancePools，然後呼叫 UpdateEndpoint。您現有的模型、自動縮放策略和監控儀表板無需重大更改即可繼續工作。
透過每例項型別的 CloudWatch 指標和來自 DescribeEndpoint 的詳細池計數，您還可以清晰即時地瞭解哪些例項型別正在為您的群組提供動力。無論您是在最佳化成本、處理 GPU 容量限制，還是構建可以從零冷啟動的彈性非同步管道，例項池都為您提供了靈活性和自動化，使 ML 推理執行更順暢，運營開銷更低。
此功能今天可用，無需額外費用。您按與標準單型別端點相同的費率支付實際配置的例項型別。要了解更多資訊，請參閱 Amazon SageMaker AI 文件並探索 GitHub 上的示例筆記本。