2026年版 ローカルLLMのためのハードウェア選定ガイド:実用的なサイジング
RAM、VRAM、GPUは実際にどれだけ必要なのか — 過剰投資せず、想定外のトラブルにも遭わずにローカルLLMを動かすための、エンジニア向けの実用ガイドです。
なぜこの記事が必要なのか
前回の記事 ローカルLLMモデルを日常業務で活用する方法 では、なぜ ローカルでLLMを動かすのか — プライバシー、オフライン稼働、コスト管理、カスタマイズ性 — について解説しました。
実際に試し始めて5分以内に、誰もがぶつかる質問は同じです:
「結局、自分のマシンではどのモデルがどのくらいの速度で動くのか?」
モデルカードに記載されている「最低要件」は、実運用ではほぼ当てになりません — 多くの場合、楽観的すぎる数字です。本記事は実用版です:現実の数字、正直なトレードオフ、そして2026年4月時点に更新されたハードウェア層別の具体的な推奨構成を提示します。
メモリ計算の基本
最も重要な式は、これだけです:
必要メモリ ≈ (パラメータ数 × 1パラメータあたりのバイト数) + KVキャッシュ + オーバーヘッド
これだけ。あとはこの式の派生にすぎません。
「7B」モデルとは、パラメータ数が70億個あるということ。FP16(1パラメータ2バイト)の精度なら、weights をロードするだけで14 GB必要です。さらに以下も必要となります:
- KVキャッシュ — コンテキスト長とモデルサイズに比例。7Bモデル・コンテキスト8Kなら1〜2 GB、32Kなら4〜8 GB。
- フレームワークのオーバーヘッド — 通常10〜20%。
- アクティベーションメモリ — 推論時は小さいが、ゼロではない。
実用上は、weightsの純粋なサイズに対して20〜30%上乗せして計画してください。FP16の7Bモデルには、14 GBではなく約18 GBの実用メモリが必要です。
これが、ローカルLLMにおいて 量子化(quantization) が最も重要な概念である理由です。
量子化をシンプルに理解する
量子化とは、weightsをFP16(16ビット浮動小数点)から、より低精度の整数表現に圧縮する技術です。モデルの品質は多少低下しますが、メモリ削減効果は劇的です。
| フォーマット | bits/param | 7Bモデル | 14Bモデル | 32Bモデル | 70Bモデル | FP16との品質比較 |
|---|---|---|---|---|---|---|
| FP16 | 16 | 14.0 GB | 28.0 GB | 64.0 GB | 140 GB | 基準値 |
| Q8_0 | 8.5 | 7.5 GB | 15.0 GB | 34.0 GB | 75 GB | ~99% |
| Q6_K | 6.6 | 5.8 GB | 11.5 GB | 26.5 GB | 58 GB | ~98% |
| Q5_K_M | 5.7 | 5.0 GB | 10.0 GB | 23.0 GB | 50 GB | ~97% |
| Q4_K_M | 4.8 | 4.2 GB | 8.5 GB | 19.5 GB | 42 GB | ~95% |
| Q3_K_M | 3.9 | 3.4 GB | 7.0 GB | 16.0 GB | 35 GB | ~90%(劣化が見える) |
| Q2_K | 3.0 | 2.6 GB | 5.5 GB | 12.0 GB | 27 GB | 顕著な劣化 |
実践的な目安:
- Q4_K_M がデフォルトのスイートスポット。理由がない限りこれを使う。
- Q5_K_M または Q6_K はVRAMに余裕があり品質が重要な場合(RAG、コード、推論タスク)。
- Q8_0 はメモリが豊富でFP16近い品質を求める場合のみ。
- Q3_K_M以下 は他に手段がない場合のみ — 品質低下が目に見えます。
これらの数字に、典型的な8K〜16Kコンテキストでは KVキャッシュとオーバーヘッドのために約25%を上乗せしてください。32K以上のコンテキストでは KVキャッシュが急激に増え、メモリの主役を奪うことになります。
KVキャッシュ:見落とされがちなコスト
KVキャッシュはコンテキスト長に比例して増加します。長文RAG、コードリポジトリ、長期にわたるマルチターン会話など、長いコンテキストを使う用途では、小さなモデルではweightsよりもKVキャッシュのほうが大きくなることもあります。
FP16における 1KトークンあたりのおおよそのKVキャッシュサイズ:
| モデルサイズ | 1Kコンテキストあたり |
|---|---|
| 7B | ~150 MB |
| 14B | ~250 MB |
| 32B | ~500 MB |
| 70B | ~1.2 GB |
つまり、32Bモデルで32Kコンテキストを使うとKVキャッシュだけで約16 GBを消費します。これが、長文RAGをやり始めた人が weight のサイズ計算では予測できない OOM エラーに遭遇する原因です。一部の推論エンジン(llama.cpp、MLX)はKVキャッシュの量子化(KV用にQ8またはQ4)に対応しており、KVキャッシュを半分から1/4に削減できます — 通常、品質への影響はほぼ無視できる程度です。ツールが対応しているなら有効化することを強く推奨します。
4つのハードウェア層
2026年のローカルLLM向けハードウェアは、実用上4つの層に分けられます。最も野心的な用途ではなく、主要な 用途に合わせて層を選んでください。
第1層 — エントリー / ノートPCで日常利用
メモリ: 8〜16 GB unified、または 8〜12 GB VRAM
快適に動かせるモデル: 3B〜8B(Q4_K_M)
Tokens/second: 15〜35(チャット用途には十分)
現実的なハードウェア:
- MacBook Air M2/M3/M4 16 GB
- Mac mini M4 16 GB
- ノートPC + RTX 4060 8 GB / 4070 8 GB
- デスクトップ + RTX 3060 12 GB(コスパに優れる)
推奨モデル(2026年4月時点):
- Llama 3.1 8B Instruct Q4_K_M — 汎用性の高いベースライン
- Qwen 2.5 7B Instruct Q4_K_M — 多言語性能が高く、日本語にも強い
- Llama-3-ELYZA-JP-8B Q4_K_M — 日本語特化のチューニング、日本語タスクで実用的
- Gemma 3 9B Q4_K_M — 比較的新しく、効率性に優れる
- Phi-4 14B Q3_K_M — サイズの割に性能が高い、ただし量子化はタイト
できないこと: 本格的な推論タスク、大規模RAG、14B以上のモデルを良質な量子化で動かすことなど。この層はチャット、ドラフト作成、軽いコード補完、簡単な要約に向いています。無理は禁物です。
第2層 — スイートスポット(多くの読者にとって最適)
メモリ: 24〜48 GB unified、または 16〜24 GB VRAM
快適に動かせるモデル: 13B〜14B(Q5/Q6)、32B(Q4)
Tokens/second: 25〜80(モデルとプラットフォームによる)
現実的なハードウェア:
- MacBook Pro M3 Pro / M4 Pro 36〜48 GB
- Mac Studio M2 Max 32 GB
- デスクトップ + RTX 4070 Ti Super 16 GB
- デスクトップ + RTX 4080 16 GB
- RTX 3090 24 GB(中古) — 2026年現在もコスパで圧倒的。秋葉原の中古ショップ、ヤフオク、メルカリで7〜10万円程度で入手可能
- RTX 4090 24 GB(新品)
推奨モデル:
- Qwen 2.5 14B Instruct Q5_K_M — 多言語対応の優秀な汎用モデル(日本語も実用レベル)
- Qwen 2.5 32B Instruct Q4_K_M — クラスを超える性能
- Llama 3.3 70B Q3_K_M — ぎりぎり乗るが品質低下あり、可能ではある
- DeepSeek-R1-Distill-Qwen-32B Q4 — この層で最高峰の推論モデル
- Swallow-70B Q3_K_M — 日本語に強い派生モデル(量子化はタイト)
- bge-m3 または Qwen3-Embedding-0.6B を埋め込みモデルとして併用
実務利用の大半に適した層です:本格的なコーディング支援、社内文書のRAG、長文要約、日本語と英語/中国語のバイリンガル・マルチリンガルワークフローなどに対応できます。
第3層 — パワーユーザー / 小規模チームのワークステーション
メモリ: 64〜128 GB unified、または 32〜48 GB VRAM
快適に動かせるモデル: 32B(Q6/Q8)、70B(Q4_K_M)
Tokens/second: 70Bクラスで10〜25
現実的なハードウェア:
- Mac Studio M4 Max 64〜128 GB
- MacBook Pro M4 Max 64〜128 GB(モバイルワークステーション)
- デスクトップ + RTX A6000 48 GB(ワークステーション向けカード)
- RTX 3090 24 GB × 2枚(合計48 GB、NVLinkは任意)— GBあたりの価格で最良
- RTX 4090 24 GB × 2枚(合計48 GB、NVLinkなし)
- RTX 5090 32 GB シングル(新世代)
推奨モデル:
- Llama 3.3 70B Instruct Q4_K_M — 旗艦的なオープンウェイトモデル
- Qwen 2.5 72B Instruct Q4_K_M — 多言語の旗艦モデル
- DeepSeek-R1-Distill-Llama-70B Q4 — オープンソース推論モデルの最高峰
- Qwen 2.5 Coder 32B Q6_K — 高品質なコーディング専用モデル
この層から、ローカルLLMが本気の業務で実用に足りるレベルになります:適切な量子化を施した70Bクラスのモデルは、多くのタスクで中位クラスのクラウドAPIと遜色ない性能を発揮します。RAG、エージェント型ワークフロー、リポジトリ横断のコード生成 — すべてこの層で実現可能です。
第4層 — エンスージアスト / 本番サーバー
メモリ: 192 GB+ unified、または 80〜192 GB VRAM(マルチGPU)
快適に動かせるモデル: 70B(Q8)、100B+モデル、DeepSeek-V3のようなMoEモデル
Tokens/second: 構成に大きく依存
現実的なハードウェア:
- Mac Studio M3 Ultra / M4 Ultra 192〜512 GB unified
- RTX 3090 × 4枚(合計96 GB)をワークステーションマザーボードに搭載
- H100 80 GB または A100 80 GB シングル(中古市場あり)
- RTX 6000 Ada × 2枚 48 GB
この層では、DeepSeek-V3(671B MoE、活性パラメータ37B) といったモデルも現実的になります — Q4でもweightsだけで350 GB以上必要ですが。MoEモデルは興味深い特性を持ち、トークンごとに一部のパラメータしか活性化しないため、メモリ帯域の高いシステム(Mac Studio Ultraなど)では予想以上のスループットが出ることがあります。
ほとんどの読者にとっては過剰スペックです。5名以上の社内チーム向けにホスティングする、本番RAGを運用する、モデル研究を行うなどのケースでのみ意味があります。
Apple Silicon vs NVIDIA:正直な比較
最も多く受ける質問です。「場合による」が正直な答えですが、判断に役立つ実際的な比較を以下に示します:
Apple Siliconの強み:
- ユニファイドメモリ Mac Studio M4 Max 128 GBが1台あれば、NVIDIA側ではRTX A6000 48 GBや3090×2枚が必要となる70Bモデルをロードできます
- 電力効率 M4 Maxで70Bモデルを動かしても消費電力は約80W。同じ作業が3090×2枚では600W以上に
- 静音・低発熱・安定動作 日本のオフィス・自宅環境では大きな差。デスクトップGPUの騒音は集合住宅では切実な問題
- ドライバ問題なし とにかく動く
Apple Siliconの弱み:
- 同等のNVIDIAハードと比べて推論速度が遅い 70BモデルでM4 Maxは約12〜15 tok/s、3090×2枚は約22〜28 tok/s
- 高容量メモリの単価が圧倒的に高い Mac 128 GBは、3090×2枚の48 GBより遥かに高価
- 学習・ファインチューニングのエコシステムが限定的 推論は問題ないが、MLX以外での学習はかなり厳しい
- CUDAがない 多くのツール、ライブラリ、研究コードがCUDA前提で書かれている
NVIDIAの強み:
- 速度 これに尽きる — 純粋な推論スループットでは NVIDIA が勝ちます
- CUDAエコシステム すべてのフレームワーク、論文、ツールがCUDAを最優先で対応
- 柔軟性 GPUの追加、アップグレードが容易
- 中古市場 RTX 3090 24 GBは秋葉原やヤフオク、メルカリで安定供給あり
NVIDIAの弱み:
- 発熱と騒音 日本の住環境では現実的な問題
- 電力消費 デュアルGPU構成で600W以上
- ドライバ・CUDAバージョンの混乱 何かが壊れることはよくある
- コンシューマ向け単一カードのVRAM上限 24 GBが長らく上限。5090の32 GBもわずかな改善にとどまる
実用的な推奨:
- 個人開発者、毎日使う、静かな環境を希望: Mac。可能な限り大容量のユニファイドメモリを選ぶ
- 個人開発者、速度重視、デスクトップ可: RTX 3090中古、または4090
- 小規模チームでホスティング: RTX 3090×2枚のワークステーション
- 既にハードウェアを持っている場合: 手持ちで進める。両者とも実用範囲
CPUのみではどうか?
動作はしますが、計画の中心に据えるべきではありません。DDR5と最近のCPUなら、7B Q4モデルが4〜8 tokens/秒で動きます — バッチ処理ならぎりぎり使えますが、対話型としては苦痛です。13B以上はCPUでは対話型として実用に堪えません。
サーバーでCPUしか使えない場合は、CPU最適化を全有効にした llama.cpp が選択肢です。ただし正解はたいてい「中古の3090かMac miniを買う」です。
デシジョンツリー
flowchart TD
Start["What is your primary use case?"]
Start --> Daily["Daily chat, drafting, light coding"]
Start --> RAG["RAG over private documents"]
Start --> Code["Serious coding assistant"]
Start --> Reason["Reasoning, analysis, agents"]
Daily --> DailyMem["Need: 16-32 GB unified or 12 GB VRAM"]
RAG --> RAGMem["Need: 32-64 GB unified or 16-24 GB VRAM"]
Code --> CodeMem["Need: 48-96 GB unified or 24 GB VRAM"]
Reason --> ReasonMem["Need: 96 GB+ unified or 48 GB+ VRAM"]
DailyMem --> DailyHW["Mac mini M4 16-32 GB<br/>or RTX 3060 12 GB used"]
RAGMem --> RAGHW["Mac M4 Pro 36-48 GB<br/>or RTX 3090 24 GB used"]
CodeMem --> CodeHW["Mac Studio M4 Max 64 GB<br/>or RTX 4090 24 GB"]
ReasonMem --> ReasonHW["Mac Studio M4 Max 128 GB<br/>or 2x RTX 3090 48 GB"]
よくある落とし穴
繰り返し見る失敗パターン:
- 使いたいモデルではなく、実際に使うモデルに合わせて買う ほとんどのユーザーは、実際には90%の時間を8B〜14Bモデルで過ごしています。月に2回しか触らない70Bのために128 GB買うべきではありません。
- KVキャッシュを無視する 長文RAGはチャットとはまったく別のメモリ問題です。それに合わせてサイジングしてください。
- 「とにかく乗せたい」だけでQ3量子化を選ぶ Q3_K_Mまで落とさないと乗らないなら、より小さいモデルをQ5_K_Mで動かしたほうが品質的にはマシです。
- モデルと埋め込みモデルのメモリ予算を分けて考えていない RAGなら埋め込みモデルとLLMの両方が同時にメモリに乗ります。両方を計算してください。
- OSの分を忘れる 4〜8 GBはOSとアプリのために確保。ユニファイドメモリ全部をLLMに割り当ててはいけません。
- 発熱を甘く見る 日本の夏のエアコンなしの部屋で3090デュアルrigを動かすと、サーマルスロットリングが起きます。換気・冷却を計画してください。
- MoEのメモリを誤解する DeepSeek-V3は「37Bが活性」だと言いますが、671B全パラメータをメモリにロードする必要があります(オフロードもできるがスループットは破綻します)。
実測ベンチマーク(2026年4月時点)
シングルユーザー、コンテキスト約4Kでの推論速度の目安:
| ハードウェア | 8B Q4 | 14B Q4 | 32B Q4 | 70B Q4 |
|---|---|---|---|---|
| MacBook Air M3 16 GB | 22 t/s | OOM | OOM | OOM |
| Mac mini M4 24 GB | 30 t/s | 18 t/s | OOM | OOM |
| MacBook Pro M4 Pro 48 GB | 45 t/s | 28 t/s | 14 t/s | OOM |
| Mac Studio M4 Max 128 GB | 70 t/s | 50 t/s | 28 t/s | 14 t/s |
| RTX 3060 12 GB | 60 t/s | offload | offload | offload |
| RTX 3090 24 GB | 110 t/s | 75 t/s | 35 t/s | offload |
| RTX 4090 24 GB | 140 t/s | 95 t/s | 45 t/s | offload |
| RTX 3090 × 2 (48 GB) | 110 t/s | 75 t/s | 50 t/s | 22 t/s |
| RTX 5090 32 GB | 170 t/s | 115 t/s | 60 t/s | offload |
「OOM」= メモリ不足。「offload」= CPUへの部分オフロード、スループットは5〜10倍低下します。
数字は量子化、コンテキスト長、プロンプト処理、ソフトウェアスタック(llama.cpp / MLX / vLLM / Ollama)によって変動します。約束ではなく、目安として扱ってください。
日本特有の検討事項:個人情報保護法、住環境、SI文化
日本市場ならではの判断要因がいくつかあります:
個人情報保護法・APPIへの対応: 日本企業がローカルLLMに関心を持つ大きな理由のひとつが、顧客データを国外のクラウドに送らずに済むという点です。これは法的リスクと企業ガバナンス両面でのリスク低減になります。個人情報を扱う業務がある企業にとって、第2層〜第3層への投資は十分にペイする可能性があります。
住環境とオフィス環境: 日本のオフィスや自宅は欧米と比べて狭く、デスクトップGPU rigを置く物理的なスペースが厳しい場合が少なくありません。また、騒音にも厳しい文化があり、3090デュアルrigのファンノイズは近隣との関係や集中力に影響します。Mac Studioが日本市場で特に支持される一因です。
SI文化と社内承認: 日本の企業文化では、新しいハードウェア・ソフトウェア導入の社内承認に時間がかかる傾向があります。最初は小さく始めて(Mac mini 24 GBなど)、効果を実証してから上位層に投資する段階的アプローチが現実的です。
中古市場: 秋葉原(TSUKUMO、ドスパラなど)、ヤフオク、メルカリで RTX 3090 24 GB は7〜10万円程度で入手可能です。本格的に始めたいが新品4090(30万円超)には踏み切れない場合の良い出発点になります。
まとめ
ローカルLLM向けの最適なハードウェアとは、KVキャッシュとOSの余裕を考慮したうえで、実際に使うモデルクラスを動かせる最も安価な構成 です。2026年の業務利用者の大半にとっては:
- Mac mini M4 24〜32 GB — カジュアルな日常利用
- Mac Studio M4 Max 64 GB または中古 RTX 3090 — 本格的な業務利用
- Mac Studio M4 Max 128 GB または3090デュアル — チーム規模、または70Bクラスの本格運用
実現する見込みのない野心のために過剰投資しないでください。逆に、節約しすぎて Q3 量子化に頼り品質を犠牲にすることも避けてください。最適は第2層であり、ほとんどの方はそこで快適に運用できます。
ハードウェアが整ったら、次のステップは推論スタックの選択と実業務ワークフローへの組み込みです。これらは別記事で扱っています:
- ローカルLLMモデルを日常業務で活用する方法 — 概念の入門編
- LM Studioにおけるコード向けシステムプロンプトエンジニアリング — モデルの実力を引き出す
- LlamaIndex + pgvector:日本語・タイ語ビジネス文書のためのプロダクションRAG — 実運用のRAG構築
組織導入のためのハードウェア選定 — 複数ユーザー、既存システムとの連携、セキュリティ・コンプライアンス対応 — については別の議論が必要です。お問い合わせ いただければ、適切なサイジングをサポートいたします。
Simplico は、タイ・日本・グローバルのお客様向けにプロダクション品質のAI、ERP、セキュリティシステムを構築しています。工場環境、SOCワークフロー、文書インテリジェンスプラットフォーム向けのローカルLLMスタックの導入実績があります。ローカルLLMプロジェクトを開始するにあたり、ベンダー営業ではなくエンジニアリング視点の助言が必要な場合は、tum@simplico.net または LINE @simplico までご連絡ください。
Get in Touch with us
Related Posts
- オープンソースだけで本番運用できるSOCを構築した話 — Wazuh + DFIR-IRIS + 自社統合レイヤー
- FarmScript:農業IoTのためにDSLをゼロから設計した話
- スマート農業プロジェクトがパイロット段階を脱せずに終わる理由
- ERPプロジェクトが予算オーバー・納期遅延・期待外れに終わる理由
- 耐障害性ドローン群設計:セキュア通信を備えたリーダーレス・トレラント・メッシュネットワーク
- NumPyブロードキャストの法則:`(3,)` と `(3,1)` の動作が異なる理由 ― そして「警告なしに間違った答えを返す」場面とは
- 重要インフラへの攻撃:ウクライナ電力網から学ぶIT/OTセキュリティの教訓
- LM Studioのコーディング向けシステムプロンプト設計:`temperature`・`context_length`・`stop`トークン徹底解説
- LlamaIndex + pgvector:日本語・タイ語ビジネス文書に対応したRAGの本番運用
- simpliShop:受注生産・多言語対応のタイ向けECプラットフォーム
- ERPプロジェクトが失敗する理由と成功のための実践的アプローチ
- Payment APIにおけるIdempotencyとは何か
- Agentic AI × SOCワークフロー:プレイブックを超えた自律防御【2026年版ガイド】
- SOCをゼロから構築する:Wazuh + IRIS-web 現場レポート
- ECと基幹システムの二重入力をなくす:受注から仕訳までの自動化アーキテクチャ
- SIerのブラックボックスから脱却する:オープンソースで構築する中小企業向けSOCアーキテクチャ
- リサイクル工場管理システム:日本のリサイクル事業者が見えないところで損をしている理由
- エネルギー管理ソフトウェアのROI:電気代を15〜40%削減できる理由
- Wazuh + オープンソースで構築する軽量SOC:実践ガイド(2026年版)
- ECサイトとERPを正しく連携する方法:実践ガイド(2026年版)













