Ray Train DLCがEKS上の分散トレーニングにおけるイメージビルドを不要に
AWSは10月28日、カスタムコンテナイメージをビルドせずにRay Train DLCを使用する8 GPUトレーニングの例を公開した。同社のDeep Learning Containerは、パッケージ化されたソフトウェア環境として、トレーニングフレームワークとネットワークライブラリを提供する。残る作業は、クラスタ設定とワークロード検証にある。
この例では、言語モデルであるQwen2.5-1.5Bを、AWSのマネージドKubernetesサービスであるAmazon EKS上のg6.12xlargeインスタンス2台で実行する。Kubernetesは、複数のマシンにまたがるコンテナ化アプリケーションを調整する。AWSは、GPU間にモデル状態を分散するトレーニング手法であるPyTorch FSDPを使い、インスタンス間通信を検証している。
これにより、AWSが保守するトレーニング環境と、チーム自身が同じソフトウェアスタックを保守する場合との比較が具体的になる。ただし、このサンプルはランダムなトークンバッチ、すなわちランダムに生成されたモデル入力を使用する。有用なモデル適応ではなく、インフラストラクチャを検証するものだ。チームは分散実行の出発点を得られる一方、データセット準備、評価、プロダクションでの復旧は別途判断する必要がある。
Ray Train DLCがEKSチームにもたらす変化
直近の変化は、公開済みイメージから分散トレーニングジョブへ至る、文書化された経路が利用できるようになったことだ。AWSの分散トレーニングサンプルは、コンテナのパッケージングを特定のクラスタ構成と結び付けている。この例は、トレーニングが容易になるという一般的な約束よりも、狭い範囲ながら実行に移しやすいものを提供している。
重要な変化は、共有トレーニング環境を誰が保守するかにある。
カスタムイメージでは、アプリケーションチームが依存関係の組み立てを担う。その責任はPythonフレームワークのインストールにとどまらない。GPU実行と通信は、トレーニングスクリプト外のライブラリを含め、連携して動作しなければならないコンポーネントに依存する。
公開イメージでは、その組み立て作業の担当者が変わる。アプリケーションチームは、得られる環境が要件に合うかどうかを引き続き判断する。ただし、自ら同等の環境を保守するか決める前に、既存の成果物を評価できる。
この違いが最も重要になるのは、チームがすでにトレーニング対象を把握している場合だ。環境互換性の解決に費やす時間は、データセットや評価プロセスを直接改善しない。最初の実験からその作業を取り除けば、より早い段階でワークロードを調査する余地が生まれる。
発表の時系列も正確に捉える必要がある。AWSのRay Trainコンテナの変更履歴では、初期イメージのリリースは2026年8月26日、バージョン1.1は9月1日とされている。10月の公開は、このコンテナファミリーを使ったデプロイメントの手順であり、初回リリースではない。
この時系列はニュースとしての価値を変える。AWSは、すでに公開したパッケージングが再現可能な分散セットアップにどう適合するかを文書化している。新しいトレーニングアルゴリズムが発明されたかのように示すことなく、ソフトウェア提供とクラスタ運用の接続に重点を置くべきだ。
エンジニアリングマネージャーにとって、判断の枠組みは明確になる。別個のトレーニングイメージを保守することで、公開環境にない能力が得られるかを問える。これは、すべての分散トレーニングプロジェクトに独自のコンテナビルドが必要だと想定するよりも具体的だ。
プラットフォームエンジニアにとって、この例はローカル要件と比較するための参照構成となる。差異は明示的なレビュー項目になる。チームは、どの変更がワークロードに属し、どの変更が既存インフラの慣行を反映するかを特定できる。
公開された経路は、例外の説明も容易にする。組織が異なるフレームワークビルドや特化した拡張機能を必要とするなら、その要件は追加保守を正当化できる。カスタムイメージは、デフォルトの出発点ではなく、文書化された必要性に基づくものとなる。
これらは普遍的な適合性を示すものではない。チームが検討できる実用的な代替案を提示するものだ。最も妥当な解釈は、AWSがこの特定の分散トレーニング構成の評価を始めるために必要な環境組み立ての量を減らした、ということである。
カスタムイメージ保守への圧力
AWSのトレーニングコンテナスタックには、分散実行フレームワークであるRayと、機械学習フレームワークであるPyTorchが含まれる。また、NVIDIAのGPUコンピューティングプラットフォームであるCUDAと、GPU間通信用のNVIDIAライブラリであるNCCLもバンドルされている。
ネットワークコンポーネントには、密結合ワークロード向けのAWSネットワークインターフェースであるElastic Fabric Adapterと、AWS OFI NCCLプラグインが含まれる。このプラグインはNCCLをネットワークプロバイダーに接続する。AWSは、リリース公開前に統合環境をテストするとしている。
カスタムイメージを選ぶチームには、同じ統合作業を担う理由が求められる。
これはカスタム環境を時代遅れにするものではない。組織には、承認済みの依存関係、特化したビルド、社内配布に関する要件があり得る。そうしたニーズは依然として有効だ。既存の成果物がすでに対処しているパッケージング作業を、日常的に重複して行うことには圧力がかかる。
複数マシンにまたがってトレーニングジョブを実行できるかを調べる、仮想的なエンジニアリンググループを考えてみよう。最初の疑問は分散動作に関するものだ。別個のイメージをビルドすると、その疑問に到達する前にもう一つの調査が加わる。
保守されたベースラインは、この順序を短縮できる。グループはまず参照環境を評価し、実際の非互換性を記録する。カスタマイズの判断は、実行前の仮定ではなく、ワークロードから得た証拠に従う。
これは運用面での比較であり、一方のコンテナが常に優れた性能を発揮するという主張ではない。慎重に保守された社内イメージでも、同じ技術要件を満たせる。違いは、所有権、更新手順、環境を利用可能な状態に保つために必要な労力にある。
公開イメージは、チームが自らのプラットフォーム作業をどう説明すべきかも変える。パッケージ化するソフトウェアが減っても、貢献が減るわけではない。プラットフォームエンジニアは、アクセス制御、リソース配置、可観測性、組織のトレーニングワークロードの要件に注意を集中できる。
ベースラインが共有されると、こうした責任を分離しやすくなる。複数の実験が同じ環境を使うなら、レビュアーはコードと構成の差異に焦点を当てられる。実験ごとに別のイメージを用意すると、その比較を整理しにくくなる。
その利点は、導入時の規律にも左右される。チームは、使用した成果物と追加した依存関係を記録する必要がある。そうしなければ、名目上共有されたベースラインが、ジョブ間で異なる実行環境を隠してしまう可能性がある。
したがってRay Train DLCは、保守を免除するものではなく、保守に関する選択肢を提供する。AWSは公開された組み立てを担う。導入組織は、受け入れ基準、デプロイメントポリシー、更新時期の判断を担う。
妥当な社内レビューでは、カスタム環境で何が可能になるのか、誰が保守するのか、互換性をどう確認するのかを問うだろう。これらの問いは、公開コンテナが勝ると前提するものではない。評価できる程度にトレードオフを可視化するものだ。
より広い意味合いは明快だ。アプリケーション固有の作業は、アプリケーション固有のパッケージングを正当化すべきである。ワークロードが保守された環境に適合する場合、別のビルドを所有することは継続的な義務を伴う選択になる。
FSDPによりネットワークはトレーニング設計の一部になる
ネットワークスタックが重要なのは、シャーディングがGPU間の協調方法を変えるためだ。fully sharded trainingでは、FSDPがパラメータ、勾配、オプティマイザ状態をワーカー間に分散する。パラメータは学習済みの値を保持し、勾配は更新を導き、オプティマイザ状態は更新プロセスを追跡する。
シャーディングされたユニットが計算を始める前に、ワーカーは必要なパラメータを集める。逆方向計算の後、勾配を同期して分割する。これにより複製された状態は減る一方、トレーニング設計で対応しなければならない通信が生じる。
メモリ節約と通信要件は、同じエンジニアリング判断に含めるべきだ。
このトレードオフは、互換性のあるネットワークライブラリを提供することが実用的な価値を持つ理由を説明する。トレーニング環境に必要なのは、動作するモデルインポートだけではない。選択した分散戦略が必要とする通信もサポートしなければならない。
比較すべきなのは、単にGPUが多いか少ないかではない。通信を考慮したうえで、状態の分散がワークロードに利益をもたらすかどうかだ。起動に成功したことは実行可能性を示すが、その構成が有用かどうかは性能測定で明らかになる。
PyTorchが異なるシャーディング戦略を文書化しているのは、このバランスが変化するためだ。フルシャーディングはより多くの状態を分散し、ハイブリッドな手法はマシン内のシャーディングとマシン間の複製を組み合わせる。こうした選択肢の存在は、参照構成を普遍的な最適解として扱うべきではないことを示している。
別の分散トレーニングシステムであるDeepSpeedは、重要な業界参照例を提供する。そのZeROアプローチもトレーニング状態を分割する。PyTorchはDeepSpeedのZeRO Stage 3をFSDPの着想源として明示しており、AWSのサンプルを確立された技術的方向性の中に位置付けている。
この文脈により、新規性を適切な規模に保てる。ここでのAWSの貢献は、パッケージ化された実行環境とそのデプロイメント経路に関するものだ。複製されたトレーニング状態を減らすという基礎的な考え方は、この手順の公開より前から存在している。
手法を比較するチームにとって有用な問いは、どの戦略がモデルと運用上の制約に適合するかである。コンテナの利用可能性は、手法を調査するための労力を減らせる。しかし、分散トレーニングシステム間の比較を決着させるものではない。
ハードウェアの説明にも注意が必要だ。AWSは、g6.12xlargeについて、NVIDIA L4 GPUを4基、ホストメモリを192 GiB、ネットワークを40 Gbpsと記載している。これらの仕様はインスタンスを説明するものであり、このワークロードにおける測定済みのトレーニングスループットではない。
ネットワーク帯域幅の数値だけでは、実験がどれだけ早く完了するかには答えられない。トレーニングには計算と通信が含まれ、その関係はワークロードが決める。読者は、ハードウェア仕様をアプリケーション性能の主張に置き換えないよう注意すべきだ。
同じ注意はメモリ見積もりにも当てはまる。永続的なモデル状態は、トレーニング中のすべての割り当てを表すわけではない。中間計算、一時バッファ、ワークロード設定も、ジョブが収まるかを評価する際に重要となる。
実用的な解釈は、シャーディングがエンジニアリング上の交換を生むということだ。特定のメモリ要求を減らす代わりに、協調を増やす。パッケージ化されたネットワークスタックは、この交換に必要な部分に対応するが、すべてのワークロードにとって有利かどうかを決めるものではない。
だからこそ、通信経路には明示的な検証が必要になる。コンテナはコンポーネントを提供する一方、実験ではそれらのコンポーネントが実際のクラスタでどう動作するかを確認しなければならない。
クラスタ構成が変わってもコンテナは固定される
AWSのKubeRayデプロイメントガイドは、このイメージがKubernetesにどう適合するかを示している。KubeRayは、Rayリソースを管理するコントローラーであるオペレーターだ。そのRayCluster構成は、調整を担うヘッドとワーカーポッド、つまりコンテナを実行するKubernetesユニットを記述する。
このガイドでは、GPUワーカーをヘッドから分離しています。また、イメージのRayバージョン、Rayが認識するGPU数、Kubernetesのリソース割り当てを整合させる必要があります。これらはイメージを取り巻く設定上の責務です。
イメージのビルドを省略しても、クラスタ設定はデプロイの明示的な一部として残ります。
この境界は、絡み合いがちな問いを分けられるため有用です。イメージは提供されるソフトウェア環境を決定します。クラスタ設定は、その環境をどこで実行し、プロセスにどのデバイスを割り当てるかを決定します。
デバイスの可用性は特に重要です。コンテナ内のライブラリは、利用を想定するデバイスへのアクセスの代わりにはなりません。したがってデプロイのレビューでは、パッケージ化された依存関係とワーカーに割り当てられたリソースの両方を確認する必要があります。
Ray Trainのランチャーは、さらに別の調整レイヤーを加えます。そのTorchTrainerは、ワーカープロセス全体でトレーニング関数を実行します。ScalingConfigはワーカー数とアクセラレータ要件を記述し、これらの判断をワーカーごとのトレーニングループの外に置きます。
この分離により、チームは変更をより明確に整理できます。モデル実験のために、必ずしも異なるクラスタトポロジーが必要になるわけではありません。クラスタ容量の変更のために、必ずしもモデルのトレーニングロジックを書き直す必要もありません。
再現可能な評価において有用な成果物は、実行を取り巻く選択の完全なセットです。これにはイメージの識別情報、クラスタ設定、ジョブコード、ワークロード設定が含まれます。モデル名だけを記録しても、不明な点が多すぎます。
「再現可能」という言葉にも、限定された意味を持たせるべきです。デプロイ入力を繰り返すことと、同一のトレーニング結果を保証することは異なります。チームは、再現しようとしているのがインフラ、実行動作、あるいはモデル品質の結果のどれなのかを明示すべきです。
公開された設定は、そのうち最初のものを確立する助けになります。ローカルでの変更をレビューする際の参照基準を提供します。ただし、変更されたセットアップがなぜ異なる振る舞いをするのかを説明する必要性までなくすわけではありません。
ワークロードの変更にも、インフラ変更と同じ注意を払うべきです。送信時に依存関係を追加すれば、ベースイメージを維持したままジョブ環境を変更できます。そうした追加も実験記録に含める必要があります。
ここでチームのドキュメントが運用上役立ちます。エンジニアは、観測結果そのものと並べて、その観測を生んだ設定にアクセスできる必要があります。完了したジョブのスクリーンショットだけでは、その背後にあるすべての判断を説明できません。
検索可能なナレッジベースは、デプロイ判断や調査メモをチームが保持する助けになります。これにより、設定ファイルやログを置き換えることなく、レビューと引き継ぎを支援できます。
したがって、固定イメージのアプローチは複雑さの整理方法を変えます。ソフトウェアのパッケージングを共有のベースラインとし、デプロイ上の違いを設定内で可視化します。参照セットアップを自分たちの標準と見なす前に、チームは依然としてその違いを確認する必要があります。
合成データによる実行は有用なファインチューニングを証明しない
サンプルのランダム入力は意図的な簡略化です。これにより、初期セットアップにデータセットを含めずに実行パスを検証できます。読者がその結果で何が確立されるかを理解しているなら、これはインフラ確認として適切です。
完了した分散ジョブと、有用にトレーニングされたモデルには、異なる証拠が必要です。
前者は実行に関するものです。ワーカーが起動し、参加し、要求された計算を完了することです。後者は学習に関するものです。得られたモデルが、定義されたタスクで許容可能に動作することです。どちらの結果も、もう一方を自動的に意味するものではありません。
この区別は、ブリーフが既存モデルへの追加トレーニングを意味するファインチューニングを扱っているため、特に重要です。この例は、そのモデルに対するトレーニング操作を実行します。ランダム入力は、実際のタスクにおける改善を示すものではありません。
したがって、サンプルを適応するチームは、自分たちのデータで何を検証するのかを定義する必要があります。これには、トレーニング後に何を許容可能な挙動と見なすかを決めることも含まれます。その定義がなければ、インフラの成功が製品の進捗を示す誤解を招く代理指標になりかねません。
評価は、トレーニング中に用いられる数値的な目的関数である損失の解釈も変えます。報告された損失値は、設定された計算を説明します。それだけで、適応済みモデルがデプロイ要件を満たすことを示すわけではありません。
次の境界は、保存された進捗に関するものです。Rayの永続ストレージに関するガイダンスでは、マルチノードトレーニングにおけるチェックポイント用として共有先を求めています。チェックポイントはトレーニング状態を保存し、ジョブの再開や後の結果利用を可能にします。
Rayは、チェックポイントを保存するワークロードと、メトリクスのみを報告する実行を区別します。チェックポイントを保存しない場合、メトリクスはローカルで集約できます。そのため、合成データによる実行確認は、より長時間のトレーニングワークロードに必要なストレージ動作を確立しなくても完了できます。
この区別には実務上の影響があります。価値あるトレーニングにセットアップを依存させる前に、チームは必要な状態を保存・再読み込みできることを確認すべきです。コンテナの再起動は、実験の進捗を復元することと同じではありません。
所有権の問題はここでも戻ってきます。公開されたイメージは互換性のあるライブラリを提供できますが、成果物をどこに置き、誰がアクセスできるかは、採用するチームが定義します。これらの要件はワークロードと組織から生じます。
パフォーマンスに関する主張にも、独自の証拠が必要です。元のウォークスルーは設定を確立し、その検証パスを説明しています。これを、この構成がQwenにとって最速の選択肢であることを示す独立した比較と読むべきではありません。
公正な比較では、ワークロードと測定条件を一貫させたうえで、代替案を検討します。そうしなければ、入力処理やトレーニング設定の違いが、インフラ比較が実際に測定しているものを不明瞭にし得ます。
また、話を論争的に見せるために、批判的な反応を作り出す理由もありません。文書化された技術的な制約だけで、十分な検討材料になります。適切な問いは、その証拠が意図した運用上の判断を支えているかどうかです。
インフラの概念実証として、このサンプルは定義された実行パスを扱っています。本番導入には、チームは自らのデータ、成果物、復旧、タスク結果に関する追加の証拠を必要とします。これらの判断を分けておくことで、サンプルとその制約の両方をより使いやすくできます。
実際のワークロード、転送の証拠、イメージ更新を注視する
次に有用となる展開は、具体的なエンジニアリング上の観測です。今後数か月にわたり、読者は公開環境と実際のトレーニング作業の要求を結び付ける証拠を探すべきです。特定の順序で、3つのシグナルが最も重要です。
最も強力な続報は、合成入力を置き換えた後に何が再現可能なままなのかを示すものです。
まず、トレーニング挙動とタスク評価の両方を含む実際のワークロード報告に注目してください。報告では、結果を解釈できる程度に、モデル、データ処理、設定を明確に特定するべきです。完了したという事実だけでは、適応済みモデルの品質を確立できません。
チェックポイントからの復旧も、その証拠に伴うべきです。保存状態から正常に再開するワークロードは、合成データ実行では未解決の運用上の問いに答えます。初期の接続性確認を超えて、この環境を採用する根拠を強めるでしょう。
期待外れのタスク結果が出ても、コンテナが自動的に無効になるわけではありません。データやトレーニングの選択も結果に影響します。有用な報告は実行の失敗とモデリングの失敗を分け、システムのどの部分に注意が必要かを明確にします。
次に、制御されたパフォーマンス測定と組み合わされた転送の証拠に注目してください。転送の証拠とは、ワーカーが実際にどの通信経路を使用したかを示す観測結果です。こうした観測は、EFA対応インスタンスの存在から推測するのではなく、スループット結果と併せて示すべきです。
比較では、接続性と効率も区別すべきです。意図した経路が動作することを確立するのは、結果を解釈するために必要です。しかしそれは、ワークロードが利用可能なハードウェアを有効に活用していることを示すものではありません。
これらの条件を開示する報告は、パッケージングに関する主張を強めるでしょう。チームが、自分たちの環境で提供スタックの挙動を検査できることを示すからです。一方、説明されない差異は、さらなる診断やより明確なガイダンスが必要な領域を示します。
3つ目に、イメージ更新が再現可能な実験にどのように組み込まれるかを注視してください。AWSの変更履歴は、すでにリリースとそれにバンドルされたコンポーネントを分けています。このコンテナを採用するチームは、自身の更新プロセスが過去の実行環境の識別情報をどのように維持するかを評価すべきです。
コンテナイメージのコンテンツ識別子であるダイジェストは、特定の実行で使用された成果物を記録する助けになります。この記録は、設定やワークロードの変更と併せて残すべきです。そうしなければ、チームはどの変更が異なる結果を説明するのかを判断しにくくなります。
このシグナルは、Ray Train DLCsの継続的な保守の意義に関わるものです。組織が更新を意図的に採用し、回帰を明確に調査できるとき、公開環境は持続的な価値を提供します。ビルド手順を最初に省くことは、その関係の一部にすぎません。
現在サンプルを評価している読者は、まず自分たちの判断に必要な証拠を定義してください。公開設定を参照として使い、正確な環境を記録し、接続性の確認とワークロード結果を分離します。次に実際のデータを導入し、保存状態からの復旧を検証し、一貫した条件下で測定値を比較してください。別のエンジニアが何が変わったのかを理解できるよう、デプロイ記録をトレーニング結果と並べて保管してください。Ray Train DLCsはチームに保守された出発環境を提供します。その環境を自らの業務に適したものにする証拠は、採用するチームが用意します。現在のトレーニングプロセスのどの部分が本当にカスタムイメージを必要とし、どの部分がまずこの共有ベースラインの評価から恩恵を受けるでしょうか？
