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だけで推論していることを担保するため、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のみになる）。このうちgemma4:e4bとqwen3.5の4b・9bは、2026年9月に追加で測った（「同じサイズ帯の現行モデルではどうか」の節）。本機では1トークンあたりの処理時間がロード時のサイズにおおむね比例していたため（読み出し量と演算量のどちらが効いているかは、後の節のとおり今回のデータでは分けられない）、同じ4bit量子化で同程度のサイズのモデルを選ぶときの桁感としては本記事の数字が使える。ただしここでいうサイズは、名前に付いたパラメータ数ではなくメモリに載る量（GB）を指す。たとえばgemma4のe4bは「実効4.5B」と表記されるが、埋め込みを含む総パラメータは8Bで、gemma3:4bと同じメモリ量・速度になるとは限らない。当てはめるときはモデル名のB数ではなく、実際にロードしたときのGBで比べたい。ただし9月に追加で測ったgemma4:e4bは、層ごとの埋め込み表が大きいため、ロード時のGB（9.43GB）の割に速く、速度は4B級並みだった（RAMはこのGBで見積もる。「同じサイズ帯の現行モデルではどうか」の節）。世代やアーキテクチャが違えばなおさら、速度をそのまま流用することはできない。

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

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

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

どちらの測定も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モデルを測り直した。

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

自分の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サイズ（前掲の表のロード時のサイズが目安）で割る。MoEや、gemma4:e4bのように層ごとの埋め込み表が大きいモデルは、この式では実際より遅めに出る（下書き用のモデルを持つモデルは、既定の状態だとOllamaが示すロード時のサイズが実際より小さく出ることがあるので、先読みを切った状態のサイズ（gemma4:26bなら18.30GB）で割る）

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

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

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にあたる。名前で判断できないときは、配布元のモデルカードで活性パラメータの記載を確認するのが確実になる。

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

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

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

27Bでは、約2200字（原稿用紙5枚半ほど）の文章を読ませただけで、生成が始まるまでに約1分かかる（2周目では約1分10秒）。qwen3.6は既定で思考モードなので、画面に答えが出始めるのはさらにその後になる。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として報告した値で、公式のAPIリファレンス（レスポンスのスキーマ）では「モデルのサイズ（バイト）」と説明されている。OSから見た実際のRAM使用量を測ったものではなく、KVキャッシュや作業領域をどこまで含むかも公式仕様からは判断できない。長いコンテキストでは一般に追加のメモリが必要になるため、表の値とは別に余裕を見ておきたい（文脈を伸ばしたときのKVキャッシュの増え方はGPU側で実測している）。もちろんOSやブラウザ、そのほかのアプリが使う分も要る。ローカルAIにシステムRAMが何GB要るかはGPU構成でも共通の論点だが、CPU推論ではモデル本体がまるごとここに乗る。この前提で、手元の環境が16GBなら8B級までが安全圏、ロード時のサイズだけで見れば32GBで27Bや35B MoEを試せる可能性がある、という見当になる。ただし下書き用のモデル（MTP）を持つモデルでは、既定の状態でこの値が実際より小さく出ることがある（9月に測ったgemma4:26bでは約半分。後の節で扱う）。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回平均になる。

両回で一致したのは、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周目の値を並べている。

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へ逃がす仕組みは別の記事で詳しく扱っている。

同じサイズ帯の現行モデルではどうか（2026年9月の追加測定）

ここまでの数字は2026年7月22日の測定で、使ったモデルは定番ではあるものの一世代前のものが多い。そこで9月23日に、同じPC（Core i7-14700F、DDR5-5600の2チャネル）で同じサイズ帯の現行モデルを追加で測った。7月から変えた条件は主に3つある（2周目の取り方も違う。表の注を参照）。Ollamaを0.34.3（2026年9月19日公開）に上げたこと、読み込みに使う長文を別の文章（約2200字）に替えたこと、思考モードを持つモデルは思考を切って（think=false）測ったことだ。4bit量子化（Q4_K_M）、生成128トークン、temperature 0、コンテキスト長4096、num_gpuを0にしてsize_vramが0であることを確かめた点は7月と同じにしている。各モデル3回ずつを1周とし、2周続けて回した（gemma4:26bだけは測り方が違う。表の注を参照）。測定前のCPU使用率は、常駐しているアプリの分で7〜18%あった。

条件の違いがどれだけ影響するかを見るため、7月にも測ったllama3.1:8bを同じ手順で測り直した。生成は1周目で毎秒11.73トークンと、7月の10.70より約1割速い。Ollamaの版の違いなのか、その日のPCの状態の違いなのかは、この1モデルだけでは分けられない。7月はモデルのダイジェスト（配布物の版を示す値）を記録していないので、モデル自体が同じだったかも確かめられない。そのため下の表は7月の表と数字を並べて比べず、表の中どうしで見比べてほしい。

※gemma4:26bは後述の「先読み」を切った状態の値で、先読みありと交互に2回ずつ（各3回、計6回）測った平均。「直後にもう1周」の列は1周目のすぐ後に同じ順で続けて測った値で、7月の2周目（約40分の連続負荷の後）とは条件が違う。生成の2周の差は4%以内にとどまったが、続けて回した時間が短いので、7月に見た1〜2割の低下を確かめ直した測定ではない。

表の生成速度は、思考モードを持つモデルでは思考を切った値になる。思考を有効にしたまま使うと、答えが表示され始めるまでに思考のぶんが上乗せされる（7月に35B MoEで見たとおり）。

dense型の3モデル（qwen3.5:4b・qwen3.5:9b・llama3.1:8b）では、ロード時のサイズ×速度がqwen3.5:4bで50.9、qwen3.5:9bで60.8、llama3.1:8bで65.4になった。7月の7モデルほど揃ってはいないが、2倍近いサイズ差に対して積の差は3割弱で、ロード時のサイズから速度の見当を立てるやり方はこの3つにも当てはまる。

形から外れたのはgemma4:e4bだ。ロード時のサイズは9.43GBとqwen3.5:9bより大きいのに、速度は4B級のqwen3.5:4bと同じ毎秒16トークン前後で、積に直すと151になる。Googleの公式モデルカードによれば、E4Bは層ごとに専用の埋め込み表（Per-Layer Embeddings）を持ち、この表は大きいものの参照に使うだけなので、実効のパラメータ数（4.5B）は総数（8B）よりずっと小さい。ロード時のログでも、モデル本体の約9.2GBのうち5.64GBはこの埋め込み表で、ほかの重みとは別枠で読み込まれていた（語彙数×層数×次元数から計算した大きさと一致する）。ログ上の本体約9.2GBから埋め込み表を除いた約3.5GBで計算し直すと積は56（Ollamaが示すロード時のサイズ9.43GBから埋め込み表を引いた約3.8GBで計算しても61）になり、dense型の3モデルと同じ範囲に入る。1トークンごとに引くのは埋め込み表のごく一部なので、速度を決めていたのは残りの部分だとみられる。

ただしRAMはロード時のサイズのほうで見積もる必要がある。速度は4B級並みでも、載せる量は9.43GBある。RAMの節で挙げた目安（16GBなら8B級までが安全圏）に照らすと、16GBの環境では余裕の小さい側に入る。

MoEのgemma4:26bは、ロード時のサイズ18.30GBと表で最も大きいのに、毎秒14.16トークン出た。3分の1の大きさのqwen3.5:9b（10.01）より速い。Googleの公式モデルカードでは総パラメータ25.2Bのうち1トークンで使うのは3.8Bで、ロード時のサイズの割に速いという7月のqwen3.6:35b-a3bと同じ性格がそのまま出ている。積は259で、表のdense型（50.9〜65.4）の4〜5倍にあたる。7月はMoEを1モデルしか測っていなかったが、構成の違う2つ目のMoEでも生成では同じ向きになった。それでも2モデルなので、一般則とまで言うには足りない。読み込みでは差が付かず、gemma4:26bの毎秒76.4トークンはllama3.1:8b（76.3）やqwen3.5:9b（72.7）とほぼ並んだ。7月の35B MoEは読み込みでも同じ日の8Bのdense型を上回っていたので、読み込みでの有利さは2つのMoEで揃わなかったことになる。

gemma4:26bには注意が2つある。1つ目は、Ollama 0.34.3がこのモデルを既定で「先読み」しながら動かすことだ。配布物に小さな下書き用のモデル（MTP）が入っていて、それが数トークン先（9月の測定の設定では最大3トークン）を予想し、本体がまとめて確かめる方式（投機的デコード）になっている。表のほかのモデルの配布物には下書き用のモデルが入っていないので、表では条件をそろえるために先読みを切った値（リクエストでdraft_num_predictを0に指定）を載せた。既定のままだと生成は毎秒17.18トークンで、先読みなしの14.16より約2割速かった（どちらも交互に測った6回の平均）。先読みがどれだけ当たるかは生成する文章やtemperatureで変わるので、この2割は9月の測定の条件（temperature 0で説明文を生成）での値になる。

2つ目はサイズの表示だ。先読みが有効な既定の状態では、Ollamaが報告するサイズが9.55GBと、先読みを切ったときの18.30GBの約半分に出た。ロード時のログを見ると、本体の重みだけで約17.7GBを確保しているので、実際に近いのは18.30GBのほうだ。下書き用のモデルを持つGemma 4でサイズが小さく表示される現象は、Ollamaの公式リポジトリにも報告がある。RAMの見積もりには18.30GBを使いたい（先読みありの既定では、下書き用のモデルのぶんとしてさらに約0.45GBを確保していた）。記事前半の目安と同じく32GBの環境から試せる大きさだが、32GB環境での動作は試していない。

まとめると、現行モデルに替えても見当の立て方は7月と変わらない。dense型はロード時のサイズから速度の見当が立つ。gemma4:e4bのように大きな埋め込み表を持つモデルは、速度は小さいモデル並み、RAMはロード時のサイズで見積もる、と分けて考える。MoEはロード時のサイズの割に生成が速い（読み込みの有利さは2つのMoEで揃わなかった）。Ollamaが示すロード時のサイズを見るときは、下書き用のモデルを持つモデルで小さく出ることがある点に気をつけたい。

何がCPUで実用的で、何がそうでないか

CPUだけで成立する使い方。短い質問への短い回答、文章の言い換えや校正、タグ付けや分類のような定型処理は3B〜8B級で回る。7月の測定でいえば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の環境でもこの範囲なら収まる。これから入れるなら同クラスの現行世代（名前のB数で4B〜9B級。gemma4:e4b、qwen3.5:4b・9bなど）が候補になるが、名前のB数ではなくロード時のGBで見る必要があり、世代が違えば速度も変わるので上の数字は桁感として使ってほしい。この枠の現行モデルは9月に追加で測っており、qwen3.5:4bが毎秒16.25トークン（ロード時のサイズ3.13GB）、qwen3.5:9bが10.01トークン（6.07GB）だった（思考を切り、Ollamaの版なども7月と違う条件で測った値。同じ日に測り直したllama3.1:8bは11.73トークン）。gemma4:e4bは速度こそ16.03トークンと4B級並みだが、RAMはロード時のサイズの9.43GBぶん要り、16GBの環境では余裕の小さい側に入る。入力が短ければ読み込みの待ちもほとんど発生しない。

条件つきで成立する使い方。長文の要約や資料の読み込みが絡む場合でも、今回測った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側の状態が関わるとみられる。本機のdense型では、ロード時のサイズ×速度から出した見かけの値（40〜60GB/s）が理論帯域89.6GB/sの4〜7割に収まった（MoEはこの形から外れる）。ただし帯域と演算のどちらがどれだけ速度を左右しているかは、今回の測定では分けられていない。GPUを足すなら、VRAM容量がそのまま全層を載せられるモデルの上限になる。価格は変動するので最新の実売を確認してほしい。

メモリは規格が合わないと装着できない。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確認、2026-09-23再確認）
• Ollama公式ドキュメント: Thinking（思考部分と最終回答が別フィールドで返る仕様／2026-07-22確認）
• Google公式: Gemma 4 モデルカード（E4B＝実効4.5B・埋め込み含む総8B、層ごとの埋め込み表（Per-Layer Embeddings）の説明／2026-07-22確認、2026-09-23再確認）
• Ollama公式リポジトリ: v0.34.3 リリース（9月の追加測定で使用した版／2026-09-23確認）
• Ollama公式リポジトリ Issue #17951: 下書き用モデル（MTP）を持つGemma 4で /api/ps のサイズが小さく表示される報告（重複としてクローズ済み／2026-09-23確認）
• Ollama公式リポジトリ Issue #17251: 下書き用のモデル（MTP。Issue内の表記は mtp-accelerator）を併用すると ollama ps の表示が実際の使用量より小さく出る報告（2026-09-23時点でopen）
• Intel公式: 第14世代 Core デスクトップ・プロセッサー Quick Reference Guide（最大メモリ速度は1チャネル1枚の構成でのもの／2026-09-23確認）
• Ollama公式リポジトリ Issue #13986: Modelfileパラメータとしての num_gpu の記載復活を求めるIssue（2026-07-22時点でopen）