View a markdown version of this page

HyperPod 上模型部署的任務治理 - Amazon SageMaker AI
推論工作負載管理的運作方式範例推論工作負載設定設定推論工作負載的任務控管

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

HyperPod 上模型部署的任務治理

本節涵蓋如何針對即時推論工作負載最佳化您共用的 Amazon SageMaker HyperPod EKS 叢集。您將了解如何設定 Kueue 的任務治理功能，包括配額管理、優先順序排程和資源共用政策，以確保您的推論工作負載在流量突增期間取得其所需的 GPU 資源，同時維持團隊訓練、評估和測試活動之間的公平分配。如需更多關於任務治理的一般資訊，請參閱 SageMaker HyperPod 任務治理。

推論工作負載管理的運作方式

若要有效管理共用 HyperPod EKS 叢集中的即時推論流量突增，請使用 Kueue 的現有功能實作下列任務治理策略。

優先順序類別組態

為具有高權重 (例如 100) 的推論工作負載定義專用優先順序類別，以確保在其他任務類型之前接納和排程推論 Pod。此組態可讓推論工作負載在叢集載入期間先佔優先順序較低的任務，這對於在流量激期間維持低延遲要求至關重要。

配額大小和配置

在您團隊的 ClusterQueue 中保留足夠的 GPU 資源，以處理預期的推論突增。在低推論流量期間，未使用的配額資源可以暫時分配給其他團隊的任務。當推論需求增加時，可以回收這些借用的資源，以排定待定推論 Pod 的優先順序。如需詳細資訊，請參閱叢集配額。

資源共用策略

根據您的要求，在兩種配額共用方法之間進行選擇：

  1. 嚴格資源控制：停用配額借出和借用，以保證您的工作負載始終有預留 GPU 容量可用。此方法需要夠大的配額大小，才能獨立處理尖峰需求，但可能在低流量期間造成閒置節點。

  2. 彈性資源共用：啟用配額借用，以在需要時使用其他團隊的閒置資源。借用的 Pod 會標記為可先佔，但如果借出團隊回收容量，則可能會將其移出。

團隊內先佔

在相同配額下執行混合工作負載 (評估、訓練和推論) 時，啟用團隊內先佔。這可讓 Kueue 先佔團隊內的低優先順序任務，以容納高優先順序推論 Pod，確保即時推論可以在不依賴外部配額借用的情況下執行。如需詳細資訊，請參閱先佔。

範例推論工作負載設定

下列範例展示 Kueue 如何管理共用 Amazon SageMaker HyperPod 叢集中的 GPU 資源。

叢集組態和政策設定

您的叢集具有下列組態：

  • 團隊 A：10 P4 GPU 配額

  • 團隊 B：20 P4 GPU 配額

  • 靜態佈建：無自動擴展

  • 總容量：30 P4 GPU

共用 GPU 集區使用此優先順序政策：

  1. 即時推論：優先順序 100

  2. 訓練：優先順序 75

  3. 評估：優先順序 50

Kueue 會強制執行團隊配額和優先順序類別，並啟用先佔和配額借用。

初始狀態：正常叢集使用率

在正常操作中：

  • 團隊 A 在所有 10 個 P4 GPU 上執行訓練和評估任務

  • 團隊 B 在其 20 GPU 配額內執行即時推論 (10 個 P4) 和評估 (10 個 P4)

  • 叢集已充分利用，所有任務均已接納並執行中

推論突增：團隊 B 需要額外的 GPU

當團隊 B 遇到流量突增時，其他推論 Pod 需要額外 5 個 P4 GPU。Kueue 偵測到新 Pod：

  • 在團隊 B 的命名空間內

  • 優先順序 100 (即時推論)

  • 由於配額限制條件而等待接納

Kueue 的回應程序會在兩個選項之間進行選擇：

選項 1：配額借用 - 如果團隊 A 只使用其 10 個 P4 中的 6 個，Kueue 可以使用閒置的 4 個 P4 來接納團隊 B 的 Pod。不過，這些借用的資源是可先佔的 - 如果團隊 A 提交任務達到其完整配額，Kueue 會移出團隊 B 借用的推論 Pod。

選項 2：自我先佔 (建議) - 團隊 B 執行低優先順序評估任務 (優先順序 50)。當高優先順序推論 Pod 等待時，Kueue 會先佔團隊 B 配額內的評估任務，並接納推論 Pod。此方法提供安全的資源分配，沒有外部移出風險。

Kueue 遵循三步驟程序來分配資源：

  1. 配額檢查

    問題：團隊 B 是否有未使用的配額？

    • 是 → 接納 Pod

    • 否 → 繼續進行步驟 2。

  2. 團隊 B 內的自我先佔

    問題：是否可以先佔低優先順序團隊 B 任務？

    • 是 → 先佔評估任務 (優先順序 50)、釋出 5 個 P4，以及接納推論 Pod

    • 否 → 繼續進行步驟 3。

    這種方法將工作負載保持在團隊 B 的保證配額內，從而避免外部移出風險。

  3. 從其他團隊借用

    問題：是否有來自其他團隊的閒置、可借用配額？

    • 是 → 使用借用配額接納 (標記為可先佔)

    • 否 → Pod 保持 NotAdmitted 狀態

設定推論工作負載的任務控管

若要將推論工作負載與 Kueue 整合，請將任務控管標籤新增至您的 InferenceEndpointConfig或 JumpStartModel CRD。這些標籤決定哪些 LocalQueue 接收配額管理的工作負載，並定義先佔決策中使用的排程優先順序。下列各節涵蓋先決條件、資源範圍、標籤組態和驗證步驟。

先決條件

在設定推論工作負載的任務控管之前，請確定 HyperPod 叢集中存在下列資源：

  • Kueue 已安裝並在您的叢集上執行

  • ClusterQueue 存在，並將 GPU 配額分配給您的團隊

  • LocalQueue 存在於您計劃部署推論端點的命名空間中

  • 針對工作負載類型定義一或多個 PriorityClass 資源 （例如推論、訓練、評估）

若要驗證這些資源是否可用，請執行下列命令：

# Verify Kueue is installed
kubectl get crd | grep kueue

# List available PriorityClasses
kubectl get priorityclass

# List ClusterQueues
kubectl get clusterqueue

# List LocalQueues in your namespace
kubectl get localqueue -n <your-namespace>

了解資源範圍

任務控管資源有不同的範圍，會影響您設定推論部署標籤的方式。

kueue.x-k8s.io/queue-name 標籤必須參考與 InferenceEndpointConfig或 位於相同命名空間中的 LocalQueueJumpStartModel。如果在該命名空間中找不到相符的 LocalQueue，Kue 將不會認可工作負載。

ClusterQueue、ResourceFlavor 和 PriorityClass 是叢集範圍，可從任何命名空間存取。

若要驗證叢集上的資源範圍：

kubectl api-resources | grep kueue

新增任務控管標籤

若要啟用推論部署的任務控管，請將下列標籤新增至 InferenceEndpointConfig或 JumpStartModel CRD 的 metadata區段：

metadata:
  name: <your-deployment-name>
  namespace: <your-namespace>
  labels:
    kueue.x-k8s.io/queue-name: <your-localqueue-name>
    kueue.x-k8s.io/priority-class: <your-priority-class>

標籤描述：

  • kueue.x-k8s.io/queue-name — 將工作負載路由至您團隊的 LocalQueue 以進行配額追蹤。必須符合與工作負載相同命名空間中的 LocalQueue 名稱。

  • kueue.x-k8s.io/priority-class — 設定先佔決策的排程優先順序。依名稱參考叢集範圍 PriorityClass。

驗證任務控管組態

JumpStartModel 使用任務控管標籤套用 InferenceEndpointConfig或 之後，請確認 Kueue 已正確認可工作負載和 Pod。

驗證任務控管是否正常運作

  1. 檢查工作負載許可狀態：

    kubectl get workloads -n <namespace>

    成功認可的工作負載會顯示在 True ADMITTED 欄中，並列出在 RESERVED IN 欄中保留資源的 ClusterQueue。

  2. 檢查 Pod 狀態：

    kubectl get pods -n <namespace>

    入學後，Pod 會逐步轉換到初始化階段，直到達到 Running 狀態為止。

  3. 檢查配額消耗：

    kubectl get clusterqueue <clusterqueue-name> -o yaml

    檢閱 status區段以確認正在追蹤資源消耗。

  4. 檢查 LocalQueue 待定工作負載：

    kubectl get localqueue -n <namespace>

    PENDING WORKLOADS 欄顯示有多少工作負載正在等待許可。

  5. 檢視 Kueue 許可事件：

    kubectl describe workload <workload-name> -n <namespace>

    檢閱事件區段，了解許可決策和任何錯誤。

如果 Pod 保持 Pending 狀態，請判斷問題是位於 Kueue 許可層級 （工作負載顯示 Admitted: False) 還是 Kubernetes 排程器層級 （工作負載已允許，但 Pod 無法排程）。