Home 論文解説: MuxServe ― 空間的・時間的多重化による複数LLMの効率的GPUサービング
投稿
キャンセル

📄 論文解説: MuxServe ― 空間的・時間的多重化による複数LLMの効率的GPUサービング

投稿日 28/05/2026
投稿者 0h-n0
19 分読了時間

本記事は arXiv:2401.02954 MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving の解説記事です。

論文概要（Abstract）

MuxServeは、複数のLLMを単一GPU（またはGPUクラスタ）上で効率的にサービングするために、空間的多重化（GPU Streaming Multiprocessorの分割）と時間的多重化（タイムスライス）を組み合わせるシステムである。著者らはリクエスト到着率に基づく配置最適化アルゴリズムを提案し、vLLMとの比較でGPU利用効率を最大1.8倍改善、スループットを最大2.4倍向上させたと報告している。

この記事は Zenn記事: Vertex AIでLLMを本番運用する：カスタムコンテナ・コスト最適化・オートスケーリング実践 の深掘りです。

情報源

  • arXiv ID: 2401.02954
  • URL: https://arxiv.org/abs/2401.02954
  • 著者: Jiangfei Duan, Runyu Lu, Haojie Duanmu, Xiuhong Li, Xingcheng Zhang, Dahua Lin, Ion Stoica, Hao Zhang
  • 発表年: 2024
  • 分野: cs.AI, cs.DC, cs.LG

背景と動機（Background & Motivation）

企業がLLMを運用する場面では、単一のモデルだけでなく、用途に応じた複数のモデルを並行して提供するケースが増加している。例えば、チャットボット向けの対話モデル、要約モデル、コード生成モデルなどを同時に運用する場面である。

従来のアプローチでは各モデルに専用のGPUを割り当てるが、以下の問題がある。

  1. GPU利用率の低さ: 全モデルが常に高負荷であるとは限らず、低トラフィック時にGPUがアイドル状態になる
  2. コストの線形増加: モデル数に比例してGPUコストが増加する
  3. 柔軟性の欠如: トラフィックパターンの変化に対してリソース割り当てを動的に調整できない

著者らは、LLM推論にはprefillフェーズ（計算集約的）とdecodeフェーズ（メモリ帯域集約的）という異なるリソース特性があることに着目し、この特性の違いを多重化に活用している。

主要な貢献（Key Contributions）

  • 貢献1: LLM推論のprefill/decodeフェーズのリソース特性の違いを活用した空間的・時間的多重化フレームワーク
  • 貢献2: リクエスト到着率と各モデルのプロファイリング結果に基づく配置最適化アルゴリズム
  • 貢献3: NVIDIA MPS（Multi-Process Service）を活用したGPU SMレベルの空間分割の実装

技術的詳細（Technical Details）

LLM推論の2フェーズ特性

LLMの推論は以下の2フェーズで構成される。

Prefillフェーズ: 入力プロンプトの全トークンを一括処理し、KVキャッシュを構築する。行列-行列乗算（GEMM）が主要な計算であり、GPUの演算ユニット（SM）を集中的に使用する。

Decodeフェーズ: 1トークンずつ逐次生成する。行列-ベクトル乗算が主要な計算であり、GPUメモリ帯域幅がボトルネックとなる。

この特性の違いにより、prefill中のモデルAとdecode中のモデルBを同一GPUで同時実行しても、リソース競合が小さいという知見が得られる。

空間的多重化（Spatial Multiplexing）

空間的多重化では、GPU上のSM（Streaming Multiprocessor）を複数のモデルに分割する。NVIDIA MPSを使用して、各モデルプロセスに割り当てるSM数を制限する。

\[\sum_{i=1}^{N} s_i \leq S_{\text{total}}\]

ここで、

  • $N$: 同居モデル数
  • $s_i$: モデル$i$に割り当てるSM数
  • $S_{\text{total}}$: GPU上の総SM数

例えば、A100 80GB（108 SM）に2つのモデルを配置する場合、各モデルに54 SMを割り当てる。

時間的多重化（Temporal Multiplexing）

時間的多重化では、同一のSMセットをタイムスライスで複数のモデルが共有する。これは空間的多重化のみでは各モデルのSM数が不足する場合に補完的に使用される。

著者らは、空間的多重化と時間的多重化を組み合わせるハイブリッドアプローチを採用している。prefillフェーズでは空間分割されたSMセットを使用し、decodeフェーズではタイムスライスにより追加のSMを一時的に借用する戦略である。

配置最適化アルゴリズム

各モデルの配置（どのGPUに、どのSM比率で配置するか）を決定するために、著者らは以下の最適化問題を定式化している。

\[\max \sum_{i=1}^{N} \text{throughput}_i(s_i, \lambda_i)\] \[\text{subject to:} \quad \text{latency}_i(s_i, \lambda_i) \leq L_i^{\text{SLO}}, \quad \forall i\]

ここで、

  • $\text{throughput}_i$: モデル$i$のスループット
  • $s_i$: モデル$i$へのSM割り当て
  • $\lambda_i$: モデル$i$のリクエスト到着率（ポアソン分布を仮定）
  • $L_i^{\text{SLO}}$: モデル$i$のSLO（レイテンシ上限）

この問題はNP困難であるため、著者らはヒューリスティックな近似解法を使用している。まず各モデルのprefill/decodeレイテンシをSM数の関数として事前プロファイリングし、そのプロファイル結果を用いて配置候補を列挙・評価する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

def optimize_placement(
    models: list[ModelProfile],
    gpus: list[GPU],
    slo_targets: dict[str, float],
) -> dict[str, Placement]:
    """配置最適化（ヒューリスティック）

    Args:
        models: 各モデルのプロファイル（SM数→レイテンシの関数）
        gpus: 利用可能なGPUリスト
        slo_targets: 各モデルのSLO要件

    Returns:
        モデルID → 配置（GPU ID, SM比率）のマッピング
    """
    placements = {}

    sorted_models = sorted(
        models,
        key=lambda m: m.memory_footprint,
        reverse=True,
    )

    for model in sorted_models:
        best_gpu = None
        best_score = -1

        for gpu in gpus:
            remaining_sm = gpu.total_sm - gpu.allocated_sm
            if remaining_sm < model.min_sm_required:
                continue

            throughput = model.estimate_throughput(remaining_sm)
            latency = model.estimate_latency(remaining_sm)

            if latency > slo_targets[model.id]:
                continue

            score = throughput / remaining_sm
            if score > best_score:
                best_score = score
                best_gpu = gpu

        if best_gpu is not None:
            sm_alloc = min(
                best_gpu.total_sm - best_gpu.allocated_sm,
                model.optimal_sm,
            )
            placements[model.id] = Placement(
                gpu_id=best_gpu.id,
                sm_count=sm_alloc,
            )
            best_gpu.allocated_sm += sm_alloc

    return placements

実装のポイント（Implementation）

NVIDIA MPS: MuxServeはNVIDIA MPSを使用してGPU SMの空間分割を実現している。MPSはGPUコンテキストの切り替えオーバーヘッドを削減し、複数プロセスがGPUを効率的に共有できる。ただし、MPSを有効にするとGPUフォールトアイソレーション（1つのプロセスのクラッシュが他のプロセスに影響する可能性）が弱くなるリスクがある。

プロファイリングフェーズ: 配置最適化の前提として、各モデルのSM数別レイテンシをオフラインで計測する必要がある。著者らは各SM割り当て比率（10%, 20%, …, 100%）でのprefill/decodeレイテンシを計測し、ルックアップテーブルとして保存する方式を採用している。

メモリ管理: 各モデルの重みはGPUメモリ上に常駐させ、KVキャッシュのみを動的に割り当てる。モデル重みのロード・アンロードはコストが高いため、空間的に分割した領域内でのみKVキャッシュを管理する設計となっている。

実験結果（Results）

GPU利用率の改善

著者らはA100 80GB GPUでOPT-13B/30B/66BおよびLLaMA-2-7B/13Bの組み合わせを評価している。

論文のTable 1によると、単一モデル専有サービング（vLLM）との比較で以下の結果が報告されている。

構成GPU利用率改善スループット改善
OPT-13B + OPT-30B1.5倍1.8倍
LLaMA-7B + LLaMA-13B1.8倍2.4倍
OPT-13B + OPT-30B + OPT-66B（3モデル）1.3倍1.6倍

SLO達成率

異なるリクエストレートでのSLO達成率が評価されている。著者らの報告では、リクエストレートが低い場合（各モデル0.5 req/s以下）、MuxServeは既存手法と同等のSLO達成率を維持しつつ、GPUリソースを大幅に削減している。一方、リクエストレートが高くなると（各モデル2 req/s以上）、SM分割のオーバーヘッドによりSLO違反率が増加する傾向が報告されている。

制約事項

著者らは以下の制約を論文中で明記している。

  • モデルサイズの制約: 非常に異なるサイズのモデル（例: 7Bと66B）を同一GPUに配置する場合、大きいモデルへのSM割り当てが不足し、性能劣化が顕著になる
  • MPS依存: NVIDIA MPS使用時のフォールトアイソレーション低下リスク。本番環境では1プロセスのクラッシュが全モデルに波及する可能性がある
  • プロファイリングコスト: 新モデル追加時にオフラインプロファイリングが必要であり、モデル数が増えるとセットアップコストが増大する

実運用への応用（Practical Applications）

Vertex AIのco-hostingとの比較

Vertex AIのモデルco-hostingはコンテナレベルのオーケストレーション（model_cohost_server）を採用しているのに対し、MuxServeはGPU SMレベルの空間分割を行う点が異なる。

特性MuxServeVertex AI co-hosting
分割粒度SM単位GPUメモリ比率単位
実現手段NVIDIA MPSvLLM --gpu-memory-partitions
フォールトアイソレーション低い（MPS制約）中（プロセス分離）
プロファイリング必須（オフライン）不要
適したモデルサイズ同程度のサイズ柔軟

実運用では、Vertex AIのco-hosting方式が運用の容易さで優れる一方、MuxServeの方式はSMレベルの細粒度な制御により理論上の最適化余地が大きい。ワークロードの予測可能性が高く、プロファイリングコストを許容できる環境ではMuxServeのアプローチが有効である。

適用が有効な場面

  • 固定的なモデルセット: デプロイされるモデルが頻繁に変わらず、プロファイリングコストを回収できる
  • 類似サイズのモデル: 7B + 7B、13B + 13Bなど、メモリ要件が近いモデルの組み合わせ
  • SLOに余裕がある: P99レイテンシ要件が緩く、SM分割のオーバーヘッドを許容できる

関連研究（Related Work）

  • vLLM (Kwon et al., SOSP 2023): PagedAttentionによるメモリ効率化。MuxServeのベースラインとして使用されている
  • AlpaServe (Li et al., OSDI 2023): 統計的多重化とモデル並列化によるGPUリソース共有。MuxServeは空間的多重化を追加した点で拡張している
  • FlexLLM (Yin et al., 2024): 推論とファインチューニングの同一GPU上での共存。MuxServeとは異なるタイプのワークロード共存を扱う
  • Vertex AI co-hosting (Nardini et al., 2026): コンテナレベルのアプローチ。MuxServeのSMレベルの分割と対照的

まとめと今後の展望

MuxServeは、LLM推論のprefill/decodeフェーズのリソース特性の違いを活用し、空間的・時間的多重化を組み合わせることで複数LLMの効率的なGPUサービングを実現している。著者らの報告ではGPU利用率を最大1.8倍、スループットを最大2.4倍改善している。

Vertex AIのモデルco-hosting機能と比較すると、MuxServeはより低レベル（SMレベル）の最適化を行うが、プロファイリングコストとMPSのフォールトアイソレーション制約が実運用上の課題となる。クラウドプラットフォームのマネージドサービスとしてはVertex AIのコンテナレベルアプローチが実用的であるが、MuxServeの知見はGPUリソース共有の理論的上限を理解する上で有用である。

参考文献

:::message この記事はAI（Claude Code）により自動生成されました。内容の正確性については原論文に基づいて検証していますが、詳細は原論文もご確認ください。 :::

blog paper arxiv
LLM inference GPU multiplexing co-hosting model-serving vLLM MPS
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次