16GB GPUで27Bモデルの256Kコンテキストを実現するTierKVの公開
15秒でわかる内容解説
2026年9月17日、arczhiがllama.cppのフォーク「TierKV」を公開した。VRAM、システムRAM、SSDの3層でKVキャッシュを管理し、16GBのGPUで27Bモデルの256Kトークンコンテキストを維持しながら高速な推論を実現する。
3層構造でVRAMを節約するアーキテクチャ
TierKVは、llama.cppの独立した研究用フォークとして開発された。ベースとなるllama.cppのコミットハッシュは`c77ae69`（2026年9月17日）であり、既存の動作を壊さないよう環境変数でオプションが切り替えられる。主要な機能は、会話履歴であるKVキャッシュを「機（VRAM）」「本棚（システムRAM）」「アーカイブ（SSD）」の3層で管理する点にある。
VRAMは「機」として扱われ、直近の会話（32〜49Kトークン）と必要なページのみを保持する。これにより、計算は常にVRAM上で行われ、推論速度の低下を防ぐ。システムRAMは「本棚」として機能し、VRAMから追い出されたページはここで保存される。256Kトークンのコンテキストでも、ホストRAMの使用量は約4.6GBに抑えられる。
SSDは「アーカイブ」として機能し、セッションの保存と復元を可能にする。ページ（64トークン単位）の移動はトークン生成ごとではなく、ターン境界で行われる。これにより、毎回のページ読み込みによる遅延を回避し、平坦な推論速度を維持している。ページのリコールには、単語の重なり（IDF）と注意機構のスコア（page-sparse attention）の2つの信号が用いられる。
| コンテキスト長 | KVキャッシュ（Q4_0） | VRAMに収まるか |
|---|---|---|
| 8Kトークン | 0.15 GB | はい |
| 57Kトークン | 1.0 GB | 限界 |
| 262Kトークン | 4.7 GB | いいえ |
VRAMの容量制限により、通常のllama.cppでは262Kトークンのコンテキストを維持するのが難しい。TierKVはこのボトルネックを、メモリ階層の最適化で解決する。
RTX 5060 Ti上での27Bモデル動作性能
テスト環境は、RTX 5060 Ti 16 GB、システムRAM 32 GB、NVMe SSD（3.5 GB/s）で構成される。モデルにはQwen3.8-27B（IQ4_XS、約13.2 GiB）が使用された。この構成で、256Kトークンのコンテキスト時におけるVRAM使用量は最大15.5 GB、システムRAM使用量は4.6 GBとなった。
推論速度は、コンテキスト長に関わらず一定であることが特徴だ。8Kトークンから262Kトークンまで、デコード速度は約22.7トークン/秒で平坦に推移した。これは、VRAMの「機」のサイズが固定されているため、アテンション計算のコストが増加しないからだ。
エージェントのコーディングタスク（DeliverableBench `ocr-dual-channel`）では、TierKVのフルスタック構成（MTP-5有効、ウィンドウ49K）でスコア100.0、所要時間398秒を記録した。これはベースラインのllama.cpp（所要時間433秒）と比較して、約35秒の高速化となった。
speculative decoding（MTP）を活用することで、8Kコンテキスト時などの短時間推論ではさらに高速化が可能だ。MTP-5有効時、推論速度は63.7トークン/秒に達した。ただし、256KコンテキストではMTPのドラフトコンテキストサイズが約1.1 GiB必要となり、VRAMの制約から推論速度は22.7トークン/秒に留まる。
| 実装 | 構成 | スコア | 所要時間(s) | デコード速度(tok/s) |
|---|---|---|---|---|
| Dense baseline | mainline llama.cpp, MTP-5, window 57,344, Q4_0 KV | 100.0 | 433 | 65.8 |
| TierKV full stack | window 49,152, Q4_0 KV + host store, hybrid selector, MTP-5 | 100.0 | 398 | 62.1 |
| KVMem reference | 262K logical, 32K retrieved window, MTP-3 | 100.0 | 482 | 50.3 |
KVMemとの比較と技術的詳細
TierKVは、同様の目的を持つKVMemプロジェクトと比較されることが多い。両者は独立した設計ながら、少ないVRAMで長いコンテキストを実現するという共通の目標を持っている。KVMemは262Kコンテキストで50.3トークン/秒を記録したが、TierKVのフルスタック構成では62.1トークン/秒を達成している。
TierKVの技術的な特徴として、ページのスプースアテンション（page-sparse attention）が挙げられる。これは全履歴ではなく、関連性の高いページのみを対象とする最適化された注意機構だ。各64トークンページには、Kベクトルのチャネルごとの最小値と最大値の小さな要約が保持される。これにより、現在のクエリに対して上位ページのスコアを効率的に計算できる。
また、システムプロンプトやタスク仕様などの重要な情報は、最初の2,048ポジションとして保護される（head protection）。これにより、古い情報が強制 eviction（追放）されることで、エージェントが指示を見失う現象を防いでいる。
SSDスナップショット機能により、プロセスを再起動しても会話履歴を復元できる。302 MBのストアを読み込むだけで、プロンプトに含まれていないパスフレーズを用いた26トークンの質問に正答するなどのテストが成功している。
今後の課題とロードマップ
TierKVはまだ研究段階のフォークであり、いくつかの制限が存在する。最大の課題は、256KコンテキストでのMTP（複数トークン予測）推論の有効化だ。現在の実装では、MTPのドラフトコンテキストがVRAMの制約により256Kでの使用が不可能であり、推論速度は22.7トークン/秒に留まる。
KVMemプロジェクトでは、ウィンドウ化されたMTPプールと状態リプレイによりこれを解決している。TierKVでも同様のポートがロードマップの最優先課題となっており、実現すれば256Kコンテキストでの推論速度は70〜85トークン/秒になると期待されている。
さらに、ウィンドウサイズが作業セットより小さい場合、エージェントがスレッドを見失う可能性がある。これは、サーバーが送信するトークンストリームに対してKVキャッシュが完全に一致していないためだ。現在はウィンドウを49K程度に保つことが推奨されている。
スペアアテンションは現在、カスタムカーネルではなく、通常のKVセルへの集約（gather）として実装されている。今後はpaged-Flash-Attentionカーネルの実装により、さらなる高速化が図られる見込みだ。
用語の注釈
- MTP
- 推論の効率化手法で、1トークン生成ごとに複数のトークンを同時に予測する。（参考：deepseek技术解读 (2)-MTP（Multi-Token Prediction）的前世 ...）
- page-sparse attention
- 全履歴ではなく関連性の高いページのみを対象とする最適化された注意機構。（参考：英語「page」の意味・使い方・読み方 | Weblio英和辞書）