Discord、単一GPUワークフローから共有RayクラスターへのMLプラットフォーム拡張

原文リンク(2025-12-03)

Discord社は、単一GPUトレーニングの限界に直面した後、機械学習プラットフォームを再構築した方法を詳述した。RayとKubernetesを標準化し、ワンクリックでクラスターを作成できるCLIを導入し、DagsterとKubeRayを通じてワークフローを自動化することで、分散トレーニングを日常的な運用に変更できた。これらの変更により、大規模モデルの毎日の再トレーニングが可能となり、広告ランキングの主要指標で200%の向上を達成した。

Uber社、Pinterest社、Spotify社などの企業からもカスタムモデルの規模と頻度が拡大するにつれ、同様のエンジニアリングレポートが発表されている。これらの報告では、手動で管理されていたチーム所有のGPUセットアップから、共有可能でプログラム可能なプラットフォームへの移行が記されている。これらのプラットフォームは、一貫性、オブザーバビリティ、迅速なイテレーションを優先している。

Discord社の変革は、チームが独自にRayクラスターを作成し、オープンソースの例をコピーして各ワークロードに合わせてYAMLファイルを修正するところから始まった。このアプローチは、設定のズレ、不明確な所有権、GPU使用の不整合を引き起こした。プラットフォームチームは、クラスターの作成と管理を標準化することで、分散型MLを予測可能なものにすることを目指した。

結果として生まれたプラットフォームはRayとKubernetesを中心に構築されているが、その上に抽象化が施されている。CLIを通じてエンジニアは高レベルのパラメータを指定することでクラスターを要求でき、ツールはRayを実行するために必要なKubernetesリソースを検証済みテンプレートを使用して生成する。この仕組みにより、チームが低レベルのクラスター設定を理解する必要がなくなり、スケジューリング、セキュリティ、リソースポリシーが一貫して適用される。

トレーニングワークフローはDagsterに統合され、KubeRayと連携してパイプラインの一部としてRayクラスターを作成および削除する。以前は手動でセットアップが必要だったジョブが、単一のオーケストレーション層を通じて実行され、クラスターのライフサイクルがシステムによって自動化された。

Discord社はまた、X-RayというUIを構築し、アクティブなクラスター、ジョブログ、リソース使用状況を表示する機能を提供した。これらのコンポーネントにより、分散トレーニングは特注のセットアップ作業ではなく、予測可能なワークフローに変わった。

同社によると、このプラットフォームは大規模モデルの毎日のトレーニングを可能にし、エンジニアが分散技術を採用しやすくなった。チームはプラットフォームグループの直接的な関与を必要とせずに、新しいトレーニングフレームワークを実装できる。この改善は、広告の関連性向上など、測定可能な製品の成果に繋がった。

他の組織も同様の移行を報告している。Uber社はMichelangeloプラットフォームの一部をRay on Kubernetesに移行し、スループットとGPU利用率の向上を報告した。Pinterest社はクラスターのライフサイクルを管理し、ログとメトリクスを集中化するRayコントロールプレーンを構築し、MLエンジニアの運用上の摩擦を軽減した。Spotify社はGKEベースの環境「Spotify-Ray」を作成し、ユーザーがCLIまたはSDKを通じてRayクラスターを起動し、実験と生産ワークフローを統一できるようにした。

しかし、内部MLプラットフォームの限界について警告する報告も発表されている。今年初めの投稿で、CloudKitchens社は最初のKubernetesベースのシステムが過度に複雑化し、単純なMLジョブの開始に10分以上かかり、PythonユーザーにとってBazelベースのワークフローが継続的な保守の摩擦を生んだと述べている。

これらの報告を総合すると、明確な抽象化と予測可能なワークフローを備えた共有MLプラットフォームへの移行が進んでいることが示唆される。プラットフォームは迅速なイテレーションと分散コンピュートへの信頼性の高いアクセスを可能にするが、設計と保守におけるトレードオフをもたらす可能性もある。