ローカルLLM用PCで最初に見る項目は、CPU名より「使いたいモデルがVRAMまたは統合メモリへ収まるか」です。モデルのparameter数、量子化、context長、同時実行数によって必要量が変わります。
「7Bなら何GBで動く」という表は、重みだけの概算にすぎません。実行時にはKV cache、activation、runtime overhead、OSや他アプリのメモリが加わります。
この記事では、重みメモリの計算、GPU・VRAM・統合メモリの違い、用途別の選び方、購入前チェックシートを解説します。
情報確認日：2026年7月17日（日本時間）
結論：モデル・量子化・contextから逆算する
1. 使いたい用途を決める
2. 候補modelと量子化を決める
3. weightの理論memoryを計算する
4. context・KV cache・runtimeの余裕を加える
5. 実際のmodel fileとruntime表示を確認する
6. 速度と品質を自分の入力で測る
7. 余裕を持つ構成だけを購入候補にする重みメモリを概算する
単純化した理論値は次の式です。
weight memory（byte）≒ parameter数 × 1 parameterあたりのbit数 ÷ 8| モデル規模 | 16-bit重み | 8-bit重み | 4-bit重み |
|---|---|---|---|
| 3B | 約6GB | 約3GB | 約1.5GB |
| 7B | 約14GB | 約7GB | 約3.5GB |
| 14B | 約28GB | 約14GB | 約7GB |
| 32B | 約64GB | 約32GB | 約16GB |
| 70B | 約140GB | 約70GB | 約35GB |
表の注意：上記はparameter数とbit数だけで計算したweightの理論値です。量子化metadata、KV cache、activation、runtime、画像encoder、OS、他アプリ、同時実行分は含みません。購入判断へそのまま使わないでください。
量子化で何が変わるか
量子化は、重みを少ないbitで表現してmemoryと通信量を減らす方法です。一般に16-bitから8-bit、4-bitへ下げるほどweightは小さくなりますが、品質、速度、対応hardwareは方式ごとに異なります。
| 観点 | 確認 |
|---|---|
| 品質 | 自分の評価入力で原版との差を測る |
| memory | model fileとruntimeの実測を確認 |
| 速度 | prompt処理と生成token/秒を別々に測る |
| 互換性 | GPU、runtime、model architectureの対応 |
| format | GGUF等のformatと量子化名を記録 |
context長がmemoryを増やす理由
LLMは入力と生成途中の情報をKV cacheへ保持します。contextを長くするほどcacheが増え、同じmodel・量子化でも必要memoryが増えます。複数sessionを同時に動かす場合はsessionごとのcacheも考慮します。
Ollamaの公式例でも、同じ12B modelで128K contextを使う構成が20GBを超えるVRAMを使用しています。最大contextを常に使わず、実際の文書・会話長に合わせます。
| 増える要素 | 影響 |
|---|---|
| context length | KV cacheが増える |
| batch・同時session | cacheと作業領域が増える |
| 画像入力 | vision encoder等のmemoryが加わる |
| 複数model常駐 | 各modelのweightとcacheが必要 |
| agent・coding | 長いtool schemaと履歴でcontextが増える |
VRAM・RAM・統合メモリの違い
Discrete GPUとVRAM
GPU専用memoryへmodelを収めると高速に実行しやすくなります。VRAMを超えた部分をsystem RAMへoffloadできるruntimeもありますが、転送やCPU処理で速度が落ちる場合があります。
Apple Siliconなどの統合メモリ
CPUとGPUが同じmemory poolを共有します。大きなmodelへ使える利点がありますが、表示、OS、他アプリも同じmemoryを使います。「搭載量すべてをmodelへ使える」わけではありません。
CPUとsystem RAM
GPUなしでも対応runtimeで推論できます。modelを大きなRAMへ置けても、生成速度が用途に合うかは別です。購入前に同等環境でtoken/秒と待ち時間を試します。
| 構成 | 強み | 注意 |
|---|---|---|
| Discrete GPU | 対応modelで高速化しやすい | VRAM上限、電力、driver |
| 統合メモリ | 大きな共有poolをGPUが利用 | OS・他appと競合、増設不可の場合 |
| CPU＋RAM | 大容量RAMを選びやすい | 速度が低い可能性 |
| 複数GPU | 大modelを分割できる場合 | software対応、帯域、電力、複雑性 |
用途別に必要条件を決める
| 用途 | 優先 | 評価入力 |
|---|---|---|
| 短いchat・要約 | 小型model、応答開始の速さ | 普段の10問 |
| coding agent | 長いcontext、tool、生成速度 | 実repositoryの代表task |
| 長文RAG | 検索品質と必要context | 文書と質問30件 |
| 画像入力 | vision対応と追加memory | 実画像と期待回答 |
| 複数利用者 | 同時session、queue、監視 | 想定concurrencyのload test |
購入前チェックシート
- 用途を1つ以上の実taskで定義した
- 候補modelの正確な名前・版・parameter数を確認した
- 使う量子化formatを決めた
- model fileの実sizeを確認した
- runtimeの対応OS・GPU・driverを確認した
- 必要contextを実際の入力から測った
- KV cacheとruntime overheadの余裕を見た
- OS・browser・editor用memoryを残した
- 画像・embedding・rerankerの追加memoryを確認した
- 同時session数を決めた
- prompt処理速度と生成速度を別々に測った
- first tokenまでの時間を測った
- 同じ評価入力で品質を比較した
- 長時間load時の温度・騒音・電力を確認した
- storage容量とmodel更新分の余裕がある
- GPU・memoryを後から増設できるか確認した
- 購入候補と同等環境でdemoを試した
- cloud APIとの総費用を比較した
- 必要性能を満たさない場合のfallbackがある
- 購入直前にmodel・runtime・hardware仕様を再確認した
簡易見積もり表の作り方
候補model:
parameter数:
量子化:
weight理論値:
model file実size:
context:
runtime表示の必要memory:
OS・他appの余裕:
同時session:
実測token/秒:
first token:
評価score:
購入判断:weight理論値だけで判定せず、候補modelを同じruntimeで読み込んだ実表示を優先します。LM Studioの公式requirementsでは、一般的な目安として16GB RAMが推奨され、Windowsでは4GB以上のdedicated VRAMが推奨されていますが、これは大modelが快適に動く保証ではありません。
よくある失敗
- parameter数だけで必要memoryを決める
- 最大contextを使わないのに、そのためだけに過剰構成にする
- modelが読み込めることと快適な速度を混同する
- 統合メモリ全量をmodelへ使えると考える
- 画像・agent・複数sessionの追加memoryを忘れる
- 量子化による品質差を評価しない
- 特定benchmarkだけで購入する
ローカルLLM自体の構成やクラウドとの違いから確認したい場合は、AIの基本も参考になります。
まとめ
ローカルLLM用PCは、model、量子化、context、同時実行から必要memoryを逆算します。parameter×bitの式はweightだけの理論値で、実際にはKV cache、activation、runtime、OSの余裕が必要です。
VRAM容量だけでなく、実際のtaskに対する品質、first token、生成速度、電力、騒音、増設性、cloudとの総費用を比較し、購入直前に現行仕様を再確認してください。