GPUなし（CPU）で動かすローカルLLM：RAM容量8/16/32別のモデル GB

#GPUなしでローカルLLMを実行するのはなぜ？

ローカルAIのガイドはどれも、タワー型PCにRTX 4070を搭載していることを前提にしています。実際には、ノートPC、業務用デスクトップPC、ミニPCの大多数は内蔵GPUで動作しているか、専用のGPUカードをまったく搭載していません。うれしいことに、LLMはCPUだけでも動作します。

CPUのみでの実行を選ぶ典型的な理由は3つあります。NVIDIA GPUを搭載していないノートPC（DellやLenovoの大半の機種、旧型のIntel搭載Mac）、IntelまたはAMDのiGPUを搭載した業務用デスクトップPC、あるいはGPUを追加したくないヘッドレスLinuxサーバーです。いずれの場合も、問題は「動くかどうか」ではなく「どのモデルなら実用的に使えるか」です。

#実際の利用で期待できる内容

何かをダウンロードする前に、どの程度の性能を期待できるかを確認しておきましょう。GPUを使わずCPUで動かすローカルLLMは、ChatGPTやRTX 4090で動かすモデルと同じ応答速度ではありません。2026年に現実的に期待できる性能の目安は以下のとおりです：

1B–2B モデル Q4

最近のCPUで20～40トークン/秒。非常にスムーズで、オンラインチャットに近い使い心地です。言い換え、短い要約、分類といった簡単なタスクに最適です。

3Bモデル Q4

10～20トークン/秒。この速度でも快適に使え、モデルが文章を生成するのと同時に読み進められます。CPUで日常的に使うには、ちょうどよいバランスです。

7B～8B Q4 モデル

4〜10トークン/秒。実用にはなりますが、待ち時間があります。非同期タスク（テキストの分析、下書きの生成）に適しています。

13B～14BのQ4モデル

2〜5トークン/秒。許容範囲の限界です。バッチ処理に限って使用し、インタラクティブなチャットには適しません。

14B を超える場合

可能ですが、かなり厳しいです。CPU で 32B モデルを動かすより、クラウド GPU を 1 時間借りるほうがよいでしょう。

#利用可能な RAM に基づくおすすめモデル

CPUで実行する場合、システムRAM全体をモデルに使えますが、OSやアプリケーションのための余裕を残す必要があります。システム用に4〜6 GBを確保するものと考えてください。残りのメモリ量によって、実行できるモデルのサイズが決まります。

#8 GB の RAM：2B から 4B のモデル

Qwen 3.5 2B Q4_K_M

約1.9GB。非常に高速でマルチモーダルに対応し、コンテキストは最大256k。ライセンスはApache 2.0です。言い換え、翻訳、分類に適しています。

Granite 4.2 3B Q4_K_M

約 2.2 GB。非常に省リソースで、トークン効率も高い IBM 製モデルです。ライセンスは Apache 2.0。フランス語も上手に使えます。

Qwen 3.5 4B Q4_K_M

約3.4 GB。新しいデフォルトの小型モデル。コードやフランス語での処理がしっかりしています。

Gemma 4 E2B Q4 (QAT)

≈4.3 GB。Googleが開発したコンパクトでマルチモーダルなモデルで、2026年にApache 2.0ライセンスに移行しました。

#16GBのRAM：8B～12Bは快適です

Granite 4.2 8B Q4_K_M

約5.3 GB。トークン効率が非常に高く、128kのコンテキストに対応。Apache 2.0ライセンス。読み込みが速いです。

Qwen 3.5 9B Q4_K_M

約 6.6 GB。2026年の 8 GB 環境では決定版の選択肢です。256k のコンテキスト、画像対応、推論にもフランス語にも優れています。

Gemma 4 12B Q4_K_M

約7.6GB。マルチモーダルで効率的なモデルで、ライセンスはApache 2.0です。RAM容量に余裕があれば、ワンランク上の選択肢になります。

Qwen 2.5 Coder 7B base Q4_K_M

約4.7 GB。今も現役で使える例外的なモデルで、2026年のローカルでのインラインコード自動補完（FIM）の定番です。

#32GBのRAM：24Bを目指すことができます

Mistral Small 24B Q4_K_M

≈14 GB。汎用性が高く、フランス語での性能も優れていますが、CPUでは3〜5トークン/秒です。

gpt-oss 20B Q4 (MXFP4)

≈14 GB。OpenAIのオープンウェイトモデル。MXFP4フォーマットにより非常に高速で、131kのコンテキストをサポート。

Qwen 3.8 27B Q4_K_M（容量の限界ぎりぎり）

約 18 GB。262k のコンテキスト、視覚機能、Apache 2.0 ライセンス。動作は可能ですが、約 2 トークン/秒と低速です。バッチ処理での利用に向いています。考えすぎを避けるため、推論設定を low にすることを検討してください。

#1. Ollama をインストール（CPUモード自動設定）

Ollamaは、使い始めるのに最も簡単なツールです。GPUがないことを自動で検出し、特別な設定なしでCPUに切り替わります。デーモンはデフォルトでhttp://localhost:11434で接続を待ち受けます。

curl -fsSL https://ollama.com/install.sh | sh

WindowsおよびmacOSで、ollama.comからインストーラをダウンロードしてください。CPUモードの特別設定は不要です — Ollama は適切な設定を自動で選択します。

ollama --version
ollama ps

ollama psコマンドを実行すると、デーモンの状態が表示されるはずです。会話が実行中であれば、PROCESSOR列に100% CPUと表示されます。ここでは、まさにこの状態を目指しています。

#2. CPUのみで比較する3つのモデル

RAMが16 GBの場合、問うべきなのは「どのモデルか」ではなく、「2026年の代表的な小型モデル3つのうち、どれを選ぶか」です。3つともダウンロードし、1時間かけて試して、ご自身で判断してください。

ollama pull qwen3.5:4b
ollama pull granite4.2:3b
ollama pull gemma4:e2b-it-qat

Qwen 3.5 4B

このサイズ帯で最も優れた汎用モデルです。フランス語に非常に強く、コーディングも得意で、コンテキストは256k、指示にもしっかり従います。3つの中では最も遅いモデルです（4Bなので）。

Granite 4.2 3B

IBMが開発した、非常に軽量でトークン効率の高いモデルです。指示に従う能力が高く、ライセンスはApache 2.0です。速度と品質のバランスがよい選択肢です。

Gemma 4 E2B

3つの中で最も高速です。マルチモーダルで、サイズの割に驚くほど高品質です。性能が控えめなCPUで、ほぼリアルタイムの処理を求める場合に最適です。コードの扱いは、他の2つより劣ります。

ollama run gemma4:e2b-it-qat --verbose
>>> Explique en 3 phrases la différence entre une LLC et une SAS.

--verbose オプションを付けると、各応答の下に統計情報が表示されます。prompt eval rate、eval rate（生成時のトークン/秒）、total duration です。このマシンで性能を評価する際の基準となる指標です。

#3. トークン/秒のベンチマーク：おおよその目安

以下は、代表的なマシンでGPUを使わず、llama.cppを内部で利用するOllamaをQ4_K_M量子化で動かした場合の目安です。実際の結果は、コンテキスト、メモリ、DDRの動作周波数によって±20％変動します。

#Intel Core i5-12400 + DDR4-3200 16 GB

Gemma 4 E2B Q4

生成速度：約26トークン/秒

Granite 4.2 3B Q4_K_M

約20トークン/秒

Qwen 3.5 4B Q4_K_M

≈ 15トークン/秒

Granite 4.2 8B Q4_K_M

≈ 8トークン/秒

Qwen 3.5 9B Q4_K_M

≈ 6トークン/秒

#Intel Core i7-13700K + DDR5-5600 32 GB

Gemma 4 E2B Q4

≈ 40トークン/秒

Granite 4.2 3B Q4_K_M

≈30トークン/秒

Qwen 3.5 4B Q4_K_M

約 23トークン/秒

Qwen 3.5 9B Q4_K_M

≈ 12トークン/秒

Mistral Small 24B Q4_K_M

約4トークン/秒

#AMD Ryzen 7 7700X + DDR5-6000 32 GB

Gemma 4 E2B Q4

≈ 44トークン/秒

Granite 4.2 3B Q4_K_M

≈ 32トークン/秒

Qwen 3.5 4B Q4_K_M

≈ 24トークン/秒

Granite 4.2 8B Q4_K_M

≈ 13トークン/秒

Qwen 3.5 9B Q4_K_M

約11トークン/秒

Mistral Small 24B Q4_K_M

約5トークン/秒

#4. AVX-512対応でllama.cppをコンパイルする（上級者向け）

Ollamaにはllama.cppの事前コンパイル済みバイナリが搭載されています。CPUのインストラクションセット（AVX2、AVX-512、AMX）に応じてllama.cppを手動でコンパイルすることで、特定のプロセッサで10〜30％のトークン/秒の改善が可能です。Intel Core 11e以降（Ice Lake / Rocket Lake / Sapphire Rapids）のAVX-512をサポートするプロセッサに限定されます。

grep -o 'avx512[a-z_]*' /proc/cpuinfo | sort -u

コマンドの出力にavx512f、avx512dqなどを含む行があれば、CPUはAVX-512をサポートしています。なければ、標準のOllamaを使い続けてください。切り替えても得られるメリットはありません。

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build \
  -DGGML_NATIVE=ON \
  -DGGML_AVX512=ON \
  -DGGML_AVX512_VBMI=ON \
  -DGGML_AVX512_VNNI=ON
cmake --build build --config Release -j

オプション -DGGML_NATIVE=ON は、コンパイラが自動的に CPU のインストラクションセットを検出するようにし、利用可能なすべての機能を有効にします。これは最も簡単で信頼性の高い方法です。

./build/bin/llama-bench -m qwen3.5-9b-Q4_K_M.gguf -t 8

-t オプションはスレッド数を指定します（論理コア数ではなく、物理コア数を設定してください）。llama-bench は、pp512（プロンプト評価）とtg128（生成）の速度をトークン/秒で示す表を返します。これが今後の比較基準になります。

#CPUでの生成速度（トークン/秒）を上げるためのヒント

1. 01
   スレッド数を設定する

   デフォルトでは、Ollamaはすべての論理コアを使用します。ハイパースレッディングに対応した一部のCPUでは、使用するスレッド数を物理コア数に合わせると（8コアのCPUならOLLAMA_NUM_THREADS=8）、速度が5〜15％向上します。
2. 02
   モデルを読み込んだ状態に保つ

   モデルの読み込みには数秒かかります。OLLAMA_KEEP_ALIVE=30mは、最後のリクエスト後30分間モデルをRAMに保持します。GPUがなければ、再読み込みが遅いため、この機能はさらに貴重です。
3. 03
   可能な限りコンテキストを縮小してください

   num_ctxを8192ではなく2048に設定すると、RAMを節約でき、処理速度も目に見えて向上します。大きなコンテキストを維持するのは、本当に必要な用途（RAG、長いドキュメント）だけにしてください。
4. 04
   Chrome と Slack を閉じます

   CPUで7BのLLMを動かすと、メモリ帯域が飽和します。RAMにもアクセスするもの（50個のタブを開いたブラウザ、Slack、Teams）はすべて、LLMが使える処理サイクルを奪います。メモリが16GBの環境では、これによって生成速度が毎秒5トークンになるか8トークンになるかの違いが生じることがあります。
5. 05
   互換性のあるDDRメモリの中で最も高速なものを選ぶ

   アップグレードする場合：DDR4-3200 → DDR4-3600 = +10％。DDR4 → DDR5-5600 = +30％～50％。LLMの推論では、CPUの重要性はメモリよりもはるかに低いです。

#CPUだけでは性能が足りなくなるとき

率直に言うと、GPUがなければ実現できない用途もあります。以下のリストにご自身の用途が当てはまるなら、控えめな性能のGPUでも導入を検討する時期です（250ユーロの中古RTX 3060 12 GBでも使い勝手が大きく変わります）。あるいは、時間単位でクラウドを借りることも検討してください。

13B以上のモデルとの対話型チャット

毎秒2〜5トークンでは、会話型AIには遅すぎます。12 GBのGPUがあれば、すぐに解決できます。

大規模コンテキスト（16k以上）を用いたRAG

プロンプトの評価処理においてCPUでは処理時間が爆発的に増加します。RTX 3060では8kプロンプトを1秒で処理できますが、i7では30秒かかります。

リアルタイムコード補完

インライン補完拡張（Tabbyなど、FIMモードでQwen 2.5 Coder 7Bベース）は、200ms未満の応答を必要とします。CPUでは1〜2秒を下回ることはできません。GPUが必須です。

大量生成

1000件のドキュメントを処理する場合、CPUでは数日、GPUでは数時間かかります。一時的なバッチ処理であれば、0.30 €/hのRunPodやVast.aiを使用すれば、一晩で完了します。

#さらに詳しく

CPUで動くローカルLLMが応答するようになりました。次に知りたいことに応じて、さらに進むための道筋をいくつか紹介します：

適切な量子化の選択

Q4_K_Mは基本の選択として無難ですが、RAM容量によってはQ5_K_MやQ3も適しています。量子化ガイドでは、こうしたトレードオフを詳しく説明しています。

全体にインターフェースを付ける

ターミナルはテストに適しています。Open WebUIやLM Studioを使えば、数分でChatGPTのようなローカルインターフェースを用意できます。

GPUを追加するタイミング

GPUの導入に踏み切るなら、GPU選びのガイドでRTX 3060、4060、4070の比較と、それぞれのLLMベンチマークを確認できます。

推奨ハードウェア： Radeon RX 9070 XT 16GB (ASUS Prime OC) — CPUのみの構成から専用GPUへ移行するために。 すべてのAIハードウェア →