ローカルAIにシステムRAMは何GB必要か｜LLM推論と画像生成の消費量を96GB実機で実測

システムRAMとは、GPUのVRAMとは別に本体側へ確保する主記憶のこと。

同じ32GBのメモリでも、載せ方ひとつでAI用途の体感は変わります。ミニPCの検証では、片方が2枚差しのデュアルチャネル、もう片方が1枚差しのシングルチャネルというだけで、実効の帯域が半分近くまで落ちる例が報告されました。容量の数字だけを見て「32GBあるから同じ」と考えると、この差を見落とします。ローカルAIで問われるのは容量だけではありません。どこに、どう載るか。そこまで踏み込んで初めて「何GB積むべきか」に答えが出ます。

システムRAMとVRAMは別物：ローカルAIで効くのはどっち

システムRAMとVRAMは、置き場所も役割も別の記憶領域です。CPUが使う主記憶がシステムRAM、GPUが専有する高速メモリがVRAM。ローカルAIでどちらが効くかは、GPUの種類で答えが変わります。

ディスクリートGPU機、つまりRTX 5080のような独立したグラフィックボードを積んだ構成では、モデルの重みはVRAMに載せて推論します。モデルがVRAMに収まっている限り、システムRAMは主役ではありません。OSやアプリの動作、モデルの読み込み時の一時的な受け皿として働く補助側に回ります。当サイトの検証環境（RTX 5080単体）では、実測で約15.9GiBまでVRAMを使えました。この枠に収まるモデルなら、推論の速度を決めるのはVRAM側です。

一方、iGPU/APU統合メモリ機はまったく別の作りです。CPU内蔵のGPUやAPUは専用VRAMを持たず、システムRAMの一部をVRAMとして共有します。この構成ではRAMの帯域がそのまま描画・推論の性能に直結する。冒頭のミニPCの例がまさにこれで、統合GPUはシステムRAMをVRAM代わりに使うため、デュアルチャネルかシングルチャネルかで実効帯域が大きく動きました。

ディスクリートGPU機とiGPU/APU統合メモリ機の違い

両者を混同すると、必要RAMの見積もりを外します。ディスクリート機はVRAMとRAMが物理的に分かれ、RAMは容量に余裕があれば十分という発想でよい。統合メモリ機はRAM=VRAMなので、容量も帯域も両方が効く。同じ「32GB」でも意味が違うわけです。

VRAMが足りない時に初めてRAMが主役になる

ディスクリート機でもRAMが前面に出る場面があります。モデルがVRAMに収まりきらないときです。VRAMからあふれた分をシステムRAMへ逃がして動かす、いわゆるCPUオフロードに入ると、推論の一部がRAM側で処理される。ここでRAMの容量と帯域が効いてきます。つまりディスクリート機では「VRAMに収まるうちは補助、あふれた瞬間に主役」と覚えておくと見通しが立ちます。

LLM推論でシステムRAMを消費する場面

ローカルLLMがシステムRAMを消費する契機は、モデルロード・CPUオフロード・KVキャッシュの3つに整理できます。それぞれ消費のタイミングも量も違うため、分けて考える必要があります。

まずモデルロード。llama.cppは既定でGGUFファイルをシステムRAMにメモリマップ（mmap、ファイルをメモリ上に対応づけて必要ページだけ読む方式）します。GPUへレイヤーをオフロードしても、OSのページキャッシュやmmapの見え方によって、システムRAM使用量がモデルファイルサイズ相当に見えることがあります。ただし、常にファイルサイズ分を物理RAMとして固定占有するわけではありません。--no-mmap は mmap を無効化する設定です。環境によってページアウトを減らすことはありますが、RAM使用量を常に減らす設定ではありません。また、モデルが総RAM量を超える場合、mmapを無効にすると読み込めない場合があります。

# モデルをロードした状態でVRAMとRAMの占有を確認する
ollama ps
nvidia-smi --query-gpu=memory.used --format=csv

# llama.cpp でmmapを無効化して挙動を比較する場合
./llama-server -m model.gguf --no-mmap -ngl 99

モデルロード時のピークと推論定常時の違い

多くの記事がこの2つを混同します。ロード時は、ファイルサイズ相当がRAMを一気に通過するピークが立つ。推論が定常に入り、重みがVRAMに載りきってしまえば、システムRAM側の実際の常駐はOSのページキャッシュ扱いに変わり、状況に応じて増減します。だから「推論中ずっとファイルサイズ分のRAMを固定で食い続ける」わけではありません。ピーク側で足りるRAMを確保しておくのが安全策になります。

VRAMからRAMへオフロードされるとき何が起きるか

VRAMに収まらないモデルを動かすと、一部のレイヤーがCPU側、つまりシステムRAMへ配置されます。RAMに置かれたレイヤーはCPUと、RAM帯域を使って計算される。このとき推論速度はVRAM完結時より落ちます。どれだけ落ちるかはオフロード比率とRAM帯域しだいで、ここが後述の「帯域が効く局面」につながります。

96GB実機でのLLM推論RAM消費：ロード時ピークと定常

ロード時に見ておきたいRAM余裕は、量子化後のモデルファイルサイズを起点に考えると見積もりやすくなります。当サイトの検証環境（RTX 5080単体・システムRAM 96GB・think=false統一・計測日2026年6月）で扱ったモデルを、この基準で読み解きます。

Qwen3-Coder-30B-A3Bを例にとります。総パラメータ30.5B、アクティブ3.3B（128エキスパート中8を使うMoE構成）のこのモデルは、量子化でファイルサイズが次のように変わります。Q3_K_Mで14.7GB、Q3_K_Sで13.3GB、Q4_1で19.2GB、Q4_K_Mで18.6GB、Q5_K_Mで21.7GB、Q6_Kで25.1GB、Q8_0で32.5GB、UD-Q4_K_XLで17.7GB、BF16では61.1GB（いずれもUnslothのモデルカードの値）。llama.cppのmmap挙動を踏まえると、安全側に見るなら、Q4_K_M（18.6GB）では少なくともその前後のRAM余裕を見ておくと、ロード時の詰まりを避けやすくなります。Q8_0なら32.5GB前後まで見ておく必要があります。

小型モデルはこの負荷がぐっと軽くなります。当サイトの検証環境（RTX 5080単体）では、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）が125.0 tokens/sec・VRAM使用量3664MiB（GPU全体で3.58GiB）、Llama 3.2 3B（Ollama: llama3.2:3b）が151.7 tokens/sec・3098MiB（同3.03GiB）、Gemma 3 4B（Ollama: gemma3:4b）が108.7 tokens/secを記録しました。ここで示したVRAM値はnvidia-smiのmemory.used、つまりデスクトップ表示などを含むGPU全体の使用量で、モデル単体のロード増分そのものではありません。これらの小型モデルはVRAMに余裕をもって収まるため、システムRAMはロード時に一瞬使われるだけで、定常では補助に徹します。

モデルサイズ別のロード時ピークRAM

目安を言葉にすると、RAM側で見るべきピークは「動かすモデルの量子化ファイルサイズ+作業余裕」。30B級のQ4_K_Mなら20GB前後、Q8_0なら35GB前後を確保できれば、ロードで詰まりにくくなります。ここに後述のKVキャッシュとOS・アプリの常用分が乗るため、実際にはさらに上積みして考えるのが現実的でした。

コンテキスト長を伸ばしたときの定常RAM推移

KVキャッシュ（生成済みトークンの中間状態を保持する領域）は、モデル重みとは別枠でコンテキスト長に比例して膨らみます。例として、Llama 3.1 8Bを32Kトークンで動かすとFP16のKVキャッシュはおよそ4.0GB、これをQ8_0に量子化するとおよそ2.0GBまで半減します（insiderllmの解説より）。長文を扱うほどこの分が積み上がるため、コンテキストを伸ばす前提なら、重みのファイルサイズにKVキャッシュ分を足してRAM/VRAMを見積もってください。VRAMに載せきれなければ、あふれた分がRAM側に回ります。

画像生成（ComfyUI / 拡散モデル）のシステムRAM消費

画像生成のRAM消費は、LLM推論とはプロファイルが異なります。ComfyUIはモデルを動的に入れ替えながら動くため、システムRAMが受け皿として大きく働く場面が出てきます。

従来のComfyUIや一部構成では、VRAMを空けるためにモデル重みがRAM側へ退避され、複数モデルを使うワークフローでシステムRAMが大きく膨らむことがありました。ただし、2026年時点のComfyUIではDynamic VRAMにより、NVIDIA環境のWindows/Linuxでモデル重み管理が大きく変わっています。最新版では従来型の「VRAMからRAMへ戻す」挙動が抑えられ、未コミットのファイルバックメモリやオンデマンド割り当てを使ってRAM消費を減らす方向に改善されています。ただし、古いComfyUI・Dynamic VRAM非対応環境・AMD/WSL・特殊ノードや、動画生成・アップスケール系のワークフローでは、依然としてRAMが大きく膨らむことがあります。

拡散モデルの代表格であるFluxで見ると、FP16にControlNetを組み合わせた構成はおよそ22〜24GBのVRAMを要します（gigagpuの検証より）。ただしこの値は公式固定値ではなく、Fluxの種類・text encoder・VAE・ControlNetの有無・解像度・ComfyUI/Forgeなどの実行環境・fp16/fp8/GGUFの量子化・Dynamic VRAM対応状況によって変わる構成依存の検証値です。FP8へ量子化するとこれがおおむね半減し、16GB級のカードでも扱える範囲に入ってきます。VRAMに載りきらない構成では、その差分がシステムRAMへ逃げるため、画像生成でもRAMの余裕がそのまま安定性につながる。

生成中にRAMへ退避される中間データ

従来のComfyUIやDynamic VRAM非対応環境では、直前まで使っていたモデルや一部ノードの処理結果が、次の工程のためにRAM側へ逃がされることがありました。2026年時点のNVIDIA版ComfyUIではDynamic VRAMによりモデル重みのRAM退避は抑えられていますが、アップスケール・動画生成・特殊ノード・AMD/WSL環境では、依然としてシステムRAMを大きく使う場合があります。

LLM推論との消費プロファイルの違い

LLM推論は、重みをVRAMに載せてしまえばRAM側は落ち着く傾向。画像生成は、モデル構成・中間データ・アップスケール・動画生成・Dynamic VRAM対応状況によってRAM使用量が波打ちやすい用途です。同じ「ローカルAI」でも、テキスト生成と画像生成でRAMの効き方が違う。両方を1台でこなすなら、画像生成側の膨らみに合わせてRAMを厚めに積むのが現実的な備えになります。

RAMオフロード推論と帯域感度：チャネル構成の効き方

メモリの帯域が推論速度に効くのは、モデルがRAM側に載る局面です。ここでチャネル構成、つまりシングルかデュアルかが速度を左右します。

冒頭のミニPCの例が示すのは、統合GPUのケースです。統合GPUはシステムRAMをVRAMとして共有するため、メモリのデュアル/シングルチャネル構成が性能を大きく左右し、シングルチャネルは実効帯域をほぼ半減させます。2025年モデルが2×16GBのデュアルチャネル、2026年モデルが単一32GBスティックのシングルチャネルになった結果、特にゲーミング性能が大きく低下しました（この構成差は製品ページに明記されていない点も報告されています）。

ただし、この教訓をディスクリートGPU機へそのまま持ち込むのは早計です。iGPU/APU機はRAM=VRAM共有という別の作りで、帯域の効き方が違う。RTX 5080のようなディスクリートGPUでは、モデルがVRAM内に収まっている限り、システムRAMのチャネル構成が推論速度へ与える影響は小さいと切り分けられます。橋渡しできるのは一点だけ。VRAMからあふれてRAMオフロード推論に入った局面では、ディスクリート機でもRAM帯域が効いてくる。つまり「RAMに載せて動かすなら帯域が効く」という限定的な範囲でのみ、両者は同じ土俵に立ちます。

シングル/デュアルチャネルが効くのはどの局面か

整理すると、帯域が効くのは「統合GPUで常時」と「ディスクリート機でオフロード時」の2局面。VRAMに収まる使い方をするディスクリート機なら、チャネル構成に神経質になる必要はありません。逆に、大型モデルをRAMへあふれさせて動かす前提や、統合メモリのミニPCを選ぶ場合は、容量と同じくらいチャネル構成を確認したいところ。

補足として、オンボードのLPDDR5を採用するノートやミニPCは、メモリが基板に直付けで後から増設できません。購入時に容量を決め切る必要がある。SODIMMやDIMMで増設できる機体とは、この点で選び方の前提が変わります。

用途別に必要なシステムRAMの目安：16/32/64/96GBで何ができるか

ローカルAIに必要なシステムRAMは、モデルサイズ・量子化・コンテキスト長・同時起動の組み合わせで決まり、単一の正解値はありません。その前提のうえで、モデルのファイルサイズを起点にした目安を示します。

数字の根拠はモデルのファイルサイズです。8B級のQ4なら数GB規模なので16GBで足りやすい。30B級MoEのQ4_K_Mは18.6GB、Q8_0は32.5GBなので、ロード時ピークとKVキャッシュ・OS分を足すと32GBは欲しい。70B級はQ4_K_Mで約40GB、Q8で約70GB、FP16で約140GBに達するため、単体マシンで扱うなら64GB以上、量子化を弱めるほどさらに上が要ります。iGPU機はRAMをVRAMと分け合うぶん、同じ用途でも一段厚めに見ておくのが安全でした。

LLM推論に振るか、余裕を持たせるか

ディスクリートGPU機なら、狙うモデルのファイルサイズを基準に「ピーク+KV+常用分」で積めば過不足が出にくい。画像生成やモデルの同時起動まで視野に入れるなら、そこに退避用の余裕を足す。当サイトの検証環境が96GBを積んでいるのは、複数モデルの入れ替えやComfyUIの膨らみを吸収するためで、単一モデルの推論だけならここまでは要りません。

APIベースのAIツール（コーディング等）はRAMが効く

GPUを使わないケースでも、RAMは効きます。ChatGPTやClaudeなどをAPI経由で使うコーディング支援ツールは、推論をクラウド側が担うのでローカルのGPUは不要。その代わり、エディタのインデックスやプロジェクトの展開でCPUとRAM・SSD速度が快適さを決めます。「AI推論にGPUは不要でもRAMは効く」という構図で、これは別記事でGitHub Copilotの推奨スペックとしても扱っています。ローカルLLM入門そのものを知りたい場合は、姉妹サイトの解説（ローカルLLMとは？Ollama × Gemma 4で使うAI環境）も参考になります。

まとめ

システムRAMとVRAMは役割が別で、ローカルAIで効く場面が違います。要点は3つ。ディスクリートGPU機ではVRAMが主役でRAMは補助、あふれた瞬間にRAMが主役へ回る。RAM消費はモデルロード時のピークと推論定常時で挙動が異なり、ロード時のピークはおおむね量子化後ファイルサイズが下限になる。そして同じ用途でも、ディスクリートGPU機とiGPU/APU統合メモリ機で必要RAMの答えは割れます。

次のステップは単純です。まず自分の機体がディスクリートGPU機か統合メモリ機かを確認する。次に主用途のモデルの量子化ファイルサイズを調べ、そこにKVキャッシュとOS・アプリの常用分、画像生成をするなら退避用の余裕を足す。この順で積み上げれば、「何GB必要か」は自分の使い方に合わせて割り出せます。

よくある質問（FAQ）

Q: ローカルLLMではVRAMとRAMのどちらを優先すべきですか？ A: ディスクリートGPU機なら、まずモデルが収まるVRAMを優先します。RAMは重要ですが、モデルがVRAMに収まるうちは補助に回るためです。VRAMからあふれてRAMオフロードに入ると、そこで初めてRAMの容量と帯域が効いてきます。

Q: 16GBのシステムRAMでローカルAIは動きますか？ A: 3〜8B級の量子化モデルなら16GBでも動きます。ただし30B級のQ4_K_Mはファイルサイズが18.6GBあり、ロード時のピークだけで16GBを超えるため厳しい。中型以上を狙うなら32GB以上が目安になります。

Q: 画像生成はシステムRAMをどれだけ使いますか？ A: ComfyUIのRAM消費は、バージョン・GPU・OS・ワークフローで大きく変わります。従来のComfyUIやDynamic VRAM非対応環境では、モデル退避や中間データでRAMが大きく膨らむことがありました。一方、2026年時点のNVIDIA版ComfyUIではDynamic VRAMにより、モデル重みをVRAMからRAMへ戻す従来型の挙動は抑えられています。ただし、動画生成・アップスケール・特殊ノード・AMD/WSL環境ではRAMを多く使う場合があるため、画像生成主体なら32GB以上を見ておくと安全です。

参考資料

• llama.cpp 公式リポジトリ（GitHub）
• Unsloth: Qwen3-Coder-30B-A3B-Instruct GGUF モデルカード（量子化別ファイルサイズ）
• ComfyUI 公式リポジトリ（GitHub）