More GPUs or a Smaller Cache? Tensor Parallelism versus KV Compression for Memory-Bound LLM Serving

テクニカル・サマリー：GPUの増設か、キャッシュの削減か？ メモリ制約のあるLLMサービングにおけるテンソル並列化とKV圧縮の比較

問題提起
大規模言語モデル（LLM）のサービング展開において、長いコンテキストや大きなバッチサイズによってメモリ制約に直面した際、実務者はこれまでほとんど連携されてこなかった2つの確立された戦略の間で、二者択一の選択を迫られる。

1. テンソル並列化（システム・コミュニティ）: モデルの重みとKVキャッシュを複数のGPUに分割（シャーディング）する。これによりメモリの余白は増えるが、ハードウェアコストが線形に増加し、各レイヤーで通信オーバーヘッド（all-reduce）が発生する。
2. KV圧縮（アルゴリズム・コミュニティ）: 量子化（例：8ビット、4ビット）や蒸発（高価値なトークンのみを保持）を通じて、単一GPU上のKVキャッシュのフットプリントを削減する。これはハードウェアコストを回避できるが、生成品質の低下とデクオンタイゼーション（逆量子化）のオーバーヘッドを伴う。

核心となる問題は、コスト正規化された比較が欠如していることである。並列化に関する論文はスループットのスケーリングを報告し、圧縮に関する論文はメモリの比率を報告する。その結果、エンジニアは、固定されたモデル、品質の閾値、およびレイテンシ目標に対して、どちらの戦略がより安価であるかを判断することができない。

手法
著者らは、これらの戦略を直接比較するために、コスト正規化されたフロンティアを構築した。

• シミュレーション・バックボーン: 本研究では、実機のA100、A40、H100ハードウェアに基づいてプロファイリングされたシミュレータであるVidurを利用している。著者らは直接的なGPUアクセスを持っておらず、レイテンシとスループットはVidurの予測器から導出されている（実機と比較して誤差9%未満で検証済み）。
• コスト指標: 主な軸は、以下の**100万トークンあたりのコスト（Cost per Million Tokens）**である：
  $$\text{Cost/Mtok} = \frac{C_{gpu/hr} \times p}{3600 \times \text{Throughput} \times 10^6}$$
  ここで、$p$ はテンソル並列度である。決定的なことに、デバイス数の乗数 $p$ が含まれており、GPUを追加することが「無料」のメモリ増設として扱われないよう保証されている。
• 実験設定:
  • モデル: Llama-2-7B（主要）および Llama-2-70B（実現可能性の限界をテストするため）。
  • 構成: テンソル並列度（TP）1, 2, 4, 8。KV圧縮の設定には、ビット幅（16, 8, 4）および保持率（1.0, 0.5, 0.25）が含まれる。
  • ワークロード: 正確なメモリ算術を確保するため、合成された固定長ワークロード（W1: インタラクティブ、W2: プリフィル重視/飽和状態）を使用。
  • 実現可能性チェック: 構成が有効であるためには、重みとKVキャッシュの両方がデバイスメモリ内に収まる必要がある（$2W/p + B \cdot m_{kv} \le M_{dev}$）。
• 制約: 本研究では、出力品質（精度）を評価せず、デクオンタイゼーションの特定のカーネルレベルのレイテンシもモデリングしていない。後者は、堅牢性をテストするための「ベストケース」シナリオとして扱っている。

主な結果
中心的な知見は、テストされた領域内において、コストの等価性が成立するクロスオーバーポイントは存在しないということである。2つの戦略が単一のコスト曲線上で競合するという前提は無効である。

1. 実現可能性の壁の下では圧縮が優位:

   • 単一GPUに収まるモデル（例：80GB A100上のLlama-2-7B）の場合、KV圧縮はGPUを追加するよりも一貫して安価である。
   • 同等のメモリ解放レベルにおいて、圧縮はテンソル並列化よりも1.20倍から2.00倍安価である。
   • 容量 vs レイテンシ: 圧縮は、1ドルあたりの同時実行容量を16.5倍にするが、テンソル並列化（TP=8）による8倍の支出増は、1ドルあたりの容量を1.21倍しか向上させない。
   • レイテンシのトレードオフ: 圧縮はコストを削減する一方で、バッチ処理の競合により、トークンあたりのレイテンシ（TPOT）を**8%から93%**悪化させる。テンソル並列化は、レイテンシと容量の両方を改善できる唯一の手段である。

2. 実現可能性の壁（モデルサイズ vs デバイスメモリ）:

   • 決定境界は、コンテキスト長やバッチサイズではなく、デバイスメモリに対するモデルサイズである。
   • 80GBのデバイスにおいて、壁は約36Bパラメータ（fp16重み）にある。
   • 壁の下（例：7B）: KVキャッシュがコンテキストウィンドウ内でデバイスメモリを使い果たすことは稀である。GPUを追加することは主に無駄な支出であり、圧縮が最適な戦略である。
   • 壁の上（例：70B）: 単一GPUでは重みを保持できない（Llama-2-70Bは127.5 GB）。KV圧縮は重みを縮小しないため、この問題を解決できない。テンソル並列化は、選択肢ではなく**入場券（必須事項）**となる。

3. 壁の上での挙動:

   • Llama-2-70Bの場合、最小限の実現可能なTP度数（TP=2）であっても、システムはメモリ飽和状態にある。
   • この領域では、TPを2から4に上げることで、結合メモリ制約が緩和されるため、超線形なスケーリング（効率169%）が得られ、インタラクティブなワークロードにおいてトークンあたりのコストが41%減少する。
   • しかし、同等のメモリ解放レベルにおいては、さらなるスケーリング（例：TP=8）よりも圧縮の方が依然として安価である。

意義と主張
本論文は、コンテキスト長が長くなるとテンソル並列化の方が安価になるという一般的な仮定を正し、インフラ計画のための決定的な意思決定ルールを提供すると主張している。

• クロスオーバーの反証: 著者らは、追加のGPUが圧縮よりも安価になるクロスオーバーポイントは見つからなかったと明言している。あらゆるレベルのメモリ解放において、圧縮の方が安価である。
• 真の意思決定ルール:
  1. 実現可能性を確認する: モデルの重みがデバイスメモリを超える場合（例：80GBに対して>36B）、テンソル並列化は必須である（$p_{min} = \lceil 2W/M_{usable} \rceil$）。
  2. 飽和を確認する: 最小限の実現可能なTP度数（$p_{min}$）においてメモリ飽和（高いKV占有率）が発生する場合、TP度数を一段階上げる（例：TP=2からTP=4）ことで、トークンあたりのコストを下げられる可能性がある。
  3. 容量を最適化する: 重みが収まり、システムがメモリ飽和していない場合、KV圧縮が容量を増やすための支配的な戦略となる。GPUを追加することは非効率である。
• 補完的なメカニズム: これら2つの戦略は、異なるものを購入する。テンソル並列化はレイテンシと実現可能性（重みの分割）を購入する。圧縮は、ハードウェアコストをほぼゼロにして容量（同時実行性）を購入する。

認められた限界
著者らは、本研究が（デクオンタイゼーションのオーバーヘッドをモデル化せずに）圧縮のレイテンシをシミュレーションに依存していること、および出力品質を測定していないことを認めている。もしデクオンタイゼーションのオーバーヘッドが大幅に高く（スループットの17〜47%の損失）、現在の文献が示唆するよりも大きい場合、順序が逆転する可能性がある。ただし、現在の文献ではオーバーヘッドはより低いことが示唆されている。また、「実現可能性の壁」はfp16重みに特有のものである。重みの量子化を行えば、この境界は移動する。