SageMaker HyperPod Inference Operator 完全ガイド：1クリックインストールからTerraformまで

はじめに：なぜInference Operatorのインストールが難しいのか？

Amazon SageMaker HyperPodは、大規模AIモデルの学習と推論のためのエンドツーエンドプラットフォームです。しかし従来は、Helmチャート、IAMロールの構成、依存関係管理などの複雑な手作業が必要で、最初のモデルをサーブするまでに数時間かかることも珍しくありませんでした。

今回、SageMaker HyperPod Inference OperatorがEKSアドオンとして提供されるようになり、状況は一変しました。SageMakerコンソールからワンクリックでインストールでき、アップグレードも自動管理されます。この記事では、実際の運用環境ですぐに使える3つのインストール方法と主要機能をハンズオン形式で解説します。

根拠資料: AWS Architecture Blog 原文

インストール方法1: SageMaker UI（推奨）— ワンクリックインストール

最もシンプルな方法です。新規クラスター作成時にQuick Setupを選択すればInference Operatorが自動インストールされ、既存クラスターでもInferenceタブのQuick Installボタン一つで完了します。

Quick Install vs Custom Install

インストール手順

1. SageMakerコンソール → HyperPod Clusters → Cluster Management に移動
2. 対象クラスターを選択 → Inferenceタブ → Quick Install または Custom Install を選択
3. インストール完了後、以下のコマンドで確認

# ポッドの状態確認
kubectl get pods -n hyperpod-inference-system

# EKSアドオンの状態確認
aws eks describe-addon --cluster-name CLUSTER-NAME --addon-name amazon-sagemaker-hyperpod-inference --region REGION

インストール方法2: EKS CLI — IaCパイプライン連携

コードベースのインフラを好むチーム向けです。ただし、IAMロール、S3バケット、VPCエンドポイントなどすべての前提条件を手動で作成する必要があります。

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 — 完全自動化

awesome-distributed-training GitHubリポジトリのTerraformモジュールを使用すると、HyperPodクラスターとInference Operatorを一度にプロビジョニングできます。

# 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"
  }
]

# Inference Operator 有効化
create_hyperpod_inference_operator_module = true

補足: TerraformモジュールはInference Operator以外に、task governance、training operator、observability アドオンも同時にサポートしています。

主要機能3選：実務で即活用

1. マルチインスタンスタイプデプロイ

優先順位付きのインスタンスタイプリストを指定すると、希望のタイプにキャパシティが不足している場合、自動的に次のタイプにフォールバックします。Kubernetesの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
  instanceTypes: ["ml.p4d.24xlarge","ml.g5.24xlarge","ml.g5.8xlarge"]

2. Node Affinityによる細かなスケジューリング制御

スポットインスタンスの除外、特定アベイラビリティゾーンの優先、カスタムラベルベースのターゲティングが必要な場合、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"

3. 既存Helmユーザー向けマイグレーションスクリプト

AWSが公開した helm_to_addon.sh スクリプトを使えば、既存のHelmデプロイをEKSアドオンに自動移行できます。失敗時はロールバックもサポートしています。

# 対話型マイグレーション
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1

# 自動承認モード
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1 --auto-approve

# 依存関係のマイグレーションをスキップ
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1 --skip-dependencies-migration

⚠️ 注意点: マイグレーションスクリプトは /tmp/hyperpod-migration-backup-* にバックアップファイルを生成します。ロールバックが必要な場合はこのディレクトリを確認してください。

実務適用のヒントと制限事項

日本市場における適用コンテキスト

日本では AWS以外のクラウド（GCP、Azure、オンプレミス） を併用する企業も少なくありません。SageMaker HyperPodはAWS EKS専用であるため、マルチクラウド戦略を検討中の場合は、Kubernetesネイティブな推論ソリューション（Kserve、Seldonなど）と比較評価することをおすすめします。

また、国内の金融機関やSIerではセキュリティポリシーが厳格なため、Quick Installが自動生成するリソース（IAMロール、S3バケットなど）が社内ルールに準拠しているか事前に確認しましょう。

本技術の制限

• EKSクラスター必須: HyperPodはEKSオーケストレーションを前提としているため、EKSがない環境では利用できません。
• 前提条件リソース: EKS CLIやTerraform方式では、IAMロール、S3バケット、VPCエンドポイントなどを手動で作成する必要があります。漏れがあるとアドオンのインストールが失敗します。
• サポートリージョン: 一部のリージョンでのみ正式サポートされています。AWS公式ドキュメントでサポートリージョンを必ず確認してください。

次のステップ

1. 実戦デプロイ: 上記のコード例を使って、実際にLlamaやDeepSeekモデルをデプロイしてみましょう。
2. 可観測性: HyperPod ObservabilityとAmazon Managed Grafanaを連携させ、レイテンシーやGPU使用率などをモニタリングする方法を学びましょう。
3. コスト最適化: マルチインスタンスタイプデプロイとスポットインスタンス活用戦略を組み合わせて、推論コストを削減する方法を研究してみてください。

合わせて読みたい記事

• NVIDIA Blackwell Ultra、AI推論の隠れたボトルネックSoftmaxを解決
• 癌診断を革新するAI、ArteraのAWSベース拡張可能アーキテクチャ設計