RTX 3060 也能跑 35B？llama.cpp 的 --n-cpu-moe 讓老電腦繼續跑本地大模型

最近看到一個很有意思的本地大模型實測：同一台大約 3000 元的老電腦，硬體沒有變，只是換了新版 llama.cpp 和一組參數，35B MoE 模型的體驗直接上了一個台階。

測試機器並不誇張：

硬體	配置
CPU	AMD Ryzen 7 3700X
GPU	RTX 3060 12GB
記憶體	32GB DDR4
系統	Windows 11
模型	Qwen3.6-35B-A3B GGUF Q4_K_M

結論很直接：過去同樣硬體只能勉強跑低量化版本，現在用新版 llama.cpp，在 Q4 量化、64K 上下文下也能進入「可日常使用」的狀態。

關鍵不是換顯卡，而是 MoE 調度

這次最佳化裡最關鍵的參數是：

1

--n-cpu-moe 32

Qwen3.6-35B-A3B 屬於 MoE（Mixture of Experts，混合專家）模型。它的總參數規模看起來很大，但每次推理並不會啟用全部專家，而是只啟用其中一部分。

這就給本地推理留下了空間：並不是所有東西都必須塞進 GPU。llama.cpp 的 --n-cpu-moe 參數可以調整 MoE 專家層在 CPU 和 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
顯存占用	約 5GB	約 7GB
體驗	能跑，但品質不穩	更流暢，回答品質明顯提升

這裡最值得注意的不是單純速度翻倍，而是量化精度和上下文長度同時提升。

過去很多 12GB 顯存使用者為了把 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，減少長上下文顯存占用；
-np 1：單併發，適合 32GB 記憶體機器；
--cache-ram 0：關閉 prompt cache，進一步控制記憶體。

需要注意的是，b9297 只是一個測試時點。截至 2026-05-26，llama.cpp Release 頁面已經繼續更新到更高版本，所以實際使用時不必拘泥於 b9297，可以優先嘗試更新的 CUDA 構建。

不同顯卡怎麼調？

這類 MoE 模型的思路不是「顯存不夠就放棄」，而是透過 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 後端，統一記憶體對大模型更友好

不要把這些數值當成絕對答案。--n-cpu-moe 的最佳值和模型、量化、顯卡、CPU、記憶體頻寬都有關係。更穩妥的做法是從幾個典型點測試：

1

0 / 16 / 32 / 64 / 128 / 256

看 tok/s、記憶體占用、首 token 延遲和回答穩定性，再決定最終配置。

32GB 記憶體夠不夠？

結論是：能跑，但餘量不大。

這類配置下，llama-server 行程工作集可能來到 20GB 以上，系統還要保留記憶體給瀏覽器、編輯器、驅動和背景服務。如果只是單人本地使用，32GB 可以嘗試；如果想長期掛服務、多併發呼叫，64GB 會舒服很多。

建議：

盡量單併發測試；
關閉不必要的背景程式；
瀏覽器分頁別開太多；
先確認 CUDA 後端正常載入；
不要一開始就把上下文拉到 128K。

為什麼這件事值得關注？

本地大模型的門檻一直被「顯存焦慮」放大。很多人預設認為 35B 級別模型必須 24GB 顯存，最好還得 4090。

這次實測說明了另一個方向：模型結構和推理框架的最佳化，能讓舊硬體繼續釋放價值。MoE、KV cache 量化、Flash Attention、CUDA kernel 最佳化、CPU/GPU 混合 offload，這些進步疊加起來，可能比單純升級顯卡更影響實際體驗。

當然，它不是魔法。8GB、12GB 顯卡跑 35B MoE 仍然需要取捨：速度、上下文、量化品質、記憶體占用不可能全都拉滿。但如果目標是個人知識庫、程式碼助手、長文件問答、離線測試，這類方案已經很值得折騰。

我的結論

如果你手裡有 RTX 3060 12GB、RTX 3080 10GB，甚至 8GB 顯卡，不妨重新看一眼新版 llama.cpp。

重點不是照抄某一個參數，而是理解這套思路：

MoE 模型不一定要把所有專家都塞進 GPU，合理的 CPU/GPU 分工，可能比「顯存夠不夠」更重要。

老電腦不一定只能跑小模型。只要框架持續最佳化、量化方案繼續進步，很多原本被判定「跑不動」的本地模型，會重新變得可用。

參考連結

llama.cpp Releases