16GB显存下的本地模型选型与部署方案

2026年4月，OpenRouter 上我长期依赖的主力模型 stepfun/step3.5-flash:free 宣布下架，这成了我寻找本地最佳主力模型的契机。当时本地模型部署方案还只有 ollama，而 16GB 显存的 RTX 4070 Ti Super 在 ollama 下最多只能跑 qwen3.5-9b——这显然不够。

于是我开始了一段曲折的选型之路。

尝试量化极限：27B 模型的显存困局

Qwen3.5 系列刚开源时，我尝试强行部署 qwen3.5-27b 和 qwen3.5-35b-a3b 的极度量化版本。

27B 模型即使量化到 Q2，推理速度也慢得无法接受。更诡异的是，把上下文压缩到 32K 这么小，也做不到纯 GPU 加载——推测是静态图显存占用已经太大。

而 35B-A3B 这个 MoE 模型，情况完全不同。使用 Q2_K_M 量化，配合 ollama 全局 q4_K_Q 量化，显存占用刚好能跑推理，文本生成速度达到了惊人的 117 Token/s。

但代价是：这种程度的量化让模型降智严重，很难放心使用。

正当我研究 Qwen3.5 的多种蒸馏版本时（以 Qwen3.5 为学生模型，蒸馏 Opus 4.6/4.7、GLM5.1、DeepSeek V4 等前沿模型），OpenRouter 上 qwen/qwen3.6-plus:free 短暂上架了几天，让我第一次体验到 Qwen3.6 的优秀模型质量。很快 Qwen3.6 也开源了，但只放出了 35B-A3B 和 27B 权重。我照例尝试了 Q2_K_M 量化——速度依旧飞快，质量依然堪忧。

Ollama 的极限已到。 它的智能 offload 没能选出让 35B-A3B 这种 MoE 模型性能最佳的配置，量化更是只能一降到底。

llama.cpp 的突破口

我在 Qwopus3.6 的 HuggingFace 评论里翻到了有趣的”买家秀”——有人用 llama.cpp 配合 --n-cpu-moe 25，在 4060 显卡上跑 Q6 量化版本，居然跑出了 30+ Token/s 的生成速度。

这让我非常眼馋。但问题在于：我放不下 ollama 的自动模型换入换出能力。

经过调研，我找到了 llama-swap——一个轻量级的模型热切换代理，完美满足了我的需求：既能用 llama.cpp 的精细参数控制，又保留了自动模型生命周期管理。llama-swap 是一个零依赖的 Go 代理，⭐ 4.5k，支持任意 OpenAI/Anthropic 兼容的推理后端（llama.cpp、vllm、tabbyAPI 等），具备自动模型卸载（ttl）、并发模型矩阵、内置 Web UI 等特性。

终于，能用 --n-cpu-moe 参数后，我试出了当前主模型的配置：

参数	值
模型	Qwopus3.6-35B-A3B
量化格式	Q5_K_L
n-cpu-moe	25
KV Cache 量化	q4_K_Q
上下文窗口	128K

生成速度：62 Token/s。

主模型终于达到了基本可作为主力模型使用、强于部分厂商模型的智力水平。

为什么选择 Qwopus3.6？

Qwen3.6 的 35B-A3B 权重本身质量优秀，但 Q2 量化下幻觉严重。Qwopus3.6-35B-A3B 是蒸馏版本中口碑最好的——Jackrong 是 HuggingFace 上极为活跃的模型产出者，也是 Qwopus 系列的作者，通过蒸馏大幅改善了量化带来的降智问题。

Qwopus3.6 的官方定位是”推理增强的 MoE 模型”：总参数量 35B，激活参数 3B/token，256 个专家，原生支持 262K 上下文窗口。在 Tekholms.aptm 的独立评测中，它以 88.6 的总分（质量 94.2、可靠性 91.7%）远超基座模型。

模型	总分	质量	可靠性	速度
🏆 Qwopus3.6-35B-A3B-v1	88.6	94.2	91.7%	44 tok/s
Qwen3.6-35B-A3B-Claude-4.6-Opus	82.7	86.0	86.1%	44 tok/s

Q5_K_L 量化在质量和显存之间取得良好平衡。16GB 显存下，配合 --n-cpu-moe 25 将 MoE 的中间层卸载到 CPU，显存占用刚好够用。

部署方案

llama-swap 部署在 Docker 容器中，核心配置：

macros:
  host: "0.0.0.0"
  n_gpu_layers_max: "999"
  ctx_size_128k: "131072"

models:
  "qwopus3.6:35b-a3b-q5-128k":
    cmd: |
      llama-server
      --port ${PORT}
      --model /ssd-models/.../Qwopus3.6-35B-A3B-v1-Q5_K_L.gguf
      --mmproj /ssd-models/.../qwopus3.6-35b-a3b-mmproj.gguf
      --n-gpu-layers ${n_gpu_layers_max}
      --n-cpu-moe 25
      --ctx-size ${ctx_size_128k}
      -ctk q4_0
      -ctv q4_0
      --flash-attn on
      --jinja
      --chat-template-file /ssd-models/.../chat_template.jinja
      --host ${host}
    ttl: 300

关键参数说明：

• n_gpu_layers_max: 999：全 GPU 加载（llama-swap 的宏定义）
• --n-cpu-moe 25：MoE 层卸载到 CPU，这是 MoE 模型显存优化的关键
• -ctk q4_0 -ctv q4_0：KV Cache 量化为 q4_0，进一步节省显存
• ttl: 300：5 分钟无请求自动卸载，释放显存

Hermes Agent 通过 custom provider 连接 llama-swap：

model:
  base_url: http://localhost:9292/v1
  default: qwopus3.6:35b-a3b-q5-128k
  provider: custom:llama-swap

踩过的坑

坑一：ollama 智能 offload 的幻觉

ollama 的自动 offload 对 MoE 模型并不友好。它尝试将更多层加载到 GPU 以加速，但 MoE 模型的中间层（MoE）显存占用巨大，反而导致无法加载或推理极慢。手动指定 --n-cpu-moe 25 才是正解。

坑二：KV Cache 量化被忽略

KV Cache 占用的显存往往被低估。35B 模型在 128K 上下文下，KV Cache 可能占用数 GB 显存。K 和 V 都要用 q4 量化，加上 -ctk q4_0 -ctv q4_0 后，显存占用大幅下降。

坑三：Chat Template 的循环问题

起初不论我用哪一版模型，都很容易在 think 和 tool call 时发生循环——模型在 think 和 tool call 的推理过程中分别都会无限循环。直到在 HuggingFace 上发现了 froggeric/Qwen-Fixed-Chat-Templates，才彻底解决了问题。这个 template 是专为修复 Qwen 3.5/3.6 官方模板的渲染错误、KV Cache 失效、Token 浪费和致命代理卡顿设计的，迭代到了 v19 才终于稳定，同时适用于 qwen3.5 和 3.6。

坑四：模型权重文件存储位置影响加载速度

高频使用的模型权重文件放在 SSD 上能显著提高加载速度——对当前主模型，这个改进把加载耗时从 1 分钟以上压缩到了 20 秒以内。如果模型文件放在 HDD 上，每次模型换入都会经历漫长的加载等待。

展望

llama.cpp 后来支持了 MTP（Mixture of Token Predictions），但这对 MoE 模型作用不大，对稠密模型的效果也不够显著，我没有采用。

最近，Gemma4 放出了一些 QAT（量化感知训练）版本——这是 MoE 模型能受益的技术。我等着 Qwen 放出 QAT 版权重，进一步提高 Q5 量化版本的智力水平。

另外，HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive 模型中的 K_P 量化很有意思。K_P（”Perfect” quant）是 HauhauCS 的自定义量化方法，通过模型特定的重要性矩阵分析，在关键位置保留更高精度——“有效将质量提升 1-2 个量化等级，而文件大小仅比基础量化大 5-15%”。可惜只有这个 Uncensored 版本有 K_P 量化，要是有 Qwopus3.6 的就好了。Q4_K_P 版本实际效果我正在验证。

总结

16GB 显存下，35B-A3B MoE 模型的性能天花板很高，但需要：

• 合适的量化格式：Q5_K_L + KV Cache 量化
• MoE 专属参数：--n-cpu-moe 是关键
• 自动模型生命周期管理：llama-swap 填补了 ollama 和 llama.cpp 之间的空白
• 耐心调试：参数组合需要大量实验

现在，主模型终于达到了基本可作为主力模型使用的水平。