RayOrch、マルチモーダルデータ準備に血統管理付き並列処理を導入

概要

基盤モデル向けのデータ準備では、入力をそのまま処理するのではなく、文書をページに、動画をフレームに分解し、その後さらに認識・抽出・フィルタリングを行うことがあります。生成される子要素の数は入力ごとに異なり、長いテールを持つこともあります。一方で、実行は並列化したいものの、最終結果は元の文書や動画に戻し、子要素の順序も維持しなければなりません。RayOrchは、この動的な粒度変更とデータ血統の管理を同時に扱うための仕組みです。

主な仕組み

• 親子関係を明示的に定義。 プログラムは、順序付きで子要素数が変動する展開と、それに対応する集約を宣言します。コンパイラが両者の対応を検証するため、アプリケーションが平坦なレコードを手作業で再グループ化する必要を減らせます。
• 準備済みタスクを親横断でバッチ化。 各呼び出しにFIFOのReady Queueを設け、複数の文書や動画から実行可能になった子タスクをまとめてGPUへ送ります。親単位で処理するよりも、入力ごとの子タスク数の偏りに対応しやすい設計です。
• 完了順ではなく血統で結果を復元。 子の所属、直近の親、変更されない序数、終端状態を記録します。そのため、タスクが順不同で終了しても、バッチ境界に依存せず正しい構造を再構成できます。
• 親単位の進行と障害処理。 必要な子タスクがすべて終端状態になれば、その親は次段階へ進めます。特定の親で障害が発生した場合は、未配布の兄弟タスクを抑止しながら、無関係な親の処理を継続できます。

評価結果

NVIDIA H20での評価では、MinerUを4基から64基へ拡張した場合に15.14倍、動画処理パイプラインを8基から64基へ拡張した場合に7.82倍の高速化が報告されています。MinerUのエンドツーエンド比較では、Ray Dataより13.1%、Daftより29.0%短い処理時間となり、DoclingではRay Dataを16.0%上回りました。これらは論文で選ばれたワークロードの結果であり、実際の効果は演算量、入力の偏り、クラスタ構成によって変わります。

意義

RayOrchのポイントは、新しいスケジューラだけでなく、血統、動的並列化、結果集約を一つの実行モデルにまとめたことです。文書解析や動画理解のように粒度が何度も変わるパイプラインでは、並列実行を確保しながら、順序復元や失敗時の制御をアプリケーション側で実装する負担を軽くできます。

ただし、親子展開が明確な処理ほど恩恵を受けやすい設計であり、すべてのバッチ処理を置き換えるものではありません。公開された実装が、より多様なマルチモーダル処理や本番環境の障害対応でどこまで有効かが、今後の検証点になります。

出典：Hugging Face Daily Papers