KVキャッシュのメモリを削減：vLLM FP8設定と回答確認

モデルはプリフィル⁴段階で入力トークン間の関係を計算します。回答を1トークンずつ生成する際には前のトークンを再び参照します。KVキャッシュのkeyとvalueを使えば、前の文脈の状態を最初から作り直さずに計算を続けられます。

関数の説明を受けた後にテストを依頼すると、次のリクエストに元のコードと前の回答が含まれることがあります。新しい質問と出力が文脈に加わるため、モデルファイルが同じでもキャッシュ使用量は変わります。アプリによる古いメッセージの除外や文脈の再構成も影響します。

質問が1行でも、アプリがコードファイル全体や長いPDFを添付すれば入力トークンは増えます。アプリのトークン表示やサーバーログで実際の入力長を確認してください。同時リクエストには個別の状態も必要なので、1人の会話と複数作業の重複を分けて試します。

Q4やNVFP4⁵はモデルの重みの保存形式です。KVキャッシュは実行中に作られる状態で、独自の精度を使います。対応する実行環境では8ビットや4ビットで保存し、長い文脈に必要な容量を減らせます。

キャッシュの変換には計算が加わり、値の精度も変わります。そのためメモリ節約、生成速度、回答の正確さを個別に比較します。短い文脈では変換コストが効果を相殺する場合があり、プリフィル性能もhead dimensionとbackendに左右されます。

以下の例はgpt-oss-20bに対応するvLLM環境で実行します。モデル配置とキャッシュ作成のためのメモリ余裕が必要です。GPU⁶数やメモリ利用率を任意に固定せず、導入したbackendのモデル対応と読み込みログを確認します。

最初のコマンドを実行し、サーバーの準備ができたら別のターミナルでcurlコマンドを送ります。first_item関数はリストの最初の要素を読むため、空リストではインデックスエラーが発生します。回答が原因を説明し、空リストのテストを提案しているか確認して基準結果を保存します。

基準の依頼が成功したらサーバーを停止し、--kv-cache-dtype fp8を加えて再起動します。モデル、文脈、重み形式、同時リクエスト数は維持します。ログでFP8 KVと実際のattention⁷ backendを確認してから、同じcurlリクエストを送ります。

FP8 KVにはGPU、attention backend、モデル構造の対応が必要です。公式のHopper・Blackwell評価はその経路の資料として読み、ほかのGPUでは導入版の対応表を確認します。GPT-OSSのようにglobal attentionとsliding-window層が混在するモデルでは、短い窓の層を標準精度のままにする設定も比較できます。

2つ目のコマンドの--kv-cache-dtype-skip-layers sliding_windowがその選択肢です。対応するビルドで全層FP8とskip-layer設定を個別に実行し、同じ関数の質問を送ります。

モデル読み込み後、準備用リクエストを除いて繰り返し測定します。TTFT⁸、トークン間遅延、完了時間、peak GPU memoryを記録し、まず1リクエストずつ比較します。長い文脈や同時利用が目的なら、その後に入力長かリクエスト数を1つずつ増やします。新しい入力とprefix再利用の入力も分けて記録します。

空リストのエラー説明と提案されたテストを実際のコードと照合します。複数の関数質問をあらかじめ用意して同じ方法で比較すれば、1つの質問の偶然に頼らずに済みます。速度差が小さくても、長い入力をメモリに収めたり多くの依頼を安定して終えたりできれば目的に合った改善です。

キャッシュ上限や古い状態の削除を使う場合は、会話の最初に渡した情報を後でも回答できるか確認します。 新しい会話では正しく、続いた会話だけで失敗する場合は、実際に送信したメッセージと状態保持設定を照合してください。アプリ全体のメモリグラフは不足の時点を探すために使い、KVキャッシュ自体はサーバーの指標で確認します。

dtypeやbackendエラーで起動できなければ、FP8オプションを外して基準コマンドを再実行します。FP8だけが失敗するならキャッシュ対応を確認してください。標準設定も失敗する場合はモデル対応、ドライバー、導入版を先に調べます。

長い依頼でメモリが不足したら、文脈か同時リクエスト数を1つずつ減らします。回答がコードの条件を繰り返し見落とすなら標準精度に戻して同じ質問を比較します。必要な文脈と同時数で正確さと安定性を保てる設定を残してください。