12GB显存跑Qwen3.6，35B MoE实测流畅

12GB VRAM跑35B MoE架构，生成速度稳定在46 t/s以上，32k长上下文无OOM风险。这组实测数据直接验证了中端显卡部署大参数模型的可行性，无需堆砌多卡即可满足日常开发需求。

• 12GB显存为Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf的甜点配置，足够保留核心专家层在GPU
• 参数-ncmoe决定MoE块卸载策略，设为18可兼顾速度与安全边界
• MTP推测解码仅提升2%吞吐，日常编码场景直接上32k上下文收益更高

硬件环境锁定在RTX 3060 12GB、32GB DDR4-3200与Windows平台的CUDA 13.x。针对Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf，-ncmoe是调优的核心杠杆。该参数直接控制MoE专家块的GPU驻留数量，数值越低，驻留GPU的专家越多，解码算力越集中。配合KV缓存量化策略，q8_0在此卡上几乎零性能开销，且生成速度显著优于q5_0或混合精度方案。llama-bench测得纯净解码性能达到pp512 ~914 t/s与tg128 ~46.8 t/s。工程落地时，预填充阶段的吞吐量必须依赖基准测试工具的pp512指标，终端交互行的Prompt读数存在干扰，不足以作为性能定标依据。

上下文窗口与显存余量的平衡是部署关键。16k配置下生成速度微增至~44.5 t/s，但显存仅剩~37 MiB，逼近OOM悬崖。切回32k后，生成速度维持在~43.4 t/s，显存释放至~273 MiB。对于代码生成任务，长上下文带来的Token容纳能力远比那1 t/s的瞬时提升更有价值，保留安全余量是生产环境的底线。

参数扫描与MTP实测对比

在-t 11的纯解码测试中，-ncmoe的数值直接决定性能拐点。低于18时，速度出现断崖式下跌，工程调参必须避开该区域：

-ncmoe 22: tg128 ~41.6 t/s -ncmoe 20: tg128 ~41.7 t/s -ncmoe 19: tg128 ~44.2 t/s -ncmoe 18: tg128 ~45.9 t/s (安全阈值) -ncmoe 17: tg128 ~46.6 t/s (显存边缘) -ncmoe 16: tg128 ~25.8 t/s (性能断崖)

MTP推测解码的测试同样暴露出边际效应递减。启用llama.cpp MTP分支，配置--spec-draft-n-max 2并配合-ncmoe 19时，生成速度达到峰值~47.7 t/s。将depth拉高至3反而拖累性能至~39.8 t/s，且-ncmoe降至18或16时会直接触发invalid vector subscript崩溃。对比调优后的纯解码方案，MTP仅带来约2%的生成加速。在显存吃紧的消费级显卡上，牺牲稳定性换取微小提速并不划算，纯解码配合大上下文才是更稳健的工程选择。

生产环境推荐配置

日常编码任务直接套用以下参数组合，兼顾吞吐与上下文长度。该配置锁定32k上下文，关闭Jinja模板与内存映射，强制使用q8 KV缓存与Flash Attention：

llama-cli.exe ^ -m "Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf" ^ -p "..." -n 512 -c 32768 ^ --temp 0 --top-k 1 -ngl 999 -ncmoe 20 ^ -fa on -ctk q8_0 -ctv q8_0 ^ --no-mmap --no-jinja -t 9 --perf

若追求极限预填充速度且能接受极低显存余量，可切换至16k方案（-c 16384 -ncmoe 19），但生产环境强烈建议保留200 MiB以上的安全水位。模型文件需自行下载对应GGUF版本，加载时确保CUDA 13.x环境完整。KV缓存扫描数据明确显示，q8_0组合在此硬件上为最优解，混合精度或q5_0方案会显著拖慢tg128表现，部署时应直接锁定q8参数。

你在部署MoE架构时，是优先压低-ncmoe保解码速度，还是优先开大-q8 KV缓存保长上下文？生产环境里踩过哪些显存断崖的坑？