kvpress 評: prefilling 時に KV キャッシュを削る 10 種類の press を transformers パイプラインに載せる

330GB という数字が示す問題設定

README は冒頭で、Llama 3.1-70B を float16 で 1M トークン扱うと最大 330GB のメモリが必要になると述べている。KV キャッシュがコンテキスト長に対して線形に増えるためで、これはモデル重みとは別に積み上がる。kvpress が解こうとしているのはこの部分である。対象読者は、長文コンテキストのモデルをデプロイする開発者と、新しい圧縮手法を試したい研究者の両方だと README は位置づけている。重みの量子化やモデルの小型化ではなく、推論時に保持する KV ペアそのものを削る方向の対処に限定している点が、この道具の守備範囲をはっきりさせている。

press は prefilling 中にスコアの低い KV ペアを落とす

仕組みは単純で、圧縮は prefilling 段階で行われる。各 press は compression_ratio 属性を持ち、キャッシュがどれだけ圧縮されたかを表す。中心になるのが ScorerPress で、KV ペアごとに重要度のスコアを計算し、下位のものを枝刈りする。スコアの作り方が手法ごとに違う。KnormPress は key のノルムの逆数、SnapKVPress は直近クエリの平均 attention 重み、TOVAPress は最後のクエリの attention 重みをヘッド間で平均したもの、ExpectedAttentionPress は生成フェーズで期待される attention 重みを使う。QFilterPress は Query ベクトルの主要な SVD 成分に Key 表現を射影して attention スコアを近似する。StreamingLLMPress はスコア方式ではなく、先頭と直近のトークンだけを残す。PyramidKVPress は層ごとにキャッシュ予算を変え、下位層に多く上位層に少なく配る。LagKVPress は KV の lag-relative な情報を使うと README は説明している。すべて training free で、BasePress を継承する。

導入は pip 1 行、パイプラインは import で自動登録される

pip install kvpress で入る。ローカルで触る場合は uv を使い、git clone したうえで uv sync、評価用と flash-attn を足すなら uv sync --extra eval --extra flash-attn を実行する。使い方は transformers の pipeline 経由で、kvpress を import すると kv-press-text-generation という名前のパイプラインが自動登録される。README の例では Qwen/Qwen3-8B を device_map="auto"、dtype="auto" で読み込み、ExpectedAttentionPress(compression_ratio=0.5) を渡して pipe(context, question=question, press=press)["answer"] で答えを得る。chat テンプレートとトークナイズはパイプライン側が処理する。この例では圧縮はコンテキストのトークンにだけ適用されるので、同じ圧縮済みコンテキストに対して別の質問を投げ、圧縮の影響だけを見比べられる。より詳しい例は notebooks/wikipedia_demo.ipynb にある。

decoding 圧縮は target_size 方式で、対応 press が絞られる

experimental な機能として DecodingPress がある。生成中に定期的にキャッシュを圧縮するラッパーで、直近の隠れ状態をバッファに持つこともできる。パラメータは base_press（ScorerPress のいずれか）、compression_interval（既定 512 ステップ）、target_size（圧縮後の目標キャッシュサイズ、既定 2048）、hidden_states_buffer_size（既定 256、バッファ不要な press は 0 にできる）。prefilling の compression_ratio と違い、こちらは target_size を指定すると、compression_interval ステップごとに、圧縮後のサイズが target_size に一致するよう圧縮率が自動計算される。README は、decoding と prefilling では圧縮の仕組みが根本的に違うため、すべての press が DecodingPress と互換ではなく、base press は ScorerPress のみ対応と明記している。既存手法を decoding 側にそのまま流用できる前提で設計を進めると、ここで詰まる。

向かない場面: 圧縮率の指定と生成中削減を同時に求める場合

prefilling 圧縮は compression_ratio で効き具合を指定するのに対し、decoding 圧縮は target_size で事後サイズを指定する。同じ「圧縮」でも制御する量が違うため、両者を同じ設定値で扱おうとすると噛み合わない。加えて decoding 側は base press が ScorerPress に限られ、RandomPress のようにスコア方式でないものや、層ごとの配分を前提とする PyramidKVPress のような設計をそのまま持ち込めるかは README からは読み取れない。生成中のキャッシュ削減を製品品質で必要とするなら、experimental という位置づけのまま依存させるのは避け、prefilling 圧縮で足りる範囲に用途を絞るほうが安全である。

代替としての H2O 実装との違い

同じ ScorerPress 系の手法を単体で使うなら、H2O の参照実装のように 1 手法だけを組み込む選択肢がある。違いは比較の設計にある。H2O 実装は attention 重みの累積に基づく独自のスコアを固定で持ち、モデル側の書き換えも手法ごとに個別対応になる。kvpress は BasePress と ScorerPress という共通の基底を置き、compression_ratio を共通の制御量として、KnormPress、SnapKVPress、TOVAPress、ObservedAttentionPress、QFilterPress、PyramidKVPress、LagKVPress などを同じ pipeline 呼び出しに差し替えられるようにしている。1 つの長文コンテキストと 1 つの質問を固定し、press だけを入れ替えて答えを並べる、という比較が短いコードで書けるのが利点である。逆に、特定手法の内部挙動を細かく詰めたい場合、共通基底の抽象が邪魔になる可能性がある。

ライセンスと追随コスト

ライセンスは Apache-2.0 で、特許許諾条項を含む点が MIT との違いになる。自社製品に組み込んで再配布する場合、変更したファイルへの表示や NOTICE の扱いなど、Apache-2.0 固有の条件を確認する必要がある。ここでは法的助言はしない。保守の面では、リリースが v0.5.2（2026-04-01）、v0.5.3（2026-04-09）、v0.5.4（2026-07-02）と 0.5 系で細かく刻まれており、API がまだ動いている段階だと読める。press の追加や DecodingPress の仕様変更が入りうるので、compression_ratio や target_size の既定値に依存したコードは上げ下げの影響を受けやすい。依存先も transformers と PyTorch で、flash_attention_2 を使う例が README に繰り返し出てくるため、モデル側の attention 実装がそれに対応しているかを先に確かめておきたい。

編集部の結論

長文コンテキストの推論で KV キャッシュのメモリが問題になっており、複数の圧縮手法を同じ pipeline 上で比較したい研究・検証用途なら kvpress は候補になる。逆に、生成中のキャッシュ削減を本番品質で求める用途には向かない。README が decoding 圧縮を experimental と明記し、base press も ScorerPress に限定しているためである。導入前に確認すべきは、自分のモデルが flash_attention_2 で動くか、対象の press が compression_ratio 方式か target_size 方式か、そして Apache-2.0 の許諾範囲で自社の再配布形態が収まるかの 3 点。まずは ExpectedAttentionPress(compression_ratio=0.5) を 1 つの長文コンテキストに当て、同じ質問を非圧縮時と並べて答えの劣化を見るところから始めるのが現実的である。

公式情報源

1. Issues
2. License: Apache-2.0
3. NVIDIA/kvpress on GitHub
4. README
5. Releases