16GB GPUでのKVキャッシュ：長文脈を実際に収容する方法

モデルは128Kのコンテキストウィンドウを宣伝していても、16 GBのGPUでは40Kトークンで失敗することがあります。アーキテクチャの上限は、ウェイト、KVキャッシュ、計算バッファ、デスクトップコンポジターがすべて同時にGPUに収まることを約束したことはありません。

KVキャッシュは、通常、長文コンテキストの計画が物理的な制限にぶつかる場所です。アクティブなトークンとシーケンスごとに増加するため、起動時に見た目上は快適に見える設定でも、急激に速度が低下したり、システムメモリにオーバーフローしたり、大きなプリフィル中に失敗したりすることがあります。

このガイドでは、この問題をVRAM（ビデオメモリ）の予算管理に変換します。キャッシュの計算式、再現可能な32Kから128Kのサイズテーブル、llama.cppの --cache-type-k と --cache-type-v、vLLMのページドキャッシュおよびプレフィックスキャッシュ、Ollamaのコンテキスト制御の動作する設定をカバーします。また、興味を引くものの盲目的な信頼には値しない実験的なアダプティブキャッシュのフォークについても触れます。これらの数値の背後にある幅広いスループット、レイテンシ、ベンチマークの文脈については、LLMパフォーマンスハブから始めることをお勧めします。

16 GB GPU向け短答

まず、1シーケンス、現実的な最大コンテキスト、Flash Attention、そして8ビットKVキャッシュから始めてください。4ビットキャッシュ、CPUオフロード、複数の並列スロット、あるいは実験的なフォークに挑戦する前に、その設定を測定してください。

私の意見はシンプルです。安定した64Kセットアップは、OOM（メモリ不足）失敗のギリギリのところで動作する名目上の128Kセットアップよりも、通常はより有用です。コンテキスト容量はトロフィーではありません。レイテンシ、品質、並行性の判断なのです。

KVキャッシュが格納するもの

自己回帰的な生成中、アテンションの各レイヤーは、処理された各トークンに対してキーとベクトルのテンソルを生成します。ランタイムはこれらのテンソルを保持し、次のトークンが以前のトークンに注意を払う際に、すべてのプレフィックスを再計算する必要がないようにします。

キャッシュは莫大な計算量を節約しますが、保持されたトークン数に応じてメモリを消費します。グループクエリアテンションを持つ従来のTransformerにおいて、有用なベースラインは以下の通りです：

KVバイト数 = シーケンス数 * トークン数 * レイヤー数 * 2 * KVヘッド数 * ヘッド次元 * 値あたりのバイト数

2という係数は、キーとベクトルを表します。マルチヘッドアテンションは、クエリヘッドと同じ数のKVヘッドを使用し、グループクエリアテンションはKVヘッドを少数にし、マルチヘッド潜在アテンションやハイブリッドなリカレントアーキテクチャは異なる計算が必要です。

パラメータ数が十分でない理由

2つの8Bモデルでも、KVキャッシュのコストは大きく異なる可能性があります。一方は32レイヤーと8つのKVヘッドを使用する一方で、もう一方はより少ないKVヘッド、共有KVレイヤー、スライディングウィンドウアテンション、または圧縮された潜在状態を使用しているかもしれません。

パラメータ数は主にウェイトメモリを予測します。KVの幾何学的構造はアテンションアーキテクチャから来るため、8B や 27B、GGUFファイルサイズから推測するのではなく、モデルのメタデータを読むべきです。アテンション設計が単純なマルチヘッドアテンション（MHA）からどれほど進化したかを示す最も明確な例は以下の通りです：

• マルチクエリアテンション（MQA） は、すべてのクエリヘッドで単一のK/Vヘッドを共有します — 最大のキャッシュ節約ですが、最も積極的な品質妥協であり、現在のフロンティアモデルでは単独で使用することはまれです。
• グループクエリアテンション（GQA） は、クエリヘッドをクラスタ化し、それぞれが1つのK/Vヘッドを共有します — ほとんどのオープンな稠密（dense）モデルで使用されている主流の妥協策であり、上記の計算式が仮定している幾何学的構造です。
• マルチヘッド潜在アテンション（MLA） は、DeepSeek-V2で導入され、DeepSeek-V3やKimi K2に引き継がれました。これは全く異なるアプローチを取ります：K/Vをヘッド間で共有するのではなく、キーとベクトルを圧縮された低ランクの潜在ベクトルに射映し、アテンション時に必要に応じてフルリゾリューションのK/Vを再構築します。DeepSeekは、同等サイズの稠密MHAモデルと比較して、約93%のKVキャッシュ削減を報告しました。これは、同じメモリ予算内でGQAと競合する、時には上回る品質を維持しながら実現されています。

実用上の結果として、「27B GQAモデル」と「27B MLAモデル」では、同じコンテキスト長に対してKVキャッシュのフットプリントが桁違いに異なる可能性があります。潜在的アテンション、DeltaNetスタイルの状態、またはスライディングウィンドウレイヤーを使用していると記載されているモデルには、上記の計算式が適用されることを前提としないでください。まずモデルカードのアーキテクチャセクションを確認してください。

Ollamaでは、ollama show MODEL --verbose でレイヤー数、アテンションヘッド数、KVヘッド数、コンテキスト長などのモデルメタデータ（フォーマットが提供する場合）を表示できます。llama.cppでは、起動時に表示されるモデルローダーの出力に、同等のGGUFメタデータとランタイムの実際のキャッシュ割当が含まれることが通常です。

モデルの上限、割当コンテキスト、使用コンテキスト

これらは3つの異なる数値です。モデルの上限は、そのトレーニングと位置エンコーディングがサポートする最大値であり、割当コンテキストはランタイムが予約または許可する値であり、使用コンテキストは現在のシーケンスに対して保持されているトークンです。

エンジンのフラグを上げることでは、モデルがサポートする位置スキームを超えることは安全に行えません。RoPEスケーリングは一部のアーキテクチャを拡張できますが、それはモデル品質の実験であり、KVメモリ最適化ではありません。

KVキャッシュサイズテーブル：32K、64K、128Kコンテキストの予算

32レイヤー、8つのKVヘッド、ヘッド次元128の代表的なGQAモデルを考えます。これらの次元は、各要素の保存サイズを乗じる前に、トークンあたり65,536個のキーとベクトル要素を生成します。

このテーブルは、2進GiBと、llama.cppの f16、q8_0、q4_0 と関連付けられる一般的な物理ブロックサイズを使用しています。これはベースラインの計算であり、プロセス全体メモリの約束ではありません。アライメント、メタデータ、ハイブリッドレイヤー、バックエンドワークスペースがオーバーヘッドを追加します。

ここで、レイヤー数を64に倍増し、他の次元は変更しません。FP16キャッシュは32Kで8 GiB、64Kで16 GiB、128Kで32 GiBとなり、単一のコンテキスト推奨がすべてのモデルをカバーできない理由を示しています。

実際の16 GB方程式

実用的な予算はKV計算式よりも広範です：

使用可能VRAM = 総VRAM - デスクトップとドライバの予約分

KV予算 = 使用可能VRAM
          - GPUに常駐するモデルウェイト
          - グラフと活性化バッファ
          - ランタイムワークスペース
          - 投機的デコーディングの状態
          - セーフティマージン

ディスプレイ接続された16 GBのカードでは、16 GiB全体が利用可能であると計画しないでください。デスクトップとドライバのために少なくとも数百MiBを確保し、その後、ワークロード依存のバッファのためにさらにマージンを残します。1.0から1.5 GiBの総余裕が妥当な初期仮定ですが、ログが権威です。

GGUFモデルがGPUで10.8 GiBを占有し、ランタイムのオーバーヘッドが約1.2 GiBにピークを迎えたとします。1 GiBのセーフティマージン後も、KVに残るは約3 GiBのみです。したがって、代表的なモデルはQ8_0で約45Kトークン、Q4_0で約87Kトークンに収まります（エンジン固有のオーバーヘッドを差し引く前）。

それだけで自動的にQ4_0が正解とは限りません。あなたのワークロードで長文コンテキストの精度が低下する場合、Q8_0キャッシュを持つより小さく、あるいはより積極的に行き詰められたモデルの方が、大きなウェイトと脆いキャッシュの組み合わせよりも良いかもしれません。まさにこの計算のための測定アンカーは、16 GB VRAM llama.cpp ベンチマークテーブルにあります。ここではVRAMが19K、32K、64Kコンテキストで記録されています。同じクラスのカードでOllama下でどのモデルサイズや量子化レベルがよく振る舞うかというより広い調査については、Ollamaによる16GB VRAM GPUでのLLMパフォーマンス比較をご覧ください。

自分のモデルのKVキャッシュ予算を計算する

以下のPythonスニペットは、従来の完全アテンションGQAキャッシュを推定します。幾何学的構造を、モデル設定またはGGUFメタデータからの値に置き換えてください。

def kv_gib(tokens, layers, kv_heads, head_dim, bytes_per_value, sequences=1):
    total = (
        sequences
        * tokens
        * layers
        * 2
        * kv_heads
        * head_dim
        * bytes_per_value
    )
    return total / (1024 ** 3)


model = {
    "layers": 32,
    "kv_heads": 8,
    "head_dim": 128,
}

types = {
    "f16": 2.0,
    "q8_0": 34 / 32,
    "q4_0": 18 / 32,
}

for tokens in (32768, 65536, 131072):
    row = {
        name: round(kv_gib(tokens=tokens, bytes_per_value=size, **model), 2)
        for name, size in types.items()
    }
    print(tokens, row)

Q8_0とQ4_0の比率には単純なブロックメタデータが含まれているため、値あたりちょうど1バイトと半バイトより少し大きくなります。ランタイムの起動レポートの方がより正確であり、それはモデル固有のキャッシュレイアウトを知っているためです。

この計算式が間違っている場合：ハイブリッドおよびスライディングウィンドウアーキテクチャ

ハイブリッドアーキテクチャを従来のGQA方程式に無理やり当てはめないでください。スライディングウィンドウレイヤーは最近のウィンドウのみを保持し、共有KVレイヤーは重複を減らし、リカレントレイヤーは固定サイズの状態を持つ場合があり、マルチヘッド潜在アテンションはヘッドごとのK/Vテンソルではなく圧縮された表現を保存します — 上記のMLAのケースが最も劇的な例です。

現代のエンジンは、これらの混合レイアウトを明示的に管理するようになっています。計算式を主要な項を説明するために使用し、その後、デプロイを予定している正確なエンジンビルドとバックエンドが報告する割当を確認してください。

llama.cpp：KとVの精度を直接制御

llama.cppは現在の引数パーサーで、--cache-type-k と --cache-type-v オプションを個別に公開しています。これは、グローバルなプリセットを受け入れるのではなく、キャッシュ精度とコンテキスト容量のトレードオフを行いたい場合、最も有用なローカル推論インターフェースです。まず周回のインストールとサービングセットアップが必要であれば、llama.cppガイドが llama-cli、llama-server、および主要なVRAMフラグをカバーしています。

保守的な64Kシングルユーザー設定は以下のようになります：

./llama-server \
  --model /models/model.gguf \
  --n-gpu-layers 999 \
  --ctx-size 65536 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --batch-size 1024 \
  --ubatch-size 256

フラグの構文とバックエンドサポートは急速に変わるため、インストールされたビルドに対して llama-server --help を実行してください。より重要なのは、起動ログを検査することです。意図したコンテキスト、キャッシュタイプ、GPUオフロード、割当されたKとVバッファが表示されるはずです。

どのllama.cppキャッシュタイプを試すべきか

KとVの両方でQ8_0から始めてください。これはF16に対してKVメモリをほぼ半減し、20B以上のモデル（Qwen3.6-27B、Nemotron-30B）に対する独立したパープレキシティテストでは、F16からの集計品質の差は測定ノイズ以内であることが示されています — これは、より小さいモデルで長文コンテキストにおいてデコード速度と精度が崩壊することを同じテストが示したQ4_0に直接移動するよりも、はるかに劇的ではないギャンブルです。

Q8_0が収まらない場合は、両方をQ4_0に量子化する前に、Q8_0のキーとQ4_0のベクトルをテストしてください。この順序には伝承だけでなく研究の裏付けがあります：Llama、Phi-4、Qwen3、Mistralチェックポイントに対する制御されたビット割当研究は、キーテンソルはベクトルテンソルよりも一貫して2倍から10倍量子化誤差に敏感であること、そしてキーに大きなビット予算を与えること（例えば4ビットのキーと2ビットのベクトル）は、フルプレシジョンの精度の最大94–98%を回復できることを発見しました — 一方で逆の分割（2ビットのキー、4ビットのベクトル）は、GSM8Kなどのタスクで30ポイントの損失を生じることがあります。キーはアテンションが実際にマッチングする以前のトークンを決定するため、まずそれらを守ることは、より安全に聞こえるだけでなく、アーキテクチャ的に健全な選択です。

内面化すべき注意点が1つあります：アグリゲートベンチマークでの「低品質リスク」は、トークンレベルでのゼロリスクを意味しません。Flash Attentionを一定に保ち、貪欲（決定論的）デコーディング下でKV精度のみを変更した制御されたテストでは、Q8_0キャッシュがプロンプトの大半で正確に生成されたテキストを変更し、Q4_0はほぼすべてのプロンプトでそれを变更したことが判明しました — 1つのトークンが反転すると、継続の残りが分岐する可能性があります。パープレキシティや下流タスクのスコアは平均して問題ないように見えますが、個々の出力はF16ベースラインと異なる場合があります。アプリケーションがバイト単位での再現可能性（リグレッションテスト、キャッシュされたレスポンス、決定論的エージェント）を必要とする場合、KV量子化を単なるメモリ最適化ではなく、挙動の変化として扱い、固定されたプロンプットセットに対して検証してください。

量子化されたVキャッシュは、Flash Attentionまたは互換性のあるバックエンドパスを必要とする場合があります。サイレントに他のタイプにフォールバックするサーバーは実験を無効にするため、起動ログがコピーされたコマンドラインよりも重要なのです。

コンテキスト、並列スロット、統一キャッシュ

--ctx-size はエンジンの容量を記述し、各並列スロットがそれだけのトークンを独立して受けることの保証ではありません。llama.cppではキャッシュ管理が進化しており、統一キャッシュの動作を含むため、コンテキストをスロット数で単純に割るという古い規則に頼るのではなく、正確なビルドをテストしてください。

容量方程式は実装変更後も生存します：同時のユニークなトークンにはどこかに保存が必要です。2つのエージェントセッションがそれぞれ48Kに達する可能性がある場合、ワークロードがプレフィックスを共有するか、エビクションと再計算を許容しない限り、約96Kのライブトークンを予算計上してください。

バッチサイズは保存されたKVを縮小しない

--batch-size と --ubatch-size はプロンプト処理と一時メモリに影響します。これらを下げることにより、大きなプリフィルを活性化メモリのスパイクから救うことができますが、各保持トークンに必要な永続的なバイト数を変えるわけではありません。

この区別が、一般的な失敗パターンを説明します：モデルが開始し、空のリクエストが動作しますが、60Kのプロンプトが取り込み中に失敗します。一時的なピークを診断するにはマイクロバッチを下げ、永続的な容量を変えるには、コンテキスト、キャッシュ精度、並列性、またはウェイトの常駐を変更してください。

vLLM：ページド容量も依然として容量である

vLLMは、サービングエンジンとしてこの問題に対処します。利用可能なメモリをプロファイルし、KVキャッシュプールを確保し、ブロック単位でキャッシュを割当てることで、並列シーケンスがそれぞれ1つの大きな連続領域を必要としないようにします。vLLMに移行するかどうかを決定している場合は、OllamaからvLLMへの移行ガイドがワークロードシグナルをカバーします。ここでは問題はいかにキャッシュプールが多くのキャッシュを持てるかであり、vLLMクイックスタートが、以下の容量レバーを超えるインストールと一般的なサービングフラグをカバーします。

PagedAttentionは、可変なシーケンス長を取り巻く断片化と無駄を削減します — ページド割当は断片化を除去しますが、トークンあたりの保存コストを削除するわけではなく、したがって1つのユニークな128Kリクエストは依然としてそのKV状態に十分なブロックを必要とします。

公式の vLLMメモリ節約ガイド は、メモリが逼迫している場合に max_model_len と max_num_seqs を制限することを推奨し、CUDAグラフが追加のGPUメモリを消費すると注記しています。16 GBのカードでは、両方の設定はモデルの最大設定から継承するのではなく、意図的であるべきです。

集中したシングルシーケンスサーバーはここで開始できるかもしれません：

vllm serve MODEL_ID \
  --max-model-len 65536 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching

すべての16 GB GPU、モデル、量子化方法、またはアテンションバックエンドがその正確な組み合わせをサポートするわけではありません。それを設定の形として扱ってください：長さと並行性を制約し、余裕を確保し、サポートされるキャッシュdtypeを選択し、初期化レポートを検証してください。

vLLMにおけるFP8 KVキャッシュ

現在の vLLM量子化KVキャッシュドキュメント は、互換性のあるCUDAおよびROCmパスでのFP8キャッシュフォーマットをサポートしています。FP8はBF16やFP16に対して生のキャッシュストレージをほぼ半減し、したがってトークン容量または並行性を増大させることができます。

スケーリングが重要です。ドキュメントは、デフォルトのスケール、ウォームアップ計算、データセット較正を区別し、最高精度のためにデータセットベースの較正を推奨しています。単純にスケール1.0でFP8を設定することは便利ですが、自動的に最も信頼できる品質の選択とは限りません。

プレフィックスキャッシュは再利用最適化である

自動プレフィックスキャッシュにより、新しいリクエストが同一のキャッシュされたプレフィックスのKVブロックを再利用できます。同じ長文ドキュメントに対する繰り返しクエリ、共有システムプロンプト、多ラウンド会話に対して優秀です。マッチングするプリフィルの再計算を避けるためです。

ユニークな長文リクエストを小さくしたり、新しいトークンの生成を加速したりはしません。vLLMプレフィックスキャッシュドキュメント は、利益を共有プレフィックスのプリフィル作業に明確に制限しています。

GPUメモリ利用率は無料メモリではない

--gpu-memory-utilization を上げると、vLLMはより大きな予約目標を得ますが、それはVRAMを生み出さないのです。1.0に近づけすぎると、ディスプレイ、他のプロセス、変化する活性化ピーク、またはPyTorch外の割当のために十分な空間を残さなくなる可能性があります。

専用16 GB GPUでは0.88から0.92あたりから開始し、プロファイルを検査し、ワークロードが安定している場合のみ増加してください。初期化に成功したが実際のプロンプトが失敗する場合、アロケータが壊れていると仮定する前に、バッチ化トークン、シーケンス並行性、CUDAグラフキャプチャ、または最大コンテキストを減らしてください。

Ollama：より簡単な制御、より少ない粒度の診断

Ollamaは意図的に小さい操作面を提供しています。その現在の コンテキスト長ドキュメント は、24 GiB未満のGPUを4Kコンテキストにデフォルト設定し、エージェントおよびコーディングワークロードに対して少なくとも64Kを推奨し、大きなコンテキストがより多くのメモリを消費することを警告しています。

サーバー全体のデフォルトを設定し、読み込まれたモデルを確認するには：

OLLAMA_CONTEXT_LENGTH=65536 ollama serve

ollama ps

リクエストまたはモデルごとに num_ctx を設定することもできます。ollama ps は重要であり、その PROCESSOR と CONTEXT 列が、モデルが完全にGPUに留まっているかどうか、および要求されたコンテキストが実際に割当されているかどうかを示すためです。これらの数値の背後にあるスケジュール動作がOllamaのバージョン間で変化することに注意してください。Ollama v0.12.1のメモリ割当の比較は、新しいスケジューラが16 GBカードで一部のモデルをさらにCPUに押し出すことを示しているため、測定したバージョンを固定してください。

Ollamaにおける量子化KVキャッシュ

Ollamaは、その 現在のFAQ で、f16、q8_0、q4_0 の選択肢を持つ OLLAMA_KV_CACHE_TYPE を公開しています。量子化KVはFlash Attentionを必要とし、Ollamaはサポートされるバックエンドで自動的に使用するか、OLLAMA_FLASH_ATTENTION=1 で要求できます。

したがって、16 GBの長文コンテキストサービスは以下のように開始できます：

OLLAMA_CONTEXT_LENGTH=65536 \
OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
OLLAMA_NUM_PARALLEL=1 \
ollama serve

Q8_0はOllamaによるF16への推奨代替案です。FAQはQ4_0がより顕著な品質損失を生じる可能性があり、特に高いコンテキストでのため、測定されたフォールバックであり、自動的な16 GBプリセットであるべきではないと警告しています。

Ollamaの並列性はコンテキスト予算を乗算する

Ollamaは特に明確なルールを文書化しています：必要なメモリは OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH に比例してスケーリングします。32K設定での4つの並列リクエストは、そのモデルに対して128Kの集計コンテキスト割当を意味する可能性があります。

16 GBの個人用エージェントでは、1つの長いセッションが安定するまで OLLAMA_NUM_PARALLEL=1 を保ちてください。2番目のリクエストをキューに並べることは、最初のモデルを部分的にCPUに移動させて両方のリクエストを遅くするよりも通常は望ましいです。その選択の背後にあるキューイング、503、モデルアンロードの仕組みは、Ollamaが並列リクエストを処理する方法に文書化されています。

CPUオフロード：価格を伴う有効な脱出手段

モデルレイヤーやKV状態の一部をシステムRAMに移動することは、割当失敗を動作するプロセスに変えることができます。それはまた、デコードパスにPCIe帯域幅とホストメモリレイテンシを置き、各生成トークンがコストを支払う可能性があります。PCIeが実際に影響を及ぼす时机のレーンと生成のエビデンスは、LLMパフォーマンスとPCIeレーンにあります。

オフロードは偶発的なバッチワークでは合理的ですが、対話的なコーディングエージェントのデフォルトとして最良であることはめったにありません。まず、より小さいウェイト量子化、Q8 KV、並行性の削減、現実的なコンテキスト上限を比較してください。容量がレイテンシよりも重要であるときにオフロードを使用してください。

平均ではなく断崖を観察してください。サーバーは8Kでは素早くデコードするかもしれませんが、ワーキングセットの一部がスパillageした後には激しく遅くなるため、空コンテキストのトークンレートだけでなく、32K、64K、意図した最大値でベンチマークしてください。

スライディングウィンドウおよびアダプティブKVキャッシュ

スライディングウィンドウアテンションは、選択されたレイヤーで最近のウィンドウのみを保持することで予算を変えます。ハイブリッドモデルは、それらのレイヤーを偶発的なグローバルアテンションまたはリカレント状態と組み合わせるため、平坦な完全コンテキストの計算はメモリを大幅に見積もりすぎる、または誤って配置します。

最適化はモデルアーキテクチャの一部であり、結果なく適用できる一般的なスイッチではありません。エンジンは、レイヤーパターン、エビクションルール、位置、およびすべてのグローバルトークンを正しく理解する必要があります。

アダプティブKVが改善しようとするもの

実験的なフォークは、レイヤーごと、コンテキスト深度ごとにキャッシュ精度またはレイアウトを選択することで、さらに進みます。目標は魅力的です：重要な場所で高い精度を維持し、敏感度の低いレイヤーを圧縮し、VRAM圧力がハードなスパillageを引き起こす前にミックスを変更する — 上記で説明されたキーの敏感度がベクトルの敏感度を上回るという発見は、手動の --cache-type-k/--cache-type-v 調整に任せるのではなく、自動的に活用したいシグナルのまさにそのタイプです。

2026年8月の下流プロジェクト、llama.cpp-adaptive-turboquant は、いくつかのレイヤーアダプティブモードの自動セレクタを報告し、RTX 5080 16 GBでの長深度テストを公開しています。これらの数値は特殊なフォークの著者報告結果であり、アップストリームのllama.cppが同じように動作するという証拠ではありません。

なぜ依然として実験的なのか

そのフォークは、カスタムキャッシュタイプ、CUDAカーネル、モデル固有のパス、ツールチェーン制約を組み合わせます。それはアップストリームのキャッシュストレージをF16からQ8_0に切り替えるよりもはるかに多くの信頼を要するコードです。

アップストリームが実際の要件を満たせず、あなたのモデルで品質、安定性、速度を再現できる場合のみ、そのようなフォークを使用してください。コミットとCUDAバージョンを記録してください。プロジェクト名にのみ付随した結果は再現可能ではないためです。

公平なアダプティブキャッシュテスト

フォークを、同じGGUF、プロンプト、サンプラー、コンテキスト深度、出力長を持つアップストリームQ8_0ベースラインと比較してください。起動VRAM、ピークプリフィルVRAM、プロンプト処理速度、デコード速度、およびコンテキストの最古の部分からの証拠を実際に必要とする品質タスクを測定してください。

成功した割当を完全な結果として受け入れないでください。キャッシュは128Kに収まっても、初期の事実を失い、シーケンスの後半で出力を破損し、あるいは有用にするにはデコードが遅すぎる可能性があります。

16 GBチューニング手順の実例：一度に1つの変数

安定した設定への最速の経路は、メモリ次元を一度に1つ変更することです。キャッシュタイプ、バッチサイズ、レイヤーオフロード、並列性、コンテキストをランダムに変更することは、説明のない動作するコマンドを生み出します。

ステップ1：ウェイトのフロアを確立する

8Kコンテキスト、1シーケンス、意図したGPUオフロードでモデルを読み込みます。ウォームアップ後のプロセスVRAMを記録し、レイヤーが予期せずCPUに移動していないことを確認します。

ウェイトとランタイムがすでに約14.5から15 GiB以上を消費している場合、長文コンテキストは健全なマージンがありません。キャッシュをチューニングする前に、より小さいウェイト量子化またはモデルを選択してください。

ステップ2：F16またはBF16 KVを品質ベースラインとして測定する

テストをサポートする最小のコンテキストを実行し、デフォルトの高い精度のキャッシュを保持します。検索、コード編集、ツール選択、長文指示タスクからの出力を保存します。

このベースラインは、後続のエラーがキャッシュ量子化から来るかどうかを示します。それなしでは、チャットテンプレートの問題や弱いモデルがQ4 KVのせいと誤って非難されることが容易です。

ステップ3：Q8またはFP8に移動する

必要に応じてFlash Attentionを有効にし、llama.cppまたはOllamaでQ8_0を選択するか、vLLMでサポートされるFP8モードを選択します。同じトークン深度で同じプロンプトを繰り返し、ログが意図したキャッシュタイプを示すことを確認します。

多くの16 GBデプロイメントにとって、これは有用な停止点です。それは生のKV容量をほぼ倍増させ、キャッシュ圧縮がスタックの中で最も積極的な量子化になることを防ぎます。

ステップ4：コンテキストを段階的に上げる

宣伝されている最大値に直接ジャンプするのではなく、32K、64K、96K、128Kをテストしてください。各段階で、プロンプト処理のトークン/秒、デコードのトークン/秒、ピークVRAM、および開始近くのエビデンスが依然として回復できるかを記録してください。

長文コンテキストデコードは、メモリが収まった後も、アテンションがより多くのキャッシュ状態を読むため、多くの場合遅くなります。容量とパフォーマンスは独立した軸です。

ステップ5：一時的なメモリをチューニングする

失敗が初期化ではなくプリフィル中に発生する場合は、マイクロバッチまたは最大バッチ化トークンを減らします。失敗が同時リクエストでのみ発生する場合は、シーケンス並行性または並列スロットを減らします。

それらの制御が理解された後、初めて混合Q8/Q4キャッシュ、完全Q4キャッシュ、CPUオフロード、またはアダプティブフォークを試すべきです。アップストリームQ8実行を比較ベースラインとして保持してください。後に投機的デコーディングやMTPを追加する場合、そのドラフトバッファが予算方程式のもう1つの行であり、無料の速度ではないことを覚えておいてください — 投機的デコーディングガイドがメカニクスとそのVRAMコストをカバーし、私の Qwen 3.6 27Bと35B MTP対標準ベンチマークは、16 GBカードでMTPヘッドの追加状態がコンテキストにどれほどコストがかかるかを示しています。

長文コンテキストベンチマークに記録すべきもの

単一の tokens/s 数値は、この記事が解決しようとしている正確な問題を隠します。長文コンテキストテストは、もう1人のオペレーターがメモリ境界を再現するために十分な詳細を保持すべきです。

プリフィルとデコードの両方において、nvidia-smi サンプリングまたは同等のベンダーツールを使用してください。エンジンの割当レポートは必要ですが、実際のプロンプト中のピークデバイスメモリが安定性を決定する数値です。

16 GB GPUにおける一般的なKVキャッシュの間違い

128Kサポートをハードウェアの約束として扱う

モデル設定のコンテキストフィールドは、アーキテクチャの上限です。それは、特定のエンジンの特定の量子化を読み込んだ後に残るメモリについては何も言っていません。

キャッシュを計算し、ランタイムを検証してください。マーケティングサイズのコンテキストでVRAM予算なしは、単に最初の重大なプロンプトまで遅延されたOOMです。

ウェイトを量子化したがKVを忘れる

4ビットGGUFはモデルウェイトを削減し、F16 KVキャッシュではありません。長文コンテキストでは、キャッシュは全体の節約を消去し、最終的にウェイトのフットプリントを超える可能性があります。

両方の量子化を報告してください。Q4_K_M モデル, Q8_0 KV は意味があり、4ビットモデル は不完全です。

ページドアテンションがトークンを圧縮すると仮定する

ページングは割当と共有の動作を改善します。それはテンソル精度を変えたり、1つのユニークなシーケンスによって要求されるKV状態を削除したりはしません。

可変ワークロードを効率的にサーブするためにページド割当を使用してください。容量を制御するために、キャッシュ精度、モデルアーキテクチャ、コンテキスト上限、並行性制限を使用してください。

プレフィックスキャッシュがすべての長文プロンプトに役立つと仮定する

プレフィックスキャッシュは、リクエストが正確なプレフィックスを共有する場合に繰り返しプリフィル計算を節約します。1回限りの100Kリポジトリダンプは、プレフィックスキャッシュが有効であるというだけで、魔法のメモリ割引を受けません。

それはワークロード最適化であり、予算方程式の代わりではありません。マルチユーザーサービングでヒット率と保持されたキャッシュ圧力を測定してください。

品質テストなしでQ4 KVを使用する

低ビットキャッシュは微妙に失敗することがあります。モデルは依然として流暢なテキストを書きますが、遠いエビデンス、正確な名前、ツール引数、またはコード依存性へのアテンションが劣化する可能性があります — 上記のトークン分岐研究が示すように、決定論的デコーディング下では、たとえ「安全な」Q8_0設定でも、正確なF16出力を再現することは保証されず、集計精度を維持することのみを保証します。

目標タスクを目標深度でテストしてください。短いチャットベンチマークは、長文コンテキストキャッシュの検証に対してほぼ無用です。

並列性をオートに残しておく

エンジンは、スループットに対して合理的だが、あなたの長文コンテキスト目標に対して不可能な並行性を選択するかもしれません。16 GBでは、1つの深いシーケンスといくつかの短いシーケンスは根本的に異なるワークロードです。

制限を明示的に設定し、測定されたトラフィックで上げてください。さもなければ、2番目のリクエストが安定した64K設定を割当またはレイテンシの驚きに変える可能性があります。

推奨される16 GBプロファイル

これらのプロファイルは、出発点であり、普遍的なプリセットではありません。特別なKV幾何学的構造を持つモデル — 特にMLAまたはハイブリッドスライディングウィンドウ設計 — は、従来のGQA例よりもはるかに安価または高価になる可能性があります。

対話的コーディングエージェント

1シーケンス、48Kから64Kコンテキスト、Q8キャッシュ、Flash Attention、可能な限り完全なGPUウェイト常駐を使用してください。このプロファイルは、印象的だがほとんど有用ではない最大値よりも、予測可能なレイテンシと良好なキャッシュ精度を優先します。

コーディングターンは大きなリポジトリまたは会話プレフィックスを共有することが多いため、エンジンがサポートする場合プレフィックス再利用を有効にしてください。それでもツール出力と古い転記を圧縮してください。キャッシュエンジニアリングが無関連なトークンを価値あるものにするわけではありません。

長文ドキュメント解析

64Kから128K容量、Q8または較準済みFP8キャッシュ、および複数の質問が同じドキュメントを対象とする場合の繰り返しプレフィックスキャッシュを持つより小さいモデルを使用してください。デコードが許容できる場合でもプリフィルが支配的になり得るため、最初のトークンまでの時間を測定してください。

1つの質問のみが尋ねられる場合、検索またはチャンク化要約は、16 GBカードを介して全コーパスを強制するよりも速く、信頼性が高いかもしれません。長文コンテキストはツールであり、情報アーキテクチャの代わりではありません。

小型マルチユーザーサーバー

モデル最大値をすべてのクライアントに宣伝するのではなく、リクエストごとのコンテキストと総アクティブシーケンスを上限設定してください。vLLMのページド割当はここでは有用ですが、Ollamaとllama.cppも集計ライブトークンへの明示的な注意を必要とします。

制御されないスパillageよりもキューイングを優先してください。より遅い承認ポリシーは、すべてのリクエストがデコード中に突然PCIeを越えることよりも害が小さくなります。

16 GB長文コンテキストのための最終推奨

16 GBでの長文コンテキストには、Q8 KVと1つのアクティブシーケンスが正しいベースラインです。それらは、低ビットキャッシュ品質、並列割当、オフロードレイテンシが同時に失敗するのではなく、実際の制限を露呈します。

アテンション幾何学的構造から計算し、ウェイトとランタイムオーバーヘッドを差し引き、その後、エンジンログとピークメモリ測定で結果を確認してください。128Kが依然として収まらない場合、より小さいモデルは最もクリーンな最適化です。収まるが遅い場合、コンテキストの削減が誠実な選択です。

ページドアテンション、プレフィックスキャッシュ、スライディングウィンドウ、アダプティブ精度はすべて、有用だが異なる問題を解決します。勝利する設定は、GPU上に留まり、古いエビデンスを正しく回復し、実際に使用するコンテキスト深度で許容できるデコード速度を維持するものです。

参考文献

• vLLM: conserving GPU memory
• vLLM: quantized KV cache (FP8)
• vLLM: automatic prefix caching
• Ollama: context length documentation
• Ollama FAQ: OLLAMA_KV_CACHE_TYPE and Flash Attention
• llama.cpp-adaptive-turboquant — 実験的なレイヤーアダプティブキャッシュフォーク（著者報告結果）
• Raschka, S. “Multi-Head Latent Attention (MLA).” LLM Architecture Gallery. https://sebastianraschka.com/llm-architecture-gallery/mla/
• “Decoding Multi-Head Latent Attention: The KV Cache Memory Bottleneck, Solved.” Vizuara. https://vizuara.substack.com/p/decoding-multi-head-latent-attention
• “Quantize What Counts: Bit Allocation Insights Informed by Spectral Gaps in Keys and Values.” arXiv:2502.15075. https://ar5iv.labs.arxiv.org/html/2502.15075
• v-code01. “kvdivergence — does KV cache quantization change the generated text under greedy decoding?” GitHub. https://github.com/v-code01/kvdivergence
• Ollamaによる16GB VRAM GPUでのLLMパフォーマンス比較
• Qwen 3.6 27Bと35B MTP対標準 on 16GB GPU