RTX 3060 でも 35B は動く？llama.cpp の --n-cpu-moe で古い PC をローカル LLM に活かす

最近、ローカル LLM の興味深い実測を見ました。約 3000 元相当の古い PC で、ハードウェアはそのままに、新しい llama.cpp といくつかのパラメータを使うだけで、35B MoE モデルの体験が大きく改善しています。

テスト環境は決してハイエンドではありません。

ハードウェア	構成
CPU	AMD Ryzen 7 3700X
GPU	RTX 3060 12GB
メモリ	32GB DDR4
OS	Windows 11
モデル	Qwen3.6-35B-A3B GGUF Q4_K_M

結論はシンプルです。以前は同じハードウェアで低量子化版をぎりぎり動かす程度でしたが、現在は新しい llama.cpp により、Q4 量子化と 64K コンテキストでも「日常的に使える」状態に近づいています。

重要なのは GPU 買い替えではなく MoE スケジューリング

今回の最重要パラメータはこれです。

1

--n-cpu-moe 32

Qwen3.6-35B-A3B は MoE（Mixture of Experts）モデルです。総パラメータ数は大きく見えますが、推論時にすべての専門家が有効化されるわけではなく、各 token で一部だけが使われます。

ここにローカル推論の余地があります。すべてを GPU に詰め込む必要はありません。llama.cpp の --n-cpu-moe は、MoE の専門家層を CPU と GPU の間でどう分担するかを調整するパラメータで、VRAM が限られた一般向け GPU でもより大きなモデルを動かしやすくします。

RTX 3060 12GB では、--n-cpu-moe 32 は最初に試す価値のあるバランス点です。GPU は得意な CUDA 計算を担当し、CPU は一部の専門家層を分担します。すべてを GPU に押し込む場合や CPU に寄せすぎる場合より、この混合スケジューリングの方が速くなることがあります。

速度はどれくらい変わるのか

典型的な比較は次のように整理できます。

項目	旧構成	新構成
生成速度	約 15 tok/s	約 33-36 tok/s
量子化	Q2_K_M	Q4_K_M
コンテキスト	4K	64K
VRAM 使用量	約 5GB	約 7GB
体験	動くが品質が不安定	より滑らかで回答品質も改善

注目すべき点は、単なる速度向上だけではありません。量子化精度とコンテキスト長が同時に上がっていることです。

以前、多くの 12GB VRAM ユーザーは 30B+ モデルを起動するために、圧縮の強い Q2 量子化を選ぶ必要がありました。モデルは起動しても、推論品質は落ちやすくなります。Q4 に移れるということは、ローカルモデルが「試せる」段階から「仕事に使える」段階へ近づくということです。

Windows 起動コマンドの例

以下は Windows のバッチ起動テンプレートです。パスは自分の環境に合わせて変更してください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


@echo off
chcp 65001 >nul

cd /d C:\Users\你的用户名\llama-b9297-bin-win-cuda-13.1-x64

llama-server.exe ^
 -m "D:\Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" ^
 -ngl 99 ^
 --n-cpu-moe 32 ^
 --flash-attn on ^
 --jinja ^
 -c 65536 ^
 -t 8 ^
 -b 512 ^
 -ub 128 ^
 --cache-type-k q4_0 ^
 --cache-type-v q4_0 ^
 -np 1 ^
 --cache-ram 0 ^
 --host 127.0.0.1 ^
 --port 8080

pause

主なパラメータは次の通りです。

-ngl 99: offload 可能な層をできるだけ GPU に載せる；
--n-cpu-moe 32: MoE 専門家層のスケジューリングを制御する、今回の重要パラメータ；
--flash-attn on: Flash Attention を有効化し、長いコンテキストの負荷を下げる；
-c 65536: 64K コンテキストを設定する；
--cache-type-k q4_0 / --cache-type-v q4_0: KV cache を量子化し、長いコンテキストでの VRAM 使用量を抑える；
-np 1: 単一同時実行。32GB メモリのマシン向け；
--cache-ram 0: prompt cache を無効化し、メモリ使用量を抑える。

注意点として、b9297 はあくまで一つのテスト時点です。2026-05-26 時点では llama.cpp の Release ページはさらに新しいバージョンへ進んでいるため、実際にはより新しい CUDA ビルドを優先して試すのがよいでしょう。

GPU ごとの調整方針

この種の MoE モデルでは、「VRAM が足りないなら諦める」のではなく、CPU/GPU の分担を調整してバランスを探します。

ハードウェア	推奨
RTX 3060 12GB / 3080 10GB	まず `--n-cpu-moe 32` を試す
RTX 3070 8GB / 4060 8GB	`--n-cpu-moe` を 128 や 256 に上げて試す
RTX 3050 6GB / GTX 1650 4GB	より多く CPU offload する。ただし速度低下は大きい
Apple Silicon Mac	Metal backend を使う。統一メモリは大きなモデルに向いている

これらの値を絶対的な正解とは考えない方がよいです。最適な --n-cpu-moe はモデル、量子化、GPU、CPU、メモリ帯域によって変わります。まずは以下のような代表点を試すのが安全です。

1

0 / 16 / 32 / 64 / 128 / 256

tok/s、メモリ使用量、初回 token の遅延、回答の安定性を見て、最終設定を決めます。

32GB メモリで足りるのか

結論としては、動くが余裕は大きくありません。

このような構成では、llama-server の working set が 20GB を超えることがあります。OS はブラウザ、エディタ、ドライバ、バックグラウンドサービスにもメモリを残す必要があります。個人がローカルで単独利用するなら 32GB でも試せますが、常時サービス化したり複数同時呼び出しをするなら 64GB の方がかなり快適です。

おすすめは次の通りです。

まず単一同時実行でテストする；
不要なバックグラウンドプログラムを閉じる；
ブラウザタブを開きすぎない；
CUDA backend が正常に読み込まれていることを確認する；
最初から 128K コンテキストを狙わない。

なぜ注目する価値があるのか

ローカル LLM は長い間、VRAM 不安とセットで語られてきました。35B クラスのモデルには 24GB VRAM が必要で、できれば RTX 4090 が必要だと考える人も多いです。

しかし、この実測は別の方向を示しています。モデル構造と推論フレームワークの改善により、古いハードウェアでも価値を引き出せます。MoE、KV cache 量子化、Flash Attention、CUDA kernel 最適化、CPU/GPU 混合 offload が重なると、単純な GPU アップグレード以上に体験へ効く場合があります。

もちろん魔法ではありません。8GB や 12GB の GPU で 35B MoE を動かすには、速度、コンテキスト、量子化品質、メモリ使用量の間で妥協が必要です。それでも、個人用ナレッジベース、コードアシスタント、長文ドキュメント QA、オフライン検証が目的なら、この種の構成は十分試す価値があります。

まとめ

RTX 3060 12GB、RTX 3080 10GB、あるいは 8GB GPU を持っているなら、新しい llama.cpp をもう一度見直す価値があります。

重要なのは、特定のパラメータをそのままコピーすることではありません。この考え方を理解することです。

MoE モデルでは、すべての専門家を GPU に詰め込む必要はありません。合理的な CPU/GPU 分担は、単純な VRAM 容量より重要になることがあります。

古い PC は小さなモデル専用とは限りません。推論フレームワークと量子化手法が進歩し続ければ、かつて「重すぎる」と判断されたローカルモデルが再び実用圏に入ってきます。

参考リンク

llama.cpp Releases