# タスク並列フレームワーク ## 定義 タスク並列フレームワークとは、計算を**タスク**(自律的に実行可能な小単位)に分解し、それらを分散クラスタ上で並列・依存順に実行するソフトウェア基盤である。フューチャ(future)とデータ依存を基本プリミティブとして持ち、計算グラフの動的構築・スケジューリング・耐障害性を担う。 強化学習(RL)・エージェント型 AI・超並列シミュレーションの台頭により、「毎秒 100 万件超のタスクをミリ秒以下のレイテンシで実行する」という要件が顕在化した。 ## 主要システムの比較 | システム | モデル | 特徴 | 限界 | |---|---|---|---| | MapReduce / Spark | BSP データフロー | 豊富な API・straggler 緩和 | 静的 DAG 前提、細粒度タスクに高オーバーヘッド | | CIEL | 動的タスクグラフ | 血統耐障害性 | アクター抽象なし、中央集権スケジューラ | | Dask | 動的タスクグラフ + Python 統合 | Python 親和性 | 中央集権スケジューラで 3K tasks/s 上限 | | Ray | 動的タスクグラフ + アクター統合 | 1.8M tasks/s、タスク+アクター統合 | 汎用ゆえ特化最適化に限界 | | TensorFlow / MXNet | 静的計算グラフ | GPU 最適化 | 動的グラフ変更・シミュレーション統合が困難 | ## 横断的知見 *注: 本節は複数ソースが揃い次第拡充する。現時点は OSDI 2018 (Ray) の単一ソースに基づく。* - **制御状態とスケジューラの分離が鍵**: Spark/CIEL は中央スケジューラに状態を同居させたことで数十ミリ秒のオーバーヘッドが生じた。Ray の GCS(Global Control Store)は状態を分離してスケジューラをステートレス化し、ミリ秒未満ディスパッチを実現した([[@2018__OSDI__Ray A Distributed Framework for Emerging AI Applications]])。Allreduce で顕在化: 中央集権スケジューラでは各ラウンドに 5ms の最低遅延が加わり性能が 2× 悪化する - **ステートレスタスクとステートフルアクターの統一**: CIEL はタスクのみ、Orleans/Akka はアクターのみ。RL のように訓練(アクター)・シミュレーション(タスク)・サービング(アクター)が混在する場合、どちらか一方だけでは実装が複雑になる。タスクとアクターの統合が汎用 AI フレームワークの必要条件である - **血統ベース耐障害性のスケーリング課題**: 既存の血統ベース(Spark RDD 等)は BSP の粗粒度前提でマスタ 1 台に収まる。Ray は GCS のシャーディングで細粒度・動的ワークロードへの血統管理を拡張した ## 未解決の問い - 超大規模 LLM 訓練(数千 GPU・数兆パラメータ)ではタスク粒度の管理コストが問題になるか? Ray 上の FSDP/Megatron-LM 実装の実績は? - RL の密結合ループを前提とした設計と、バッチ型推論サービングを前提とした設計は将来的に収束するか? - GCS のシャード分散モデルで、グローバルスナップショットやトランザクション的な状態変更が必要な場合はどう扱うか? ## 関連 - [[動的タスクグラフ]] — Ray の計算モデル基盤 - [[グローバル制御ストア]] — Ray の制御状態管理 - [[分散スケジューラ]] — ボトムアップスケジューリング - [[LLM分散学習]] — 現代の超大規模訓練フレームワークへの展開 - [[GPUクラスタスケジューリング]] — タスク並列スケジューラとの交差領域 ## 出典 - [[@2018__OSDI__Ray A Distributed Framework for Emerging AI Applications]] — Ray の提案論文。タスク並列フレームワークの設計課題を RL 要件から導出し GCS + ボトムアップスケジューラで解決