Macの統合メモリではこの技がそもそも要らない理由──llama.cppの--cpu-moe/-ncmoeを公式ドキュメントで確認した

ローカルLLM界隈で急速に広まった--cpu-moe・-ncmoeというllama.cppのオプション。NVIDIA RTX系のVRAM不足を補う小技として英語圏の実測記事が急増しているが、Mac（Apple Silicon）ユーザーの視点からの解説はほとんど見当たらない。本稿はllama.cpp公式リポジトリのドキュメントを一次で確認し、このオプションが何をするものか、そしてMacでは何が違うのかを整理する。

3行まとめ

1. -cmoe, --cpu-moeは「Mixture of Experts（MoE）の重みをすべてCPU側に保持する」オプション、-ncmoe, --n-cpu-moe Nは「先頭N層分のMoE重みだけをCPU側に保持する」オプション。いずれも公式ドキュメントに明記されている
2. この機能が解決する問題は「VRAM（GPU専用メモリ）に収まりきらない巨大なMoEモデルを、GPUとCPU（システムRAM）に分割して動かす」こと。GPUとCPUのメモリが物理的に分離している構成が前提になっている
3. Apple SiliconのMacはGPUとCPUが同じ物理メモリ（統合メモリ／Unified Memory）を共有する設計のため、「GPU用メモリとCPU用メモリのどちらに重みを置くか」という分割自体の意味合いが、NVIDIA環境とは根本的に異なる

--cpu-moe／-ncmoeは何をするオプションか

llama.cppの公式サーバードキュメント（tools/server/README.md）には、該当オプションが次のように定義されている。

MoE（Mixture of Experts）型のモデルは、パラメータ全体を毎回すべて使うのではなく、入力ごとに一部の「専門家（エキスパート）」の重みだけを選んで計算する構造を持つ。この特性を利用し、「実行時に選ばれる可能性のあるMoE部分の重みだけはシステムRAM（CPU側）に置いておき、それ以外の層（アテンション層など）はVRAM（GPU側）に置く」ことで、GPUのVRAM容量を超える巨大なモデルでも動かせるようにする、というのがこのオプションの狙いである。

なお同じREADMEには、投機的デコーディング用のドラフトモデル向けに--spec-draft-cpu-moe・--spec-draft-n-cpu-moeという対になるオプションも用意されていることが確認できた。

この技が前提にしている「メモリの分離」

-cpu-moe系オプションが意味を持つのは、GPUの高速なVRAM（数十GB程度が一般的）と、CPUがアクセスするシステムRAM（比較的大容量だが低速）が、物理的に別のメモリチップとして存在する構成が前提にある。NVIDIAのコンシューマー向けGPU（RTX 4090・5090など）はまさにこの構成で、VRAM容量の上限（例えば24GBや32GB）を超えるモデルを動かそうとすると、どの層をVRAMに置き、どの層をシステムRAMに「オフロード」するかという配分の最適化が、体感速度に直結する重要な調整項目になる。

Apple Siliconでは前提そのものが違う

llama.cppの公式READMEは、Apple Siliconについて「ARM NEON・Accelerate・Metalフレームワークで最適化された、ファーストクラスの対応プラットフォーム」と明記しており、対応バックエンド一覧にも「Metal（Apple Silicon向け）」が挙げられている。

Apple Siliconの大きな特徴は、GPUとCPUが同じ物理メモリチップ（統合メモリ／Unified Memory）を共有する設計になっていることだ。Apple自身がM1発表時から一貫して説明してきたこのアーキテクチャでは、「VRAM」と「システムRAM」という区別自体が存在しない。GPUもCPUも、同じメモリプールに直接アクセスできる。

この構造の違いが意味することは次の通りだ。

• NVIDIA環境（VRAM分離型）: モデルの一部をVRAMに、一部をシステムRAMに物理的に振り分ける必要があり、その配分を-ngl（GPUに載せる層数）や-cpu-moe系オプションで細かく調整することが、動かせるモデルサイズと速度の両方を左右する
• Apple Silicon環境（統合メモリ型）: GPU（Metal経由）がアクセスするメモリと、CPUがアクセスするメモリが最初から同じ物理メモリなので、「MoEの重みをCPU側に固定する」という操作をしても、GPU側から見た実効的なアクセス速度・容量の制約が、NVIDIA環境ほど劇的には変わらない

つまり、Mac上でllama.cppを使ってMoEモデルを動かす場合、-cpu-moe系オプションでわざわざ重みの配置を調整する動機そのものが、NVIDIA環境と比べて薄いというのが、統合メモリアーキテクチャから導かれる論理的な帰結である。

GitHub Issueで見つかった実例──Metalには独自の「working set」上限があり、話はもう少し複雑

llama.cppのGitHub Issueをcpu-moeで検索すると、実際にMac（Metal）環境でこのオプションを使おうとした開発者の報告が複数見つかった。中でも2件は、この記事の前提そのものに関わる重要な情報を含んでいた。

1件目、2026年に報告されたIssue #27822（"Hybrid CPU/Metal: Metal OOM leads to EXC_BAD_ACCESS"）は、M5 Pro・統合メモリ64GiBの環境で、67.5GiBのモデル（当然RAMに収まらないサイズ）を--cpu-moe付きで読み込もうとした際の挙動を報告している。報告者はこう書いている。

"Separately, and probably known: -ot/--cpu-moe don't reduce what Metal maps, since the mmap span is per-file."

（訳）「別件として、おそらく既知の話だが、-ot／--cpu-moeはMetalがマッピングする範囲を減らさない。mmapの範囲がファイル単位で決まるためだ」

2件目、既にクローズ済みのIssue #24510（"Metal: -ngl maps the whole model file when the blocks are not contiguous"）は、このメカニズムをより具体的に検証している。M1 Pro・16GB環境で、-ngl 2（49層中2層だけをGPU側にオフロード、実際の重みは約947MiB）を指定したところ、実際にMetalがマッピングしたモデルバッファのサイズは30,973MiB（約30GB）──ファイル全体に近いサイズだったという。原因は、GGUFファイル内でオフロード対象のテンソルが連続した位置に格納されていない場合、Metalバックエンドが「最小オフセットから最大オフセットまで」を1つの連続領域としてマッピングしてしまう実装（get_mapping_range）にあると、報告者はコード上の該当箇所まで示して説明している。テンソルの並び順を変える（output.weightをファイル末尾に移動する）ことで、マッピングサイズは30,973MiBから947MiBまで縮小したことも実証されていた。

この2つのIssueが示すのは、「統合メモリだからVRAM/RAMの区別が意味を持たず、-cpu-moeの効果が薄れる」という単純な話ではなく、Metalバックエンド自体にrecommendedMaxWorkingSetSizeという独自のメモリ上限があり、しかもそのマッピング計算の実装上の癖（mmap範囲がファイル単位）によって、-cpu-moe系オプションを使っても意図通りにメモリ使用量を減らせない場合がある、というより具体的な技術的事情だ。前段までの「統合メモリでは分割の意味合いが薄れる」という論理的推論自体は否定されないが、実際にMacでこのオプションを使おうとした際に起きる問題は、その推論よりも実装依存で込み入っている。

「Macでは不要」は公式明記ではなく論理的な推論

• 「Macでは-cpu-moe系オプションの効果が薄れる」という当初の結論は、GitHub Issue #27822・#24510で見つかった実例により、部分的に裏付けられたと同時に、より複雑であることも分かった。単純に「不要」なのではなく、Metal特有のmmap実装の癖により、意図通りに機能しないケースが報告されている
• Issue #24510はstale（14日間動きがない）を理由に自動クローズされており、修正がマージされて解決したのか、単に放置されているだけなのかは、コメント欄からは判断できなかった。Issue #27822は本稿執筆時点（2026年8月27日）でオープンのままだった
• この2件のIssueはいずれも特定モデル・特定バージョンでの再現報告であり、すべてのMac・すべてのMoEモデルで同様の問題が起きると一般化できるかどうかは、本稿では検証していない。自分の手元のMac環境で実際に--cpu-moeを使って再現を試みたわけでもない
• --cpu-moe系オプションのNVIDIA環境における具体的な速度改善幅（何倍速くなるか）は、本稿では実測データを確認しておらず、数値としては記載していない

関連記事

• Mac Studio 1台か、Mac mini 3台の分散推論か
• Qwen3.8-27BはどのMacで動くか
• ローカルLLM おすすめモデル【2026年】
• オープンソース vs クローズドAI 比較【2026年】