TorchServe の開発終了を受け Ray Serve Deep Learning Containers を推奨

TorchServe はもはや積極的にメンテナンスされていません。公式プロジェクトの通知によると、今後のアップデートやバグ修正、新機能追加、セキュリティパッチの提供は予定されておらず、脆弱性への対応も行われない可能性があります。現在 TorchServe でモデル推論を実行しているチームにとっては、セキュリティパッチが停止し、PyTorch や CUDA の最新バージョンとの互換性更新も止まることを意味します。エンジニアたちは、GPU スタック全体で互換性のあるバージョンを選定したり、各層の脆弱性を自ら修正したり、コンポーネントのズレによって生じる微妙な不具合をデバッグしたりする責任を一身に背負うことになります。これは最終製品に価値を追加しない、単なる手間のかかる作業であり、モデルの提供速度を低下させる要因となります。

AWS Deep Learning Containers（DLC）は、トレーニングワークロードにおいて長年こうした課題を解決してきました。DLC は、フレームワークとその依存関係、GPU スタックを束ねた事前構築済みでパフォーマンスに最適化された Docker イメージです。テスト済みかつパッチ適用済みの組み合わせとして提供されるため、すぐにプルして利用できます。Ray Serve DLC のリリースにより、このアプローチが推論ワークロードにも拡張されました。HTTP エンドポイントの背後でモデルを提供するために特化したコンテナが用意され、AWS によってメンテナンスとテストが行われています。必要な推論スタックはすべて既に組み込まれた状態で提供されます。

本記事では、Ray Serve DLC の紹介と、この新しいイメージを用いて Amazon Elastic Kubernetes Service (Amazon EKS) 上でビジョン・ランゲージモデルをデプロイする手順について解説します。Ray Serve DLC を用いたモデルの実行や、Ray Serve でサービングアプリケーションを実行する方法、さらに単一の GPU ノードへのデプロイ方法についても取り上げます。完全なコードは、付随するリポジトリで確認できます。

前提条件

本記事の手順を遂行するには、以下の準備が必要です。

• 課金設定が有効になった AWS アカウント
• 対象リージョンにおける g5.xlarge インスタンスの十分なサービスクォータ
• インストールおよび設定済みの AWS Command Line Interface (AWS CLI)、eksctl、kubectl

Ray Serve アプリケーションの構築

Ray Serve DLC の CPU バージョンは Amazon Linux 2023 ベースイメージを基に構築されています。一方、GPU 対応版は公式の NVIDIA Amazon Linux 2023 イメージをベースとしており、OS レイヤーと CUDA ランタイムライブラリの両方を含んでいます。

この基盤の上に、深層学習フレームワーク (PyTorch)、FastAPI と Uvicorn を備えた Ray Serve サービングレイヤー、そしてビジョン、オーディオ、マルチモーダルなワークロード向けの一般的なユーティリティが追加されています。これらのユーティリティには、ビデオ前処理のために NVIDIA ハードウェアアクセラレーションを有効化した FFmpeg も含まれています。

すべてのコンポーネントはリリース前に統合して検証・テストされているため、CUDA ランタイム、フレームワーク、サービングレイヤー間のバージョンの不一致 (drift) は発生しません。また、セキュリティパッチもビルド時に適用されています。

Ray Serve の Deep Learning Container (DLC) は、Amazon EKS および Amazon EC2 向けと Amazon SageMaker 向けの別々のイメージとして公開されており、それぞれの環境に合わせた専用エントリーポイントが用意されています。これらはすべて同じ基盤スタックと依存関係を共有しています。利用可能なイメージタグの最新リストについては、Ray DLC 利用可能イメージページをご参照ください。

この DLC には共通の推論スタックが含まれているため、Qwen3-VL モデルを含む多くのモデルは、カスタムイメージを作成せずにそのまま実行できます。追加ライブラリが必要な場合は、エンジニアが同じテスト済みベースイメージにそれらをレイヤーとして追加するだけで対応可能です。

本稿では、GPU 版の Ray Serve DLC を使用して Qwen3-VL-2B ビジョン・ランゲージモデルを推論サービスとして提供します。アプリケーションは ConfigMap を通じてコンテナに注入されるため、イメージの再構築なしで推論コードを変更できる柔軟なデプロイが可能になります。DLC にはすでに GPU スタック、PyTorch、Ray Serve、Transformers が含まれています。

serving アプリケーションの作成

Ray Serve では、モデルのエンドポイントとして Python クラスを定義し、@serve.deployment デコレーターで装飾します。HTTP リクエストの処理には __call__ メソッドを実装し、.bind() を呼び出して登録を行います。アーカイバやハンドラークラス階層、プロパティ設定ファイルといった従来の仕組みは不要です。

TorchServe から移行される場合、カスタムハンドラ、torch-model-archiver の実行ステップ、そして config.properties ファイルのすべてが置き換わります。

以下の例では、Qwen3-VL-2B というビジョン・ランゲージモデルを GPU 上に読み込み、HTTP エンドポイントとして公開しています。画像 URL とテキストプロンプトを含むリクエストを受け取ると、モデルは画像の説明や質問への回答といった自然言語で応答を生成します。

from ray import serve
from transformers import AutoModelForImageTextToText, AutoProcessor
import torch

@serve.deployment(ray_actor_options={"num_gpus": 1})
class QwenVLService:
    def __init__(self):
        model_name = "Qwen/Qwen3-VL-2B-Instruct"
        self.processor = AutoProcessor.from_pretrained(model_name)
        self.model = AutoModelForImageTextToText.from_pretrained(
            model_name, torch_dtype=torch.float16
        ).to("cuda")

    async def __call__(self, request):
        try:
            body = await request.json()
            image_url = body.get("image_url")
            prompt = body.get("prompt")
            messages = [{"role": "user", "content": [
                {"type": "image", "image": image_url},
                {"type": "text", "text": prompt},
            ]}]
            inputs = self.processor.apply_chat_template(
                messages, tokenize=True, add_generation_prompt=True,
                return_dict=True, return_tensors="pt"
            ).to("cuda")
            generated_ids = self.model.generate(**inputs, max_new_tokens=200)
            trimmed = [o[len(i):] for i, o in zip(inputs.input_ids, generated_ids)]
            output = self.processor.batch_decode(trimmed, skip_special_tokens=True)[0]
            return {"response": output}
        Except Exception:
            logger.exception("Qwen inference request failed")
            return {"error": "Unable to generate a response. Please try again later."}

app = QwenVLService.bind()

qwen_serve.py のサービングロジック全体は、qwen-serve-code という ConfigMap に追加されます。また、@serve.deployment デコレータには ray_actor_options={"num_gpus": 1} を指定し、

Ray は、利用可能な GPU が 1 つあるワーカー上でこのデプロイメントをスケジューリングします。

モデルは、次節で使用する A10G GPU で利用可能な 24 GB の VRAM に収まるよう、float16 で読み込まれます。

Amazon EKS でのデプロイ

Ray Serve DLC を、先ほど作成した qwen-serve-code ConfigMap とともにデプロイします。以下の図は目標とするアーキテクチャを示しています：1 つの GPU ノードを持つ Amazon E クラスターで、1 つのポッドがポート 8000 で HTTP を通じてモデルを提供する構成です。

Figure 1: Amazon EKS 上のシングルノード推論アーキテクチャ。1 つの GPU ポッドがポート 8000 で HTTP を介してモデルを提供しています

本デプロイでは、1 つの g5.xlarge インスタンス（NVIDIA A10G GPU 1 基、VRAM 24 GB）を使用します。これはシングルノード推論環境であり、1 つのポッドに 1 つの GPU、1 つのマシンが対応しています。マルチノードでの分散サービング（マシン間でのモデル並列化や、複数のレプリカによる水平方向の自動スケーリング）を行う場合は、この基盤の上に KubeRay を構築して、ノード全体に Ray ワーカーをオーケストレーションします。

同梱のリポジトリには、インフラストラクチャのセットアップを自動化するスクリプトが含まれています。

スクリプト deploy_cluster.sh は、eksctl を用いて E クラスターをプロビジョニングします。これには、仮想プライベートクラウド（VPC）によるネットワーク構成、AWS Identity and Access Management (IAM) ベースのポッド認証用の OIDC プロバイダー、およびクラスターの主要コンポーネントが含まれています。

アドオン。

• deploy_node_group.sh スクリプトは、role=gpu-worker というラベルが付与された単一の g5.xlarge インスタンスを持つ管理済み GPU ノードグループを追加します。

deploy_ray_cluster.sh スクリプトは、qwen_serve.py を含む ConfigMap の適用、GPU ノードにポッドをスケジューリングする Kubernetes Deployment マニフェストのデプロイ、そしてポート 8000 で Ray Serve の起動を実行します。

3 つのスクリプトを実行した後、ポッドが実行中で GPU が割り当てられていることを確認してください。

kubectl get pods -n inference
kubectl describe pod -n inference -l app=ray-serve | grep "nvidia.com/gpu"

ポッドの状態が Ready と表示されたら、ポートフォワードしてテストを行います。

kubectl port-forward -n inference deploy/ray-cluster 8000:8000

新しいターミナルで、Qwen3-VL-2B ビジョン言語モデルに対して画像の説明を要求するリクエストを送信します。

curl -X POST http://127.0.0.1:8000/ \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://s3.amazonaws.com/model-server/inputs/kitten.jpg",
    "prompt": "Describe this image briefly."
  }'

モデルが画像を記述した JSON 応答を受け取れるはずです。推論が GPU で実行されていることを確認するには、以下のコマンドを実行します。

kubectl exec -n inference deploy/ray-cluster -- nvidia-smi

注: ポッドは Ray Serve が応答を開始する数分前に「Ready」と表示されますが、これはモデルの読み込みが完了していないためです。最初のリクエストが拒否された場合は、1 分待ってから再度試してください。

クリーンアップ

継続的な課金を防ぐために、以下の手順で逆順にリソースを削除します。

./delete_ray_cluster.sh   # Remove the Ray Serve deployment
./delete_node_group.sh    # Remove the GPU node group
./delete_cluster.sh       # Delete the EKS cluster

まとめと次のステップ

これで推論エンドポイントが稼働し、CUDA の互換性を自分で管理したり、TorchServe ハンドラのボイラープレートを書いたり、GPU スタックを組み立てる多段階の Dockerfile を構築したりすることなく、この状態に到達できました。Ray Serve DLC が目指しているのはまさにこれです。サポートされ事前テスト済みのコンテナを提供することで、インフラストラクチャの維持管理から解放し、モデルコードの開発に集中できるようにします。

現在 TorchServe を使用しているチームにとって、これは強力な移行パスとなります。DLC によりバージョンのズレが解消され、アップグレードはタグの差し替えだけで済むようになり、AWS が定期的に提供するセキュリティパッチも利用できます。単一ノードを超えてスケーリングが必要なワークロードには、KubeRay を使用することで、この基盤をマルチノード分散推論へと拡張できます。

まずは、完全なエンドツーエンドのデプロイメントを確認するために、以下のコードサンプルを試してみてください。

コードサンプル

CPU 対応版やその他のフレームワークを含む、利用可能な Deep Learning Containers (DLC) イメージの一覧は、以下の AWS Deep Learning Containers リファレンスページで確認できます。

AWS Deep Learning Containers リファレンス

執筆者について

Ananth Raghavendra

Ananth は AWS のシニア AI ソリューションアーキテクトです。Amazon SageMaker HyperPod、Amazon EKS、Ray、SageMaker Serverless Inference、Amazon Nova Forge、Slurm などのプラットフォームとオーケストレーターを活用し、NVIDIA GPU や AWS Trainium、AWS Inferentia で動作する分散型生成 AI アプリケーションのアーキテクチャ設計を専門としています。

Jinyan Li

Jinyan は Amazon Web Services のソフトウェア開発エンジニアです。AWS 上で機械学習ワークロードを処理するためのコンテナ環境の構築と改善に注力しています。ノースイースタン大学でコンピュータサイエンスの修士号を取得しています。

Felipe Lopez

フェリペはAWSのシニアAI/MLスペシャリストソリューションアーキテクトです。AWS入社前はGEデジタルやSLBで働き、産業用途向けのモデル化および最適化製品に注力していました。