Local / Edge実践ガイド

ローカルLLMのOut of Memoryを直す方法|VRAM不足の確認順

ローカルLLMのOut of Memoryを直す方法 — VRAM不足の確認順
目次

ローカルLLMでOut of Memory(OOM)が出ても、原因が単純な「GPUのVRAM不足」とは限らない。モデルの重みに加え、KVキャッシュ、ランタイムの作業領域、GPUとCPUへの配置などが実行時メモリへ影響する。

対処は、コンテキストとKVキャッシュ → 量子化・モデルサイズ → GPU/CPUオフロード → ハードウェアの順で進めると無駄が少ない。一度に複数の設定を変えず、どの変更でOOMが解消したかを確認する。

1. OOMが起きる場面を確認する

最初に、どの段階でメモリ不足になるかを見る。

  • モデル読み込み時
  • 長いプロンプトを処理したとき
  • 生成を始めたとき
  • 複数リクエストを同時に処理したとき
  • コンテキストを大きくしたとき

同時に、モデル名、量子化、ランタイム、コンテキスト長、GPU/CPU配置、エラー全文を確認する。

GGUFやsafetensorsのファイル容量は保存する配布物の大きさであり、推論時のピークVRAMそのものではない。メモリ不足を考えるときは、ファイルサイズと実行時メモリを分ける必要がある。

詳しくはLLMのファイルサイズ・VRAM・RAM・実行時メモリは何が違う?で整理している。

2. まずコンテキストを下げる

長いコンテキストを設定している場合は、最初に実際の用途で必要な長さまで下げる。

LLMは過去トークンのKey/Valueを保持するKVキャッシュを使う。標準的なキャッシュでは、保持するトークン列が長くなるほど必要なメモリも増える。

モデルが128Kや256Kへ対応していても、普段32Kしか使わないなら最大値を常時確保する必要はない。コンテキストを下げてOOMが消えるなら、モデル本体を変更せずに解決できる可能性がある。

KVキャッシュとメモリの関係はKVキャッシュとは? 長いコンテキストでVRAMが増える理由で確認できる。

3. 次に量子化を小さくする

必要なコンテキストまで下げても収まらない場合は、同じモデルのより小さな量子化を検討する。

たとえばQ6やQ8を使っているなら、用途に応じてQ5やQ4系を候補にできる。ただし、量子化名だけで必要VRAMや品質差を固定することはできない。

確認するのは、実際の配布ファイル、ランタイム対応、チャットテンプレート、コンテキストを含む実行条件だ。

量子化の選び方はGGUFのQ4・Q5・Q6・Q8はどれを選ぶ?で詳しく説明している。

4. それでも足りなければモデル自体を小さくする

量子化を下げてもOOMになる、または品質上これ以上量子化を下げたくない場合は、一段小さいモデルが候補になる。

大きなモデルを強くCPUへオフロードするより、小さいモデルをGPU中心で実行した方が用途によっては扱いやすい場合もある。

モデルを変えると回答品質や機能も変わるため、単純にパラメータ数だけで置き換えず、実際の用途を満たすか確認する必要がある。

5. partial offloadでCPUとRAMを使う

モデルをGPUへ全量配置できない場合、LM Studioやllama.cppなどでは一部をCPUとシステムRAMへ置くpartial offloadを利用できる。

これによりVRAM不足でも起動できる場合があるが、CPU計算やデバイス間転送が増えるため、全量GPU配置と同じ速度になるとは限らない。

オフロードを試すときは、モデル、量子化、コンテキストを固定し、GPUへ置く量だけを変更する。起動できたかだけでなく、最初の応答までの時間や生成速度が用途に合うかも確認したい。

GPUオフロード・CPUオフロードとは?では、full GPU配置とpartial offloadの違いを整理している。

6. RAMを増やせば必ず解決するわけではない

partial offloadを使う場合はシステムRAMの余裕が役立つ。ただし、RAMはVRAMと同じ性能のメモリではない。

RAMへモデルを置けることで起動条件が広がっても、CPU側の処理が増えれば待ち時間は長くなる可能性がある。また、ランタイムやモデルによってオフロードできる範囲も異なる。

そのため「VRAM不足ならRAMを増やせば解決」という固定した判断はできない。

7. 最後にGPUやPC構成を見直す

コンテキストを必要な長さへ下げ、量子化とモデルサイズを検討し、partial offloadも試したうえで必要な速度を満たせないなら、ハードウェア側の容量不足が購入判断の材料になる。

この段階で確認したいのは、単に「OOMが出た」ことではなく次の条件だ。

  • 必要なモデルと量子化
  • 普段使うコンテキスト長
  • GPUへどこまで配置したいか
  • CPU offloadを許容できるか
  • 必要な応答速度
  • 現在のVRAMとRAMでどこまで不足するか

ここまで分かれば、より大きなVRAMが本当に必要なのか、モデルや設定で十分なのかを判断しやすい。

GPU容量を選ぶ段階ではローカルAI向けGPUは16GB・24GB・32GBのどれを選ぶ?が参考になる。

OOM対策では、最初からGPU交換を答えにしない。必要なコンテキストへ下げる → 量子化・モデルを見直す → offloadを試す → それでも不足する場合にハードウェアを増やすという順なら、設定で解決できる問題と本当の容量不足を分けやすくなる。

まとめ

  • OOMはモデル本体だけでなく、KVキャッシュ、作業領域、GPU/CPU配置などを含む実行時メモリ不足で起きる
  • 最初に必要以上に大きなコンテキストを下げ、同じモデル・量子化で再試行する
  • 次に小さい量子化やモデル、partial offloadを順番に試し、起動できることと実用速度を分けて確認する
  • 必要なモデル・コンテキストを満たせないことが確認できてからVRAMやRAMの増設・GPU交換を検討する

公式サイトで次に進む

この記事で明示的に扱うソフトだけを表示します。配布・手順は各公式ページで確認してください。

local-gen.jpがファイルを配布するものではなく、互換性を保証するものでもありません。

同じテーマから

この記事で扱ったデータ

モデル・GPU・実行ソフトの確認済みデータを、記事とは別に確かめられます。

サイト内検索