Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models

Cornserve は、任意のモダリティの入出力を可能とする Any-to-Any マルチモーダルモデルの計算グラフを柔軟に表現し、コンポーネントの分離と独立したスケーリングを実現することで、高いスループットと低いレイテンシを提供する分散推論システムです。

要約

🌽 コーンサーブ（Cornserve）：何でもできる AI のための「超効率的な料理店」

この論文は、**「Cornserve（コーンサーブ）」**という新しいシステムについて紹介しています。名前の「Corn」は、この研究がミシガン大学（トウモロコシの産地）から生まれたことにちなんでいます。

一言で言うと、**「文字、画像、音声、動画など、あらゆるものを混ぜ合わせて理解し、何でも作れる最新の AI（マルチモーダルモデル）を、もっと速く、安く、スムーズに動かすための仕組み」**です。

---

🍽️ 従来の問題点：「万能料理人」の限界

昔の AI（例えば、文字だけを書く AI）は、**「一人の天才シェフ」**がすべての注文をこなしていました。
しかし、最新の「何でもできる AI（Any-to-Any モデル）」は、以下のような複雑な注文をします。

• 「この写真を見て、その雰囲気を説明して（画像→文字）」
• 「この文章を読んで、それを歌にして（文字→音声）」
• 「この動画を見て、その続きをシナリオと音声で書いて（動画→文字＋音声）」

【従来のシステムの悩み】
従来のシステムは、この「万能シェフ」を 1 人だけ雇って、すべての注文を順番に処理させようとしていました。

• 問題点 1： 注文によって使う道具（計算リソース）が違います。画像処理には重い道具、音声生成には別の道具が必要です。
• 問題点 2： 1 人のシェフが「画像処理」をしている間、他の「音声生成」の道具はただ待っているだけで、無駄な時間（リソース）が発生します。
• 問題点 3： 注文が混雑すると、シェフがパンクして、料理が出るまでがものすごく遅くなります。

---

🚀 コーンサーブの解決策：「分業制のキッチン」

Cornserve は、この「万能シェフ 1 人」方式を捨て、**「分業制のキッチン」**に変えるアイデアです。

1. 料理の工程をバラバラにする（モデルの分割）

AI の計算過程を、**「画像を見る担当」「文章を考える担当」「音を作る担当」**といった小さなチーム（コンポーネント）に分けます。

• 例： 写真を見て文章を書く注文なら、「画像担当」→「文章担当」だけを使います。
• 例： 文章を歌にする注文なら、「文章担当」→「音担当」だけを使います。

これにより、**「使わない担当チームは休ませておける」**ので、リソースの無駄がなくなります。

2. 注文の記録と再生（Record-and-Replay）

これが Cornserve の一番すごい技術です。
厨房のマネージャーは、注文が来るたびに「どの担当チームを、どの順番で呼べばいいか」を瞬時に判断する必要があります。しかし、注文は複雑で、その都度変わります。

• 記録フェーズ： まず、注文を「仮の料理」で通します。この時、実際の料理は作らず、「誰が、誰に、何を渡したか」という**「レシピのメモ（記録）」**だけを取ります。
• 再生フェーズ： そのメモを見ながら、実際に必要な担当チームに「本物の料理」を作らせます。

これにより、複雑な注文でも、「必要な人だけ」を正確に呼び出して、並行して作業させることができます。

3. 食材の直接配送（データ転送）

担当チームが別の部屋（別の GPU サーバー）にいる場合、食材（データ）を運ぶ必要があります。
Cornserve は、この食材の配送を**「直接配送」**にします。

• 従来の方法：食材を一度「注文受付カウンター（制御盤）」に預けてから、担当者に渡す（遅い）。
• Cornserve の方法：食材を**「担当者の手元」に直接、高速道路（RDMA）や共有倉庫（共有メモリ）で送る**。

これにより、食材の移動時間が劇的に短縮されます。

---

📊 どれくらい速くなったの？（実験結果）

Cornserve を使った実験では、以下のような驚異的な成果が出ました。

• 処理速度（スループット）： 最大で約 3.8 倍速くなりました。
  • 例え話： 1 時間で 100 食作れていたのが、同じ時間で 380 食作れるようになったイメージです。
• 待ち時間（レイテンシ）： 最も遅い注文（遅延）が最大で約 5.8 倍短くなりました。
  • 例え話： 注文してから料理が出るまでの「最悪の待ち時間」が、劇的に改善されました。

特に、**「音声生成」**のような重い処理が必要な場合、従来のシステムではメモリ不足で動けなかったものが、Cornserve ならスムーズに動くようになりました。

---

🌟 まとめ

Cornserve は、「何でもできる AI」を動かすための、究極の分業システムです。

• 昔： 1 人の万能シェフが、すべての注文を順番にこなす（遅い、疲れる）。
• 今（Cornserve）： 専門家のチームに分け、必要な人だけを集めて、食材を直接手渡しで渡す（速い、効率的）。

このシステムがオープンソース（誰でも使える状態）で公開されているので、今後、もっと複雑で面白い AI アプリケーションが、私たちの生活にどんどん登場してくるでしょう。

「AI の料理店」が、Cornserve によって、より美味しく、早く、安くなるのです！ 🍿🎤📸

技術概要

Cornserve: 任意のマルチモーダルモデル向け分散推論システムの技術的概要

本論文は、テキスト、画像、動画、音声など、あらゆる組み合わせの入力・出力を扱える「Any-to-Any モデル」の推論を効率的に行うための分散推論システムCornserveを提案しています。既存のシステムは特定のモデル構造やモダリティに特化しているため、複雑な計算グラフを持つ汎用的な Any-to-Any モデルを効率的にスケールさせることが困難でした。Cornserve は、この課題を解決し、最大で 3.81 倍のスループット向上と 5.79 倍のレイテンシ（遅延）低減を実現しました。

以下に、問題定義、手法、主要な貢献、評価結果、および意義について詳細をまとめます。

---

1. 背景と課題 (Problem)

Any-to-Any モデル（例：Qwen Omni, InternVL 3 など）は、多様なモダリティの入力を処理し、多様なモダリティの出力を生成する新しいクラスのモデルです。しかし、これらを推論（サービング）する際には以下の 2 つの大きな課題が存在します。

1. リクエストと計算経路の多様性 (Heterogeneity of Request & Path)

   • 入力・出力のモダリティの組み合わせによって、モデル内で実行されるコンポーネントの順序や経路が異なります。
   • 例：Qwen Omni において、音声出力を要求するリクエストは「エンコーダ → 思考用 LLM → 発話用 LLM → 音声生成器」という経路をたどりますが、テキスト出力のみなら「発話用 LLM」や「音声生成器」を経由しません。
   • 既存のシステムは単一の計算グラフを想定しており、動的な経路変化への対応が困難です。

2. コンポーネント間のスケーリング特性の違い (Heterogeneity of Scaling)

   • モデルを構成する各コンポーネント（エンコーダ、LLM、生成器など）は、GPU 上のスループットやリソース要件が全く異なります。
   • 例：同じ A100 GPU 上でも、テキスト生成コンポーネントは音声生成コンポーネントの 4 倍のスループットを達成します。
   • 従来のモノリシック（単一）デプロイメントでは、最も遅いコンポーネントがボトルネックとなり、他の高速なコンポーネントの能力が活かせません。

2. システム設計と手法 (Methodology)

Cornserve は、Kubernetes ベースで構築された分散システムであり、以下の 3 つの主要な機能を提供します。

2.1 柔軟なタスク抽象化 (Flexible Task Abstraction)

開発者が任意の計算グラフを素の Python コードで記述できるように設計されています。

• Unit Task: エンコーダ、LLM、生成器などの原子となるモデルコンポーネント。
• Composite Task: 複数の Unit Task を組み合わせてモデル全体の計算ロジックを定義するクラス。
• App: 複数のタスクをインスタンス化し、非同期関数 serve をエントリポイントとして定義するモジュール。
  これにより、ループや分岐を含む複雑な制御フローを持つモデルも Python だけで表現可能です。

2.2 モデルの分割 (Model Fission)

モデルをコンポーネント境界で分割し、それぞれを独立してスケーリング可能なコンポーネントとしてデプロイします。

• コンポーネントの独立スケーリング: 各コンポーネントを専用 GPU で実行し、負荷に応じてレプリカ数を動的に調整できます（例：音声生成器を多数レプリケートし、LLM をテンソル並列化で実行）。
• コンポーネント共有: 異なるモデル間で同じエンコーダなどが使われる場合、Cornserve は単一の Task Manager と Executor を共有し、GPU 使用量を削減します。

2.3 分散ランタイムと Record-and-Replay 実行モデル

動的な計算グラフを効率的に実行するための核心技術です。

1. Record 段階: リクエストを受け取ると、実際の計算を行わずに、どのコンポーネントが呼び出され、データ依存関係がどうなるかを「記録」します。この段階ではプレースホルダーが返されます。
2. Dispatch: 記録された計算グラフ（サブグラフ）に基づき、タスクディスパッチャが各コンポーネントを適切な Executor に割り当てます。
3. Replay 段階: 実際の計算を実行し、Record 段階で決定された経路に従って結果を生成します。
   これにより、制御フローに依存する複雑なロジックを、開発者が明示的にグラフを定義することなくサポートします。

2.4 効率的なデータ転送 (Data Forwarding)

• Sidecar: GPU ごとに動作するデーモンプロセス。コンポーネント間のテンソルデータを転送します。
• 転送方式:
  • 同一ノード内：Linux 共有メモリ (/dev/shm) を使用し、NVLink/NVSwitch の帯域幅を消費しないようにします。
  • 異ノード間：RDMA (UCX ライブラリ) を使用します。
• これにより、制御プレーンを経由せず、プロデューサからコンシューマへ直接データが転送されます。

3. 主要な貢献 (Key Contributions)

1. 汎用的な Any-to-Any モデル向け初の分散サービングシステム:
   特定のモデルアーキテクチャに依存せず、任意の計算グラフを持つマルチモーダルモデルを支援する最初のシステムです。
2. Python ベースの直感的な抽象化:
   複雑な分散ロジックを隠蔽し、開発者が Python コードでモデルの計算グラフを自然に記述できる仕組みを提供しました。
3. 高度な最適化技術:
   • モデルの分割による独立スケーリング。
   • 共有コンポーネントの自動検出と共有。
   • Record-and-Replay による動的経路の効率的な実行。
   • 共有メモリ/RDMA を活用した低オーバーヘッドなデータ転送。

4. 評価結果 (Results)

実験は、80GB メモリ搭載の NVIDIA A100 GPU を 8 台および 16 台搭載した 2 ノード環境で実施され、Qwen 2.5 Omni および Qwen 3 Omni を対象に評価されました。

• スループット (Throughput):

  • Qwen 2.5 Omni: 8 GPU 環境で 3.09 倍、16 GPU 環境で3.81 倍のスループット向上。
  • Qwen 3 Omni: モノリシック構成では GPU メモリ不足 (OOM) で実行不可能でしたが、Cornserve のモデル分割により正常に実行可能となり、効率的なサービングを実現しました。
  • 16 GPU へのスケーリングでは、単純な 2 倍を超えた 2.68 倍の向上が見られ、コンポーネント間の負荷分散が効果的であったことを示しています。

• レイテンシ (Latency):

  • 16 GPU 環境での Qwen 2.5 Omni において、P50, P95, P99 遅延がそれぞれ 3.24 倍、5.3 倍、5.79 倍改善されました。
  • 要因：モノリシック構成ではコンポーネントが直列実行されブロックが発生しますが、Cornserve では並列実行が可能になり、また音声生成器の連続バッチ処理（Continuous Batching）が実現されたためです。

• オーバーヘッド:

  • Sidecar によるデータ転送のオーバーヘッドは最小限に抑えられており（8MB テンソルで 5-10ms）、ボトルネックにはなっていません。

5. 意義と将来展望 (Significance)

Cornserve は、マルチモーダル AI の進化に伴い不可欠となる「任意の入出力モダリティを扱うモデル」のインフラ基盤を提供します。

• 開発の民主化: 複雑な分散システムを構築する専門知識がなくても、Python で任意のマルチモーダルモデルを効率的にデプロイ可能にします。
• リソース効率: モデルの特性に応じたきめ細やかなリソース配分により、GPU コストを大幅に削減できます。
• 将来の研究基盤: より高度で複雑な Any-to-Any モデルの開発を加速させ、マルチモーダル AI の実用化を促進する基盤技術となります。

Cornserve はオープンソースとして公開されており、Kubernetes 上で動作する実用的なシステムとして、今後のマルチモーダル推論サービスの標準的なアプローチとなる可能性があります。