memory & vram / pillar

LM StudioのメモリとVRAMの目安｜ファイルサイズ・KVキャッシュ・コンテキスト長を統合解説

「モデルが動くか」はメモリ(RAM)だけで決まるわけではありません。VRAM、ファイルサイズ、KVキャッシュ、コンテキスト長、GPUオフロードが絡みます。 本ページでは、各がどう消費されるかを仕組みから説明し、自分の環境での判断の仕方をまとめます。

読了後に判断できること：空きRAM/VRAMの確認、KVキャッシュの増え方、オフロードの意味、 「動かないときの切り分け」の手順。数値はあくまで目安であり、精密値は環境依存です。

RAM / VRAM / ストレージの違い

3つのメモリの役割
項目役割GGUF選びでの意味
ストレージ(SSD/HDD)ファイルの保存場所GGUFファイルサイズの置き場。実行時メモリではない。
RAM実行時の作業メモリCPU動作や部分的なオフロードで消費。
VRAMGPUの専用メモリGPU全オフロード時はここが主戦場。
重要：「ファイルサイズ＝必要メモリ」ではありません。ロード時の追加メモリやKVキャッシュで、 ファイルサイズより多く消費するのが一般的です。また 空き（available） RAM/VRAM を見ます。 OSや常駐アプリが使っている分は引かれます。

共有メモリと iGPU

Apple Silicon や一部の APU/SoC では、RAM と VRAM が 統合（unified memory） されています。 この場合「RAM と VRAM の合計」ではなく、共通のメモリプールからモデルも描画も消費します。 一方、Intel/AMD の内蔵GPU（iGPU）は、BIOS で確保した 共有メモリ を使うことがあり、 システムから見える空きRAM が減る場合があります。

どちらが自分の環境かは、OSのシステム情報（macOS「このMacについて」、Windows「タスクマネージャー」の パフォーマンスタブ等）で確認してください。数値を断定する前に、まず「自分の空き状況」を観察します。

何がメモリを食うか

ローカルLLMの実行時、大きく次のものがメモリを消費します。

メモリ消費の要素
要素概要増減の鍵
weight fileモデル重み本体（量子化済み）量子化精度・モデル規模
mmapファイルをメモリにマップして読む仕組み実装・OS依存。全ロードとは限らない
KV cacheコンテキストの「記憶」保持分コンテキスト長・アーキテクチャ
compute buffer計算の中間バッファバッチサイズ・実装
context / flash attnコンテキスト処理の設定長くするほど増大
vision / MoEマルチモーダル・専門層モデル構成依存

「計算バッファが何GB」などの精密値は、モデル・実装・設定で変わるため、ここでは範囲の目安として扱います。

KVキャッシュの増え方（目安）

KVキャッシュはコンテキスト長にほぼ比例して増大します。理論的な目安式と、仮モデルでの例は コンテキスト長とKVキャッシュ で詳しく扱っています。 要点：コンテキスト長を2倍にすると、KVキャッシュも約2倍になる傾向があります。

長い履歴が不要なら、既定値（多くは8k付近）から始めるのが無難。長くしすぎてメモリ不足になるケースを避けられます。

GPUオフロード

GPUオフロードは、モデルの層をどれだけ GPU（VRAM）へ載せるかを決めます。 全層を載せる（full offload）なら VRAM が主戦場になり、載せきれない分は RAM（CPU）へ回ります（部分オフロード）。

ここでも断定しない：部分オフロード時の「VRAM使用量は層数に比例する」という単純な倍数は、 配置ルール・実装・活性化タイミングで変わるため使いません。LM Studio の --estimate-only や 実測（コマンド作成ツール）で確認するのが確実です。

decision tree（動かないときの切り分け）

  1. 自分の 空きRAM と（あれば）空きVRAM を確認する。
  2. モデルの規模・量子化を、チェッカーで「まず試す」候補に下げる（例: 7Bなら Q4_K_M から）。
  3. コンテキスト長を既定値（8k付近）に戻す。
  4. GPUオフロードを下げる（部分オフロード、あるいは一旦CPUのみ）でロードできるか試す。
  5. それでもダメなら、より小さいモデル・軽い量子化を選ぶ。

これは「目安の手順」です。正確なエラー原因はログ・バージョンを確認（トラブルシューティング）。

具体例（仮定付き・目安）

環境別の目安（あくまで一般的な目安）
環境まず試す注意点
8GB RAM / GPUなし1B〜3B / 軽量Q4系7B以上は重い。CPU動作で遅くなりやすい。
16GB RAM7B〜8B / Q4_K_M14B以上・Q8_0は重くなりやすい。
32GB RAM / VRAM 8GB7B〜14B / Q4_K_M・Q5_K_MVRAMに載る範囲を確認。長いコンテキストは注意。
64GB RAM / VRAM 12GB+より大きいモデルも候補GPU/速度/同時アプリに注意。

上の「まず試す」は仮定付きの目安。OSと常駐アプリを除いた空きRAM、同時に使うアプリのメモリも影響します。 特に unified memory 環境では「合計」ではなく「空きプール」で考えます。

確認シート（ご自身で埋める）

自分の環境チェック
項目あなたの値
空きRAM（OS起動直後）＿＿ GB
空きVRAM（GPUありの場合）＿＿ GB
試したいモデル規模＿＿ B
量子化＿＿（例: Q4_K_M）
コンテキスト長＿＿（既定値から開始推奨）
GPUオフロード＿＿（full / 部分 / CPU）

架空の数値は入れません。ご自身の環境の実測値を記入してください。

適用外と限界

  • 本ページの数値は目安。精密値はモデル・量子化・ハードウェア・実装・設定に依存。
  • 「計算バッファが○GB」等の固定値は使いません（環境依存）。
  • unified memory と 専用VRAM では、余裕の計算が変わります。
  • 常駐アプリ・ブラウザの消費も無視できません。実測値で判断。

よくある質問

「VRAM 8GB だと何Bまで？」
一概には言えませんが、7-8B の Q4_K_M 程度が現実的な目安です。メモリに余裕がなければ 3B クラスも選択肢に。
「システムRAM と VRAM、どちらが重要？」
GPUで動かすなら VRAM がボトルネックになりやすいです。VRAM不足なら CPU/統合GPUへオフロードしますが、速度は落ちます。
「計算バッファは何GB？」
固定値ではなく、実装・設定・コンテキスト長で変わります。本サイトは固定係数を使わず、相対的な余裕で判断します。
「チェッカーの数字は正確？」
目安です。実際の使用量は環境で変わるため、まずは「動くか」を実測で確認するのが確実です。
チェッカーで選ぶ KVキャッシュの仕組み resource estimate コマンド ロードできない時は

更新履歴：2026-07-18 Pillar 拡張（unified/shared、消費要素、offload、decision tree、worksheet、限界を追加）。