lovegamingpcs.com
AI開発環境

ローカルLLMを動かすPCスペック — VRAM別「載るモデル」早見表と、メインRAMで補う方法

ローカルLLM(Ollama / llama.cpp)を動かすPCスペックはVRAM容量でほぼ決まる。パラメータ数×ビット数の計算式、8〜32GBのVRAM別に載るモデル規模の目安、メインRAMへのオフロードを公式ドキュメント基準で整理する。

倉庫の棚にサイズ違いのAIモデルの箱が並び、棚の幅ごとに載る箱の大きさが変わる早見表のイメージ
AI生成のイメージ画像です

ローカルLLMが載るかどうかは、GPUの型番ではなくVRAMの容量で決まる。

「RTX 5070と5060 Ti 16GB、AIならどっち?」——ゲーム脳のままだと答えを間違える。演算性能で上の5070はVRAM 12GB、格下扱いの5060 Tiには16GB版がある(公称値。出典: NVIDIA公式比較表)。

ローカルLLMでは、この4GBの差が「載る/載らない」の分かれ目になる。

この記事は「実際に動かしてみた」記事ではない。Ollama・llama.cppの公式ドキュメントとモデルカードの公称値から、どのVRAMに何が載るのかを電卓で整理したものだ。

見る順番は選び方の記事と同じで VRAM → メインRAM → CPU。

まず計算式。パラメータ数 × ビット数 ÷ 8 = 重みの容量

LLMの本体は「重み(パラメータ)」の塊で、これを丸ごとGPUの作業机(VRAM)に広げてから動かす。必要なVRAMは、ほぼこの式で見積もれる。

パラメータ数 × 1パラメータあたりのビット数 ÷ 8 = 重みの容量(バイト)

8Bモデルを16bit(FP16)のまま置くと 8B × 16 ÷ 8 = 16GB。同じモデルを4bitに落とせば約4GBだ。

ここで出てくるのが量子化。重みの精度を16bitから8bit・4bitへ丸めてサイズを圧縮する技術で、llama.cppは「1.5〜8bitの整数量子化」に対応している(出典: llama.cpp README)。

公称値で確かめると、Llama 3.1 8Bは Q4_K_M で 4.58GiB(1重みあたり約4.9bit)、Q8_0 で 7.95GiB、F16 で 14.96GiB(出典: llama.cpp quantize README)。Ollamaのライブラリでも llama3.1:8b の既定タグは4.9GBで、q4_K_Mタグと同じサイズだ。

Q4_K_Mの「K」はllama.cppのK-quant方式、「M」は中サイズ(S/M/L)。4bitと言いつつ実効4.5bit前後なのは、ブロックごとのスケール値が上乗せされるからだ(出典: Hugging Face GGUFドキュメント)。

忘れがちなのが、重み以外にも机を使うこと。会話の文脈を保持するKVキャッシュと作業領域が上乗せされ、Ollamaの既定コンテキスト長4096トークンを伸ばすほど消費は増える(出典: Ollama FAQ)。

だからファイルサイズ + 余白で見る。段取り八分、余白を先に取っておくのが現場の鉄則だ。

VRAM別「載るモデル」早見表

Ollamaライブラリの公称ダウンロードサイズ(既定タグ、Q4_K_M相当)を基準にした目安だ。「快適」は、重みがVRAMに丸ごと収まり、コンテキスト用の余白が残る状態を指す。

VRAM 該当GPU(公称値) 快適に載る目安 ぎりぎり/工夫が要る
8GB RTX 5060 / 5060 Ti 8GB / 5050 7B〜8Bの4bit(llama3.1:8b 4.9GB、qwen3:8b 5.2GB) 14B級は要オフロード
12GB RTX 5070 8Bの8bit(8.5GB)。14Bの4bit(qwen3:14b 9.3GB)は余白薄め 20B級以上
16GB RTX 5070 Ti / 5080 / 5060 Ti 16GB 14Bの4bit(9.3GB)に余白あり 30B級(19〜20GB)は要オフロード
24GB RTX 50シリーズに該当なし(前世代の上位帯) 30B-A3B MoE(19GB)、32Bの4bit(20GB)が収まる。余白は薄い 70Bは要オフロード
32GB RTX 5090 32Bの4bit(20GB)に長めのコンテキスト余白 70Bの4bit(43GB)は単体では不可

出典: NVIDIA公式比較表(VRAM)、Ollamaライブラリ(llama3.1 / qwen3 各タグの公称サイズ)。

読み方は2つ。「載る」と「快適」は違う——20GBのモデルを24GBに入れると、残り4GBでKVキャッシュと作業領域を賄うことになる。そして70B級(Llama 3.1 70B: 43GB)はコンシューマGPU1枚では4bitでも収まらない。ここから先はオフロードの世界だ。

VRAMが足りないとき: メインRAMに逃がす

載らないモデルは、エラーで止まるか、CPU側へ退避して遅くなる。この「退避」を意図的にやるのがオフロードだ。

llama.cppは公式に「VRAM総容量より大きいモデルを部分的に高速化するCPU+GPUハイブリッド推論」を掲げ、-ngl(GPUに置くレイヤー数)で分担を指定できる(出典: llama.cpp README / server README)。

Ollamaも同じ仕組みで、ollama ps の表示が「48%/52% CPU/GPU」なら、モデルがGPUとシステムメモリに分割ロードされている(出典: Ollama FAQ)。

つまりメインRAMはVRAMの延長戦場になる。32GBか64GBかが、ここで効いてくる。

MoEモデルはオフロードと相性がいい

MoE(Mixture of Experts)型は、総パラメータの一部しか各トークンで動かない。Qwen3-30B-A3Bなら総30.5B・活性3.3B、128のエキスパートのうち8つが動く(出典: Qwen3-30B-A3Bモデルカード)。

llama.cppにはこのMoEの重みだけをCPU側に置く --cpu-moe / --n-cpu-moe N オプションがあり、「毎回動く部分はGPU、エキスパート群はメインRAM」という分担が公式に用意されている(出典: llama.cpp server README)。

メインRAMを128GBまで積めば何が狙えるか、という計算はMiniMax M3の記事でやった。「GPUよりRAMに寄せた構成」がMoE時代の一つの現実解になりつつある。

ただし、オフロードは速度と引き換えだ。VRAMの解説記事で書いた通り、主役はあくまでVRAMだ。

NVIDIAかRadeonか: LLMは両対応、画像生成はNVIDIAが第一導線

LLM推論に限れば、Radeonの立場はかなり改善している。

  • llama.cppのバックエンドにはCUDA(NVIDIA)、HIP(AMD)、Vulkan(GPU汎用)が並ぶ(出典: llama.cpp README)
  • OllamaはNVIDIA(compute capability 5.0以上)とAMD(ROCm v7)に対応、Windows/LinuxではVulkanも既定で有効(出典: Ollama GPUドキュメント)

ただしAMDのROCm対応カードは、WindowsではRadeon RX 7000番台(7900 XTX〜7600)に限られ、Linuxより短いリストだ(出典: 同上)。

画像生成側は差がはっきりする。ComfyUIの公式READMEはNVIDIA(CUDA)向けPyTorchを最初に案内し、AMDはLinuxのROCm、Windowsは別途の専用手順という構成だ(出典: ComfyUI README)。

現場でいえば、NVIDIAは「どの現場でも通る標準工法」、Radeonは「対応現場なら安く上がる工法」。LLMだけなら後者で戦えるが、画像生成まで広げるなら前者の安心感は大きい。

予算別の現実解は、セール表とランキングで

  • VRAMを最優先。同価格帯なら容量の多い方
  • メインRAMは32GBから、空きスロットを確認。MoEオフロード狙いなら64GB以上
  • CPUは足を引っ張らなければいい

20万・30万・40万のどこで何が買えるかは週ごとに動くので、今週のセール機をVRAM基準で仕分けた表と二刀流ランキングに寄せている。型番ではなく「GB」の数字で見てほしい。

「最強の1台」を探すより、「VRAMとメインRAMの2点を外さない1台」を選ぶ。ローカルLLMは、その2点を外さなければ載る。

※本記事は公開情報(各公式ドキュメント・モデルカード・公称スペック)に基づく解説です。動作可否や速度は量子化方式・ランタイム・コンテキスト長・ドライバにより変わります。特定製品の性能はメーカー公式をご確認ください。

出典