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_M
n-cpu-moe 25
KV Cache 量化 q4_K_Q
上下文窗口 128K

生成速度：62 Token/s。

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

为什么选择 Qwopus3.6？

Qwopus3.6 的核心价值不是“通用聊天更强”，而是在本地 16GB 显存条件下，把编程能力、工程理解和代码修复能力尽量拉满。

我最初把它作为所有本地 agentOS 场景的主模型，是因为它足够通用、足够强。但体验 Nex-N2 系列后，我把模型角色拆开了：

  • nex-n2-mini：负责通用 agent、agentOS、computer use、长任务执行闭环。它的优势是更强的指令遵循、工具调用、状态跟踪和少犯错。
  • qwopus3.6：负责 Claude Code、OpenClaw coding、Opencode、Codex 这类强 harness 编程工具。它的优势是代码理解、Diff 质量、重构和测试修复。

这个选择背后的判断是：

nex-n2-mini 负责“听话、执行、闭环”；qwopus3.6 负责“写代码、修工程”。

agentOS / computer use 为什么切到 nex-n2-mini

Claude Code、Opencode、Codex 这类 AI 编程工具有一个特点：它们通过强 harness 约束模型行为，包括文件修改、git diff、测试反馈、错误恢复和迭代流程。模型不是完全自由地写文本，而是在工程流程里被约束、被验证、被纠错。

所以在这类工具里，只要模型足够听话，核心矛盾就更偏向编程能力本身。因此我会把编程更强的 qwopus3.6 放在这些 coding tool 中。

但 Hermes-agent、OpenClaw 的通用 agent 路径不一样。它们需要模型持续完成：

  • 理解用户目标
  • 拆解任务
  • 调用本地工具
  • 观察执行结果
  • 处理失败
  • 修正计划
  • 把闭环推到可验证状态

这类任务对“指令遵循”和“工具使用稳定性”的要求更高。Nex-N2 系列强调 Agentic Thinking，把 reasoning、tool use、environment execution 连成闭环；Nex-N2-mini 又比 Pro 更适合本地低延迟使用。因此我把本地 agentOS 和 OpenClaw 的主模型切到 nex-n2-mini，是为了让模型更像一个可靠的执行器。

Claude Code / OpenClaw coding 为什么保留 qwopus3.6

强 harness 能显著降低模型自由度带来的风险，但不能完全替代模型能力。

像 Claude Code、Codex、Opencode 这类工具虽然约束了模型，但仍然要求模型做到：

  • 正确理解错误信息
  • 判断是否需要改文件
  • 生成最小必要 patch
  • 避免无关重构
  • 根据测试失败定位根因
  • 避免重复错误修改

这些能力里，编程质量权重很高。因此在这些工具中，我依然选择本地编程最强的 qwopus3.6。

更准确地说，这不是“nex-n2-mini 不如 qwopus3.6”，而是二者承担的任务不同：

场景 核心需求 本地主模型 原因
Hermes-agent / OpenClaw 通用 agent / computer use 指令遵循、工具调用、状态跟踪、执行闭环 nex-n2-mini 更重视可靠执行和少犯错
Claude Code / Opencode / Codex 风格 coding tool 代码理解、Diff、重构、测试修复、工程判断 qwopus3.6 harness 已约束执行，核心释放编码能力

这种策略和社区主流方向是一致的：coding tool 优先 coding model，agentOS / computer use 优先 agentic / tool-following model。成熟做法不是“一个模型打天下”，而是按任务风险域做模型路由。

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

部署方案

llama-swap 部署在 Docker 容器中，核心架构如下：


graph LR
  subgraph 客户端
    HA[Hermes Agent]
    API[OpenAI API]
  end

  subgraph llama-swap
    SW[llama-swap :9292]
    L1[llama-server]
    L2[llama-server]
  end

  subgraph 模型存储
    SSD[/SSD: GGUF/Chat Template/]
  end

  HA --> SW
  API --> SW
  SW --> L1
  SW --> L2
  L1 --> SSD
  L2 --> SSD

  style SW fill:#f9f,stroke:#333,stroke-width:2px
  style SSD fill:#bbf,stroke:#333,stroke-width:2px

llama-swap 作为代理层，负责：

  • 模型热切换：客户端通过统一接口请求不同模型
  • 自动卸载：无请求 5 分钟自动卸载模型，释放显存
  • 生命周期管理：替代 ollama 的自动 offload，但更精细可控

核心配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
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_M.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

  "nex-n2-mini:35b-a3b-q5-128k":
    cmd: |
      llama-server
      --port ${PORT}
      --model /ssd-models/.../nex-agi_Nex-N2-mini-GGUF
      --n-gpu-layers ${n_gpu_layers_max}
      --n-cpu-moe 25
      --ctx-size ${ctx_size_128k}
      --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 分钟无请求自动卸载，释放显存

部署模型来源：

由于 Nex-N2-mini 与 qwopus3.6:35B-A3B 架构相同，部署方案可以直接复用。只需要在 llama-swap 中增加一个模型项，并把 --model 指向实际 GGUF 文件即可；客户端模型名、路由和调用侧默认配置可以按场景独立切换。

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

1
2
3
4
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 浪费和致命代理卡顿设计的，迭代到了 v20 才终于稳定，同时适用于 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_M + KV Cache 量化
  • MoE 专属参数：--n-cpu-moe 是关键
  • 自动模型生命周期管理：llama-swap 填补了 ollama 和 llama.cpp 之间的空白
  • 耐心调试：参数组合需要大量实验

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

AI
#LLM #本地模型 #llama.cpp #Nex-N2 #qwopus3.6 #agentOS #Claude Code #OpenClaw #llama-swap #Qwopus3.6
16GB显存下的本地模型选型与部署方案
https://bipedalbit.net/2026/06/14/本地模型选型与部署方案/
作者
Bipedal Bit
发布于
2026年6月14日
许可协议