ローカルLLMのメモリ｜長い文書を扱う余裕まで確かめる

手元のパソコンで、長い議事録を読ませたい。モデルを選ぶとき、ダウンロード容量と空きメモリを比べるだけでは、会話の分を見積もれません。推論には重みのほかに、処理済みの文章に対応するキャッシュや作業用の領域も必要です。¹²

議事録なら、担当者と期限を拾う、といった確認項目を先に決めておくと比べやすくなります。これは評価用の課題の例で、測定済みの成績ではありません。答え合わせの際は、回答の文言だけでなく、議事録のどの箇所に根拠があるかも記録します。表現が自然でも必要な担当者を取り違えていれば、その設定は見直す。先に確認項目を決めれば、保存容量以外の判断材料も残せます。

確認したいのは、いつものアプリを開いた状態で、目的の文書を処理して回答まで出せるか。メモリの使い道は、公式資料から次のように整理できます。特定の機種で測定した結果は扱いません。

読み込む重みと、実行中の領域を分ける

重みには、学習で得たパラメータが保存されています。量子化は保存する数値の精度を下げ、必要なメモリを減らす方法です。精度をできるだけ保つ工夫はありますが、品質への影響は検討が必要です。日本語の公式資料でも、量子化する層と他のモジュールで精度が異なる例が説明されています。³⁴

計画段階では「常駐する重み＋KVキャッシュ＋一時的な計算領域＋実行時の割り当て」を概算の内訳にすると整理できます。ほかのアプリが使う分も残します。これは共通の計算式ではありません。CPUとGPUへの配置で負担する領域が変わり、読み込み中と生成中では最大使用量も異なります。¹⁵²

全パラメータを同じビット幅で隙間なく保存すると仮定すれば、「パラメータ数×ビット数÷八」で重みのバイト数を概算できます。実際には量子化の定数や別精度の層もあるため、ファイルと実行時の報告で補正します。この概算にキャッシュは含まれません。³⁶

KVキャッシュには文章の長さが効く

自己回帰型のTransformerは、それまでの文脈を使って次のトークンを生成します。KVキャッシュは、処理済みトークンの注意機構のキーと値を保存し、計算を再利用する仕組みです。学習済みの重みとは別に、要求ごとの状態を持ちます。¹

動的キャッシュは生成が進むと増えます。静的キャッシュは最大サイズを先に確保するので、短い会話でも予約領域が大きい場合があります。スライディングウィンドウやチャンク型の注意機構を使う層では、対応する範囲で増加が止まります。モデルを変えたら、同じ増え方をするとは限りません。⁷

通常の全注意機構を想定した概算には、保持するトークン数、同時処理する系列数、層数、KVヘッド数、ヘッドの次元、キャッシュ精度が関係します。パラメータ数だけでは、この条件は決まりません。長さの影響を比べるなら、モデルと精度を固定します。¹⁷

入力文書だけで枠を使い切らず、回答の分も確保したいところです。指示文や履歴を含む実際の入力形式でトークン数を確認し、必要な回答量と合わせてコンテキストを設定します。¹⁸

同時に動く要求の数も決めておく

Ollamaは、コンテキストを長くすると必要なメモリが増えると説明しています。同じモデルで要求を並列処理する場合も、その数に応じてコンテキストの割り当てが増えます。重みの共有と、要求ごとの状態は分けて考える必要があります。⁹⁸

個人で使うなら、まず逐次処理で長い文書が最後まで扱えるかを確認できます。共有する場合は、長い要求が重なる状況も試します。待機列にある要求と実行中の要求は同じではなく、Ollamaにも並列処理と待機列を調整する別々の設定があります。⁹

ollama psで、割り当てられたコンテキストとCPU・GPUの配置を確認します。比較時は長さを明示しておくほうが確実です。現在、FAQとコンテキストガイドには既定値の説明に差があるため、記憶した値を前提にしないようにします。⁹⁸

重みを量子化しても、キャッシュの設定は別

llama.cppには、キーと値のキャッシュ型をそれぞれ指定する項目があります。OllamaにもKVキャッシュの量子化設定があります。重みのファイル名から、実行中のキャッシュ精度までは判断できません。使っているバックエンドで対応状況を確認します。⁹¹⁰

設定を変えたら、手元の仕事で答えを比べます。たとえば文書中の細部を抜き出す課題を用意し、正解と照合する。出力形式に条件があるなら、その条件も固定します。量子化の影響はモデルや課題によって変わるとOllamaも説明しているので、どの用途でも同じ品質を保つとは言えません。⁹

メモリ削減と速さも別々に確認します。Transformersの資料は、短い文脈でGPUメモリに余裕がある場合、キャッシュの量子化が遅延を悪化させる可能性を挙げています。容量の問題がどこにあるかを確かめてから、設定を一つずつ変更します。⁷

比較用の文章は、そのまま保存しておきます。短く編集して動くようになっても、削った箇所が仕事に必要なら、当初の目的は満たせません。必要な資料の範囲と、待てる時間を先に決めておく。その条件で答えを照合すれば、容量を減らすために何を諦めたかも判断できます。

使用量の表示を、そのまま足し算しない

PyTorchのCUDA環境では、テンソルが使っている量と、キャッシュ用アロケータが確保した量は異なります。memory_allocated()とmemory_reserved()はそれぞれを観察する値です。未使用の予約領域も、nvidia-smiでは使用中に見える場合があります。両者には重複があるので合計しません。⁵

empty_cache()が解放するのは、使われていないキャッシュ領域です。使用中の重みやKVテンソルは残ります。llama.cppを使っている場合は、その実行環境の報告を確認します。PyTorchの関数名をすべての環境に当てはめることはできません。⁵¹⁰

CPUに分担させたあとの待ち時間を測る

llama.cppはCPUとGPUを組み合わせた推論に対応し、GPUに置く層数を指定できます。Transformersのキャッシュ退避は、多くの層のKVキャッシュをCPU側に置き、必要に応じて転送する方式です。どちらの対象を移動したか、設定を記録しておきます。⁷¹⁰¹¹

専用VRAMとシステムメモリは別々に見積もります。キャッシュの退避では、転送によって生成の処理速度が落ちる可能性が公式に説明されています。機種を問わず使える減速率はここでは示せません。同じ文書を使い、最後の回答までの待ち時間を比べるのが判断材料になります。⁷²

メモリ不足の発生段階で、調べる場所を絞れます。表は原因の断定ではなく、確認の出発点です。

状況	調べる対象	比較する条件
読み込み中に失敗する	重み、配置、読み込み時の最大使用量2	小さいファイルで再確認
長文を渡すと失敗する	コンテキストとKVキャッシュ78	同じモデルで長さを短縮
要求が重なると失敗する	並列処理の割り当て9	同じ課題を逐次処理
終了後もGPU使用量が高い	PyTorchの使用中領域と予約領域5	allocatedとreservedを照合
CPU分担後の応答が遅い	転送と実行の負担72	配置だけを変えて比較

モデルファイルと実行環境の版、文脈の長さ、キャッシュ精度、配置、同時処理数を残します。読み込みと入力処理、回答生成まで観察し、次の更新でも同じ文書で確かめる。その記録があれば、変更後の品質と待ち時間を比較できます。¹²

参考文献

Footnotes

1. Hugging Face Transformers — 英語原文。KVキャッシュの仕組みとテンソルの次元：https://huggingface.co/docs/transformers/en/cache_explanation ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Hugging Face Accelerate — 読み込み時の使用量とデバイス配置を説明する英語資料：https://huggingface.co/docs/accelerate/en/concept_guides/big_model_inference ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. Hugging Face Transformers — 現行の英語版。重みの量子化と精度の取捨選択：https://huggingface.co/docs/transformers/en/quantization/overview ↩ ↩²

4. Hugging Face日本語資料 — v4.43.3の量子化説明。用語と層ごとの精度の確認に使用し、現行の対応状況は英語版で確認：https://huggingface.co/docs/transformers/v4.43.3/ja/main_classes/quantization ↩

5. PyTorch CUDA資料 — 使用中のテンソル、予約領域、キャッシュ解放の英語公式説明：https://docs.pytorch.org/docs/2.14/notes/cuda.html ↩ ↩² ↩³ ↩⁴

6. Hugging Face bitsandbytes — 現行英語版。量子化定数とモジュールの精度：https://huggingface.co/docs/transformers/en/quantization/bitsandbytes ↩

7. Hugging Face Transformers — 動的・静的キャッシュ、量子化、CPU退避の条件を説明する英語資料：https://huggingface.co/docs/transformers/en/kv_cache ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

8. Ollama — 文脈の長さとメモリ、実際の設定確認に関する英語公式資料：https://docs.ollama.com/context-length ↩ ↩² ↩³ ↩⁴

9. Ollama FAQ — 並列処理、配置、待機列、キャッシュ量子化の英語公式資料：https://docs.ollama.com/faq ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

10. llama.cpp server — GPU層数とK/Vキャッシュ型の公式仕様：https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md ↩ ↩² ↩³

11. llama.cpp — CPUとGPUを組み合わせた推論の公式概要：https://github.com/ggml-org/llama.cpp/blob/master/README.md ↩