SUN: Shared Use of Next-token Prediction for Efficient Multi-LLM Disaggregated Serving

この論文は、マルチモデル LLM 推論におけるデコード実行の非効率性を解消するため、タスク固有のプレフィルモジュールのみを微調整し、デコードモジュールをモデル間で共有する「SUN」という手法を提案し、GPU 利用率とスループットを大幅に向上させることを示しています。

要約

🍽️ 背景：今の AI 世界の「非効率なレストラン」

まず、今の AI サービス（チャットボットや翻訳など）がどう動いているか想像してみてください。

• AI モデル = 料理人
• ユーザーの質問 = 注文
• GPU（高性能な計算機） = 厨房のコンロ

今のシステムでは、**「料理人ごとに、専用のコンロと助手を割り当てている」**状態です。
例えば、「数学が得意な AI」「プログラミングが得意な AI」「法律が得意な AI」がそれぞれ別々の厨房にいます。

ここには 2 つの大きな問題があります。

1. 混雑と空転（偏り）
   • 人気のある「数学 AI」の厨房は注文が殺到してパンクしますが、マイナーな「法律 AI」の厨房は暇すぎて、コンロが空回りしています。
   • 結果として、**「忙しい人はもっと忙しく、暇な人はもっと暇」**という無駄が生まれます。
2. 作業の邪魔（プレフィルとデコードの干渉）
   • AI は「質問を読んで理解する（プレフィル）」と「答えを 1 文字ずつ書く（デコード）」の 2 つの作業をします。
   • これらを同じコンロでやると、理解中に書く作業が入り込んでしまい、**「料理の完成が遅くなる」**という問題があります。

---

☀️ 解決策：SUN（サン）のアイデア

この論文が提案する**「SUN（Shared Use of Next-token Prediction）」**は、この非効率を解決する魔法のようなシステムです。

1. 「料理人」を 2 人に分ける（モジュールの分解）

SUN は、1 人の料理人を 2 人の役割に分けます。

• A さん（プレフィル担当）： 注文（質問）を読んで、**「何を作るかのレシピ（メモ）」**を書く人。
  • 特徴： 料理によってレシピが変わるので、「数学用」「法律用」など、それぞれの専門家に特化させます。
• B さん（デコード担当）： レシピを見て、**「実際に料理（答え）を 1 文字ずつ作る」**人。
  • 特徴： どの料理でも「包丁の使い方」や「火加減」は同じです。だから、「1 人の万能な B さん」を全員で共有します。

2. 共有された「B さん」を効率よく使う（デコードの共有）

これが SUN の最大の特徴です。

• 従来の方法： 数学 AI には数学用の B さん、法律 AI には法律用の B さんが付いています。数学 AI が忙しくても、法律 AI の B さんは手伝えません。
• SUN の方法： 数学 AI の A さんが作った「レシピ」を、共有されている「B さん」に渡します。
  • 結果、「数学が得意な A さん」と「法律が得意な A さん」が、同じ「B さん」のチームで働けるようになります。
  • 注文が偏っても、B さんたちは「今、誰の料理が必要か」を気にせず、**「空いている B さんが次の料理を作る」**というように、全員で力を合わせて作業できます。

🚕 アナロジー：タクシーの相乗り

• 今： 数学の先生と法律の先生が、それぞれ**「専用タクシー」**を 1 台ずつチャーターしています。先生が 1 人しか乗っていなくても、タクシーは 1 台丸ごと使われます（無駄！）。
• SUN： 先生たちはそれぞれ**「専用バス停（A さん）」で待ちますが、「共有されたタクシー（B さん）」**が来るまで待ちます。
  • 数学の先生が乗るべきタクシーが空いていなくても、法律の先生のタクシーが空いていれば、そのタクシーに乗せてもらえます。
  • タクシー（GPU）の稼働率が上がり、必要なタクシーの台数（コスト）を減らせるのです。

---

🎯 SUN が実現した 3 つのすごいこと

1. 精度は落ちない（「レシピ」を調整する）

   • 「B さん（共有部分）」を固定したまま、「A さん（専門部分）」だけを勉強させます。
   • これにより、A さんは「B さんが読めるように、完璧なレシピ」を書くようになります。
   • 結果、**「全員で共有しても、個別に勉強したのと同じくらい上手に料理ができる」**ことが証明されました。

2. コストが半分以下に（GPU 節約）

   • 従来のシステムでは、モデルごとに GPU を用意していましたが、SUN では**「共有プール」**にまとめられます。
   • 実験では、必要な GPU の数を 50% 減らしても、同じくらいの処理能力を維持できました。つまり、電気代や設備費が激安になります。

3. さらに高速化（QSUN：量子化 SUN）

   • さらに、共有する「B さん」の道具（重み）を、少し簡易なもの（低精度）に置き換える実験もしました。
   • これでも「A さん」が少しだけ練習（再学習）すれば、**「道具を簡易化しても、味はほとんど変わらない」どころか、「調理スピードが 45% 向上」**しました。

---

🌟 まとめ

SUNは、「専門家の頭脳（A さん）」と「作業の手（B さん）」を分けて、作業の手を全員で共有するというアイデアです。

• 今までの問題： 忙しすぎる人と暇な人がいて、機械（GPU）がもったいない。
• SUN の解決： 作業の手を共有して、**「忙しくても、みんなで助け合いながら効率よく」**動かす。

これにより、**「AI をもっと安く、もっと速く、もっと多くの人に使わせる」ことが可能になります。まるで、「高級レストランが、同じ厨房で何種類もの料理を、無駄なく大量に作れるようになった」**ようなものです。

技術概要

SUN: 分散型マルチ LLM サービングにおける効率的な次トークン予測の共有

本論文「SUN: Shared Use of Next-token Prediction for Efficient Multi-LLM Disaggregated Serving」は、NAVER Cloud の研究チームによって提案された、大規模言語モデル（LLM）の分散型サービングにおける新たなアーキテクチャと最適化手法です。以下に、論文の技術的要点を問題定義、手法、主要な貢献、実験結果、および意義の観点から詳細にまとめます。

1. 背景と問題定義

近年、汎用チャットボットから、特定のドメインに特化したモデルや、複数の専門モデルが協調するエージェント型 AI ワークフローへの移行が進んでいます。これに伴い、サービスプロバイダーは数十から数百の専門 LLM を同時に展開・サービングする「マルチ LLM サービング」の課題に直面しています。

既存の分散型サービング（Disaggregated Serving）技術（例：DistServe）は、モデル内の「プリフィル（入力処理）」と「デコード（トークン生成）」のフェーズを異なるデバイスに分離することで、フェーズ間の干渉を解消し、スループットを向上させています。しかし、**マルチモデル環境における「モデル間アイソレーション（分離）」**という新たなボトルネックが残っていました。

• リソースの断片化: 従来の分散型サービングでは、各モデルごとに専用のデコードワーカー（GPU）が割り当てられます。
• 非効率なリソース利用: トラフィックが偏っている（Skewed）現実世界のワークロードでは、人気モデルはキューが溢れる一方で、人気がないモデルの GPU は遊休状態になります。
• バッチ化の限界: デコードフェーズはメモリ帯域幅に制約される（Memory-bound）ため、GPU 利用率が低くなりがちです。しかし、モデルごとにリソースが分離されているため、異なるモデル間でのデコードリクエストのバッチ化（Cross-model batching）が不可能であり、GPU 利用率の改善が困難でした。

2. 提案手法：SUN (Shared Use of Next-token Prediction)

SUN は、このモデル間アイソレーションを解消し、複数の特化モデル間でデコード実行を共有することを可能にするアルゴリズムです。

2.1. 基本的なアプローチ

SUN は、デコーダ専用の Transformer モデルを以下の 2 つのモジュールに分解します。

1. プリフィルモジュール: プロンプトから KV キャッシュを生成する。
2. デコードモジュール: KV キャッシュと直前のトークンから次のトークンを生成する。

2.2. プリフィルのみによる微調整 (Prefill-Only Tuning)

SUN の核心は、**「タスク固有のプリフィルモジュールのみを微調整し、デコードモジュールは凍結（Frozen）して共有する」**という戦略です。

• 共有デコード: 全タスクで同じパラメータを持つ 1 つのデコードモジュールを使用します。
• タスク適応: 各タスク（数学、コーディング、ツール呼び出しなど）に対して、そのタスクに特化したプリフィルモジュールのみを微調整します。
• KV キャッシュの互換性: 従来のナティブな共有（ベースモデルの KV キャッシュをそのまま使う）では精度が大幅に低下しますが、SUN はプリフィルモジュールを微調整することで、共有されたデコードモジュールが正しく解釈できる「タスク適応型かつデコーダ互換性のある KV キャッシュ」を生成できるように学習させます。これにより、フル微調整（Full Fine-tuning）と同等の精度を維持しつつ、デコードリソースを共有できます。

2.3. モデル非依存のデコードルーティング

デコードフェーズでは、リクエストの送信元モデルを識別せず、共有されたデコードワーカープールに対してロードバランシングを行います。これにより、人気モデルと不人気モデルのトラフィック偏りを吸収し、GPU 利用率を最大化します。

2.4. 量子化版 SUN (QSUN)

さらに、デコードフェーズはメモリ帯域幅がボトルネックであるため、**デコードモジュールのみを重み量子化（Weight-only Quantization、例：4-bit）**し、プリフィルモジュールは高精度（16-bit）のまま維持する「QSUN」を提案しています。

• 量子化による精度低下を補うため、量子化されたデコードモジュールに対して再度「プリフィルのみ」の再微調整（Re-tuning）を行います。
• これにより、量子化による遅延削減効果を活かしつつ、精度を回復させます。

3. 主要な貢献

1. ロバストなモデル間デコード共有: 初となる、プリフィルのみ微調整を通じて複数のタスク固有モデル間で単一の凍結デコードモジュールを共有するアルゴリズムを提案。多様なタスクとモデル規模において、フル微調整と同等の精度を維持。
2. 高利用率のためのモデル非依存ルーティング: 共有ワーカー間でのデコードリクエストのロードバランシングを実現し、分散型サービング環境（vLLM ベース）において、デコード GPU を 50% 削減してもシステムスループットを維持。偏ったワークロード下でも遅延オーバーヘッドを無視できるレベルに抑える。
3. 精度を維持する量子化デコード: 共有デコードモジュールへの重み量子化とプリフィル再微調整を組み合わせた QSUN を提案。45% の高速化を実現しつつ、フル精度 SUN と同等の精度を回復し、AWQ などの既存手法を上回る性能を発揮。

4. 実験結果

実験は vLLM ベースの分散型サービング環境（DGX A100 ノード、8 GPU）で実施され、LLaMA3.1-8B や Qwen3 シリーズなどのモデルで評価されました。

• 精度: SUN は、数学（GSM8K）、コーディング（HumanEval）、ツール呼び出し（BFCL）などの多様なベンチマークにおいて、フル微調整（Full-FT）と同等、あるいはそれ以上の精度を達成しました（例：LLaMA3.1-8B で HumanEval は 48.2 → 49.4 に向上）。
• スループットと GPU 効率:
  • 従来の分散型サービング（モデルごとに 1 GPU 割り当て）と比較して、SUN はデコード GPU を削減（例：4 GPU から 2 GPU へ）しても、システム全体のスループットを維持しました。
  • 偏ったワークロード（Skewed workloads）下では、SUN は 1 GPU あたりのスループットを最大 2.0 倍 向上させました。
  • 出力トークンあたりの時間（TPOT）は、ベースラインに対して 5% 以内の劣化に抑えられています。
• QSUN の性能:
  • 量子化（4-bit）を適用した QSUN は、16-bit の Full-FT ベースラインと比較して TPOT を最大 45% 削減しました。
  • 精度面では、量子化による低下をプリフィル再微調整で回復し、AWQ（両フェーズ量子化）よりも高い精度と TTFT（First Token までの時間）を達成しました。

5. 意義と結論

SUN は、マルチ LLM サービングにおける「モデル間アイソレーション」という根本的な課題を解決する画期的なアプローチです。

• TCO（総所有コスト）の削減: 高価な HBM を搭載した GPU を効率的に利用し、必要な GPU 数を削減することで、運用コストを大幅に下げることができます。
• 実世界での適用性: トラフィックが偏っている現実のユースケース（エージェントワークフローや専門モデルの混在）において、リソースの断片化を防ぎ、安定した低遅延サービスを提供します。
• システムとモデルの共設計: モデルの構造分解（プリフィル/デコード）と、システムレベルのリソース共有（分散型サービング）を密接に連携させることで、両者の利点を最大化しています。

結論として、SUN はマルチモデル環境における LLM サービングの効率性を飛躍的に向上させ、大規模な専門モデル群の展開を現実的かつ経済的に可能にする重要な技術です。