**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS で AI/ML 推論ワークロードを実行する
**ヒント**
今後開催予定の Amazon EKS AI/ML ワークショップに[登録](https://events.eksworkshop.com/workshops/genai/)してください。
推論は、トレーニングされた AI モデルを実行して、入力データから予測または出力を生成するプロセスです。これには、テキストまたはコードを生成する大規模言語モデル (LLM)、画像を生成する拡散モデル、音声合成および文字起こし用の音声モデル、リアルタイム分析または生成用のビデオモデルの提供が含まれます。Amazon EKS は、NVIDIA GPU または AWS Trainium アクセラレーターを使用した推論ワークロードのデプロイ、動的スケーリング、より広範な Kubernetes や AWS のツールとサービスのランドスケープとの統合を提供する、スケーラブルでポータブルなソリューションです。
## 推論に Amazon EKS を使用する理由
Amazon EKS は、Kubernetes オーケストレーションと AWS インフラストラクチャを組み合わせて、大規模な推論の実行における主要な課題に対処します。
+ **動的 GPU スケーリング** — Karpenter は、ポッドリソースリクエストに基づいて適切なサイズの GPU インスタンスをオンデマンドでプロビジョニングし、アイドル時にゼロからスケーリングし、トラフィックの増加に応じてキャパシティを追加します。これにより、高価な GPU リソースの過剰プロビジョニングを回避できます。
+ **高速コールドスタート** — SOCI (Seekable OCI) 並列プルは、大きなコンテナイメージレイヤーを同時にダウンロードして解凍し、イメージのプル時間を数分から数秒に短縮します。Amazon S3 から GPU メモリへの直接モデルストリーミングと組み合わせると、ポッドは 2 分未満でサービスの提供を開始できます。
+ **GPU 障害の自動復旧** — EKS ノードモニタリングエージェントは GPU ハードウェア障害を検出し、ノードの自動交換をトリガーして、手動による介入なしでダウンタイムを最小限に抑えます。
+ **コストの最適化** — オンデマンドフォールバック、適切なサイズのインスタンス選択、ゼロへのスケーリング動作を備えたスポットインスタンスは、GPU コストを削減します。リザーブドキャパシティ (ODCR) は、定常状態のワークロードのコストをさらに削減できます。
+ **オープンスタンダードと移植性** — 推論ワークロードは、vLLM や SGLang などのオープンソースモデルサーバーを備えた標準の Kubernetes API (デプロイ、サービス、HPA) で実行され、環境間で移植性を提供します。
+ **統合モニタリング** — vLLM または SGLang と NVIDIA DCGM Exporter からの Prometheus メトリクスは、Grafana ダッシュボードを通じてリクエストのレイテンシー、トークンスループット、GPU 使用率、メモリ使用量を可視化します。
## 用語集
このセクションでは、以下の用語を使用します。
+ **推論** — トレーニング済みモデルを実行して、入力データから出力 (テキスト、埋め込み、分類) を生成するプロセス。
+ **モデルサーバー** — モデルをメモリにロードし、推論リクエストを受け取り、予測を返すコンテナ化されたサービス。例としては、[vLLM](https://docs.vllm.ai/en/latest/)、[SGLang](https://github.com/sgl-project/sglang)、[Triton Inference Server](https://github.com/triton-inference-server/server)、[Text Generation Inference (TGI)](https://github.com/huggingface/text-generation-inference) などがあります。
+ **モデルの重み** — モデルサーバーが GPU メモリにロードするファイル (通常は SafeTensors または GGUF 形式) として保存される、トレーニング済みモデルの学習済みパラメータ。
+ **アクセラレーター** — 推論に必要なマトリックス操作を高速化する NVIDIA GPU や AWS Trainium/Inferentia チップなどの特殊なハードウェア。
+ **テンソル並列処理** — 同じノード上の複数の GPU にモデルを分割して、1 つの GPU のメモリを超えるモデルを提供します。
+ **KV キャッシュ** — テキスト生成中に以前に計算されたキーと値のペアを保存し、新しいトークンごとに冗長計算を行うことを回避するメモリバッファ。
## Amazon EKS での推論の仕組み
大まかに言うと、Amazon EKS に推論ワークロードをデプロイするには、以下のステップが必要です。
| Step | 説明 |
| --- | --- |
| **クラスターを設定する** | GPU 対応ノード、モニタリング、ストレージを備えた EKS クラスターを作成します。EKS の AI/ML に関するドキュメントの「[クラスターを設定する](ml-cluster-setup.md)」を参照してください。 |
| **モデルの重みを保存する** | モデルレジストリ (Hugging Face など) からモデルの重みをダウンロードし、コールドスタートまたはスケールアップイベント中にモデルを迅速にロードできるように Amazon S3 に保存します。 |
| **モデルサーバーをデプロイする** | GPU ノードでモデルサーバー (vLLM など) を実行する Kubernetes デプロイを作成します。モデルサーバーは S3 から GPU メモリに重みをストリーミングし、OpenAI 互換 API を公開します。 |
| **推論エンドポイントを公開する** | 安定したネットワークエンドポイントを提供する Kubernetes サービスを作成します。テストにはポートフォワーディングを使用し、本番トラフィックには AWS Application Load Balancer (ALB) などのロードバランサーを使用します。 |
| **モニタリングとスケール** | Prometheus メトリクス (リクエストレート、トークンスループット、レイテンシー、KV キャッシュ使用率) を使用してパフォーマンスをモニタリングし、自動スケーリングを設定します。 |
## 推論パフォーマンスメトリクス
推論パフォーマンスを理解するには、レイテンシーとスループット全体でメトリクスを追跡する必要があります。
**レイテンシーメトリクス**
+ **Time to First Token (TTFT)** — リクエストの到着から最初に生成されたトークンまでの時間。インタラクティブアプリケーションには不可欠です。
+ **Time Per Output Token (TPOT)** — 最初のトークンから後続の各トークンを生成する平均時間。
+ **End-to-end request latency** — リクエストの送信からフルレスポンスの完了までの合計時間。
**スループットメトリクス**
+ **Requests per second** — すべてのレプリカで 1 秒あたりに処理された推論リクエストの合計。
+ **Output tokens per second** — 合計出力トークンを経過時間で割ったものとして測定されるトークン生成のレート。
+ **GPU utilization** — 推論にアクティブに使用される GPU コンピューティングサイクルの割合。
+ **KV cache utilization** — 割り当てられた KV キャッシュメモリが使用されている割合。サーバーがキャパシティ上限にどれだけ近いかを示します。
## コールドスタート時間の短縮
大きな推論コンテナ (8～15 GB) とモデルの重み (10～100 GB 以上) では、ポッドの起動が遅くなる可能性があります。以下の手法は、コールドスタートの遅延を最小限に抑えます。
+ **SOCI 並列プル** — コンテナイメージレイヤーをシーケンシャルではなく同時にダウンロードして解凍します。GPU インスタンスの EKS Auto Mode でデフォルトで有効になっています。
+ **S3 からのモデルストリーミング** — [Run:ai Model Streamer](https://github.com/run-ai/runai-model-streamer) などのツールは、モデルの重みを Amazon S3 から GPU メモリに直接ストリーミングし、ローカルディスクをバイパスしてロード時間を数分から数秒に短縮します。
+ **Amazon ECR にイメージを保存する** — リージョン ECR リポジトリから VPC エンドポイント経由でプルすることで、大規模なコンテナイメージのインターネットレイテンシーを回避できます。
+ **インスタンスストアキャッシュ** — ローカル NVMe ディスクを持つ G ファミリーインスタンスはコンテナレイヤーとモデルアーティファクトをキャッシュできるため、同じノードで後続のプルを高速化できます。
## デプロイするもの
「[モデルのロードと提供](ml-inference-load-serve-model.md)」のチュートリアルでは、エンドツーエンドの推論アプリケーションをデプロイする方法について説明します。
1. **モデル重みのダウンロード** — Kubernetes ジョブは、Hugging Face から Ministral-3-8B-Instruct モデルをダウンロードし、S3 バケットにアップロードします。
1. **vLLM のデプロイ** — デプロイは Run:ai Model Streamer を使用して vLLM を実行し、S3 から GPU メモリに直接重みをストリーミングして、OpenAI 互換 API を提供します。
1. **Grafana でモニタリング** — ServiceMonitor は vLLM Prometheus メトリクスをモニタリングスタックに接続し、リアルタイムダッシュボードを提供します。
1. **チャットフロントエンドのデプロイ** — Open WebUI は、vLLM エンドポイントに接続されたブラウザベースのチャットインターフェイスを提供します。
このチュートリアルでは、[AI/ML ワークロード用の Amazon EKS クラスターを設定する](ml-cluster-setup.md) セクションのクラスターインフラストラクチャを使用し、EKS Auto Mode とセルフマネージド Karpenter パスの両方に対応しています。