AI工具

RTX 3060 也能跑 35B？llama.cpp 的 --n-cpu-moe 让老电脑继续本地大模型

说明 RTX 3060 运行 MoE GGUF 时如何正确使用 llama.cpp 的 --n-cpu-moe，并用统一命令复测速度、显存和首字延迟，避免照抄不可比的跑分。

RTX 3060 12GB 可以借助 CPU/GPU 混合卸载尝试较大的 MoE GGUF，但“能加载”不等于“达到某个固定速度”。llama.cpp 版本、GGUF 来源、量化、上下文、批量大小、CPU 和内存带宽都会改变结果。本文保留一组参考硬件，重点给出可复测的方法。

测试机器并不夸张：

硬件 配置
CPU AMD Ryzen 7 3700X
GPU RTX 3060 12GB
内存 32GB DDR4
系统 Windows 11
模型 Qwen3.6-35B-A3B GGUF Q4_K_M

这张表只是复测基线，不是已经完成的性能证明。下载社区 GGUF 时还应记录仓库、文件名、文件大小和 SHA256；没有这些信息，其他机器无法判断是否在测试同一个模型。

关键不是换显卡，而是 MoE 调度

这次优化里最关键的参数是：

1

--n-cpu-moe 32

Qwen3.6-35B-A3B 属于 MoE（Mixture of Experts，混合专家）模型。它的总参数规模看起来很大，但每次推理并不会激活全部专家，而是只激活其中一部分。

这就给本地推理留下了空间：并不是所有东西都必须塞进 GPU。llama.cpp 的 --n-cpu-moe 参数可以调整 MoE 专家层在 CPU 和 GPU 之间的分配，让显存有限的消费级显卡也能跑更大的模型。

按 llama.cpp CLI 文档，--n-cpu-moe N 表示让前 N 个 MoE 层的权重保留在 CPU。32 只是一个候选值；它可能降低显存占用，也可能因为内存带宽不足而变慢，必须与 0、16、模型实际 MoE 层数等值对照。

用统一口径测速度

不要把不同量化、上下文和提示长度的截图放在一起比较。先固定模型文件与构建版本，再分别测试候选值：

1
2
3

.\llama-bench.exe -m "D:\models\model.gguf" -ngl 99 -fa 1 -p 512 -n 128 -r 5 --n-cpu-moe 0
.\llama-bench.exe -m "D:\models\model.gguf" -ngl 99 -fa 1 -p 512 -n 128 -r 5 --n-cpu-moe 16
.\llama-bench.exe -m "D:\models\model.gguf" -ngl 99 -fa 1 -p 512 -n 128 -r 5 --n-cpu-moe 32

记录 pp512、tg128、峰值显存、系统内存和是否发生磁盘换页。只有同一模型、同一构建和同一参数下的结果才适合横向比较；Q2 与 Q4 的输出质量也不能只靠 token/s 判断。

一个可参考的 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 从 0 开始，再测试 16、32
RTX 3070 8GB / 4060 8GB 先缩短上下文，再逐步增加 CPU MoE 层数
RTX 3050 6GB / GTX 1650 4GB 优先选择更小模型或更低量化，并留意系统换页
Apple Silicon Mac 用 Metal 后端，统一内存对大模型更友好

不要把这些数值当成绝对答案。--n-cpu-moe 的最佳值和模型、量化、显卡、CPU、内存带宽都有关系。更稳妥的做法是从几个典型点测试：

1

0 / 16 / 32 / 模型实际 MoE 层数

看 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 分工，可能比“显存够不够”更重要。

老电脑不一定只能跑小模型。只要框架持续优化、量化方案继续进步，很多原本被判定“跑不动”的本地模型，会重新变得可用。

参考链接