# SCBench: A KV Cache-Centric Analysis of Long-Context Methods > [!abstract] > 長コンテキスト大規模言語モデル（LLM）は多様なアプリケーションを可能にする一方、計算とメモリ効率に関して重大な課題をもたらした。 > これらの課題に対処するため、KV キャッシュを中心とした長コンテキスト推論の最適化が開発されてきた。 > しかし既存ベンチマークは単一リクエストでの評価にとどまっており、実世界における KV キャッシュのライフサイクル全体を反映できていない。 > この見落としは特に重大であり、KV キャッシュ再利用（プレフィックス・キャッシング）は vLLM・SGLang 等の推論フレームワークや OpenAI・Microsoft・Google・Anthropic 等のプロバイダですでに広く採用されているためだ。 > このギャップを埋めるべく、本論文では SCBench（SharedContextBench）を提案する。 > SCBench は KV キャッシュ中心の観点から長コンテキスト手法を評価する包括的ベンチマークであり、①KV キャッシュ生成、②KV キャッシュ圧縮、③KV キャッシュ検索、④KV キャッシュローディングの 4 段階を対象とする。 > SCBench は共有コンテキストを持つテスト例を用い、2 つの共有コンテキストモードで 12 タスクをカバーし、文字列検索・意味的検索・グローバル情報・マルチタスクの 4 能力カテゴリを評価する。 > SCBench を用いて 8 カテゴリの長コンテキスト手法（ゲート線形 RNN の Codestral-Mamba、Mamba-アテンション・ハイブリッドの Jamba-1.5-Mini、スパース・アテンション・KV キャッシュ破棄・量子化・検索・ローディング・プロンプト圧縮）を 6 つの Transformer ベース長コンテキスト LLM 上で広範に分析した。 > 主要な知見として、sub-O(n) メモリ手法はマルチターンシナリオで苦戦し、O(n) メモリかつ sub-O(n²) プリフィリング計算のスパース符号化が堅牢に動作することが示された。 > 動的スパース性は静的パターンより表現豊かな KV キャッシュをもたらし、ハイブリッド・アーキテクチャのレイヤーレベル・スパース性は高い性能を維持しながらメモリ使用量を削減する。 > さらに、長生成シナリオにおけるアテンション分布シフト問題を同定した。 ## 論文情報 | 項目 | 内容 | |------|------| | 会議 | ICLR 2025 | | arXiv | 2412.10319 | | 著者 | [[Yucheng Li]]†, [[Huiqiang Jiang]]‡, Qianhui Wu, Xufang Luo, Surin Ahn, Chengruidong Zhang, Amir H. Abdi, Dongsheng Li, Jianfeng Gao, Yuqing Yang, Lili Qiu | | 所属 | [[Microsoft]]（主）, [[University of Surrey]]（† Yucheng Li はインターン中） | | URL | https://arxiv.org/abs/2412.10319 / https://aka.ms/SCBench | | ‡ 責任著者 | Huiqiang Jiang | ## 概要 長コンテキスト LLM の推論効率化手法は、KV キャッシュのライフサイクルを軸に 4 段階に整理できる。しかし従来の評価はすべて単一リクエスト設定であり、実際のプロダクション環境で広く使われる KV キャッシュ再利用（プレフィックス・キャッシング）を模擬していなかった。本論文は [[SCBench]] というベンチマークを提案し、マルチターン・マルチリクエストの共有コンテキスト設定で 8 カテゴリ・13 手法・8 LLM を評価した最初の包括的分析を提供する。 ## 問題設定 ### 既存ベンチマークの KV キャッシュライフサイクル不足 LLM 推論で KV キャッシュは復号フェーズの計算コストを大幅に削減するが、長コンテキスト入力では GPU メモリを圧迫するため多様な圧縮・スパース化が提案されている。従来の評価ベンチマーク（LongBench・InfiniteBench・RULER・HELMET 等）はいずれも単一リクエスト評価に限定されており、以下の実世界パターンを捉えていなかった。 1. **マルチターン**：単一セッション内で同じ長コンテキストを参照しながら複数回クエリする（チャット・CoT 推論等） 2. **マルチリクエスト**：複数セッション・複数ユーザが同じ長コンテキストの KV キャッシュを共有する（コードリポジトリ共同作業等） KV キャッシュ再利用はすでに vLLM の RadixAttention・SGLang や OpenAI・Microsoft Azure・Google Gemini・Anthropic Claude が本番採用しており、この評価空白は実用上の大きな問題だった。 ### 従来ベンチマークとの比較 | ベンチマーク | 正確な検索 | 意味的検索 | グローバル情報 | マルチタスク | マルチターン | マルチリクエスト | KV キャッシュ再利用 | |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | LongBench | — | ✓ | ✓ | — | — | — | — | | InfiniteBench | ✓ | ✓ | ✓ | — | — | — | — | | RULER | ✓ | ✓ | ✓ | — | — | — | — | | HELMET | ✓ | ✓ | ✓ | — | — | — | — | | **SCBench** | **✓** | **✓** | **✓** | **✓** | **✓** | **✓** | **✓** | ## 提案手法 ### SCBench の 4 フェーズ評価と KV キャッシュ中心の分類 本論文は長コンテキスト手法を KV キャッシュの 4 段階に分類する統一フレームワークを導入する。 | 段階 | 処理内容 | 代表的手法 | |------|---------|-----------| | ❶ KV キャッシュ生成（生成フェーズ最適化） | プリフィリング時のアテンション計算を効率化 | スパース・アテンション（A-shape, Tri-shape, MInference）, SSM, プロンプト圧縮 | | ❷ KV キャッシュ圧縮（格納前の削減） | 復号前に KV 状態をプルーニング/量子化 | StreamingLLM, SnapKV, PyramidKV, KIVI | | ❸ KV キャッシュ検索（既存キャッシュの再利用） | 入力のプレフィックスに基づき KV キャッシュを検索・再利用 | CacheBlend | | ❹ KV キャッシュローディング（部分ローディング） | 各復号ステップで KV の一部だけを動的にロード | Quest, RetrievalAttention | ### 2 つの共有コンテキストモード - **マルチターン・モード**：単一セッション内で長コンテキストを参照しながら複数のクエリを行う設定。KV キャッシュへの注目領域がターン間で変化する - **マルチリクエスト・モード**：同一の長コンテキストを複数の独立セッション/ユーザが共有する設定。クエリを伴わないスパース符号化・復号の汎化能力を測定する ### 12 タスク分類 ベンチマークは計 931 マルチターン・セッション・4,853 クエリを含む（平均 5 ターン/セッション）。平均入力長は 227K トークン。 **文字列検索能力**（正確な一致） - `Retr.KV`：125K 入力・大規模キー値ペア辞書から値を検索 - `Retr.Prefix-Suffix`：112K 入力・前後文字列の一致に基づく検索（O(Σwᵢ²) 計算量） - `Retr.MultiHop`：124K 入力・変数代入の多段追跡 **意味的検索能力**（セマンティック理解が必要） - `Code.RepoQA`：65K 入力・GitHub リポジトリからの関数検索（Python/C++/Java 等 7 言語） - `En.QA` / `Zh.QA` / `En.MultiChoice`：英語・中国語 QA（InfiniteBench 由来、人手アノテーション） **グローバル情報処理能力** - `Math.Find`：120K 入力・大規模数値配列の統計値計算（最大・最小・中央値） - `ICL.ManyShot`：22K 入力・多数ショット文脈内学習 - `En.Sum`：104K 入力・複数 arXiv 論文の要約 **マルチタスク能力** - `Mix.Sum+NIAH`：要約とNIAH（Needle in A Haystack）の同時実行 - `Mix.RepoQA+KV`：コード関数検索とKV 検索の同時実行 ### Tri-shape：新規提案のスパース・アテンション手法 従来の A-shape（シンクトークン＋ローカルウィンドウ）に対し、Tri-shape はアテンション行列の底部に密なクエリ領域を加えることで三角形のスパース・パターンを形成する。スパース符号化・密復号の知見を活用し、初回ターン精度と多リクエスト性能の両立を図る。 ## 新規性 ### KV キャッシュ中心のベンチマーク設計 SCBench は以下の点で従来ベンチマークと根本的に異なる。 1. **KV キャッシュのライフサイクル全体**を評価対象とする唯一のベンチマーク 2. 実世界のプレフィックス・キャッシング挙動（マルチターン・マルチリクエスト）を正確に模倣 3. タスクの「圧縮可能性」が性能に与える影響を明示的に分析した最初の研究（例：NIAH の反復ノイズは高圧縮可能、Retr.KV のランダムペアは非圧縮） 4. クエリ非依存設定（クエリなしスパース符号化）の汎化能力を初めて系統的に測定 ## 実験設定 ### 評価対象の LLM（8 モデル） - Transformer ベース（6 モデル）：Llama-3.1-8B, Llama-3.1-70B, Qwen2.5-72B, Qwen2.5-32B, Llama-3-8B-262K, GLM-4-9B-1M - ゲート線形 RNN：Codestral-Mamba-7B - SSM-アテンション・ハイブリッド：Jamba-1.5-Mini すべて BFloat16、グリーディ復号、4×NVIDIA A100 GPU（大規模モデルは 8×A100 40GB または 4×H100 80GB）。推論フレームワークに vLLM-0.52 と FlashAttention-2 を使用。 ### 評価対象の長コンテキスト手法（13 手法・8 カテゴリ） | カテゴリ | 手法 | KV サイズ | プリフィリング複雑度 | 復号複雑度 | |---------|------|---------|---------------------|-----------| | ゲート線形 RNN | Codestral-Mamba | O(k) | O(kn) | O(km) | | ハイブリッド | Jamba-1.5 | O(n) | O(n²) | O(nm) | | プロンプト圧縮 | LLMLingua-2（圧縮率 1/3） | O(αn) | O(α²n²) | O(αnm) | | スパース・アテンション | A-shape, Tri-shape, MInference | O(n) | O(kn) | O(nm) | | KV キャッシュ破棄 | StreamingLLM, SnapKV, PyramidKV | O(k) | O(n²) | O(km) | | KV キャッシュ量子化 | KIVI（2bit, group_size=32） | O(n) | O(n²) | O(nm) | | KV キャッシュ検索 | CacheBlend | O(n) | O(n²) | O(nm) | | KV キャッシュローディング | Quest, RetrievalAttention | O(n) | O(n²) | O(km) | ## 実験結果 ### 主要結果：sub-O(n) 手法のマルチターン崩壊 Table 4 より、Llama-3.1-8B での代表的スコア（multi-turn AVG.）： | 手法 | 圧縮率 | マルチターン AVG | マルチリクエスト AVG | |------|--------|----------------|---------------------| | FullAttention（基準） | 1 | 48.7 | 37.2 | | MInference（スパース符号化） | 1/32 | 42.5 | 36.4 | | Tri-shape | 1/32 | 30.3 | 25.9 | | A-shape | 1/32 | 27.1 | 27.6 | | StreamingLLM（KV 破棄） | 1/32 | 15.5 | 14.5 | | SnapKV（KV 破棄） | 1/32 | 20.9 | 15.2 | | KIVI（量子化） | 1/8 | 32.0 | 24.8 | | CacheBlend | 1 | 49.3 | 34.8 | | Quest（ローディング） | 1/32 | 22.1 | 19.6 | KV キャッシュ破棄系（StreamingLLM・SnapKV・PyramidKV）はリクエスト増加とともに精度が急落し、第 2 リクエスト以降でほぼゼロになるケースが観察される。 ### スパース性：符号化 vs. 復号の非対称性 - **スパース符号化 + 密復号**（O(n) メモリ）：A-shape・Tri-shape はリクエストが増えるほど精度が向上する。単一ターンで密よりわずかに劣るが、マルチリクエストでは安定 - **密符号化 + スパース復号**（sub-O(n) メモリ）：StreamingLLM 等は符号化を密にしても復号をスパースにするだけで大幅に性能劣化する - この非対称性の原因：復号は生成における因果接続に本質的役割を担い、スパース復号は複雑なアテンション関数形成を制約するため（Yun et al., 2020） ### 動的スパース性の優位性 MInference（動的スパース・アテンション）はすべての LLM・タスクにわたって一貫して Tri-shape・A-shape（静的）を上回る。1/32 バジェットで A-shape の 1/4 バジェット相当の性能を達成する。クエリ非依存設定（マルチリクエスト）でも動的パターンは頑健性を維持する。 ### クエリ非依存設定での劣化 Table 5 より、クエリ有り vs. クエリなし（マルチリクエスト）のスコア差（Llama-3.1-8B）： | 手法 | 文字列検索（有り/なし） | 意味的検索 | グローバル | マルチタスク | |------|----------------------|-----------|-----------|------------| | SnapKV | 0.0 / 0.0 | 19.0 / 9.7 | 17.9 / 14.6 | 5.1 / 0.0 | | Tri-shape | 12.1 / 7.8 | 31.4 / 25.7 | 31.1 / 45.6 | 28.0 / 24.6 | | MInference | 28.1 / 28.9 | 40.4 / 35.6 | 35.4 / 50.1 | 28.3 / 30.9 | SnapKV はクエリなし設定で壊滅的に性能劣化するが、MInference の動的パターン（対角線接続）は汎化能力を維持する。 ### 圧縮率の影響：1/4 閾値での急落 Figure 4 によると、sub-O(n) 手法は圧縮率 1/4 で急激な性能劣化が起きる。O(n) メモリ維持手法（RetrievalAttention・KIVI）は高圧縮率でも比較的安定する。 具体的に： - A-shape と Tri-shape：1/2 予算で約 5〜6 ポイント低下、1/4 予算で大幅低下 - StreamingLLM と SnapKV：1/4 予算でそれぞれ 26 ポイントと 19 ポイント低下 ### レイヤーレベル・スパース性（ハイブリッド・アーキテクチャ） Jamba-1.5-Mini は SSM レイヤーでメモリを削減しつつ、一部の Transformer アテンション・レイヤーで O(n) KV キャッシュを維持し将来のルックアップに備える。この設計により単一ターン・インタラクションでは高性能（多リクエストでは精度劣化あり）。 ### アテンション分布シフト（OOD 問題） 生成長・ラウンド数の増加に伴い、KV キャッシュの重要度分布が大きく変化する。Figure 6b の Retr.KV アテンション可視化では、ターン間で重要な KV が大きく移動することが確認される。この分布外（OOD）問題は O(n) 手法の RetrievalAttention でも精度劣化を引き起こす。 ### モデル規模の効果 Qwen2.5-72B（フルアテンション）はマルチターン AVG. 52.9、マルチリクエスト 45.8 と最高性能を示す。ただしスパース手法（A-shape 適用時：38.4 / 35.4）との乖離は小さいため、スパース符号化の損失は規模拡大で相殺可能なことが示唆される。 ### Codestral-Mamba の限界 純粋 SSM モデル（Codestral-Mamba）は正確な文字列検索でほぼゼロ（Retr.String: 0.0〜3.9）。SSM の固定サイズ状態への情報圧縮は、高精度な KV 記憶に本質的に不向きであることが確認された。 ## 考察 ### 圧縮可能・非圧縮タスクの違い NIAH の反復ノイズや要約タスクは高圧縮可能であり、sub-O(n) 手法でも合理的な精度を達成できる。一方、ランダムキー値ペア（Retr.KV）や前後一致検索（Retr.Prefix-Suffix）は本質的に非圧縮であり、厳密な O(n) メモリが必須である。従来の単一ターン評価（特に NIAH）はモデル能力を過大評価していた可能性がある。 ### エラー伝播の影響 黄金回答をコンテキストとして使う主設定とモデル生成を使う設定の比較（Table 13）では、後者で全体的に精度が低下し、ターン数に比例してエラーが蓄積する。ただし「密復号優位・動的スパース性優位」という主要知見は設定変更後も維持された。 ### CPU-GPU 協調による sub-O(n) 復号の可能性 Full O(n) KV キャッシュを CPU RAM に格納し、関連 KV だけを GPU に動的ローディングするアプローチ（Quest・RetrievalAttention）は、sub-O(n) GPU メモリを実現しながら O(n) 情報アクセスの利点を保つ。ただし RetrievalAttention でもアテンション分布シフトによる精度劣化が発生している。 ## 強み - KV キャッシュのライフサイクル全体を初めてカバーする包括的ベンチマーク - 2 つの共有コンテキストモード（マルチターン・マルチリクエスト）と 12 タスク・4 能力カテゴリの多角的設計 - 8 カテゴリ・13 手法・8 モデルを同一条件で比較した最大規模の横断評価 - 新規手法 Tri-shape の提案と実験による検証 ## 弱点・課題 - 評価は主に 128K トークン入力に限定。1M トークン以上の超長コンテキストへの外挿は不明 - エラー伝播実験では黄金回答を参照コンテキストとして使うため、実環境のエラー蓄積を完全には模倣できていない - 新規ベンチマーク（SCBench 自体）への過適合リスク：SCBench の評価知見が将来の手法設計に利用されれば、ベンチマーク特有の最適化が生じる可能性がある - Codestral-Mamba・Jamba は Transformer ベース手法との比較が一部タスクで不完全（アーキテクチャの本質的制約との区別が難しい）