32GBのIntel Mac miniで「35B級MoE」ローカルLLMは動くか — CPUだけで4モデル実測

結論（先に）

• 35B級のMoEモデルも、32GBのIntel Mac mini（GPUオフロードなし＝100% CPU推論）に収まって動く。 速度は 4.8〜6.8 tok/s。人の読み取り速度（約5〜7 tok/s）に近い速度域。
• MoEは"でかいのに速い"。 gemma4:26b（MoE）は 6.6 tok/sで、同じ系列の gemma4:12b（dense）の 2.7 tok/s の 約2.4倍。総パラメータは26B > 12Bなのに、MoEのほうが速い。
• ただし「速い＝使える」ではない。 速度1位の gpt-oss:20b は日本語タスクで素直に答えず、最遅の qwen3.6:35b は中国語の文字が混じる。今回のテストで日本語品質が最もクリーンだったのは gemma4:26b（速度6.6）だった。

検証のきっかけ

よく聞かれるのが「結局、自分のマシンで動くんですか？」という問いです。2026年に入って登場した MoE（Mixture-of-Experts／専門家混合） モデルが、この状況を変えつつあります。総パラメータは20〜35Bと大きくても、1トークンを生成するたびに実際に動くパラメータ数は3〜4Bだけ、という構造です。

「アクティブが3〜4Bなら、3B級の速度（前回の実測で10 tok/s前後）が出るのでは？」と考えていました。本当にそうなるのか、GPUオフロードの効かないIntel Mac miniで確かめました（Intel内蔵GPUはOllamaが使わないため、推論は100% CPU）。Apple Siliconなら話は早い（GPUが効く）のですが、あえて条件の厳しいCPU推論で「どこまで実用か」を見るためです。

検証環境

補足：Intel MacでのOllamaは brew install ollama の本体だけだと推論エンジン（llama-server）が同梱されず、pull は通っても生成が500エラーになります。公式配布版（Ollama.app に同梱）を使うのが回避策です。

bash

cd ~ && curl -fL -o Ollama-darwin.zip https://ollama.com/download/Ollama-darwin.zip
unzip -o -q Ollama-darwin.zip -d ~/ollama-app
~/ollama-app/Ollama.app/Contents/Resources/ollama serve &

計測方法（再現用）

REST APIの eval_count（生成トークン数）と eval_duration（生成所要ナノ秒）から tok/s = eval_count / (eval_duration / 1e9) を計算します。ollama run のverbose表示より安定します。

curl -s http://localhost:11434/api/generate -d '{
  "model": "gemma4:26b",
  "prompt": "あなたは社内の業務アシスタントです。…（日本語の指示）",
  "stream": false,
  "options": { "num_predict": 200, "seed": 42 }
}'

ピークメモリと演算先（CPU/GPU）は、生成中に ollama ps で確認します。

結果

参考までに、前回同じマシンで測ったdenseモデルの素の速度は llama3.2:3b=10.5 / gemma2:9b=4.1 / qwen2.5:14b=2.3 tok/s でした。

発見1：メモリ使用量

4本ともピークメモリは 8.9〜23GB で、計測時はいずれも32GB内に収まりました。最大の qwen3.6:35b でも23GB。これは8GB機では物理的に不可能な領域です。32GBなら20〜35Bクラスも載りますが、8GBでは選択肢に入りませんでした。

発見2：速度（MoEと同門dense比較）

同じGemma 4系列で比べると：

• gemma4:26b（MoE・実際に発火するのは3.8B）→ 6.6 tok/s
• gemma4:12b（dense・12B全部が発火）→ 2.7 tok/s

総パラメータは 26B > 12B。普通なら「大きいほうが遅い」はずが、MoEのほうが約2.4倍速い。生成のたびに動くのが3.8Bだけだからです。「大きく積んで、小さく動かす」は、GPUのないCPUマシンでも成立します。

発見3：速度の上限

一方で、当初の期待は外れました。アクティブ3〜4Bなのでdenseの3B級（10 tok/s前後）が出ると踏んでいましたが、実測は 4.8〜6.8 tok/s。むしろdenseの9B（4.1）寄りです。

CPU推論では、発火するのが3〜4Bでも、全エキスパートをメモリ上に持ち、トークンごとにどのエキスパートを使うか選ぶ（ルーティング）コストが乗ります。GPUのような並列メモリ帯域がない分、ここが効いてきます。MoEの利得は部分的に効く。「載る・denseより速い」は本当ですが、「劇的に速い」とまでは言えません。

発見4：思考モデルの挙動

qwen3.6 や gpt-oss は reasoning（思考）モデルです。生成を num_predict: 200 に絞ると、200トークンを全部「思考（thinking）」に使い切り、最終回答（response）が空のまま打ち切られました（done_reason: length）。

速度の数値自体は200トークンを実際に生成しているので有効です。ただし日本語の回答を得たいなら、思考を切る（think: false）か、トークン上限を増やす必要があります。最新モデルをデフォルト設定のまま使うと、答えではなく思考過程だけが返ってくることがある、というのは2026年のローカルLLMで注意しておきたい挙動です。

発見5：日本語品質

思考を切って回答本文を取り直すと、速度と日本語品質の順位は一致しませんでした。

• gemma4:26b（◎）：自然で構造化された日本語。利点・注意点を過不足なく列挙。例：「機密情報の保護：データを外部に送信せず社内サーバー内で完結するため、設計図や製造ノウハウの流出リスクを最小限に抑えられます」。
• gemma4:12b（◎）：dense 12Bでも日本語はクリーン。
• qwen3.6:35b（○）：内容は濃いが、中国語の簡体字・異体字が混入（「データ主权」「取舍」「論理推問」など）。社外に出すには校正が要る。
• gpt-oss:20b（△）：思考を切っても回答せず思考のみ、しかも英語。日本語タスクに素直に出すには追加の作り込みが必要。

皮肉なことに、生成速度1位の gpt-oss は日本語で答えず、最遅の qwen3.6 は中国語が混じる。速度の数字だけで選ぶと外す好例です。

実際の出力（抜粋）

同一プロンプト「製造業の中小企業がローカルLLMを導入する利点と注意点を日本語の箇条書きで5つ」で取得した結果。

gemma4:26b（◎） — 構造化された自然な日本語：

機密情報の保護: データを外部（クラウド）に送信せず社内サーバー内で完結するため、設計図や製造ノウハウなどの流出リスクを最小限に抑えられます。

gemma4:12b（◎） — dense 12Bでも同様にクリーン：

機密情報の保護: 設計図面、製造ノウハウ、顧客情報などの機密データを外部サーバーに送信せずに処理できるため、情報漏洩リスクを低減できます。

qwen3.6:35b（○） — 内容は濃いが中国語の文字が混入：

データ主权を完全に自社で管理できます／モデルサイズの取舍／複雑な論理推問ではクラウド型LLMに比べて性能が劣る

gpt-oss:20b（△） — num_predict=500 でも回答（response）は空。思考（thinking）のみ英語で完結：

（response_len=0 / thinking_len=1257。最終回答なし）

4モデル比較サマリ

参考：人が日本語を読む速度の目安は約7〜10文字/秒（≒tok/s）。6 tok/s台はその手前で、ストリーミング対話に使える範囲。

このデータで分かったこと

まとめ

• 32GBのIntel Mac mini（CPUのみ）で、35B級のMoEも4.8〜6.8 tok/sで動く。 人の読み取り速度（約7〜10文字/秒）に近い速度域。
• MoEは同門denseより速い（gemma4で約2.4倍）。「大きく積んで小さく動かす」はCPUでも成立する。
• ただし「アクティブ3B＝3B並みの速度」とはいかないし、速い＝使えるでもない。今回のテストでは日本語品質が最もクリーンだったのはgemma4:26bだった。
• OllamaとこのRESTコマンドがあれば、32GBのIntel Macでも動く。