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

# HyperPod 上模型部署的任務治理
<a name="sagemaker-hyperpod-model-deployment-task-gov"></a>

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

## 推論工作負載管理的運作方式
<a name="sagemaker-hyperpod-model-deployment-task-gov-how"></a>

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

**優先順序類別組態**

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

**配額大小和配置**

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

**資源共用策略**

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

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

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

**團隊內先佔**

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

## 範例推論工作負載設定
<a name="sagemaker-hyperpod-model-deployment-task-gov-example"></a>

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

**叢集組態和政策設定**  
您的叢集具有下列組態：
+ **團隊 A**：10 P4 GPU 配額
+ **團隊 B**：20 P4 GPU 配額
+ **靜態佈建**：無自動擴展
+ **總容量**：30 P4 GPU

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

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

1. **訓練**：優先順序 75

1. **評估**：優先順序 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。

1. **團隊 B 內的自我先佔**

   問題：是否可以先佔低優先順序團隊 B 任務？
   + 是 → 先佔評估任務 (優先順序 50)、釋出 5 個 P4，以及接納推論 Pod
   + 否 → 繼續進行步驟 3。

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

1. **從其他團隊借用**

   問題：是否有來自其他團隊的閒置、可借用配額？
   + 是 → 使用借用配額接納 (標記為可先佔)
   + 否 → Pod 保持 `NotAdmitted` 狀態

## 設定推論工作負載的任務控管
<a name="sagemaker-hyperpod-model-deployment-task-gov-configure"></a>

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

### 先決條件
<a name="sagemaker-hyperpod-model-deployment-task-gov-prereqs"></a>

在設定推論工作負載的任務控管之前，請確定 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>
```

### 了解資源範圍
<a name="sagemaker-hyperpod-model-deployment-task-gov-scoping"></a>

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

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

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

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

```
kubectl api-resources | grep kueue
```

### 新增任務控管標籤
<a name="sagemaker-hyperpod-model-deployment-task-gov-labels"></a>

若要啟用推論部署的任務控管，請將下列標籤新增至 `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。

### 驗證任務控管組態
<a name="sagemaker-hyperpod-model-deployment-task-gov-verify"></a>

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

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

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

   ```
   kubectl get workloads -n <namespace>
   ```

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

1. 檢查 Pod 狀態：

   ```
   kubectl get pods -n <namespace>
   ```

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

1. 檢查配額消耗：

   ```
   kubectl get clusterqueue <clusterqueue-name> -o yaml
   ```

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

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

   ```
   kubectl get localqueue -n <namespace>
   ```

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

1. 檢視 Kueue 許可事件：

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

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

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