二、测试目的

验证 8G 显存消费级显卡在 Windows 环境下运行 35B MoE 大模型的可行性，并压榨出最大上下文长度与稳定生成速度的平衡点。

三、测试过程与数据记录

阶段 1：默认参数（失败）

-ngl 80 -c 4096

• 显存：逼近 8G 爆满
• 现象：failed to fit params to free device memory，llama.cpp 自动回退
• 速度：~7.5 t/s（显存爆满触发内存交换，断崖式下跌）
• 结论：不可直接用默认参数硬塞

阶段 2：MoE 专家路由优化（部分改善）

-ngl 80 --n-cpu-moe 38 -c 4096

• 显存：~2.5G（异常偏低）
• 速度：~15 t/s
• 问题：显存过低，说明 GPU 层数被过度削减，大量权重滞留 CPU 内存，速度瓶颈在内存带宽而非 GPU

阶段 3：强制显存适配 + 降低 GPU 层数（关键突破）

-ngl 30 --n-cpu-moe 20 -c 4096 -fit off

• 显存：6.8G / 8G（余量 1.3G）
• 速度：~15 t/s
• 结论：-fit off 关闭自动适配后，30 层权重成功驻留显存，进入甜点区

阶段 4：上下文扩容（最终定稿）

-ngl 30 --n-cpu-moe 20 -c 8192 -fit off

• 显存：7.0G / 8G（余量 1.1G）
• 速度：~17 t/s
• 结论：上下文从 4K 提升到 8K，显存仅增加 ~200MB，速度反而微升，达到最佳平衡点

四、最终推荐配置（定稿）

@echo off
cd /d D:\llama-b9374-bin-win-cuda-12.4-x64
llama-server.exe ^
  -m "models\Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-IQ2_M.gguf" ^
  -ngl 30 ^
  --n-cpu-moe 20 ^
  -c 8192 ^
  -n 2048 ^
  --no-warmup ^
  -np 1 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  -fit off
pause

五、关键结论

1. 8G 显存跑 35B MoE 可行，但需精确调参

   • 不能无脑 -ngl 80，必须配合 -fit off 手动控制显存分配
   • --n-cpu-moe 是 8G 卡跑大 MoE 模型的核心参数，负责将非激活专家路由到系统内存

2. 显存甜点区：6.5G ~ 7.2G

   • 低于 6G：GPU 层数不足，权重在 CPU，速度受限
   • 高于 7.5G：余量不足，Windows WDDM 驱动波动易导致爆显存断崖

3. Windows WDDM 驱动占用不可忽视

   • 可用显存仅 7.1G 左右（8192 MiB 标称，实际空闲 7158 MiB）
   • 同配置在 Linux 下预计可多出 500MB~1G 可用显存，有望稳定 16K 上下文

4. 上下文与速度并非完全负相关

   • 本例中 4K → 8K 上下文，速度从 15 t/s 微升至 17 t/s，说明之前 4K 时 GPU 利用率未吃满，8K 反而让流水线更饱和

5. Qwen3.6-35B-A3B 的思考链（thinking）会消耗额外 token

   • 复杂 prompt 容易陷入长 reasoning 导致响应延迟
   • 建议前端 prompt 加前缀约束："请直接回答，不要输出思考过程"

六、使用注意事项

• 运行时请勿同时运行大型游戏或视频剪辑软件，1.1G 余量经不起抢占
• 长期稳定运行建议保持 -c 8192，不要尝试 16K（预估显存需求 8.5G+，必爆）
• 如需更高速度，唯一出路是换显卡（显存 12G+）或迁移至 Linux 系统