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