翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon SageMaker HyperPod での GPU パーティションの使用 HyperPod
GPU パーティショニング

クラスター管理者は、組織全体で GPU 使用率を最大化する方法を選択できます。NVIDIA マルチインスタンス GPU (MIG) テクノロジーで GPU パーティショニングを有効にして、GPU リソースをより小さく分離されたインスタンスに分割し、リソース使用率を向上させることができます。この機能を使用すると、ハードウェア全体を 1 つの十分に活用されていないタスクに専念するのではなく、1 つの GPU で複数の小さなサイズのタスクを同時に実行できます。これにより、無駄なコンピューティング能力とメモリがなくなります。

MIG テクノロジーを使用した GPU パーティショニングは GPUs、サポートされている 1 つの GPU を最大 7 つの別々の GPU パーティションに分割できます。各 GPU パーティションには専用のメモリ、キャッシュ、コンピューティングリソースがあり、予測可能な分離を提供します。

## 利点

+ **GPU 使用率の向上** - コンピューティングとメモリの要件に基づいて GPUsパーティション化することで、コンピューティング効率を最大化
+ **タスクの分離** - 各 GPU パーティションは、専用のメモリ、キャッシュ、コンピューティングリソースで独立して動作します。
+ **タスクの柔軟性** - 単一の物理 GPU でタスクの組み合わせをサポートし、すべて並行して実行されます。
+ **柔軟なセットアップ管理** - Kubernetes コマンドラインクライアント を使用した Do-it-yourself (DIY) Kubernetes 設定と`kubectl`、GPU パーティションに関連付けられたラベルを簡単に設定および適用するためのカスタムラベル付きのマネージドソリューションの両方をサポートします。

## サポートされるインスタンスタイプ


MIG テクノロジーを使用した GPU パーティショニングは、次の HyperPod インスタンスタイプでサポートされています。

**A100 GPU インスタンス** - [https://aws.amazon.com/ec2/instance-types/p4/](https://aws.amazon.com/ec2/instance-types/p4/)
+ **ml.p4d.24xlarge** - 8 NVIDIA A100 GPUs (GPU あたり 80 GB HBM2e)
+ **ml.p4de.24xlarge** - 8 NVIDIA A100 GPUs (GPU あたり 80 GB HBM2e)

**H100 GPU インスタンス** - [https://aws.amazon.com/ec2/instance-types/p5/](https://aws.amazon.com/ec2/instance-types/p5/)
+ **ml.p5.48xlarge** - 8 NVIDIA H100 GPUs (GPU あたり 80 GB HBM3)

**H200 GPU インスタンス** - [https://aws.amazon.com/ec2/instance-types/p5/](https://aws.amazon.com/ec2/instance-types/p5/)
+ **ml.p5e.48xlarge** - 8 NVIDIA H200 GPUs (GPU あたり 141GB HBM3e)
+ **ml.p5en.48xlarge** - 8 NVIDIA H200 GPUs (GPU あたり 141GB HBM3e)

**B200 GPU インスタンス** - [https://aws.amazon.com/ec2/instance-types/p6/](https://aws.amazon.com/ec2/instance-types/p6/)
+ **ml.p6b.48xlarge** - NVIDIA B200 GPUs

## GPU パーティション


NVIDIA MIG プロファイルは、GPUsパーティション化方法を定義します。各プロファイルは、MIG インスタンスあたりのコンピューティングとメモリの割り当てを指定します。以下は、各 GPU タイプに関連付けられた MIG プロファイルです。

**A100 GPU (ml.p4d.24xlarge)**


| プロファイル | メモリ (GB) | GPU あたりのインスタンス数 | ml.p4d.24xlarge あたりの合計 | 
| --- | --- | --- | --- | 
| `1g.5gb` | 5 | 7 | 56 | 
| `2g.10gb` | 10 | 3 | 24 | 
| `3g.20gb` | 20 | 2 | 16 | 
| `4g.20gb` | 20 | 1 | 8 | 
| `7g.40gb` | 40 | 1 | 8 | 

**H100 GPU (ml.p5.48xlarge)**


| プロファイル | メモリ (GB) | GPU あたりのインスタンス数 | ml.p5.48xlarge あたりの合計 | 
| --- | --- | --- | --- | 
| `1g.10gb` | 10 | 7 | 56 | 
| `1g.20gb` | 20 | 4 | 32 | 
| `2g.20gb` | 20 | 3 | 24 | 
| `3g.40gb` | 40 | 2 | 16 | 
| `4g.40gb` | 40 | 1 | 8 | 
| `7g.80gb` | 80 | 1 | 8 | 

**H200 GPU (ml.p5e.48xlarge および ml.p5en.48xlarge)**


| プロファイル | メモリ (GB) | GPU あたりのインスタンス数 | ml.p5en.48xlarge あたりの合計 | 
| --- | --- | --- | --- | 
| `1g.18gb` | 18 | 7 | 56 | 
| `1g.35gb` | 35 | 4 | 32 | 
| `2g.35gb` | 35 | 3 | 24 | 
| `3g.71gb` | 71 | 2 | 16 | 
| `4g.71gb` | 71 | 1 | 8 | 
| `7g.141gb` | 141 | 1 | 8 | 

**Topics**
+ [

## 利点
](#sagemaker-hyperpod-eks-gpu-partitioning-benefits)
+ [

## サポートされるインスタンスタイプ
](#sagemaker-hyperpod-eks-gpu-partitioning-instance-types)
+ [

## GPU パーティション
](#sagemaker-hyperpod-eks-gpu-partitioning-profiles)
+ [

# Amazon SageMaker HyperPod での GPU パーティションの設定 HyperPod
](sagemaker-hyperpod-eks-gpu-partitioning-setup.md)
+ [

# ノードのライフサイクルとラベル
](sagemaker-hyperpod-eks-gpu-partitioning-labels.md)
+ [

# MIG を使用したタスク送信
](sagemaker-hyperpod-eks-gpu-partitioning-task-submission.md)

# Amazon SageMaker HyperPod での GPU パーティションの設定 HyperPod
GPU パーティションのセットアップ

**Topics**
+ [

## 前提条件
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-prerequisites)
+ [

## MIG 設定を使用したクラスターの作成
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-create-cluster)
+ [

## 既存のクラスターへの GPU 演算子の追加
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-add-operator)
+ [

## MIG 設定の更新
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-update)
+ [

## MIG 設定の検証
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-verify)
+ [

## MIG 設定をデバッグするための一般的なコマンド
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-debug-commands)
+ [

## SageMaker AI コンソールの使用
](#sagemaker-hyperpod-eks-gpu-partitioning-setup-console)

## 前提条件

+ サポートされている GPU インスタンスを持つ HyperPod Amazon EKS クラスター
+ NVIDIA GPU Operator のインストール
+ クラスター管理のための適切な IAM アクセス許可

## MIG 設定を使用したクラスターの作成


### の使用 AWS CLI


```
aws sagemaker create-cluster \
  --cluster-name my-mig-cluster \
  --orchestrator 'Eks={ClusterArn=arn:aws:eks:region:account:cluster/cluster-name}' \
  --instance-groups '{
    "InstanceGroupName": "gpu-group",
    "InstanceType": "ml.p4d.24xlarge",
    "InstanceCount": 1,
    "LifeCycleConfig": {
       "SourceS3Uri": "s3://my-bucket",
       "OnCreate": "on_create_script.sh"
    },
    "KubernetesConfig": {
       "Labels": {
          "nvidia.com/mig.config": "all-1g.5gb"
       }
    },
    "ExecutionRole": "arn:aws:iam::account:role/execution-role",
    "ThreadsPerCore": 1
  }' \
  --vpc-config '{
     "SecurityGroupIds": ["sg-12345"],
     "Subnets": ["subnet-12345"]
  }' \
  --node-provisioning-mode Continuous
```

### の使用 CloudFormation


```
{
  "ClusterName": "my-mig-cluster",
  "InstanceGroups": [
    {
      "InstanceGroupName": "gpu-group",
      "InstanceType": "ml.p4d.24xlarge",
      "InstanceCount": 1,
      "KubernetesConfig": {
        "Labels": {
          "nvidia.com/mig.config": "all-2g.10gb"
        }
      },
      "ExecutionRole": "arn:aws:iam::account:role/execution-role"
    }
  ],
  "Orchestrator": {
    "Eks": {
      "ClusterArn": "arn:aws:eks:region:account:cluster/cluster-name"
    }
  },
  "NodeProvisioningMode": "Continuous"
}
```

## 既存のクラスターへの GPU 演算子の追加


### GPU Operator をインストールする


をクラスターリージョン (us-east-1、us-west-2 など) `{$AWS_REGION}`に置き換えます。

```
helm install gpuo helm_chart/HyperPodHelmChart/charts/gpu-operator \
-f helm_chart/HyperPodHelmChart/charts/gpu-operator/regional-values/values-{$AWS_REGION}.yaml \
-n kube-system
```

### インストールの確認 (2～3 分待機)


すべての GPU オペレータポッドが実行されていることを確認します。

```
kubectl get pods -n kube-system | grep -E "(gpu-operator|nvidia-)"
```

**予想されるポッド:**
+ gpu-operator-\$1 - 1 インスタンス (クラスターコントローラー)
+ nvidia-device-plugin-daemonset-\$1 - GPU ノードあたり 1 (すべての GPU インスタンス)
+ nvidia-mig-manager-\$1 - MIG 対応ノードあたり 1 (A100/H100)

### 古いデバイスプラグインを削除する


既存の nvidia-device-plugin を無効にします。

```
helm upgrade dependencies helm_chart/HyperPodHelmChart \
--set nvidia-device-plugin.devicePlugin.enabled=false \
-n kube-system
```

### GPU リソースの検証


ノードに GPU 容量が表示されていることを確認します。nvidia.com/gpu: 8 (または実際の GPU 数) が表示されます。

```
kubectl describe nodes | grep "nvidia.com/gpu"
```

## MIG 設定の更新


**MIG 更新前のノードの準備**  
インスタンスグループの MIG 設定を更新する前に、ワークロードの中断を防ぐためにノードを準備する必要があります。再設定するノードからワークロードを安全にドレインするには、次の手順に従います。

### ステップ 1: インスタンスグループのノードを特定する


まず、更新するインスタンスグループに属するすべてのノードを特定します。

```
# List all nodes in the instance group
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME

# Example:
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=p4d-group
```

このコマンドは、指定されたインスタンスグループ内のすべてのノードのリストを返します。次のステップでは、各ノード名を書き留めます。

### ステップ 2: 各ノードのコードとドレイン


ステップ 1 で識別されたノードごとに、次のアクションを実行します。

#### ノードのコード接続


コーディングにより、ノードで新しいポッドをスケジュールできなくなります。

```
# Cordon a single node
kubectl cordon NODE_NAME

# Example:
kubectl cordon hyperpod-i-014a41a7001adca60
```

#### ノードからワークロードポッドをドレインする


ノードをドレインして、システムポッドを保持しながらすべてのワークロードポッドを削除します。

```
# Drain the node (ignore DaemonSets and evict pods)
kubectl drain NODE_NAME \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --force \
  --grace-period=300

# Example:
kubectl drain hyperpod-i-014a41a7001adca60 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --force \
  --grace-period=300
```

**コマンドオプションの説明:**
+ `--ignore-daemonsets` - DaemonSet ポッドが存在する場合でも、ドレインオペレーションを続行できるようにします
+ `--delete-emptydir-data` - emptyDir ボリュームを使用してポッドを削除します (ドレインを成功させるために必要)
+ `--force` - コントローラーによって管理されていないポッドを強制的に削除します (注意して使用)
+ `--grace-period=300` - ポッドが正常に終了するまで 5 分かかります

**重要**  
ポッドの数とその終了猶予期間によっては、ドレインオペレーションに数分かかる場合があります。
次の名前空間のシステムポッドは実行されたままになります: `kube-system`、`cert-manager`、、`kubeflow``hyperpod-inference-system`、、`kube-public`、`mpi-operator`、、`gpu-operator``aws-hyperpod``jupyter-k8s-system``hyperpod-observability`、、`kueue-system`、および `keda`
DaemonSet ポッドはノードに残ります (設計上無視されます)

### ステップ 3: ワークロードポッドが実行されていないことを確認する


ドレイン後、ノードにワークロードポッドが残っていないことを確認します (システム名前空間を除く）。

```
# Check for any remaining pods outside system namespaces
kubectl get pods --all-namespaces --field-selector spec.nodeName=NODE_NAME \
  | grep -v "kube-system" \
  | grep -v "cert-manager" \
  | grep -v "kubeflow" \
  | grep -v "hyperpod-inference-system" \
  | grep -v "kube-public" \
  | grep -v "mpi-operator" \
  | grep -v "gpu-operator" \
  | grep -v "aws-hyperpod" \
  | grep -v "jupyter-k8s-system" \
  | grep -v "hyperpod-observability" \
  | grep -v "kueue-system" \
  | grep -v "keda"

# Example:
kubectl get pods --all-namespaces --field-selector spec.nodeName=hyperpod-i-014a41a7001adca60 \
  | grep -v "kube-system" \
  | grep -v "cert-manager" \
  | grep -v "kubeflow" \
  | grep -v "hyperpod-inference-system" \
  | grep -v "kube-public" \
  | grep -v "mpi-operator" \
  | grep -v "gpu-operator" \
  | grep -v "aws-hyperpod" \
  | grep -v "jupyter-k8s-system" \
  | grep -v "hyperpod-observability" \
  | grep -v "kueue-system" \
  | grep -v "keda"
```

**予想される出力:** ノードが適切にドレインされている場合、このコマンドは結果を返さない (またはヘッダー行のみを表示する) 必要があります。まだ実行中のポッドがある場合は、削除されなかった理由を調査し、必要に応じて手動で削除します。

### ステップ 4: ノードの準備状況ステータスを確認する


MIG 更新に進む前に、すべてのノードが接続されていることを確認します。

```
# Check node status - should show "SchedulingDisabled"
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME
```

ノードは STATUS 列`SchedulingDisabled`に表示され、接続され、MIG 更新の準備が整っていることを示します。

### 既存のクラスターで MIG プロファイルを更新する


既存のクラスターで MIG プロファイルを変更できます。

```
aws sagemaker update-cluster \
  --cluster-name my-mig-cluster \
  --instance-groups '{
    "InstanceGroupName": "gpu-group",
    "InstanceType": "ml.p4d.24xlarge",
    "InstanceCount": 1,
    "KubernetesConfig": {
       "Labels": {
          "nvidia.com/mig.config": "all-3g.20gb"
       }
    },
    "ExecutionRole": "arn:aws:iam::account:role/execution-role"
  }'
```

**注記**  
ジョブがノードで既に実行されている場合、MIG パーティショニングは失敗します。ユーザーは、MIG パーティショニングを再度試行する前に、ノードをドレインするためのエラーメッセージを受け取ります。

## MIG 設定の検証


クラスターの作成または更新後、MIG 設定を確認します。

```
# Update kubeconfig
aws eks update-kubeconfig --name your-eks-cluster --region us-east-2

# Check MIG labels
kubectl get node NODE_NAME -o=jsonpath='{.metadata.labels}' | grep mig

# Check available MIG resources
kubectl describe node NODE_NAME | grep -A 10 "Allocatable:"
```

## MIG 設定をデバッグするための一般的なコマンド


次のコマンドを使用して、クラスター内の MIG 設定のトラブルシューティングと検証を行います。

```
# Check GPU Operator status
kubectl get pods -n gpu-operator-resources

# View MIG configuration
kubectl exec -n gpu-operator-resources nvidia-driver-XXXXX -- nvidia-smi mig -lgi

# Check device plugin configuration
kubectl logs -n gpu-operator-resources nvidia-device-plugin-XXXXX

# Monitor node events
kubectl get events --field-selector involvedObject.name=NODE_NAME
```

**注記**  
`nvidia-driver-XXXXX` と をクラスターの実際のポッド名`nvidia-device-plugin-XXXXX`に置き換え、 をノードの名前`NODE_NAME`に置き換えます。

## SageMaker AI コンソールの使用


### MIG を使用した新しいクラスターの作成


1. **Amazon SageMaker AI** > **HyperPod クラスター** > **クラスター管理** > ** HyperPod クラスターの作成**に移動する

1. **EKS によってオーケストレーション**された を選択する

1. **カスタムセットアップ**を選択し、**GPU Operator** がデフォルトで有効になっていることを確認する

1. **「インスタンスグループ**」セクションで、**「グループの追加**」をクリックします。

1. インスタンスグループを設定し、**詳細設定**に移動して **GPU パーティショントグルの使用**を有効にし、ドロップダウンから目的の **MIG 設定**を選択します。

1. **インスタンスグループを追加**をクリックし、残りのクラスター設定を完了します。

1. **送信**をクリックしてクラスターを作成します

### 既存のクラスターでの MIG 設定の更新


1. **Amazon SageMaker AI** > **HyperPod クラスター** > **クラスター管理**に移動する

1. 既存のクラスターを選択し、変更するインスタンスグループ**の編集**をクリックします。

1. **詳細設定**で、まだ有効になっていない場合は **GPU パーティションを使用し**、ドロップダウンから別の **MIG 設定**を選択する

1. **変更の保存** をクリックします。

# ノードのライフサイクルとラベル
ノードのライフサイクル

Amazon SageMaker HyperPod は、GPU パーティショニングを開始する前に HyperPod クラスターの作成と更新中に、クラスターインスタンスに対してディープヘルスチェックを実行します。HyperPod ヘルスモニタリングエージェントは、GPU パーティションインスタンスのヘルスステータスを継続的にモニタリングします。

## MIG 設定状態


GPU パーティション設定のノードは、いくつかの状態を経ます。
+ **保留中** - ノードが MIG プロファイルで設定されている
+ **設定** - GPU オペレーターが MIG パーティショニングを適用しています
+ **Success** - GPU パーティショニングが正常に完了しました
+ **失敗** - GPU パーティショニングでエラーが発生しました

## ノードの状態のモニタリング


```
# Check node health status
kubectl get nodes -l sagemaker.amazonaws.com/node-health-status=Schedulable

# Monitor MIG configuration progress
kubectl get node NODE_NAME -o jsonpath='{.metadata.labels.nvidia\.com/mig\.config\.state}'

# Check for configuration errors
kubectl describe node NODE_NAME | grep -A 5 "Conditions:"
```

## カスタムラベルとテイント


カスタムラベルとテイントを使用して MIG 設定を管理し、GPU パーティションにラベルを付け、インスタンス全体に適用できます。

```
{
  "KubernetesConfig": {
    "Labels": {
      "nvidia.com/mig.config": "all-2g.10gb",
      "task-type": "inference",
      "environment": "production"
    },
    "Taints": [
      {
        "Key": "gpu-task",
        "Value": "mig-enabled",
        "Effect": "NoSchedule"
      }
    ]
  }
}
```

# MIG を使用したタスク送信
タスク送信

**Topics**
+ [

## Kubernetes YAML の使用
](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-kubectl)
+ [

## HyperPod CLI の使用
](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-cli)
+ [

## MIG を使用したモデルデプロイ
](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-deployment)
+ [

## HyperPod CLI の使用
](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-hyperpod-cli)

## Kubernetes YAML の使用


```
apiVersion: batch/v1
kind: Job
metadata:
  name: mig-job
  namespace: default
spec:
  template:
    spec:
      containers:
      - name: pytorch
        image: pytorch/pytorch:latest
        resources:
          requests:
            nvidia.com/mig-1g.5gb: 1
            cpu: "100m"
            memory: "128Mi"
          limits:
            nvidia.com/mig-1g.5gb: 1
      restartPolicy: Never
```

## HyperPod CLI の使用


HyperPod CLI を使用して、MIG をサポートする JumpStart モデルをデプロイします。次の例は、GPU パーティショニングの新しい CLI パラメータを示しています。

```
# Deploy JumpStart model with MIG
hyp create hyp-jumpstart-endpoint \
  --model-id deepseek-llm-r1-distill-qwen-1-5b \
  --instance-type ml.p5.48xlarge \
  --accelerator-partition-type mig-2g.10gb \
  --accelerator-partition-validation True \
  --endpoint-name my-endpoint \
  --tls-certificate-output-s3-uri s3://certificate-bucket/ \
  --namespace default
```

## MIG を使用したモデルデプロイ


HyperPod Inference では、Studio Classic `kubectl`および HyperPod CLI を介して MIG プロファイルにモデルをデプロイできます。JumpStart モデルを にデプロイするために`kubectl`、CRDs にはモデルを目的の MIG プロファイルにデプロイ`spec.server.acceleratorPartitionType`するために というフィールドがあります。CRD で選択された MIG プロファイルにモデルをデプロイできるように、検証を実行します。MIG 検証チェックを無効にする場合は、 `spec.server.validations.acceleratorPartitionValidation`を に使用します`False`。

### JumpStart モデル


```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: deepseek-model
  namespace: default
spec:
  sageMakerEndpoint:
    name: deepseek-endpoint
  model:
    modelHubName: SageMakerPublicHub
    modelId: deepseek-llm-r1-distill-qwen-1-5b
  server:
    acceleratorPartitionType: mig-7g.40gb
    instanceType: ml.p4d.24xlarge
```

### InferenceEndpointConfig を使用して Amazon S3 からモデルをデプロイする InferenceEndpointConfig


InferenceEndpointConfig を使用すると、Amazon S3 からカスタムモデルをデプロイできます。モデルを MIG にデプロイするには、 `requests`と で MIG プロファイルについて`spec.worker.resources`言及します`limits`。以下の簡単なデプロイを参照してください。

```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: custom-model
  namespace: default
spec:
  replicas: 1
  modelName: my-model
  endpointName: my-endpoint
  instanceType: ml.p4d.24xlarge
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: my-model-bucket
      region: us-east-2
    modelLocation: model-path
  worker:
    resources:
      requests:
        nvidia.com/mig-3g.20gb: 1
        cpu: "5600m"
        memory: "10Gi"
      limits:
        nvidia.com/mig-3g.20gb: 1
```

### InferenceEndpointConfig を使用して FSx for Lustre からモデルをデプロイする


InferenceEndpointConfig を使用すると、FSx for Lustre からカスタムモデルをデプロイできます。モデルを MIG にデプロイするには、 `requests`と で MIG プロファイルについて`spec.worker.resources`言及します`limits`。以下の簡単なデプロイを参照してください。

```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: custom-model
  namespace: default
spec:
  replicas: 1
  modelName: my-model
  endpointName: my-endpoint
  instanceType: ml.p4d.24xlarge
  modelSourceConfig:
    modelSourceType: fsx
    fsxStorage:
      fileSystemId: fs-xxxxx
    modelLocation: location-on-fsx
  worker:
    resources:
      requests:
        nvidia.com/mig-3g.20gb: 1
        cpu: "5600m"
        memory: "10Gi"
      limits:
        nvidia.com/mig-3g.20gb: 1
```

### Studio Classic UI の使用


#### MIG を使用した JumpStart モデルのデプロイ


1. **Studio Classic** を開き、**JumpStart** に移動します。

1. 目的のモデルを参照または検索する (DeepSeek」、「Llama」など)

1. モデルカードをクリックし、**デプロイ** を選択します。

1. デプロイ設定では、次の操作を行います。
   + デプロイターゲットとして **HyperPod** を選択する
   + ドロップダウンから MIG 対応クラスターを選択する
   + **[インスタンス設定]** で次の設定を行なってください。
     + インスタンスタイプを選択する (例: `ml.p4d.24xlarge`)
     + 使用可能なオプションから **GPU パーティションタイプ**を選択する
     + **インスタンス数**と **Auto Scaling** の設定を構成する

1. **デプロイ**を確認してクリックする

1. **「エンドポイント」セクションの「デプロイの進行状況をモニタリングする**」

#### モデル設定オプション


**エンドポイント設定:**
+ **エンドポイント名** - デプロイの一意の識別子
+ **バリアント名** - 設定バリアント (デフォルト: AllTraffic)
+ **インスタンスタイプ** - GPU パーティション (p シリーズ) をサポートする必要があります
+ **MIG プロファイル** - GPU パーティション
+ **初期インスタンス数** - デプロイするインスタンスの数
+ **自動スケーリング** - トラフィックに基づいて動的スケーリングを有効にします

**詳細設定:**
+ **モデルデータの場所** - カスタムモデルの Amazon S3 パス
+ **コンテナイメージ** - カスタム推論コンテナ (オプション)
+ **環境変数** - モデル固有の設定
+ **Amazon VPC 設定** - ネットワーク分離設定

#### デプロイされたモデルのモニタリング


1. **Studio Classic** > **デプロイ >** **エンドポイント**に移動する

1. MIG 対応エンドポイントを選択する

1. 次のようなメトリクスを表示します。
   + **MIG 使用率** - GPU パーティションあたりの使用量
   + **メモリ消費量** - GPU パーティションごと
   + **推論レイテンシ**ー - リクエスト処理時間
   + **スループット** - 1 秒あたりのリクエスト数

1. 自動モニタリング用の **Amazon CloudWatch アラーム**を設定する

1. MIG 使用率に基づいて**自動スケーリングポリシー**を設定する

## HyperPod CLI の使用


### JumpStart デプロイ


HyperPod CLI JumpStart コマンドには、MIG サポート用の 2 つの新しいフィールドが含まれています。
+ `--accelerator-partition-type` - MIG 設定を指定します (例: mig-4g.20gb)
+ `--accelerator-partition-validation` - モデルと MIG プロファイル間の互換性を検証します (デフォルト: true)

```
hyp create hyp-jumpstart-endpoint \
  --version 1.1 \
  --model-id deepseek-llm-r1-distill-qwen-1-5b \
  --instance-type ml.p4d.24xlarge \
  --endpoint-name js-test \
  --accelerator-partition-type "mig-4g.20gb" \
  --accelerator-partition-validation true \
  --tls-certificate-output-s3-uri s3://my-bucket/certs/
```

### カスタムエンドポイントのデプロイ


カスタムエンドポイント経由でデプロイ`--resources-limits`するには、既存のフィールド`--resources-requests`と を使用して MIG プロファイル機能を有効にします。

```
hyp create hyp-custom-endpoint \
  --namespace default \
  --metadata-name deepseek15b-mig-10-14-v2 \
  --endpoint-name deepseek15b-mig-endpoint \
  --instance-type ml.p4d.24xlarge \
  --model-name deepseek15b-mig \
  --model-source-type s3 \
  --model-location deep-seek-15b \
  --prefetch-enabled true \
  --tls-certificate-output-s3-uri s3://sagemaker-bucket \
  --image-uri lmcache/vllm-openai:v0.3.7 \
  --container-port 8080 \
  --model-volume-mount-path /opt/ml/model \
  --model-volume-mount-name model-weights \
  --s3-bucket-name model-storage-123456789 \
  --s3-region us-east-2 \
  --invocation-endpoint invocations \
  --resources-requests '{"cpu":"5600m","memory":"10Gi","nvidia.com/mig-3g.20gb":"1"}' \
  --resources-limits '{"nvidia.com/mig-3g.20gb":"1"}' \
  --env '{
    "OPTION_ROLLING_BATCH":"vllm",
    "SERVING_CHUNKED_READ_TIMEOUT":"480",
    "DJL_OFFLINE":"true",
    "NUM_SHARD":"1",
    "SAGEMAKER_PROGRAM":"inference.py",
    "SAGEMAKER_SUBMIT_DIRECTORY":"/opt/ml/model/code",
    "MODEL_CACHE_ROOT":"/opt/ml/model",
    "SAGEMAKER_MODEL_SERVER_WORKERS":"1",
    "SAGEMAKER_MODEL_SERVER_TIMEOUT":"3600",
    "OPTION_TRUST_REMOTE_CODE":"true",
    "OPTION_ENABLE_REASONING":"true",
    "OPTION_REASONING_PARSER":"deepseek_r1",
    "SAGEMAKER_CONTAINER_LOG_LEVEL":"20",
    "SAGEMAKER_ENV":"1"
  }'
```