はじめに:なぜ今、Inference Operator のインストールが劇的に変わったのか
従来、SageMaker HyperPod で推論ワークロードをデプロイするには、Helm チャートの管理、IAM ロールの設定、依存関係の解決、手動アップグレードなど、AI チームは多くの複雑な作業を強いられていました。最初のモデルが推論結果を返すまでに数時間かかることも珍しくありませんでした。
今回、Amazon SageMaker HyperPod Inference Operator が EKS Add-on として提供されるようになり、状況は一変しました。SageMaker コンソールから ワンクリックインストール と マネージドアップグレード が可能になり、Helm チャートや複雑な IAM 設定は不要です。
この記事では、3つのインストール方法(コンソール、CLI、Terraform) を実際のコードとともに解説し、マルチインスタンスタイプデプロイ や Node Affinity といった高度な機能を実務でどう活用するかまでカバーします。
本記事は AWS Architecture Blog を基に、日本の開発者コミュニティ向けに再構成しました。

実践編:3つのインストール方法とコード例
方法1:SageMaker UI からのインストール(推奨)
SageMaker コンソールは最もシンプルな方法を提供します。Quick Install と Custom Install の2つのオプションがあります。
インストール手順:
- SageMaker Console → HyperPod Clusters → Cluster Management に移動
- 対象クラスターを選択 → Inference タブを開く
- Quick Install(自動設定)または Custom Install(既存リソースの再利用)を選択
- Install ボタンをクリック
- インストール確認:
kubectl get pods -n hyperpod-inference-system
方法2:EKS CLI からのインストール
CLI を好むチームは以下のコマンドで直接インストールできます。ただし、前提リソース(IAM ロール、S3 バケット、VPC エンドポイント)は事前に手動で作成する必要があります。
# EKS Add-on 作成(前提リソースは別途作成が必要)
aws eks create-addon \
--cluster-name my-hyperpod-cluster \
--addon-name amazon-sagemaker-hyperpod-inference \
--addon-version v1.0.0-eksbuild.1 \
--configuration-values '{
"executionRoleArn": "arn:aws:iam::ACCOUNT-ID:role/SageMakerHyperPodInference-inference-role",
"tlsCertificateS3Bucket": "hyperpod-tls-certificate-bucket",
"hyperpodClusterArn": "arn:aws:sagemaker:REGION:ACCOUNT-ID:cluster/CLUSTER-ID",
"alb": {
"serviceAccount": {
"create": true,
"roleArn": "arn:aws:iam::ACCOUNT-ID:role/alb-controller-role"
}
},
"keda": {
"auth": {
"aws": {
"irsa": {
"roleArn": "arn:aws:iam::ACCOUNT-ID:role/keda-operator-role"
}
}
}
}
}' \
--region us-west-2
方法3:Terraform からのインストール
IaC(Infrastructure as Code)を活用する組織では、awesome-distributed-training の Terraform モジュールが利用可能です。
# custom.tfvars の例
kubernetes_version = "1.33"
eks_cluster_name = "tf-eks-cluster"
hyperpod_cluster_name = "tf-hp-cluster"
resource_name_prefix = "tf-eks-test"
aws_region = "us-east-1"
instance_groups = [
{
name = "accelerated-instance-group-1"
instance_type = "ml.g5.8xlarge"
instance_count = 2
availability_zone_id = "use1-az2"
ebs_volume_size_in_gb = 100
threads_per_core = 1
enable_stress_check = false
enable_connectivity_check = false
lifecycle_script = "on_create.sh"
}
]
# HyperPod Inference Operator を有効化
create_hyperpod_inference_operator_module = true
初めてのモデルデプロイ
Add-on がインストールされると、以下のように JumpStartModel CRD を使ってモデルをデプロイできます。
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
name: deepseek-test-endpoint
spec:
model:
modelId: "deepseek-llm-r1-distill-qwen-1-5b"
sageMakerEndpoint:
name: deepseek-test-endpoint
server:
instanceType: "ml.g5.8xlarge"
# デプロイ実行
kubectl apply -f jumpstart-model.yaml
# デプロイ状態確認
kubectl get jumpstartmodel

応用編:マルチインスタンスタイプデプロイと Node Affinity
マルチインスタンスタイプデプロイ
リソースの可用性を高めるため、優先順位リストを指定できます。システムは最優先のインスタンスタイプから試行し、キャパシティが不足している場合は自動的に次のタイプにフォールバックします。
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
name: lmcache-test-1
namespace: default
spec:
replicas: 13
modelName: Llama-3.1-8B-Instruct
# 優先順位: p4d -> g5.24xlarge -> g5.8xlarge
instanceTypes: ["ml.p4d.24xlarge", "ml.g5.24xlarge", "ml.g5.8xlarge"]
この機能は Kubernetes の Node Affinity の requiredDuringSchedulingIgnoredDuringExecution と preferredDuringSchedulingIgnoredDuringExecution を活用して実装されています。
Node Affinity で細かなスケジューリング制御
Spot インスタンスを除外したい、特定のアベイラビリティゾーンを優先したい、カスタムラベルを持つノードだけにデプロイしたい——そんな場合は nodeAffinity を直接指定します。
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
name: lmcache-test-1
namespace: default
spec:
replicas: 15
modelName: Llama-3.1-8B-Instruct
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: node.kubernetes.io/instanceType
operator: In
values: ["ml.g5.4xlarge"]
worker:
resources:
limits:
nvidia.com/gpu: "1"
requests:
cpu: "6"
memory: 30Gi
nvidia.com/gpu: "1"
日本企業の環境での適用ポイント
日本企業では、プライベート EKS クラスター に HyperPod を構築するケースが多く見られます。この場合、VPC エンドポイントの設定が特に重要です。AWS Console の Quick Install を使えば自動的に VPC エンドポイントが構成されますが、CLI や Terraform でインストールする場合は S3 VPC Endpoint や EKS API Endpoint を事前に作成しておく必要があります。
また、金融機関や官公庁では KMS 暗号化 と CloudTrail ログ が必須条件となることが多いです。Inference Operator はデフォルトで S3 TLS 証明書ストレージに SSE-S3 暗号化を使用しますが、KMS キーを指定したい場合は Custom Install で設定してください。

まとめ:実務への適用と次のステップ
SageMaker HyperPod Inference Operator の EKS Add-on 統合により、インフラの複雑さを大幅に削減し、ML チームがモデルの最適化とサービングに集中できる環境が整いました。
主なメリット
| メリット | 説明 |
|---|---|
| 迅速なタイムトゥーバリュー | クラスター作成後数分で最初の推論エンドポイントをデプロイ可能 |
| 複雑性の低減 | IAM ロール、S3 バケット、VPC エンドポイントなどを一括自動生成 |
| 一貫した設定 | AWS ベストプラクティスに従ったセキュアな構成を自動適用 |
| 簡単なアップグレード | EKS Add-on の仕組みでワンクリックアップグレードとロールバックに対応 |
注意点
- 既存の Helm インストールユーザー:AWS 提供の
helm_to_addon.shマイグレーションスクリプトを使えばダウンタイムなしで移行可能です。ただし、ロールバックに備えて/tmp/hyperpod-migration-backup-/にバックアップが保存されるので確認してください。 - コスト:マルチインスタンスタイプデプロイを使う場合、フォールバック先のインスタンスが高額になる可能性があるため、コストモニタリングの設定を推奨します。
- Tiered KV Cache:インストール時に有効化すると、長文コンテキストの推論で最大40%のレイテンシー削減が期待できますが、メモリ使用量が増加するためワークロードの特性に合わせて選択してください。
次のステップ
- ターミナルコーディングを変える:Gemini 3 Flash が CLI で使えるように – 最新 AI モデルを CLI で手軽に試す方法
- 単一障害点からの脱却:Amazon Key チームが明かすイベント駆動アーキテクチャ(EDA)の実践ノウハウ – EDA と組み合わせたスケーラブルな ML システム設計
- 公式ドキュメント:SageMaker HyperPod Inference Operator インストールガイド および トラブルシューティングガイド
今すぐ SageMaker コンソールで新しい HyperPod クラスターを作成する際に Inference Operator を有効にするか、既存のクラスターにワンクリックで追加してみてください。🚀