はじめに:なぜ今、Inference Operator のインストールが劇的に変わったのか

従来、SageMaker HyperPod で推論ワークロードをデプロイするには、Helm チャートの管理、IAM ロールの設定、依存関係の解決、手動アップグレードなど、AI チームは多くの複雑な作業を強いられていました。最初のモデルが推論結果を返すまでに数時間かかることも珍しくありませんでした。

今回、Amazon SageMaker HyperPod Inference OperatorEKS Add-on として提供されるようになり、状況は一変しました。SageMaker コンソールから ワンクリックインストールマネージドアップグレード が可能になり、Helm チャートや複雑な IAM 設定は不要です。

この記事では、3つのインストール方法(コンソール、CLI、Terraform) を実際のコードとともに解説し、マルチインスタンスタイプデプロイNode Affinity といった高度な機能を実務でどう活用するかまでカバーします。

本記事は AWS Architecture Blog を基に、日本の開発者コミュニティ向けに再構成しました。

SageMaker HyperPod cluster dashboard showing Inference Operator installation status Dev Environment Setup

実践編:3つのインストール方法とコード例

方法1:SageMaker UI からのインストール(推奨)

SageMaker コンソールは最もシンプルな方法を提供します。Quick InstallCustom Install の2つのオプションがあります。

インストール手順:

  1. SageMaker Console → HyperPod Clusters → Cluster Management に移動
  2. 対象クラスターを選択 → Inference タブを開く
  3. Quick Install(自動設定)または Custom Install(既存リソースの再利用)を選択
  4. Install ボタンをクリック
  5. インストール確認: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

Kubernetes node affinity scheduling inference pods on GPU instances in HyperPod Coding Session Visual

応用編:マルチインスタンスタイプデプロイと 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 の requiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecution を活用して実装されています。

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 EndpointEKS API Endpoint を事前に作成しておく必要があります。

また、金融機関や官公庁では KMS 暗号化CloudTrail ログ が必須条件となることが多いです。Inference Operator はデフォルトで S3 TLS 証明書ストレージに SSE-S3 暗号化を使用しますが、KMS キーを指定したい場合は Custom Install で設定してください。

Developer deploying a Llama model on SageMaker HyperPod using kubectl Algorithm Concept Visual

まとめ:実務への適用と次のステップ

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%のレイテンシー削減が期待できますが、メモリ使用量が増加するためワークロードの特性に合わせて選択してください。

次のステップ

  1. ターミナルコーディングを変える:Gemini 3 Flash が CLI で使えるように – 最新 AI モデルを CLI で手軽に試す方法
  2. 単一障害点からの脱却:Amazon Key チームが明かすイベント駆動アーキテクチャ(EDA)の実践ノウハウ – EDA と組み合わせたスケーラブルな ML システム設計
  3. 公式ドキュメントSageMaker HyperPod Inference Operator インストールガイド および トラブルシューティングガイド

今すぐ SageMaker コンソールで新しい HyperPod クラスターを作成する際に Inference Operator を有効にするか、既存のクラスターにワンクリックで追加してみてください。🚀

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。