H2O（Heavy-Hitter Oracle）（エイチツーオー・ヘビーヒッターオラクル）

H2O（Heavy-Hitter Oracle）— 累積Attentionスコア駆動のKVキャッシュ圧縮

H2O（Heavy-Hitter Oracle）は、2023年にUT Austinの研究チームが発表したKVキャッシュ動的圧縮アルゴリズムだ。LLM推論においてKVキャッシュサイズを削減する手法として、SnapKV・ScissorHandsなどの後続研究の先駆けとなった。

Heavy Hitter仮説

H2Oの中核となる観察は「LLM推論中に少数のトークンが累積的に高いAttention Scoreを獲得し続ける」という事実だ。これらのトークンをHeavy Hitter（HH）と呼ぶ。

実験的に確認された特性:

• 全トークンの20〜30%のHeavy Hitterが累積Scoreの80〜90%を占める（パレート則に近い分布）
• Heavy HitterはDecodeステップが進んでも入れ替わりが少ない（安定した重要トークン集合）
• 文章の意味的に重要な単語（名詞・動詞・文頭トークン等）がHHになる傾向

アルゴリズム

H2Oは各Decodeステップで以下の処理を行う:

1. スコア更新: 現在ステップのAttention Scoreを各トークンの累積スコアに加算
2. HH選択: 累積スコア上位HH_size個のトークンのKVペアを保持
3. Recent保持: 直近Recent_size個のトークンのKVペアを常に保持（局所性のため）
4. 削除: HH ∪ Recent 以外のKVペアをキャッシュから削除

キャッシュサイズ上限 = HH_size + Recent_size（固定）でメモリを制御する。

性能評価（2023年時点）

GPT-NeoX-20Bでの評価:

• KVキャッシュ圧縮率: 4〜5倍（HH_size + Recent_size = 全長の20〜25%）
• OPT/GPT-NeoX/LLaMAシリーズでの精度保持率: 95%以上
• メモリ削減により単一GPU（A100 80GB）で2〜4倍長いシーケンスを処理可能

Streaming LLMとの比較:

• Streaming LLM（Attention Sink）は先頭トークン+直近のみ保持
• H2Oは累積スコアによる動的選択 → 長距離依存の捕捉が優れる
• 精度: H2O > Streaming LLM（特に長文QAタスク）

H2Oの課題

オフラインでの決定問題 Decodeが進むまでどのトークンがHeavy Hitterになるかわからないため、リアルタイムで動的に選択する必要がある。この「オンライン決定」がH2Oを理想的なオフライン選択からやや劣らせる原因。

Prefill vs Decodeの非対称性 H2OはDecode中の動的選択に最適化されており、Prefillフェーズ全体のKVキャッシュ圧縮はSnapKVやPyramidKVの方が適している。

実装

H2OはHugging FaceのGeneration Pipeline互換のPythonパッケージとして公開されている（github.com/FMInference/H2O）。past_key_valuesを置き換えるだけで既存コードに適用可能。

from h2o_hf import H2OLlamaForCausalLM

model = H2OLlamaForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-hf",
    heavy_ratio=0.1,
    recent_ratio=0.1,
)

よくある質問（FAQ）

Q1: H2OはSnapKVと組み合わせて使えますか？ A: 設計思想が異なる（H2O=Decode中動的選択、SnapKV=Prefill時静的選択）ため直接的な組み合わせは難しい。研究レベルではPrefill=SnapKV+Decode=H2Oと段階的に適用するアプローチが研究されている。

Q2: Heavy Hitterはどのトークンが選ばれやすいですか？ A: 実験的に、文頭の特殊トークン（BOS）・区切り文字（.、,）・名詞句の主要語が高頻度でHeavy Hitterになる。これはAttentionの「Attention Sink」現象とも関連している。

Q3: H2OはGQA（Grouped Query Attention）に対応していますか？ A: 基本的なH2OはMHA前提の設計だが、GQA対応の拡張版実装もコミュニティから提供されている。LLaMA-3-8BなどGQAモデルへの適用実績あり。