# Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 19 / Tue)、Research Track Oral "Agentic AI 1 & Multimodal/Generative Models" セッション（14:00 - 14:15 PDT、第5発表・セッション最終） > - **URL:** https://mlsys.org/virtual/2026/oral/3753 > - **登壇者:** Dong Wang（Meta FAIR, research engineer。data creation・agent RL・LLM inference に従事）。論文は Meta FAIR の共同研究（著者: Dong Wang, Yang Li, Ansong Ni, Ching-Feng Yeh, Youssef Emad, Xinjie Lei, Liam Robbins, Karthik Padthe, Hu Xu, Xian Li, Asli Celikyilmaz, Ramya Raghavendra, Lifei Huang, Carole-Jean Wu, Shang-Wen Li） > - **所属:** Meta FAIR（連絡先: Dong Wang、Shang-Wen Li） > - **関連研究:** OSS `https://github.com/facebookresearch/matrix` > - **掲載:** Proceedings of the 9th MLSys Conference, Bellevue, WA, USA, 2026 > [!abstract] 概要（論文 PDF アブストラクト） > 合成データは、特に実データが希少・高コスト・プライバシーセンシティブな場合に、大規模言語モデルの学習においてますます重要になっている。こうした生成タスクの多くは、専門化されたエージェントが協調してより高品質・多様・構造的に豊かなデータを生み出す、協調的なマルチエージェントワークフローを必要とする。しかし既存のマルチエージェント合成フレームワークは、しばしば中央集権的なオーケストレータに依存してスケーラビリティのボトルネックを生むか、特定ドメイン向けにハードコードされて柔軟性を欠く。本論文では **Matrix** を提案する。これは制御フローとデータフローの双方を、分散キューを通じて受け渡されるシリアライズ済みメッセージとして表現する分散型フレームワークである。この peer-to-peer 設計が中央オーケストレータを排除する。各タスクは軽量なエージェントを通じて独立に進行し、LLM 推論やコンテナ化環境のような計算集約的な操作は分散サービスが処理する。Ray 上に構築された Matrix は数万の並行 agentic ワークフローへスケールし、多様なデータ生成ワークフローへの容易な適応を可能にするモジュラーで設定可能な設計を提供する。我々はマルチエージェント協調対話、Web ベース推論データ抽出、カスタマーサービス環境でのツール利用トラジェクトリ生成といった多様な合成シナリオで Matrix を評価した。すべてのケースで、Matrix は同一ハードウェア資源下で出力品質を損なうことなく **2〜15x** の高いデータ生成スループットを達成する。 > [!note] 出典に関する注記 > 公式タイトルは論文 PDF 表紙の "Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework"（ファイル名では `:` を ` -` に置換）。発表者は Meta FAIR の Dong Wang（自動文字起こしの "Don Wang"/"Meta FAIR" は不鮮明だが論文表紙・連絡先で確定）。本文の数値・固有名はスライド/論文を権威とした。 ## 背景・動機: 合成データ生成と中央集権オーケストレーションのボトルネック - LLM/基盤モデルの学習は、コストが高くノイジーでプライバシーに配慮を要する人手データへの依存を減らすため、合成データを多用する方向へ移行している。近年は単一モデル/固定パイプラインではなく、複数の知的エージェント間の相互作用でデータを生む **agentic 合成データ生成**が主流化（スライド "The Importance of Synthetic Data"。SOTA 例として Kimi K2、Meta CWM を挙げる）。 - こうしたワークフローはループ付きの複雑な制御フローを持ち、従来の線形データパイプラインを超える。論文はデータ生成を **data-to-data transformation**（各入力行が独立タスク、ランタイムが多数を並行実行）として枠付ける。 - 現代の合成データに要求される特性（スライド "The Demands of Modern Synthetic Data"）: - **Control Intensive**: 推論・ツール利用・検証の複数ステップを含むマルチエージェントオーケストレーションが必要で、単純な線形パイプラインでは扱えない。 - **Diverse Needs**: モデル・ツール・制御フローを毎回インフラを作り直さずに差し替えられる設定可能性・柔軟性。 - **Efficiency**: "Generate & Reject" パラダイム（データソースフィルタリングと rejection sampling）が高スループットを要求する。例として NaturalReasoning は数百万の Web 文書をフィルタし大半を破棄、rejection sampling は大量の候補プールを生成して少数の高品質トラジェクトリを残す。これらをオーケストレータのボトルネックなしに数万の並行タスクで処理する必要がある。 - 既存のデータ生成システムの多くは**中央集権オーケストレーション**（多くは単一ボックス上で実行）。単一オーケストレータが第1エージェント/LLM に1ステップ走らせ→結果がオーケストレータに戻り→次のエージェントを判断して送る、をループする。この中央オーケストレーションが大規模実行時にボトルネックになる（スライド "Centralized Orchestration Creates a Bottleneck"、論文 Figure 2）。 - 関連ワーク: 汎用エージェントフレームワーク（AutoGen, LangGraph, CrewAI 等）は authoring 向けで本研究のスループット領域には追加のスケーラブル基盤が必要。専用システム（AgentInstruct, SWE-Agent, SWE-Synth, TaskCraft, AgentSynth 等）は特定タスク構造に最適化されドメイン適応に手間がかかる。Matrix はこの中間（"The Missing Middle"）を埋める汎用ランタイムとして位置付ける。 ## Matrix の P2P アーキテクチャ・5コンポーネント - **コアアイデア**: 中央集権オーケストレーションを peer-to-peer (P2P) エージェントアーキテクチャに置換。各タスクの状態（orchestration logic・中間結果・会話履歴）を**シリアライズ済みメッセージ**としてエージェント間で受け渡す。現在アクティブなエージェントがこの状態を消費・更新し、オーケストレータが決めた次エージェントへ emit する。エージェント自身は**ステートレス**でクラスタ全体に弾力的かつ独立にスケールできる（スライド "Peer-to-Peer Agent Orchestration"、論文 Figure 3）。 - **5コンポーネントの全体アーキテクチャ**（スライド "Matrix Architecture & Key Properties"、論文 Figure 1）: 1. **Configuration**: Hydra で agent role・入出力スキーマ・メトリクス（success_rate, rewards）・リソース要件・orchestrator（sequential/hierarchical）を指定。 2. **Agent Environments**: Data Loader → Multi-Agents → Continue 判定（Yes でループ継続 / No で Sink へ）でエージェントループを回す。 3. **Data Store**: Seed data / Generated Data / Assets Data の読み書き（入力読込と生成データのストリーム出力）。 4. **Cluster Management**: Ray + SLURM 上に構築。LLaMA・vLLM・bash・Apptainer Container・Agent・Actor を載せる。 5. **Monitoring**: Ray ベースの dashboard と Experiments（system/gpu metrics, queue length, query latency）。 - **キー特性4点**（スライド同上）: 1. **Independent Scaling**: 各 agent role はステートレスな Ray actor プール。あるエージェント種が遅ければそのプールだけ拡張でき、他は据え置き。 2. **High Task Concurrency**: 並行タスク数は actor 数から**デカップリング**。比較的少数の永続 actor を通じて**数万のワークフロー**を流せる。 3. **Backpressure Control**: グローバルな **semaphore** がインフライトのワークフロー数を制限。driver は token を acquire できた場合のみ新タスクを admit（token はタスク完了時に解放）。back pressure でシステム過負荷/クラッシュを防ぐ。 4. **Modularity**: P2P 設計が本質的にステートレスエージェント・シリアライズ可能 orchestrator・分散サービスを促す。LLM モデルやツールは Ray クラスタ内のサービスとして抽象化。 - **P2P オーケストレーション詳細**（論文 §4.1, Algorithm 1）: driver が各入力タスクを `Orchestrator` オブジェクトに変換（タスク固有の状態と制御フローを保持）。orchestrator はシリアライズ可能でエージェント間を follow し、各エージェントが `update()` で状態を進め `current_agent()` で次エージェントを局所的に決定。完了（`is_done`）で特殊な終端エージェント `_sink` へルーティングし、結果を永続化・メトリクス集約。各エージェントは Ray Actor として永続的な非同期 event loop (`_event_loop`) を持つ。 - **分散サービス**（論文 §4.2）: LLM 推論は HTTP オーバーヘッド回避のため **gRPC** ベース通信。Ray head node のネットワーク律速を避けるため active model replica URL のローカルキャッシュを保持し worker node 経由で直接負荷分散。長会話では sticky routing で prefix cache を再利用。Apptainer コンテナ等の stateful サービスは resource pool と registry（container ID → Ray actor）でルーティング。 ## フォルトトレランス・back pressure・スケジューリング - **Agent Fault Tolerance**（論文 §4.5、スライド "Reliability & Observability"）: Matrix は **at-most-once** 実行セマンティクス。ユーザ実装エージェントにバグ/例外があると actor が死ぬが、Ray が数秒で actor を再起動。同一 role のエージェントは **per-role message broker** を共有し、broker が (i) 処理待ち orchestrator の incoming queue と (ii) どの orchestrator がどの instance に割当中かの assignment map を保持。broker は round-robin で dispatch し、actor crash 時に該当 instance の orchestrator を failed としてマークし sink へ failed trajectory として転送。これにより**インフライトのメッセージのみ失われ**、システム全体は停止しない（broker と sink は framework component で信頼）。 - **Row-Level Scheduling**（論文 §4.4）: Ray Data 等の batch 処理は固定サイズバッチを actor が実行するが、長時間/複雑なタスクがバッチを停滞させ後続バッチをブロック（idle GPU、batch-level scheduling の bubble effect）。Matrix は**各タスクを先行タスク完了直後に独立スケジュール**する row-level scheduling で、heterogeneous なマルチエージェントワークロードの GPU 利用率を上げ E2E レイテンシを下げる（LLM 推論の continuous batching に類比）。 - **System Debugging**（論文 §4.7、スライド "Reliability & Observability"）: Ray が actor のログを driver プロセスへストリームし "local-like" デバッグを実現。各入力タスクの全 trajectory を記録し、エラー文脈（timeout・connection failure・service error）をオフライン解析用にディスクへ書き出す。未処理例外は asyncio event loop の future へ伝播し、orchestrator を failed としてマーク→sink で出力に永続化。ユーザは failed trajectory をフィルタして再実行可能。 - **Monitoring**: Ray dashboard に加え **Grafana** dashboard へカスタムメトリクス（distributed queue length, pending tasks, query latency）を publish してボトルネックを特定。 ## ケース1: Collaborative Reasoner (Coral) — スケーラビリティと障害注入 - **対象**: Collaborative Reasoner (Coral, Ni et al., 2025a)。対話駆動タスクで LLM の協調推論を評価・改善。2エージェント（"teacher" と "student"）が議論・反論し、マルチターンでコンセンサスに至る。self-collaboration で訓練データを生成（論文 Figure 4: teacher/student/answer_extractor/answer_matcher の P2P グラフ）。 - **スケーラビリティ**（スライド "Matrix Scales Linearly..."、論文 Figure 5）: 両システムとも asyncio で並行性を実装。max concurrency を **400〜10,000**（GPU あたり 50 並行クエリ、タスク並行性 = 50 × A100 ノード数）と増やすと、中央集権の Coral baseline は約 **4,000〜6,000** で頭打ち（オーケストレータがスケジューリングボトルネック化）。Matrix (P2P-agent) は GPU ノード追加に対し**ほぼ線形にスケール**。 - **大規模結果**（論文 Table 1、31 A100 ノード = 248 GPU、LLaMA-3.1-8B-Instruct）: P2P-agent は **2B トークンを 4 時間で生成**し、公式 Coral 実装比 **6.8x** 高スループット。 | Metric | Baseline | P2P-Agent | |---|---|---| | Runtime | 9:03:22 | 4:17:05 | | Concurrent tasks | 5,000 | 12,400 | | Total trajectories | 300k | 1 Million | | Agreement correctness | 0.4732 | 0.4778 | | Tokens generated | 616,759,036 | 2,002,025,810 | | Tokens per second | 18,917 | 129,833 | - **オーバーヘッド分析**（8 H100 ノード = 64 GPU で 200k Coral trajectory、論文 Table 2/3）: 典型タスクで **agent processing が E2E レイテンシの約 80%**（median 80.12%）、queuing は無視可能。最遅タスクでは processing が約 99% を占める。dummy agent（実計算なし）の bottleneck study では **約 1.1k trajectories/s、12k orchestration messages/s** を維持（論文 Table 4: agent processing median 36.72%）。orchestration の network bandwidth は約 1.6 MB/s（2.26M シリアライズメッセージ）と僅少。約 12k orchestration messages/s を超える場合は data parallelism でスループットを伸ばせる。 - **障害注入 / Actor Crash Recovery**（論文 Table 5/6、スライド "Actor Crash Recovery..."）: 200k Coral trajectory を (i) 無障害 (ii) 12分ごとにランダムに agent actor を kill の2設定で評価。at-most-once セマンティクスにより killed actor のインフライト orchestrator が失われうる。actor は計7回 kill され、毎回 Ray が数秒で再起動。結果、**約 2% のタスクのみ失われ（lost trajectories 4,080/200k）、スループット低下はわずか 5%（75,579 → 72,059 tokens/s）**。agreement correctness も安定（0.4781 vs 0.4856）。 ## ケース2: NaturalReasoning — Ray Data 比較・並列性3種 - **対象**: NaturalReasoning (Yuan et al., 2025)。STEM/経済/社会科学等にわたる 2.8M の難問を含む大規模推論データセット。Matrix で生 Web 文書から NaturalReasoning 風データを curate。マルチターン対話と異なり**大半の入力が早期にフィルタされ、残った一部のみが高コストな下流処理をトリガする高フィルタリング領域**で Matrix をストレス（スライド "Web-Based Reasoning Data Curation"、論文 Figure 6）。 - **3エージェントの curation パイプライン**: - **Filter**: 英語文書を識別し、fine-tuned LLaMA-3.1-3B-Instruct で推論内容を含むか分類。 - **Score**: LLaMA-3.3-70B-Instruct で複数の品質軸に沿って評価（NaturalReasoning の手法に準拠）。 - **Question**: 質問・参照解答・独立した推論ステップを抽出（LLaMA-3.3-70B-Instruct）。抽出解答と独立生成解答の整合をチェックして低品質を除く。 - **フィルタ統計**（論文 Table 7、25M DCLM Web 文書）: filter_by_en 3.68%、filter_by_classifier 90.24%、filter_by_score 0.44%、filter_by_no_boxed_answer 0.19%、**success 5.45%**。最終的に約 100万件の高品質な推論 Q&A を生成。3B フィルタモデルは Yes/No 単一トークン出力で効率的なため、英語フィルタ後のデータの 97% を処理してもボトルネックにならない。 - **3種の並列性**（スライド "Three Levels of Parallelism"、論文 §4.3）: 1. **Data parallelism**: 入力データセットをパーティション分割し独立処理（Spark/Ray Data に類似）。 2. **Task parallelism**: 1パーティション内で多数のタスクを asyncio で並行実行。 3. **Agent parallelism**: 各 agent role が CPU/GPU/メモリを独立確保し、instance 数を増やして水平スケール。 - **並列性のスループット評価**（500k DCLM サブセット、32 A100 ノード×8 GPU、論文 Table 8。3B フィルタモデルは 32 レプリカ、70B モデルは 56 レプリカ、max concurrent tasks = 14k）。タプルは (data parallelism, task parallelism, agent parallelism): | Settings Name | Three Parallelisms | Normalized Throughput | |---|---|---| | Baseline | (1, 14000, 1) | 1 | | Increase Data Parallelism | (20, 700, 1) | 1.61 | | Only Data Parallelism | (240, 1, 1) | 0.38 | | Increase Task Parallelism | (240, 50, 1) | 1.43 | | Increase Agent Parallelism | (1, 14000, 2) | 1.03 | | More Agent Parallelism | (1, 14000, 10) | 0.91 | - **Data parallelism**: Setting 1 は 14k 並行を許すが入力の 93% が Filter で早期に落ちるため実効並行は約 700 に留まる。20 パーティションに増やすと実効並行が 20×700 ≡ 14k に達し **1.61x** 高速化。20 を超えても各パーティション内の task parallelism が既に GPU を飽和させるため追加効果は小。 - **Task parallelism**: Setting 3 → 4（パーティション当たり 50 並行）で **3.8x** 高速化。並行性を上げる方がパーティション数を増やすより効果的。 - **Agent parallelism**: Setting 1 → 5（agent instance 2倍、sink 除く）はわずかな利得、Setting 6 はさらに増やしても利得なし。LLM 推論が Ray Serve 側で I/O-bound なため、計算の大半が GPU にあるこのケースでは agent (CPU) はボトルネックでない。 - **スケジューリング粒度**（row-level vs batch-level、論文 Table 9, Algorithm 2、スライド "Impact of Scheduling Granularity: Row vs Batch"）: Ray Data baseline（batch-level）と比較。多くの GPU 資源（32 A100 ノード）・14k 並行タスクを揃え、P2P-agent は Setting 2 (20, 700, 1)、Ray Data baseline は Setting 4 (240, 50, 1)。P2P-agent は **2.1x** 高スループット（同等時間で 2.7x 多い文書を処理）。 | Metric | Baseline (Ray Data) | P2P-Agent | |---|---|---| | Runtime | 12:57:28 | 17:57:55 | | Concurrent tasks | 14,000 | 14,000 | | Webdoc processed | 9.3M | 25M | | Questions generated | 410,755 | 1,192,799 | | Tokens generated | 129,622,944 | 378,591,258 | | Tokens per second | 2,778 | 5,853 | ## ケース3: Tau2-bench — 柔軟性・ネットワーク最適化 - **対象**: Tau2-bench (τ²-bench, Barres et al., 2025a)。dual-control 環境で会話エージェントを評価。AI agent と user simulator が共有ツール/API を介して相互作用。telecom ドメインの customer support トラジェクトリ生成に用いる（フィルタ・reward 検証後に post-training データとして利用）。 - **4エージェント+1オーケストレータの実装**（スライド "Multi-Agent Tool-Use Trajectories"、論文 Figure 7。緑がサービス呼び出し）: - **User-simulator**: 人間ユーザを表現。 - **Assistant**: 推論とツール利用ステップを実行。 - **Tool-executor**: HTTP ベースのツール呼び出しを実行（公式 tau2-agent から適応）。 - **Reward-calculator**: 初期状態から全ツール呼び出しを replay し、DB 状態へのアサーションで task-specific reward を計算（公式 tau2-agent 実装を再利用しベンチ指標と比較可能に）。 - **2通りのオーケストレータ記述法**（スライド "Two Ways to Author Orchestrator"）: 制御フローはコード（imperative な if/else、`update()` で `_current_agent` を遷移）でも、宣言的に **LangGraph**（`StateGraph` + `add_conditional_edges`）でも書ける。後者は線形/グラフベースのパイプラインに既存フレームワークを再利用できる。 - **柔軟性 / Containerized Execution**（スライド "Matrix Flexibility: Containerized Execution"）: Matrix は **Apptainer/Docker** を native サポート。tool-executor と reward-calculator を**公式 Tau2-bench Docker コンテナ内で直接実行**し、コードを書き直さずに HTTP ツール呼び出し・DB 検証・reward 計算の再現性を担保。LLM 推論サービスは **gpt-oss-120b** を使用。 - **スケーラビリティ**（論文 Figure 8）: tau2-agent baseline は単一マシン制約で約 500 スレッドで飽和。P2P-agent はエージェント/コンテナをクラスタ分散し並行性に対しスケール継続。 - **大規模結果**（論文 Table 10、13 H100 ノード、1.5k コンテナ、56 gpt-oss-120b レプリカ）: P2P-agent は tau2-agent baseline 比 **15.4x** 高い tokens/s。reward も同等（0.5918 vs 0.5921）。 | Metric | Baseline | P2P-Agent | |---|---|---| | Runtime | 1:13:41 | 1:15:21 | | Concurrent tasks | 500 | 1,500 | | Total trajectories | 1519 | 22,800 | | Average reward | 0.5918 | 0.5921 | | Tokens generated | 11,080,385 | 185,376,127 | | Tokens per second | 2,654 | 41,003 | - **Message Offloading によるネットワーク最適化**（論文 §4.6, Figure 9/10、スライド "Mitigating Network Congestion via Message Offloading"）: orchestrator が会話履歴を保持するため、エージェント間を流れる大きな会話内容がネットワーク輻輳を起こしうる。Matrix は **512 バイトを超える会話内容を Ray Object Store にオフロード**し（orchestrator は object ID のみ保持、オンデマンドで取得、完了時に削除）。会話サイズ分布（Figure 9）では**約 12% のみが閾値を超え**オフロード対象。これにより**ピークネットワーク利用が約 1 GB/s → 約 760 MB/s（約 20% 削減）**（Figure 10、18:30 前後で有効/無効を比較）。これは通信集約的な将来のマルチモーダルデータ生成に向けてシステムを備えさせる。 ## 結論・限界・将来 - **結論**（スライド "Conclusion"、論文 §6）: Matrix は (1) **Efficient** — P2P 非同期スケジューリングと独立 actor スケーリングで専用 baseline 比 **2〜15x** 高 token throughput、(2) **Flexible** — Coral/NaturalReasoning/Tau2-bench という多様なマルチエージェントワークフローを単一システムで支え Hydra と LangGraph で設定可能、(3) **Open Source** — Ray/vLLM/SGLang/Apptainer 等の OSS 基盤上に構築され `https://github.com/facebookresearch/matrix` で完全公開。中央集権ボトルネックを排し数万の並行エージェントワークフローを実行する。 - **限界**（スライド "Limitations & Future Work"、論文 §6）: - **Serializable State**: per-task orchestrator 状態がシリアライズ可能でエージェント間で受け渡せることを前提とする。 - **Shared Mutable State**: 各ステップが非常に大きな mutable な共有状態を read/write し、データ移動/同期がコストを支配する場合には不向き。 - **Ray Dependency**: Ray actor ランタイムに依存し、その運用上の制約・失敗セマンティクスを継承する。 - **将来研究**: - **Reusable Patterns**: 再利用可能な orchestrator パターンと E2E 例のライブラリを提供しカスタムコードを最小化。 - **Multi-modal Data**: マルチモーダルデータ生成の探求。 - **Continuous Synthesis**: on-policy な連続データ合成の探求。 ## Q&A - 記録された Q&A なし（文字起こしはセッション終了時の雑音のみで、司会がポスターセッションへ誘導してセッションを終了）。