本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

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

本节介绍如何针对实时推理工作负载优化共享的 SageMaker HyperPod Amazon 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）会被标记为可抢占状态，如果借出团队回收资源容量，这些容器组（pod）可能会被驱逐。

**Intra-Team 抢占权**

在同一配额下运行混合工作负载（评估、训练和推理）时，启用团队内抢占功能。这使得 Kueue 能够在团队内部抢占低优先级作业，以容纳高优先级的推理容器组（pod），从而确保实时推理可独立运行，而无需依赖外部配额借入。有关更多信息，请参阅[抢占](https://kueue.sigs.k8s.io/docs/concepts/preemption/)。

## 推理工作负载设置示例
<a name="sagemaker-hyperpod-model-deployment-task-gov-example"></a>

以下示例显示了 Kueue 如何在共享的 Ama SageMaker HyperPod zon 集群中管理 GPU 资源。

**集群配置和策略设置**  
您的集群具有以下配置：
+ **团队 A**：10 个 P4 GPU 配额
+ **团队 B**：20 个 P4 GPU 配额
+ **静态预调配**：不自动扩缩
+ **总容量**：30 个 P4 GPU

共享 GPU 池使用以下优先级策略：

1. **Real-time 推断**：优先级 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： Self-preemption （推荐）**-团队 B 运行低优先级评估作业（优先级 50）。当高优先级推理容器组（pod）处于等待状态时，Kueue 会在团队 B 的配额内抢占评估作业的资源，并接纳这些推理容器组（pod）。此方法可实现安全的资源分配，且不存在外部驱逐风险。

Kueue 遵循三步流程来分配资源：

1. **配额检查**

   问题：团队 B 是否有未使用的配额？
   + 是 → 接纳容器组（pod）
   + 否 → 继续执行步骤 2

1. **Self-preemption 在 B 队内**

   问题：低优先级的团队 B 作业能否被抢占？
   + 是 → 抢占评估作业（优先级 50），释放 5 个 P4，并接纳推理容器组（pod）
   + 否 → 继续执行步骤 3

   此方法可将工作负载控制在团队 B 的保障配额范围内，从而避免外部驱逐风险。

1. **从其他团队借入**

   问题：其他团队是否有闲置的可借入配额？
   + 是 → 使用借入的配额接纳（标记为可抢占状态）
   + 否 → 容器组（pod）保持 `NotAdmitted` 状态

## 为推理工作负载配置任务治理
<a name="sagemaker-hyperpod-model-deployment-task-gov-configure"></a>

要将您的推理工作负载与 Kueue 集成，请向您的`InferenceEndpointConfig`或 CRD 添加任务管理标签。`JumpStartModel`这些标签确定哪个 LocalQueue 接收配额管理的工作负载，并定义抢占决策中使用的调度优先级。以下各节涵盖先决条件、资源范围界定、标签配置和验证步骤。

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

在为推理工作负载配置任务治理之前，请确保您的 HyperPod 集群中存在以下资源：
+ **Kueue** 已在您的集群上安装并运行
+ **ClusterQueue**已为你的团队分配了 GPU 配额
+ A **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`标签必须引用 LocalQueue 与您的`InferenceEndpointConfig`或位于同一命名空间中的`JumpStartModel`。如果在该命名空间中找不到匹配 LocalQueue 项，Kueue 将不允许该工作负载。

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>

使用任务管理标签应用`InferenceEndpointConfig`或`JumpStartModel`后，验证 Kueue 是否承认工作负载以及 Pod 的调度是否正确。

**验证任务治理是否有效**

1. 检查工作负载准入状态：

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

   成功允许的工作负载显示`True`在 “已接受” 列中，并在 “ 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>
   ```

   待处理的工作负载列显示有多少工作负载正在等待接收。

1. 查看 Kueue 入场活动：

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

   查看 “活动” 部分，了解录取决定和任何错误。

如果 Pod 保持`Pending`状态，请确定问题出在 Kueue 准入级别（工作负载显示`Admitted: False`）还是 Kubernetes 调度器级别（允许工作负载但 pod 不可调度）。