Qwen3.6 本地部署显存：27B 与 35B-A3B 量化估算和实测方法

Qwen3.6 本地部署常见的两个开放权重版本是 Qwen3.6-27B 和 Qwen3.6-35B-A3B。前者是 27B 稠密模型，后者是约 35B 总参数、每个 token 激活约 3B 参数的 MoE 模型。

MoE 的激活参数较少，通常能降低每 token 计算量，但不会把需要加载的权重缩小到 3B。选择显卡时应先看总权重和量化文件，再计算 KV cache 与运行余量。

三种数字不能混用

• 理论权重体积：用参数量和位宽计算，只用于初筛；
• GGUF 文件大小：具体转换文件在磁盘上的大小，包含量化元数据；
• 运行时显存：权重、KV cache、计算缓冲、多模态投影和后端开销之和。

网上写“Q4 需要 18GB 显存”而不说明模型文件、上下文和后端，不能视为实测结论。

裸权重理论估算

公式：

1

权重 GiB ≈ 参数量 × 位宽 ÷ 8 ÷ 1024³

实际 GGUF 通常大于对应的裸权重估算。不同 Q4/Q5 方案的有效平均位宽也不同，因此表格不能代替下载页的真实文件大小。

按显存做初步选择

以下是部署起点，不是保证值，默认单并发、4K 左右上下文并允许必要的 CPU offload：

如果同时加载视觉 mmproj、把上下文提高到几十万 token 或增加并发，显存需求会显著上升。不要把模型卡的最大上下文当成默认启动值。

选 GGUF 时记录完整文件名

至少记录：

1
2
3
4
5
6

基础模型：Qwen/Qwen3.6-27B 或 Qwen/Qwen3.6-35B-A3B
转换仓库与 commit：
GGUF 文件名：
量化：Q4_K_M / Q5_K_M / 其他
SHA256：
llama.cpp 版本：

第三方 GGUF 应能追溯到官方基础权重，并说明转换工具和许可证。只有仓库名相似，不能证明文件来自官方。

llama.cpp 的实测步骤

从 4K 上下文、单并发开始：

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen-model-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

另开终端记录：

1

nvidia-smi --query-gpu=name,memory.total,memory.used,driver_version --format=csv

启动日志中还要保存模型缓冲、KV cache、offload 层数和后端信息。之后分别在 4K、8K 上下文下运行同一提示词，记录峰值显存、首 token 延迟和生成 tokens/s。

Ollama 的测量方法

1

ollama run qwen3.6:27b

具体标签以 Ollama 模型库当前页面为准。运行后执行：

1
2

ollama ps
nvidia-smi

ollama ps 的 PROCESSOR 会显示 CPU/GPU 分配。如果模型标签没有明确量化类型，不能把结果与某个 GGUF 的 Q4_K_M 直接比较。

稠密模型与 MoE 的部署差异

27B 稠密模型每一层都参与计算，结构相对直接；35B-A3B 会根据 token 路由到部分专家。部署 MoE 时除了权重容量，还要关注后端是否正确实现专家路由。

可能出现的差异包括：

• 相同权重体积下，每 token 计算量不同；
• MoE 对内存访问和专家调度更敏感；
• 不同后端对专家的 GPU/CPU 分配策略不同；
• 某些旧版后端能读配置，却不能正确生成；
• 多卡分配时，专家跨设备传输可能成为瓶颈。

因此，35B-A3B 不能只与 3B 模型比较速度，也不能只与 35B 稠密模型比较显存。

下载前计算磁盘与系统内存

本地部署至少会同时存在下载缓存、GGUF 文件和运行时内存映射。计划测试多个量化时，磁盘很容易先不够。

Windows 可检查：

1
2
3
4
5

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Used, Free

Get-CimInstance Win32_ComputerSystem |
  Select-Object TotalPhysicalMemory

系统内存不应只等于未 offload 的权重。如果模型部分放在 CPU，还要为操作系统、文件缓存、KV cache 和后端缓冲留出空间。系统开始频繁换页后，生成速度会大幅下降。

为两个型号建立独立启动配置

不要反复修改同一条长命令。分别建立脚本，能避免测 27B 时误用 35B 的上下文或文件。

27B 起步命令

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen3.6-27b-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8081

35B-A3B 起步命令

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen3.6-35b-a3b-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8082

端口分开后，可以逐个启动和对比；显存不足时不要同时运行两个服务。

验证聊天模板和思考输出

Qwen 不同版本可能有不同的聊天模板、思考模式或特殊 token。出现以下现象时，先查模型卡与后端支持：

• 输出把 system、user 等角色标签原样打印；
• 回答不断重复；
• 思考内容与最终答案边界异常；
• JSON 输出前混入额外标记；
• 工具调用参数不是合法 JSON。

不要通过删除随机特殊 token 来“修复”。模板错误可能让基准测试和实际应用得到完全不同的结果。

API 连通与模型身份检查

启动两个服务后，分别检查模型列表：

1
2

curl.exe http://127.0.0.1:8081/v1/models
curl.exe http://127.0.0.1:8082/v1/models

再使用相同请求比较：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

$payload = @{
  model = 'local-qwen'
  messages = @(
    @{ role = 'user'; content = '用 JSON 返回三个 Linux 日志排查步骤。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
  -Uri 'http://127.0.0.1:8081/v1/chat/completions' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $payload

把端口改成 8082 重复测试。检查服务日志中的实际模型文件，避免客户端传入的 model 字段掩盖了后端加载的文件。

KV cache 应单独测量

测量顺序可以是：

1. 服务刚启动、未请求；
2. 输入 1K token；
3. 输入 4K token；
4. 输入 8K token；
5. 保持 8K，增加第二个并发请求。

每一步记录显存峰值与响应时间。若只记录启动后显存，就会漏掉长上下文和并发产生的缓存。

测试文本应来自本地固定文件，避免每次 token 数不同。可以先用客户端 tokenizer 统计，或从 API usage 字段核对实际输入 token。

多卡部署先确认分配结果

两张 24GB 显卡不一定自动得到理想的 48GB 空间。不同后端可能按层、张量或专家切分，且一张卡还会承担额外输出层和缓存。

观察每张卡：

1

nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu --format=csv -l 1

如果一张卡接近 OOM、另一张仍有大量空闲，应查当前 llama.cpp 的 tensor split 与设备选择参数。参数会随版本变化，使用前以对应 release 的帮助输出为准：

1

.\llama-server.exe --help

不要复制旧版本的多卡参数后直接用于生产。

视觉输入要做三项匹配

多模态部署需要同时满足：

• 该 Qwen 模型本身支持视觉输入；
• mmproj 与具体基础模型匹配；
• 当前 llama.cpp 构建支持该多模态架构。

视觉投影文件不能在 27B 与 35B-A3B 间随意混用。测试时先用一张小图片和一个明确问题，再检查日志是否真的加载视觉编码器。只收到文本回答不代表图片被处理。

还要记录图片尺寸和数量，因为视觉 token 同样会扩大上下文与缓存。

建立自己的任务基准

建议至少包含五类任务：

每个任务固定温度、seed 和最大输出长度，至少运行三次。MoE 与稠密模型的波动、速度和正确率都应一起记录。

速度要拆成两个指标

• Prompt processing：读取输入的速度，长文和 RAG 更关注它；
• Token generation：生成回答的速度，聊天体验更关注它。

只公布一个 tokens/s 容易混淆。如果 35B-A3B 生成快但处理长输入慢，它未必适合你的文档工作流。

首 token 延迟也要单列。用户通常对等待第一个字的时间比最终吞吐更敏感。

量化升级的判断规则

从 Q4_K_M 升到 Q5_K_M 前，先回答：

• 关键任务错误率是否明显下降；
• 结构化输出是否更稳定；
• 显存是否仍给 KV cache 留有余量；
• 生成速度下降是否可接受；
• 是否从全 GPU 变成部分 CPU offload。

如果升级量化导致大量 offload，质量小幅提升可能抵不过速度损失。

常见问题

35B-A3B 为什么比 27B 文件更大却可能更快

它需要存放更多总权重，但每个 token 只激活部分专家。实际速度取决于专家路由、内存带宽和后端优化，不能仅按激活参数推断。

24GB 显卡应该选哪个

先测 27B Q4/Q5，再测 35B-A3B Q4。固定上下文与任务，比较全 GPU 驻留、速度和正确率，不要直接把 MoE 当成稳赢。

为什么改成更低量化仍然 OOM

可能是上下文、并发、视觉投影或其他程序占用没有变化。查看启动日志和 nvidia-smi，不要只比较 GGUF 文件大小。

能否直接使用模型卡的最大上下文

理论支持不等于本机配置可承受。先从 4K/8K 开始，按真实需求增加并记录 KV cache。

OOM 后的恢复顺序

1. 关闭并发，保持 -np 1；
2. 把上下文从 8192 降到 4096 或 2048；
3. 换更小量化；
4. 降低 GPU offload，使用系统内存承接部分权重；
5. 停止其他占显存进程；
6. 重启服务，再从启动日志确认配置生效。

CPU offload 会让“能运行”变成“运行很慢”，所以必须同时记录速度。

27B 还是 35B-A3B

• 需要部署简单、后端兼容稳定：优先比较 27B；
• 关注 MoE 的推理效率：在同一硬件上实测 35B-A3B；
• 只有 12GB 显存：优先考虑更小模型，不要为了型号强行大量 offload；
• 做多模态：先核对官方模型卡与后端的视觉支持，再计入 mmproj 开销。

Qwen 模型卡与后端资料

• Qwen3.6-27B 官方模型卡
• Qwen3.6-35B-A3B 官方模型卡
• llama.cpp 官方仓库