TorchServeのサポート終了後を引き継ぐAWS Ray Serve Deep Learning Containers
TorchServeが無期限のメンテナンス停止に入る中、AWSはAWS Ray Serve Deep Learning Containersを使用した単一GPU向けの移行パスを公開した。この変更が重要なのは、TorchServeユーザーが本番のPyTorchモデルを支える、積極的に保守されたサービングフレームワークを失うためだ。AWSは代わりに検証済みのコンテナスタックを提供するが、チームはサービングアプリケーションを書き換え、周辺インフラを運用し続けなければならない。
新たな移行ガイドでは、Qwen3-VL-2Bの視覚言語モデルをAmazon Elastic Kubernetes Service、すなわちAmazon EKSにデプロイする。これは、1基のNVIDIA A10G GPUと24 GBのGPUメモリを備えた1台のg5.xlargeインスタンス上の、1つのポッド内で実行される。この例では、ポート8000のHTTPエンドポイントを通じてモデルを公開する。
この控えめなデプロイは、より大きな対立を浮き彫りにする。TorchServeはかつて、モデルのアーカイブ化、ハンドラー、設定、サービングを、PyTorch中心のワークフローにまとめていた。AWS Ray Serve Deep Learning Containersは、そのフレームワークを、保守されたイメージ、Ray Serveアプリケーションコード、標準的なKubernetesリソースに置き換える。運用上の責任は消えるのではなく、その形を変える。
AWS、TorchServeのサポート空白をコンテナ移行パスに転換
AWSはTorchServeのメンテナンス停止に対し、ドロップイン置き換えではなく、検証済みの推論スタックで対応している。
公式のTorchServeドキュメントには現在、限定メンテナンスの通知が表示されている。そこでは、このプロジェクトはもはや積極的に保守されていないとされる。既存リリースは引き続き利用できるが、更新、バグ修正、機能追加、セキュリティパッチは予定されていない。
この警告は、本番ユーザーのリスク評価を変える。安定したアプリケーションであれば、既存のTorchServeリリース上で稼働を継続できる。しかし、新たなフレームワーク、オペレーティングシステム、CUDA、またはセキュリティ要件が生じるたびに、アプリケーション所有者は新たな互換性判断を迫られる。
セキュリティは、先送りが最も難しい要素だ。TorchServeの通知は、脆弱性が対処されない可能性があると明示的に警告している。組織はデプロイを隔離し、周辺レイヤーにパッチを適用できるが、サービングフレームワークに対する将来のアップストリーム修正には依存できない。
AWSは、こうしたワークロード向けに、一般にDLCと呼ばれるRay Serve Deep Learning Containerをサポート対象の基盤として位置付けている。DLCは、選定されたフレームワークと関連依存関係をまとめてインストールし、検証したコンテナイメージだ。AWSはAmazon EC2およびEKS向け、さらにAmazon SageMaker向けに、個別のRay Serveイメージを公開している。
GPUイメージは、NVIDIA Amazon Linux 2023ベースから始まる。この基盤には、オペレーティングシステムとCUDAランタイムライブラリが含まれる。AWSはその上に、PyTorch、Ray Serve、FastAPI、Uvicorn、Hugging Face Transformers、そしてビジョン、音声、マルチモーダル処理向けのユーティリティを追加している。
このイメージには、動画前処理用のNVIDIAハードウェアアクセラレーションを備えたFFmpegビルドも含まれる。この詳細は、動画フレーム、画像、音声、テキストを組み合わせるモデルを提供するチームにとって重要だ。こうしたワークロードでは、モデルフレームワークとHTTPサーバーだけでは不十分なことが多い。
AWSは、各イメージリリース前に含まれるコンポーネントをまとめて検証するとしている。セキュリティパッチはイメージのビルド時に適用される。このアプローチにより、CUDAランタイム、PyTorch、Ray Serve、Webサービング層の間で生じるバージョンドリフトを抑えられる。
ただし、この約束には明確な境界がある。AWSはコンテナの組み合わせをサポートし検証する一方で、ユーザーはモデルコード、クラスター構成、ネットワーク制御、スケーリングポリシー、アップグレードプロセスについて引き続き責任を負う。保守されたイメージは、チームが自ら組み立てる必要のある領域を狭める。
この例は、Ray Serveを透過的なTorchServe互換モードとして提示することも避けている。エンジニアは新しいPythonサービングクラスを作成し、Ray Serveを通じてデプロイする。TorchServeアーカイブをインポートしたり、その管理インターフェース全体を再利用したりはしない。
この違いにより、発表の位置付けは現実的なものになる。AWS Ray Serve Deep Learning Containersは、影響を受けるワークロードにサポートされた移行先を提供する。本番移行を自動化するものではなく、デプロイテストの必要性をなくすものでもない。
TorchServeチームがGPUスタックのより多くを担う理由
TorchServeの積極的な保守終了により、アップストリームの不確実性はプラットフォームおよび機械学習エンジニアリングチームへ直接移る。
GPU推論サービスは、独立して進化する複数のレイヤーに依存する。これにはオペレーティングシステム、NVIDIAランタイム、CUDAライブラリ、PyTorch、モデル依存関係、リクエストサーバー、オーケストレーション環境が含まれる。モデルコードが変わらなくても、互換性の問題は発生し得る。
TorchServeは以前、PyTorchチームに認識しやすいパッケージングとサービングの道筋を提供していた。開発者はtorch-model-archiverでモデルアーカイブを作成し、カスタムハンドラーを提供し、config.propertiesを通じて挙動を制御できた。このワークフローには独自の複雑さがあったが、共有された運用上の慣行も提供していた。
メンテナンス停止により、この慣行が隣接ソフトウェアの進化に追随し続けるという確信は失われる。チームはすべての依存関係を固定できるが、固定は次の判断を先送りするだけだ。オペレーティングシステムのパッチ、GPUの変更、フレームワークのアップグレードはいずれ、スタック全体にわたる検証を強いる。
TorchServeを継続利用することは可能だ。プロジェクトが消滅したわけではなく、既存リリースも多くのデプロイで引き続き機能する。問題は、そのまま利用を続けることが、サポートされた標準ではなく、意図的な社内所有の選択になる点だ。
この道を選ぶ組織には、明確なセキュリティプロセスが必要となる。関連する依存関係を監視し、公開インターフェースを評価し、イメージを再ビルドし、新しいTorchServeリリースを期待せずに修正をテストしなければならない。TorchServe自体に存在する脆弱性への計画も必要だ。
代替案である移行は、直ちにエンジニアリング作業を生む。TorchServeのハンドラーとモデルアーカイブが、自動的にRay Serveデプロイへ変わるわけではない。リクエスト解析、ヘルスチェックの挙動、メトリクス、モデルロード、バッチ処理、エラー処理はすべて比較が必要になる。
Ray Serveは主要なプログラミングモデルを変える。開発者はPythonクラスに@serve.deploymentを付与し、そのクラス内でモデルを初期化し、__call__を通じて受信HTTPリクエストを処理する。.bind()を呼び出すと、Ray Serve用にアプリケーションが登録される。
このモデルは、TorchServeのアーカイブおよびハンドラー構造よりシンプルに感じられるかもしれない。また、通常のPythonコンポジションとRayのリソース宣言への直接アクセスを開発者に提供する。たとえばAWSのデプロイは、ray_actor_options={"num_gpus": 1}を通じて1基のGPUを要求する。
ただし、アプリケーションコードがシンプルになっても、本番運用がシンプルになるとは限らない。チームには引き続き、レディネスチェック、認証、トラフィック管理、テレメトリー、デプロイ制御、ロールバック手順が必要だ。モデルウェイトをどのように環境へ持ち込むか、更新中にレプリカをどう振る舞わせるかも決めなければならない。
AWSコンテナは、いくつかの互換性に関する選択をアップストリームへ移す。AWSがベースオペレーティングシステム、CUDAランタイム、フレームワーク、サービング依存関係を選定し、検証する。これにより、社内で組み立てたイメージに必要な反復的な統合作業を減らせる可能性がある。
一方で、AWSのイメージリリースへの新たな依存も生まれる。プラットフォームチームはイメージタグを追跡し、変更をレビューし、追加レイヤーをスキャンし、自らの環境で新バージョンを認定しなければならない。検証済みベースは有用な根拠となるが、アプリケーションレベルの認証ではない。
コンプライアンス要件のあるチームには、さらに多くの検証が必要だ。イメージの内容が社内ポリシーを満たすこと、更新が必要な期間内に提供されることを確認しなければならない。完全なイメージに対するソフトウェア部品表と脆弱性管理記録も必要となる。
したがって、この負担は成熟したTorchServe資産を持つチームに最も重くのしかかる。彼らは1つのフレームワークを中心に、ハンドラー、パッケージング手順、ダッシュボード、運用ノウハウを蓄積してきた。Ray Serveへの移行は、旧システムがなお安定して見える間に、その知見を移し替えることを意味する。
小規模なデプロイでは、異なる判断が必要になる。サービスにモデルが1つしかなく、トラフィックも予測可能であれば、完全なRayおよびKubernetesスタックは不要な仕組みを導入する可能性がある。その価値は、組織がすでにEKSを運用しているか、より広範なスケーリング需要を見込んでいるかに左右される。
AWS Ray Serve Deep Learning Containersがサービングモデルをどう変えるか
中心的な仕組みは事前統合にある。AWSがベーススタックを固定する一方、Ray ServeがTorchServeのパッケージングとリクエストライフサイクルを置き換える。
AWSの例では、画像とテキストを処理する視覚言語モデルQwen/Qwen3-VL-2B-Instructを提供する。画像URLとプロンプトを受け取り、生成された説明または回答を返す。このモデルは、GPU推論とマルチモーダル前処理の両方を実行するため、この例に適している。
AWSはHugging Face Transformersを通じてモデルをロードする。AutoProcessorがマルチモーダル入力を準備し、AutoModelForImageTextToTextが半精度ウェイトでモデルをロードする。その後、アプリケーションはこれらのウェイトをCUDAデバイスへ移す。
サービングクラスはHTTPリクエストを直接受け取る。JSONから画像URLとプロンプトを抽出し、モデル入力を準備し、生成を実行して結果を返す。FastAPIとUvicornは、DLCに含まれるWebサービングの基盤を提供する。
この設計により、馴染み深いTorchServeの成果物が3つなくなる。TorchServeモデルアーカイブ、TorchServeハンドラー階層、config.propertiesファイルは存在しない。サービング契約はRay Serveアプリケーションとそのデプロイ設定に置かれる。
AWSはこのPythonアプリケーションをKubernetes ConfigMap経由で注入する。ConfigMapは、ポッドが実行時にマウントできる非機密の設定またはファイルを保存する。これによりエンジニアは、コンテナイメージを再ビルドせずにデモコードを変更できる。
この柔軟性は評価段階で有用だ。サービングロジックを検証済みのベースイメージから分離し、編集、デプロイ、テストのループを短縮する。ただし本番チームは、可変設定が自らのリリースおよび監査要件に適しているかを判断すべきだ。
一部の組織は、代わりに派生イメージへアプリケーションを組み込むだろう。この方法では、AWSベースと承認済みサービングコードの両方を含む不変の成果物が作られる。再現性を高められる一方、アプリケーション変更のたびに新しいビルドが必要となる。
デプロイはKubernetesのnvidia.com/gpuリソースで1基のGPUを予約する。また、role=gpu-workerラベルを使用してGPUノードを選択する。これらの設定は、Kubernetesが推論ポッドを意図したインスタンスに配置する助けとなる。
Rayはコンテナ環境とアプリケーション宣言を通じてGPU割り当てを受け取る。モデルクラスは、ポッドに公開された単一GPUに対応して1基のGPUを要求する。より大規模な構成では、Rayは宣言されたリソースプール全体にデプロイをスケジュールできる。
AWSは、この例に関連する3つのスクリプトを提供している。1つ目は、eksctl、ネットワーク設定、OpenID Connectプロバイダー、コアアドオンを用いてEKSクラスターを作成する。2つ目は、マネージドGPUノードグループを追加する。
3つ目のスクリプトは、ConfigMapとKubernetesデプロイを適用する。Ray ServeポッドをGPUノードにスケジュールし、ポート8000でサービスを開始する。付属のサンプルリポジトリでは、これらのデプロイ成果物を確認できる。
デプロイ後、ユーザーはポッドを確認し、GPU の割り当てを検証できます。次に、ローカルポート 8000 を実行中のデプロイメントへフォワードし、画像 URL とプロンプトを含む HTTP リクエストを送信できます。ポッド内で nvidia-smi を実行すれば、GPU が使用されていることを確認できます。
起動シーケンスには、本番設計で対処すべき運用上の詳細があります。AWS は、Ray Serve がリクエストに応答する前に Kubernetes がポッドを準備完了と報告する場合があると指摘しています。ポッドがその状態に達した後も、モデルのロードが続いている可能性があります。
デモでは最初のリクエストが拒否されても許容されますが、本番トラフィックの背後では危険です。チームは、コンテナの状態だけでなく、アプリケーションの可用性に readiness を結び付けるべきです。モデルとエンドポイントが実際のリクエストを処理できるようになるまで、プローブは成功しない状態を維持する必要があります。
モデルのダウンロードも別の変数を加えます。このデモではアプリケーション初期化時にモデルを取得しており、外部サービスの可用性とネットワークスループットに依存します。本番チームは、起動時の挙動を制御するためにローカルストレージ、オブジェクトストレージ、またはイメージレイヤーを使用する場合があります。
シークレットにも別途対応が必要です。ConfigMap にアクセストークンや非公開認証情報を格納すべきではありません。必要な認証は Kubernetes Secrets、EKS Pod Identity、または承認済みの別のシークレットシステムによって提供されるべきです。
これらの判断は、DLC が実際に何を簡素化するのかを示しています。DLC はソフトウェア基盤を標準化し、テスト済みの実行環境を提供します。一方で、組織がモデル、シークレット、リリース成果物、サービス公開をどう扱うかまでは決定しません。
シングル GPU デモは出発点であり、本番環境への最終判断ではない
1 GPU 上の 1 ポッドはデプロイ経路を証明しますが、本番の信頼性、効率性、スケールを確立するものではありません。
AWS は意図的にリファレンスアーキテクチャを小規模に保っています。EKS クラスターには、g5.xlarge インスタンスに基づく管理対象 GPU ノードが 1 台あります。1 つのポッドがノードの NVIDIA A10G GPU を使用し、1 つの Ray Serve プロセスがモデルエンドポイントを公開します。
この構成は移行テストに有用です。チームは、分散クラスターを先に設計しなくても、ハンドラーを移植し、応答挙動を確認し、出力を比較し、GPU へのアクセスを検証できます。また、障害を切り分けやすくなります。
同じ単純さが、読者が導くべき結論も制限します。この例では、冗長レプリカ、マルチノードのモデル並列処理、トラフィック駆動のオートスケーリング、可用性ゾーンをまたぐ障害復旧は示されていません。比較対象となるレイテンシーやスループットの結果も公開されていません。
こうした測定がなければ、この投稿は Ray Serve が特定の TorchServe デプロイメントを上回ることを立証できません。性能はモデル、入力形状、同時実行数、バッチ処理、GPU、前処理経路、生成設定に依存します。移行チームには、自らの代表的なテストが必要です。
このアーキテクチャには、サービス障害の単一障害点もあります。ポッドが再起動するか GPU ノードが利用不能になると、Kubernetes が復旧するまでエンドポイントは応答しなくなります。本番サービスには通常、追加のレプリカまたは明確な復旧目標が必要です。
設計をスケールさせる際には、Ray クラスターの管理に推奨される Kubernetes オペレーターである KubeRay が導入されます。Ray の Kubernetes デプロイメントガイダンスでは、Ray クラスター設定と Serve アプリケーションを組み合わせる RayService カスタムリソースが説明されています。
KubeRay は、ヘッドポッドとワーカーポッド、アプリケーション更新、クラスターライフサイクルを管理できます。異種コンピュートリソースとオートスケーリングにも対応しています。こうした機能により、Ray Serve はマルチモデルパイプラインや、ノードをまたいで拡張する必要があるサービスにとってより適した選択肢になります。
一方で、運用上の概念も増えます。チームは Ray ヘッド、ワーカー、Serve コントローラー、リソース宣言、Kubernetes カスタムリソース、複数層のログを理解する必要があります。トラブルシューティングは Kubernetes と Ray の両コントロールプレーンにまたがる場合があります。
このトレードオフは、代替案を比較する際に重要です。単一の Transformer モデルを提供するチームは、スタンドアロンの vLLM エンドポイントを評価するかもしれません。複数のモデル形式を扱う組織は、NVIDIA Triton Inference Server を検討する可能性があります。Kubernetes を中心とするチームは、標準化された推論リソースとして KServe を評価するかもしれません。
これらの選択肢は重なる課題を解決しますが、優先事項は異なります。Ray Serve は Python アプリケーションの合成、分散実行、レプリカ、ルーティング、スケーリングを重視します。TorchServe は、PyTorch モデルのパッケージ化と提供を中心に据えていました。
AWS 自身も他のサービング経路を文書化しています。現在の EKS 推論ガイダンスでは、LLM デプロイメントに vLLM Deep Learning Container を使用しています。これは、Ray Serve DLC が普遍的な置き換えではなく、サポートされるパターンの 1 つであることを示しています。
適切な選択はワークロードに依存します。カスタム前処理を備えた視覚言語サービスは、Ray Serve の Python ネイティブな構成から恩恵を受けられます。標準化されたテキスト生成エンドポイントでは、大規模言語モデル向けに特化して最適化されたエンジンが適する可能性があります。
移行評価はインターフェースの互換性から始めるべきです。チームはリクエストスキーマ、エラー応答、ヘルスエンドポイント、認証、クライアントタイムアウトを比較する必要があります。その後、制御されたテストセットに対してモデル出力を検証すべきです。
続いて負荷テストが必要です。エンジニアはコールドスタート時間、初回応答までの時間、定常状態のレイテンシー、スループット、GPU メモリ、バースト時の挙動を測定すべきです。テストには、本番と同じ前処理および生成構成を含める必要があります。
障害テストも同様に重要です。チームはポッドを終了し、ノードをドレインし、モデルへのアクセスを中断し、無効なアプリケーションリビジョンをデプロイすべきです。これらのテストにより、置き換え先が復旧およびロールバックの期待を満たすかどうかが明らかになります。
可観測性には直接的な対応付けが必要です。既存の TorchServe メトリクスとダッシュボードは、そのままでは移行できません。運用担当者は、Ray、アプリケーション、Kubernetes、GPU のどのメトリクスが、健全性、飽和状態、ユーザーに見える劣化を定義するのかを決める必要があります。
最後に、チームにはアップグレード実験が必要です。ステージング環境で 2 つの DLC バージョン間を移行し、必要となるコード、構成、モデルの変更を記録すべきです。日常的なアップグレードのデプロイが依然として危険すぎるなら、サポートの価値は限定的です。
TorchServe ユーザーが次に注視すべきこと
次の検証点は、AWS が明確な移行例を、信頼できるリリースおよびスケーリング経路へと発展させられるかどうかです。
最初のシグナルは、Ray Serve DLC のリリース頻度です。チームは、文書化されたイメージタグ、フレームワークバージョン、CUDA の組み合わせ、セキュリティ更新、廃止ポリシーを注視すべきです。予測可能なリリースは、このイメージが長期的な保守作業を削減するという AWS の主張を強化するでしょう。
リリースノートは、リリース頻度と同じくらい重要です。運用担当者は、どの依存関係が変更されたか、更新に破壊的な挙動が含まれるかを把握する必要があります。また、新しいイメージを採用する前にテストできるよう、サポート対象タグ間に十分な重複期間も必要です。
2 番目のシグナルは、readiness、モデルロード、障害復旧に関する本番向けガイダンスです。現在の例は、Ray Serve が応答する前にポッドが準備完了に見える可能性を認めています。より強力なリファレンスでは、Kubernetes の readiness をロード済みモデルと応答可能なエンドポイントに合わせるべきです。
このガイダンスでは、モデルストレージと起動時の挙動も扱うべきです。初期化中に重みをダウンロードする方式は小規模なデモでは機能します。より大規模なデプロイメントには、再現可能なロード、制御された認証情報、適切なストレージ、実際のモデルウォームアップに合わせた起動プローブが必要です。
3 番目のシグナルは、1 GPU から複数レプリカまたは複数ノードへ移行するためのサポートされた経路です。AWS は、分散サービングと水平スケーリングのために読者を KubeRay へ案内しています。今後の例では、DLC が RayService デプロイメント内でどのように動作するかを示すべきです。
マルチレプリカのリファレンスでは、トラフィックルーティング、ローリング更新、オートスケーリングシグナル、GPU ワーカーが消失した場合の復旧を文書化すべきです。また、Ray ヘッドのワークロードを GPU 推論ワーカーから分離し、高価なアクセラレーター容量をモデル用に確保する必要があります。
チームは、すべてのリファレンスが揃うまで評価の開始を待つべきではありません。今から TorchServe サービスを棚卸しし、公開範囲、事業上の重要性、移行の難易度で順位付けできます。インターネットに公開されたエンドポイントは、隔離されたバッチシステムより早期に注意を向けるべきです。
サービスごとに、エンジニアは現在利用している TorchServe の機能を一覧化できます。これにはモデルアーカイブ、カスタムハンドラー、ワークフロー、バッチ処理、メトリクス、管理 API、構成ファイルが含まれます。この棚卸しは具体的な Ray Serve 移行チェックリストになります。
小規模な概念実証では、既存のリクエストおよびレスポンス契約を維持すべきです。クライアントを変更しないことで、サービングレイヤーの移行をより広範なアプリケーション書き換えから切り離せます。また、旧エンドポイントと新エンドポイントの間で制御されたトラフィック比較が可能になります。
評価では、同じモデル重みと代表的な入力を使用すべきです。チームは出力の一貫性、レイテンシー、スループット、GPU 使用率、エラー挙動を比較できます。また、各サービスが再起動後に復旧するまでの時間も記録すべきです。
セキュリティチームは、生成されたイメージを完全な成果物としてレビューすべきです。AWS のベースイメージにはテスト済みの依存関係やビルド時のパッチが含まれる場合がありますが、ローカルで追加したパッケージは脆弱性を再導入する可能性があります。カスタマイズ後もスキャンを継続する必要があります。
プラットフォーム所有者は、移行前に所有責任も定義すべきです。AWS は DLC を保守し、Ray は Ray Serve を保守し、組織は自らのアプリケーションと EKS デプロイメントを所有します。明確な境界により、サポート対象コンポーネントをサポート対象のエンドツーエンドサービスと誤認することを防げます。
より広い教訓は、すべての TorchServe ユーザーが Ray Serve を採用しなければならないということではありません。保守されていないサービングレイヤーには、今や明示的な判断が求められるということです。現状維持、Ray Serve への移行、別のサーバーの選択は、それぞれ異なるサポートモデルを生み出します。
AWS Ray Serve Deep Learning Containers は、その選択肢の 1 つをより具体的にします。新しい例は、テスト済みのベース、直接的なプログラミングモデル、動作するシングル GPU EKS デプロイメントを提供します。同時に、残る責任も可視化します。
代表的な TorchServe サービスを 1 つ選び、実際のトラフィックパターンで移行をテストしてください。DLC が可用性を損なわずに依存関係の作業を削減できるなら、より広範な展開に値します。Ray の運用レイヤーがその利点を上回る場合も、このテストが早期に明らかにするでしょう。
