GPUなしでローカルLLMは実用になるか｜CPUのみ推論をi7実機で検証

ローカルLLMを試そうとすると、まず「GPUがないと無理なのか」という壁にぶつかる。答えだけ言えば動く。ただし動くことと使えることは別で、1文字出るのに何秒もかかるなら結局は使わなくなる。ここで扱うのはモデルを手元のPCで動かす話で、ブラウザで使うクラウド型のAIサービスは対象外になる（そちらは手元で計算しないのでGPUの有無は関係ない）。

そこで、GPUなしでローカルLLMを走らせ、モデルの大きさごとに実際の速度を測った。使ったのはCore i7-14700F（20コア28スレッド）とDDR5-5600のデュアルチャネル構成で、Ollamaの設定でGPUへ送る層数を0に固定している。

搭載メモリは96GBだが、これは27B級まで測り切るための余裕であって必要量ではない。CPU推論の速度には、容量そのものよりメモリの速度とチャネル構成、それにCPU側の状態が強く関わるとみている。そのモデルが載りさえすれば、同じDDR5・同じ2チャネルなら16GBでも32GBでも大きくは変わらないはずだ。ただし今回は容量もチャネル数も変えて比べていないので、ここは測定に裏打ちされた話ではない。自分の環境への当てはめ方は後の節で扱う。

測定条件

項目	内容
CPU	Intel Core i7-14700F（8 Pコア + 12 Eコア = 20コア28スレッド／ベース65W・最大ターボ219W）
メモリ	DDR5-5600 48GB × 2（2チャネル・計96GB）
推論ソフト	Ollama 0.31.1（測定時点の最新安定版は0.32.1）
GPUオフロード	num_gpu = 0（size_vram = 0 を毎回確認）
生成量	速度測定は1回あたり128トークン、temperature 0、コンテキスト長4096。日本語の文字数換算は300トークン、思考モードの確認は300トークンと1024トークンで各1回（Ollamaが返す思考フィールドと回答フィールドを分けて記録。27Bは1024トークンの測定中にサーバーが落ちたため未取得）
試行回数	12B以下は3回、14B・27B・35Bは2回。表の値は平均
測定日	2026年7月22日

CPUだけで推論していることを担保するため、Ollamaのリクエストごとの設定でnum_gpuを0にした。num_gpuはGPUの枚数ではなくGPUへオフロードする層数を指定するもので、0を渡すと全層がCPU側に載る。実測で確かめたのは0を渡した場合で、モデルごとに/api/psを叩き、size_vramが0、すなわちOllama報告上はモデルのVRAM使用量が0であることを確認した。8モデルすべてで0だった。0以外の値での層数指定は今回試していない。なおnum_gpuとnum_threadは現行の公式ドキュメントのパラメータ表には載っていないが、0.31.1では有効に動作する（num_gpuについては記載の復活を求めるIssueが公式リポジトリに立っている。2026年7月時点でopen）。0.32系では実装が変わる可能性があるので、再現するなら版も合わせたい。

モデルは同じ4bit量子化（Q4_K_M）で揃えた。1Bのみ量子化を明示したllama3.2:1b-instruct-q4_K_Mを使っており、既定タグのllama3.2:1bとは別物なので再現時は注意してほしい。小型枠のllama3.1・llama3.2・gemma3・qwen3系は定番として選んだもので、同クラスの現行世代としてはgemma4のe4b、qwen3.5の4b・9bが該当する（Llama系には8B級の現行世代がなく、llama3.3は70B、llama4はMoEのみになる）。本機では1トークンあたりの処理時間がロードサイズにおおむね比例していたため（読み出し量と演算量のどちらが効いているかは、後の節のとおり今回のデータでは分けられない）、同じ4bit量子化で同程度のサイズのモデルを選ぶときの桁感としては本記事の数字が使える。ただしここでいうサイズは、名前に付いたパラメータ数ではなくメモリに載る量（GB）を指す。たとえばgemma4のe4bは「実効4.5B」と表記されるが、埋め込みを含む総パラメータは8Bで、gemma3:4bと同じメモリ量・速度になるとは限らない。当てはめるときはモデル名のB数ではなく、実際にロードしたときのGBで比べたい。世代やアーキテクチャが違えばなおさら、速度をそのまま流用することはできない。

測ったのは生成速度・プロンプト読み込み速度・Ollamaが報告するロードサイズの3つで、出力の品質は評価していない。同じ速度でも回答の中身はモデルごとに違うので、速度の話と賢さの話は分けて読む必要がある。小さいモデルが用途に耐えるかは、実際に使うモデルで確かめることになる。

モデルサイズ別の生成速度

まず数字を出す。左が1周目、右はそこから約40分回した後の2周目で、同じ条件・同じプロンプトの独立した2回の測定になる。思いついたときに短く質問する使い方なら1周目の列、まとまった処理を連続で回すなら2周目の列で見ると実際に近い（差が出る理由は「回し続けると1〜2割遅くなる」で扱う）。

モデル	パラメータ	Ollama報告サイズ	1周目（低負荷から）	2周目（連続負荷後）
llama3.2:1b-instruct-q4_K_M	1.2B	1.01GB	53.26 tok/s	48.03
llama3.2:3b	3.2B	2.56GB	22.29 tok/s	19.21
gemma3:4b	4.3B	2.88GB	17.97 tok/s	14.51
llama3.1:8b	8.0B	5.58GB	10.70 tok/s	9.02
gemma4:12b	11.9B	8.90GB	6.41 tok/s	5.56
qwen3:14b	14.8B	10.10GB	5.80 tok/s	4.83
qwen3.6:27b	27.8B	17.32GB	2.97 tok/s	2.35
qwen3.6:35b-a3b（MoE）	35B中3B活性	23.52GB	13.26 tok/s	11.54

どちらの測定も8モデルを同じ順に測っているため、1周目の列も厳密には「その順番で測った値」で、後半の大きいモデルは測定開始時ほど冷えてはいない。実際、同じ1Bを1周の最後にもう一度測ると1周目は53.26から51.47へ、2周目は48.03から44.60へと、1周のあいだにも3〜7%落ちている。順序が両回で同じなのでモデルごとの左右比較は成立するが、左の列を「どのモデルも完全に冷えた状態の値」と読むことはできない。

各値は平均で、1Bと35B MoEは試行内のばらつき（2周目で1Bが44.57〜54.52、35B MoEが9.86〜13.23）が低下幅と同程度あるため、個々の低下率には幅がある。8Bと12Bは2回の測定でレンジが重ならず、差は明瞭だった。

最後の1つだけ流れから外れている。35Bのモデルが14Bより2.3倍速く、27Bと比べれば4.5倍速い（試行2回のばらつき下限12.50で見ても2.2倍で、順序は動かない）。構造の違いによるもので、後の節で分けて扱う。それ以外の7モデルは、大きくなるほど順当に遅くなっている。

その速度は体感でどうか

トークン毎秒という単位は感覚に直結しないので、日本語の文字数に直す。同じ日本語の設問を投げて出力を数えたところ、llama3.2:3bとllama3.1:8bはどちらも300トークンで458〜459文字、1トークンあたり約1.53文字だった。ただしトークナイザの効率は系列で差があり、同じ2203字の文章を読ませたときの入力トークン数はllama3.2系で1703、qwen3.6系で1252と1.4倍の開きがある。以下の換算はllama系の値で、Qwen系ならもう少し多くの文字が1トークンに入る。

この比率で換算すると、10.70トークン/秒は毎秒16文字前後（2周目の9.02なら14文字前後）、2.97トークン/秒は毎秒4.5文字前後（同2.35なら3.6文字前後）になる。日本語の黙読速度は毎分400〜600字あたりを目安に挙げる資料が多いが、読み手や文章の難易度で大きく変わるため一つの値には決まらない。毎秒に直すとおよそ7〜10字になる。この目安でいえば毎秒16文字も14文字も読む速度を上回るので、どちらも文字が出るのを待つ感覚にはなりにくい（この2文字の差より個人差の幅のほうが大きい）。一方で毎秒4.5文字は黙読の半分以下で、明らかに文字が出るのを待つ状態になる。実際に測った128トークン（日本語なら約200文字）の生成時間は8Bで約12秒、27Bで約43秒だったので、400字の回答ならその倍と見ればよい。なお27Bの換算にもllama系の比率を当てているため、Qwen系の実際はもう少し速い側になる（低め側の見積もりとして読める）。

生成したトークンがそのまま画面に出るとは限らない。gemma4:12bとqwen3.6:35b-a3bに同じ設問を投げて300トークン生成させたところ、どちらも可視の回答は0文字だった。Ollamaは思考部分と最終回答を別のフィールドに分けて返すので、上限を1024トークンに広げ、両方のフィールドの中身を確かめた。

qwen3.6:35b-a3bは思考側に2813文字が入り、可視の回答は0文字のまま上限で打ち切られた。生成したトークンが答えではなく思考に費やされていたことになる。一方gemma4:12bは思考側が0文字で、可視の回答は234文字だった。このモデルは2203字の文章を1246トークンで読んでおり（1トークンあたり約1.8文字）、同じ比率なら1024トークンは1800字前後にあたる。234文字とは大きく開くが、思考フィールドにも何も入っていないため、可視の回答にならなかった分の行き先は今回の記録では追えない。少なくとも「gemma4の出力が思考で埋まった」とは言えない。確かなのは結果のほうで、上限1024トークンまで回して画面に出たのは234文字、所要163秒だった（1回の測定）。表の6.41トークン/秒がそのまま可視の文字速度になるとは限らない。

Qwenの公式モデルカードによればqwen3.6系は27Bを含めて既定で思考モードで動く（明示的に無効化はできる）。27Bの思考出力は測れていない（測定中にOllamaのサーバーが落ちた）が、生成が2.97トークン/秒と遅いぶん、同じ量の思考が出れば待ち時間への影響は最も大きくなる。なお今回はtemperature 0で揃えており、Qwenが思考モード向けに推奨する値（一般用途で1.0）とは異なる。速度比較の条件としては妥当だが、通常使うときの思考量を代表する条件ではない。

回し続けると1〜2割遅くなる

同じ測定を2回やると、全モデルで速度が落ちていた。1周目は測定を始めた状態、2周目はそこから約40分、長文処理やGPU側の測定を挟みながら回し続けた後の値で、8モデルすべてが同じ方向に9.8〜20.9%低下している。プロンプト読み込みのほうも5.5〜19.3%落ちた。8モデルすべてで低下の向きが一致したので、単純な試行内のばらつきだけでは説明しにくい。測定順は両回とも同じなので、各モデルは同じ順番上の位置で比較できる。ただし1周目と2周目では開始時のシステム状態が違うため、測定順と連続負荷状態の影響を完全には分離できない。連続して負荷をかけたことと単に時間が経ったことのどちらがどれだけ効いたかも、順序を入れ替えた測定をしていない以上は分けられない。

可逆かどうかを確かめるため、15分アイドルを挟んでから3モデルを測り直した。

モデル	1周目	2周目（連続負荷後）	15分アイドル後
llama3.2:1b-instruct-q4_K_M	53.26	48.03	53.25
llama3.1:8b	10.70	9.02	10.07
gemma4:12b	6.41	5.56	5.89

1Bは1周目とほぼ同じ値まで戻ったが、8Bと12Bは1周目の92〜94%どまりだった。低下分に対する戻りでみると8Bで6割、12Bで4割ほどにとどまる。少なくとも低下の一部（1Bでは全部）は、負荷を止めて時間を置くと解消する。単なる不可逆な経時変化だけでは、この回復を説明しにくい。関わっているのは、負荷をかけている間に進み、休ませると戻る可逆な状態だとみられる。候補として素直なのは熱や電力の枠だ。i7-14700Fはベース65W・最大ターボ219Wの製品で、短時間の全開と、長く回し続けられる控えめな動作（クロックが下がった状態）は同じではない。ただし今回はCPUの温度・消費電力・実クロック・スロットリングの発生を記録していないので、原因を熱・電力と特定はできない。15分では戻りきらない分が残っている理由も、冷却時間の不足なのか別の要因なのかはこの測り方では分けられない。

なぜ大きいモデルほど戻りが小さいのかも今回の測り方では確定できない。有力なのは、測定が数秒で終わる軽いモデルは冷えたまま走り切り、1回20秒前後を3回繰り返すモデルは測定の途中で控えめな動作に入る、という見方だ。しかしこの3モデルは1B→8B→12Bの順に測っており、モデルの大きさと測定順が同じ向きに並んでいる。後に測ったモデルほど直前の負荷が積み上がるため、この3点だけでは「大きいから」か「後だから」かを分けられない。順序を逆にして測り直すのが切り分けになる。

実用上の含意は単純で、CPU推論の速度は1回試した数字では決まらない。見積もりは低い側で立てておくほうが外れない。

本機のdense型では、サイズが倍になると速度は半分になった

今回の測定では、dense型はメモリに載る量が倍になると生成速度がおよそ半分になった（MoEだけは外れるので次の節で分けて扱う）。読み取れるのは「本機では、1トークンあたりの処理時間がOllama報告サイズにおおむね比例した」というところまでで、それが読み出し量で決まっているのか演算量で決まっているのかは今回の測り方では分けられない（この節の後半で扱う）。したがって、量子化を下げて載る量を減らせば同じだけ速くなる、とまでは今回のデータからは言えない（量子化を変えた比較は測っていない）。

自分のPCの速度を見積もるには、この比例関係が道具になる。手順は3つ。

1. 自分のメモリの規格と枚数を確認する（Windowsならタスクマネージャーのパフォーマンス→メモリで速度と使用スロット数が見える）。2枚挿していても挿す位置によってはデュアルチャネルにならないので、確実を期すならマザーボードのマニュアルやCPU-Z等で確認する
2. 理論帯域を出す。転送速度 × 8バイト × チャネル数で、DDR5-5600の2枚挿しなら89.6GB/s、DDR4-3200の2枚挿しなら51.2GB/s。1枚挿しは1チャネルとして数える（DDR5で2サブチャネルと表示される場合も、この式では1チャネル扱いになる）
3. その半分を、動かしたいモデルのGBサイズ（前掲の表のOllama報告サイズが目安）で割る

DDR4-3200の2チャネル環境で8B級（約5.6GB）なら25.6÷5.6でおよそ4.5トークン/秒という見当になる。この「半分」は本機の実測（1周目で理論値の6〜7割、2周目で5割前後）の低いほうを取った係数で、同じ式を本機に当てはめると8.0となり実測の10.70より控えめに出る。式の外に残る要因はコア数と電力枠で、コアの少ない機体や電力枠の狭い機体では見積もりが実際より速い側に出るため、下振れ側に見ておくほうが外れない。なおこの式はメモリ帯域が効いていることを前提にした目安で、前提そのものは今回のデータでは確かめていない（係数は本機の実測から取った経験値）。DDR4とDDR5で見積もりが変わるのもこの前提に乗っている。桁を見るための目安と考えたい。

根拠は次のとおりで、Ollama報告サイズと生成速度を掛け合わせた値がほぼ一定になる。

モデル	報告サイズ × 速度（1周目）	報告サイズ × 速度（2周目）
llama3.2:1b-instruct-q4_K_M	53.8	48.5
llama3.2:3b	57.1	49.2
gemma3:4b	51.8	41.8
llama3.1:8b	59.7	50.3
gemma4:12b	57.0	49.5
qwen3:14b	58.6	48.8
qwen3.6:27b	51.4	40.7
qwen3.6:35b-a3b（MoE）	311.9	271.4

MoEを除く7モデルは、1.01GBの1Bから17.32GBの27Bまで17倍のサイズ差があるのに、1周目の測定では51.4〜59.7に収まっている。単位はGB/秒になる。

ただしこの一定性から律速要因は決められない。1トークンあたりの読み出し量も演算量もモデルサイズにほぼ比例するので、メモリ帯域が効いていても演算が効いていても同じ形が出る。実際、読み込み側で同じ計算をしても370〜536に収まる。読み込みは同じ重みを大量のトークンで使い回すぶん、読み出し量あたりの演算量が生成より桁違いに多い、つまり演算寄りの処理だ。そこでも同じ形が出るということは、この一定性は帯域律速の証拠にはならない。係数自体も2周目には40.7〜50.3へ15%前後下がったが、これも判別には使えない。CPUが実際に引き出せる帯域はコアやアンコアのクロックに依存するので、帯域が効いている場合でも電力状態が変われば係数は動く。分かるのは、この係数がメモリの規格だけで決まる固定値ではなく、連続して回すと1〜2割動くということだ（何がそうさせているかは温度も消費電力も記録していないので特定できない。詳しくは「回し続けると1〜2割遅くなる」で扱う）。なお後のGPU比較では、生成の差が6〜8倍なのに読み込みの差は36〜48倍と桁が分かれている。律速要因を決める材料にはならないが、生成と読み込みで効いているものが違うという整理とは同じ向きの観察になる。この係数はいずれも本機1台での観測で、他のCPU・他のメモリ構成に当てはまる保証はない。

参考までに、DDR5-5600を2チャネルで動かしたときの理論帯域は5600 MT/s × 8バイト × 2チャネルで89.6GB/sになる（メモリが5600 MT/sで動作している場合の計算値）。報告サイズ×速度から出した40〜60GB/sは、この4割半ば（2周目の下限40.7）から7割弱（1周目の上限59.7）にあたる。ただしこれは報告サイズの全量を毎トークン読み切ったと仮定した見かけの値で、実際に流れたバイト数を測ったものではない。

例外はMoE — 35Bが14Bより速い

qwen3.6:35b-a3bだけが規則から外れたのは、モデルの構造が違うからだ。Qwenの公式モデルカードによれば、このモデルは総パラメータ35Bのうち1トークンあたり3Bだけが活性化する。256個のエキスパートを持ち、そのうち8個のルーティングされたエキスパートと1個の共有エキスパートが使われる設計になっている。重み全体はRAMに置く必要があるため報告サイズは23.52GBと最大だが、1トークンの計算で活性化される重みは全体の一部に限られる。実際のメモリ読み出し量は測っていないものの、これがdense型より速かった主因と考えられる。

先ほどの積が311.9とdense勢（51.4〜59.7）の5.6倍になったのはこのためだ。ただし活性が35B中3B（約12分の1）でも速度が12倍になるわけではない。denseと同じ読み出し効率を仮定して逆算すると1トークンあたり4.2GB前後（報告サイズの2割弱）になるが、これは実際に流れた量ではなく、denseの係数をそのまま当てた見かけの値だ。エキスパートが飛び飛びに置かれるぶん実効の読み出し効率はdenseより落ちるとみられ、実際に読む量はこれより少ない。読む量が活性比に近いところまで減っても時間がその比では縮まないのはこのためで、毎トークン必ず通る部分やエキスパートを選ぶ手間も残る。どの要因がどれだけ効いているかは今回の測り方では分けられない。

MoEかどうかはモデル名で見分けられることがある。qwen3.6:35b-a3bのように総パラメータの後ろに「a＋数字b」（a3b＝活性3B）が付いていればMoE型だと判断してよい。ただし付いていなくてもMoEのことがある。たとえばOllamaのgemma4:26bは上流名がGemma 4 26B-A4Bで、総25.2Bのうち3.8Bだけが活性化するMoEにあたる。名前で判断できないときは、配布元のモデルカードで活性パラメータの記載を確認するのが確実になる。

今回試したMoEは1モデルだけなので、一般則とまでは言えない。活性パラメータの比率やエキスパートの粒度はモデルごとに違うため、有利さの度合いは他のMoEにそのまま当てはまらない。RAMの要求も厳しくなる。報告サイズ23.52GBを載せるなら32GBが試すための最低目安だが、OSやコンテキスト、同時に起動しているアプリの分で余裕はほとんど残らない。常用するなら一段上の容量を見ておきたい（32GB環境での動作は今回試していない）。

読ませる側の待ち時間はもっと厳しい

生成速度ばかり注目されるが、CPU推論でより厳しいのは入力を読み込む段階（プロンプト処理）だ。同じ日本語の長文（2203文字。トークン数はモデルによって1240〜1703と前後する）を読ませ、読み込みだけにかかった時間を測った。以下は1周目の値になる。

モデル	読み込み速度	入力トークン数	読み込みに要した時間
llama3.2:1b-instruct-q4_K_M	530.4 tok/s	1703	3.2秒
llama3.2:3b	187.6 tok/s	1703	9.1秒
gemma3:4b	149.2 tok/s	1240	8.3秒
llama3.1:8b	72.7 tok/s	1688	23.2秒
gemma4:12b	47.9 tok/s	1246	26.0秒
qwen3:14b	40.0 tok/s	1552	38.8秒
qwen3.6:27b	21.3 tok/s	1252	58.7秒
qwen3.6:35b-a3b（MoE）	108.5 tok/s	1252	11.5秒

27Bでは、約2200字（原稿用紙5枚半ほど）の文章を読ませただけで最初の1文字が出るまでに約1分かかる（2周目では約1分10秒）。8Bでも23秒だ。ここが、CPU推論が用途を選ぶ理由になる。短い質問を投げて短く返してもらう使い方なら読み込みは一瞬で済むが、長い資料を貼って要約させる、検索して引っ張ってきた文書を大量に読ませるといった使い方は、返答が始まる前の待ち時間が別次元になる。ここでも今回のMoEは有利で、35B MoEの108.5トークン/秒は8Bのdense型より速い。

読み込みは入力の全トークンをまとめて処理できるのに対し、生成は1トークンずつ順に作る。効いてくるボトルネックが違うため、CPUの演算性能とメモリ帯域のバランスが変われば両者の比率も変わる。今回の実測では読み込みが生成の約7〜10倍という範囲に収まったが、これはこのCPUとこのメモリ構成での値だと見ておきたい。

効くのはVRAMではなくRAM

GPUで動かすときはVRAMに収まるかどうかが最初の関門になるが、CPU推論ではその役割をシステムRAMが担う。今回Ollamaが報告したサイズは、1Bで1.01GB、8Bで5.58GB、14Bで10.10GB、27Bで17.32GB、35B MoEで23.52GBだった。

これはOllamaが/api/psのsizeとして報告した値で、公式上は「モデルのサイズ（バイト）」と定義されている。OSから見た実際のRAM使用量を測ったものではなく、KVキャッシュや作業領域をどこまで含むかも公式仕様からは判断できない。長いコンテキストでは一般に追加のメモリが必要になるため、表の値とは別に余裕を見ておきたい（文脈を伸ばしたときのKVキャッシュの増え方はGPU側で実測している）。もちろんOSやブラウザ、そのほかのアプリが使う分も要る。ローカルAIにシステムRAMが何GB要るかはGPU構成でも共通の論点だが、CPU推論ではモデル本体がまるごとここに乗る。この前提で、手元の環境が16GBなら8B級までが安全圏、報告サイズだけで見れば32GBで27Bや35B MoEを試せる可能性がある、という見当になる。VRAMの容量の考え方をそのままRAMに読み替えるとわかりやすい。

モデルを最初に読み込む時間もサイズに応じて伸びる。今回の初回ロード（1周目）は1Bで1.9秒、12Bで11.4秒、27Bで38.9秒、35B MoEで49.8秒だった。2周目は大きいモデルほど短くなり（27Bで20.7秒、35B MoEで30.0秒）、ストレージの速度だけでなく直前に読んだ状態かどうかにも左右される。いずれにせよ、大きいモデルは使い始める前の待ち時間も長い。

スレッド数は既定のままでよかった

CPU推論の設定で最初に触りたくなるのがスレッド数だ。llama3.1:8bでnum_threadを変えて測ったが、2回のスイープで形が一致しなかった。各点は1回ずつの測定で、比較用に並べた既定の値だけは前掲の表と同じ3回平均になる。

スレッド数	1周目	2周目
4	6.90 tok/s	6.76 tok/s
8	8.70	7.13
12	9.01	7.74
16	8.83	8.91
20	9.92	9.21
指定なし（既定）	10.70（3回平均）	9.02（3回平均）

両回で一致したのは、4スレッドまで絞ると20スレッドより2〜3割遅い（6.90対9.92、6.76対9.21）ことだけで、8〜20の範囲の形と最適値は再現しなかった。既定との大小も逆転しており、1周目は既定がスイープ最大を上回り、2周目は下回っている。この範囲の差は連続負荷で観測した1〜2割の変動と同程度で、スレッド数の効果として分離できていない。少なくともこの環境では、既定から動かして得られる明確な利得は確認できなかった。

GPUを積むとどれだけ変わるか

比較のため、同じ日・同じOllama 0.31.1・同じプロンプトで、RTX 5060 Ti 16GBに載せた場合も測った（GPU側はオフロード指定を外した既定の状態）。CPU側は1周目の値を並べている。

モデル	CPUのみ	RTX 5060 Ti	生成の差	読み込みの差	VRAM常駐率（バイト比）
llama3.2:1b-instruct-q4_K_M	53.26	338.60	6.4倍	36倍	100%
llama3.2:3b	22.29	158.93	7.1倍	41倍	100%
gemma3:4b	17.97	112.97	6.3倍	37倍	100%
llama3.1:8b	10.70	79.83	7.5倍	48倍	100%
gemma4:12b	6.41	47.46	7.4倍	40倍	100%
qwen3:14b	5.80	44.30	7.6倍	45倍	100%
qwen3.6:27b	2.97	13.05	4.4倍	24倍	84%
qwen3.6:35b-a3b	13.26	54.60	4.1倍	4.0倍	62%

14B以下の6モデルはOllama上で100% GPUと表示され、生成で6〜8倍、読み込みでは36〜48倍の差がついた。生成の差より読み込みの差のほうがはるかに大きいのがこの表の要点で、長い文章を読ませる用途ほどGPUの有無が効くことになる。

下の2つは事情が違う。27Bと35B MoEは16GBに収まりきらず、Ollamaが報告した総ロード量に対するVRAM使用量はそれぞれ84%と62%だった。モデル全体をVRAMだけには置けておらず、残りはCPU側のメモリに置かれる。この比率はメモリ量の比であって、GPUへオフロードされた層数の割合を示すものではない（/api/psが返すのはバイト数であり、層数の割合を示すものではない）。それでも一部がCPU側に残る以上、GPUを積んでも生成の差は4倍前後にとどまっている（読み込みの差も35B MoEでは4.0倍まで縮み、27Bは24倍と全層が載った場合の6割ほどになる）。したがってこの2モデルの数値は、モデル全体をGPUへ載せた場合の性能を示すものではなく、CPU側への部分的な残留の影響を含んでいる。層は順番に処理されるため、CPU側の処理に加えてCPU・GPU間の転送や同期の待ち時間も加わり、VRAMに置かれたバイト比率ほど単純には速くならない。実際、27Bで4.4倍、35B MoEで4.1倍と、全層が載った14B以下の6〜8倍を下回った。VRAMからあふれた分をRAMへ逃がす仕組みは別の記事で詳しく扱っている。

何がCPUで実用になり、何がならないか

CPUだけで成立する使い方。短い質問への短い回答、文章の言い換えや校正、タグ付けや分類のような定型処理は3B〜8B級で回る。今回の測定でいえばllama3.2:3b（報告サイズ2.56GB・22.29 tok/s、2周目19.21）かllama3.1:8b（5.58GB・10.70 tok/s、同9.02）が入口で、RAM 16GBの環境でもこの範囲なら収まる。これから入れるなら同じサイズ帯の現行世代（gemma4:e4b、qwen3.5:4b・9bなど）が候補になるが、名前のB数ではなくロード時のGBで見る必要があり、世代が違えば速度も変わるので上の数字は桁感として使ってほしい。入力が短ければ読み込みの待ちもほとんど発生しない。

条件つきで成立する使い方。長文の要約や資料の読み込みが絡む場合でも、今回測ったMoEは現実的な範囲に収まった。qwen3.6:35b-a3b（報告サイズ23.52GB・RAMは32GBから）なら2200字の読み込みが11.5秒（2周目13.1秒）、生成が13.26トークン/秒（同11.54）だった。ただし既定では思考出力が先に出る。実測では1024トークン生成しても可視の回答は0文字で、その間はすべて思考に費やされていた。13.26トークン/秒で換算すれば1024トークンだけで1分以上になる。上の読み込み11.5秒・生成13.26トークン/秒がそのまま体感になるのは思考を切って使う場合で、既定のまま使うなら最初の1文字までの待ちを別に見込む必要がある。

CPUでは厳しい使い方。qwen3.6:27bのようなdenseの大型モデルを常用すること、長い文脈を毎回読ませること、対話の往復を高速に繰り返すことは待ち時間が積み上がる。27Bで長文を読ませれば1分、返答にさらに1分、加えて既定では思考出力が先に出る（27Bの思考量は測れていないが、同じ量の思考が出れば1トークンあたりの時間が長いぶん上乗せは大きくなる）という時間感覚になる。ここまで来ると16GB級のGPUを1枚積むほうが解決が早い。ただし27Bや35B MoEは16GBのGPUにも載りきらない。逆算の材料は本文の報告サイズで、27Bが17.3GB、35B MoEが23.5GB。ここにコンテキストぶんの余裕を足すと16GBでは足りない。16GB級に収めるなら14B級までのdense型に落とすか、MoE型をRAMに載せる選び方になる。VRAM 16GBに収まるモデルの早見表は別記事にまとめてある。

常時起動で細かい処理を投げる用途なら、GPUを積まない構成のまま完結する身軽さがある。ただし推論中はCPU負荷が高くなりやすく、消費電力や動作音そのものは今回測っていない。なお、クラウドのAIサービスを使うツール類でGPUが不要なのはこれとは別の話で、Claude Codeのようにサーバー側で推論するツールは、クラウドのモデルを使う通常の構成なら手元で計算しないため、応答の速さにGPUの有無が効かない（ローカルモデルを繋ぐ構成にすればこの記事の話に戻る）。

よくある質問

ノートPCでも同じ結果になるか
同じにはならない。効いてくるのはノートかデスクトップかという区分ではなく、メモリの規格とチャネル数、CPUのコア数、そしてその筐体が維持できる電力と冷却になる。今回のデスクトップでも連続負荷で1〜2割落ちたが、それがどこまで電力や冷却に由来するかは測っていないので断定できない。ただ一般には、電力枠や冷却の余裕が小さい機種ほど連続負荷での落ち込みは大きくなりやすい。一般的なx86ノートはコア数もメモリ帯域も下回ることが多いが、LPDDR5Xを広いバス幅で載せた機種や、メモリを統合しているMacのように帯域が広い例もある。「本機のdense型では、サイズが倍になると速度は半分になった」で示した見積もり手順は桁を見るのに使えるが、ノートでは実際より速い側に出ると見ておきたい。

メモリを増やせば速くなるか
同じ枚数・同じ規格のまま容量だけ増やしても、速度そのものはほとんど変わらない（厳密にはモジュールのランク数や動作クロック・タイミングが変わることはある）。ただし増やし方によっては上がる。1枚挿しのシングルチャネル構成に同じモジュールをもう1枚足して2チャネルにすると実効帯域がおよそ倍になる。帯域が効いているという前提に立てば生成速度も大きく伸びる方向だが、その前提も含めて今回は測っていない。容量のほうは「そのモデルが載るかどうか」を決める別の条件だと分けて考えるとよい。

量子化をさらに下げれば速くなるか
今回はすべて4bit量子化（Q4_K_M）で揃えており、それより低いビット幅は測っていない。メモリに載る量と速度がほぼ反比例していた観測からは速くなる方向が期待できるが、低ビット化は読み出す量を減らす一方で復元の演算が増えるため、比例して返るとは限らない。精度への影響も別途評価が要る。

内蔵GPUやNPUがあれば違うのか
今回の測定はCPUのみで、内蔵GPUもNPUも使っていない（使用したi7-14700Fは内蔵GPU非搭載のFシリーズ）。それぞれ性格が異なるので、NPUとGPU・CPUの役割の違いを踏まえて別に検討する必要がある。

この設定はどうやって指定するのか
Ollamaではnum_gpuにGPUへ送る層数を指定する。0を渡せば全層がCPUに載る。/api/generateを叩くならリクエストJSONの"options": {"num_gpu": 0}に、ollama runの対話セッションなら/set parameter num_gpu 0で指定できる。実際にCPUだけで動いているかは、モデルを読み込んだ状態で/api/psを確認し、size_vramが0になっているかで判断できる。

構成を強化するなら

CPU推論で容量を決めるのはRAMで、速度に効くのはメモリの帯域（規格の速度×チャネル数）とCPU側の状態になる。GPUを足すなら、VRAM容量がそのまま全層を載せられるモデルの上限になる。価格は変動するので最新の実売を確認してほしい。

候補	効く場面	目安
32GBメモリ（DDR5）	16GBで容量が足りないとき。27B・35B MoEを試すための最低目安	DDR4世代のPCは同容量のDDR4を。1枚挿しなら2枚にして2チャネルにするほうが速度にも効く
64GBメモリ（DDR5）	大きいモデルを載せたまま長いコンテキストや他の作業も並行する	速度は容量ではなく帯域側
RTX 5060 Ti 16GB	生成速度がボトルネックになった場合。14B級までなら全層が載る	VRAM 16GB

メモリは規格が合わないと装着できない。DDR4世代のPCにDDR5は挿さらないため、増設前に対応規格を確認してほしい。

参考資料

• Intel公式: Core i7-14700F 製品仕様（コア構成・ベース/ターボ電力／2026-07-22確認）
• Qwen公式モデルカード: Qwen3.6-35B-A3B（総パラメータ35B・活性3B・エキスパート構成・既定の思考モード／2026-07-22確認）
• Qwen公式モデルカード: Qwen3.6-27B（dense型27B・既定の思考モード／2026-07-22確認）
• Google公式モデルカード: Gemma 4 26B-A4B（総25.2B・活性3.8BのMoE／2026-07-22確認）
• Ollama公式ドキュメント: /api/generate（eval_count・eval_duration 等の生成レスポンス／2026-07-22確認）
• Ollama公式ドキュメント: /api/ps（size・size_vram の定義／2026-07-22確認）
• Ollama公式ドキュメント: Thinking（思考部分と最終回答が別フィールドで返る仕様／2026-07-22確認）
• Google公式: Gemma 4 モデルカード（E4B＝実効4.5B・埋め込み含む総8B／2026-07-22確認）
• Ollama公式リポジトリ Issue #13986: Modelfileパラメータとしての num_gpu の記載復活を求めるIssue（2026-07-22時点でopen）