进阶 11 分钟Qwen

Qwen3.6 35B-A3B 本地部署：测试与需求分析 VRAM

Qwen3.6 35B-A3B 是阿里巴巴推出的混合专家模型（MoE）：总参数量为 350 亿，但每个 token 仅激活 30 亿参数。理论上，它有望兼具 30B 以上模型的质量和 3B 模型的速度。实际使用时，容易踩坑的却是显存。本指南按量化方式测量本地运行 qwen3.6 的实际需求，以及常见显卡每秒能生成多少 token。

作者： Mohamed Meguedmi·更新于 2026-06-03·已在 Windows、macOS 和 Linux 上测试

#为何在本地部署 Qwen3.6 35B-A3B

有三个具体原因值得尝试这个模型，而不是传统的 32B 稠密模型。首先是速度：每个 token 的计算只涉及 3B 个活跃参数，因此在显存相同的情况下，推理速度比 Qwen 32B 稠密模型快得多。其次是质量：在公开基准测试中，35B-A3B 在推理、编程和法语方面的表现可与 14B–24B 稠密模型相媲美。

最后，它是少数能在适用于生产环境的宽松许可证下提供这种平衡的模型之一。如果您正在寻找一个准确、响应迅速、又能装进 24 GB 显存显卡的通用助手，Qwen3.6 35B-A3B 是目前最有力的候选之一。

i
名称含义解析
35B = 总计350亿个参数。A3B = 每个token有30亿个「激活」参数。MoE路由器在每次前向传播时，从约64个专家中动态选择少数几个，从而降低计算成本，但不会降低内存成本。

#一分钟了解 MoE 架构

本地 AI 套件

只需 1 小时，即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档，无需云端。

  • 在线空间，终身可用
  • PDF + 文件
  • 30 天内退款
本地 AI 套件 →或 所有套件终身使用权 — 49 € →

在密集模型中，每个标记会经过所有层和所有神经元。在Mixture of Experts（MoE）架构中，部分前馈层被独立的专家模块替代，一个小型的‘路由’网络会为每个标记决定激活哪些专家（通常为2到8个），其余专家则处于休眠状态。

每个 token 的计算量
与激活的参数数量（3B）成正比。因此生成速度很快。
显存（VRAM）
与总参数量（35B）成正比。所有专家都必须加载，因为无法预先知道会调用哪一个。
质量
介于 3B 稠密模型和 35B 稠密模型之间。在通用任务中，实际表现接近 14B–24B 稠密模型。
批处理敏感性
每次只处理一个提示时，MoE 表现出色。批次非常大时，计算优势会减弱，因为最终会激活所有专家。
→
为什么适合自托管
在 RTX 4090 24 GB 显存的设备上，一个 Qwen 32B 稠密模型在 Q4 量化下通常只能达到 25–35 个 token/s。在相同显存下，Qwen3.6 35B-A3B 模型的运行速度约为 70–90 个 token/s，大多数非专业任务的响应质量相当。

#硬件要求

最小 VRAM 要求
16 GB 可用于测试（Q3，需接受将部分计算卸载到 CPU）。20–24 GB 可在 Q4 下流畅使用。
较为充裕的显存
32 GB（RTX 5090）或 48 GB（Apple 统一内存），适用于 Q5/Q6 量化和长上下文。
系统 RAM
如果可以接受将部分计算卸载到 CPU，系统内存至少需要 32 GB。如果仅加载到 RAM 中，则需要 64 GB。
磁盘
为 Q4_K_M 预留 22 GB 磁盘空间，为 FP16 预留 70 GB。强烈建议使用 NVMe SSD。
操作系统 / 运行时
Linux、macOS（Apple Silicon）、Windows 11。Ollama ≥ 0.5.x 或较新的 llama.cpp（2026 年 3 月之后的构建版本）。
!
MoE ≠ 小模型
不要被“3B活跃参数”误导：仍需将整个模型加载到VRAM中。即使推理“只计算3B参数”，RTX 4060 8GB也不够。所有专家都必须能够被即时访问。

#各量化级别的实际显存占用

以下是在 llama.cpp 中使用 8k token 的上下文测得的内存占用（模型 + KV 缓存 + 额外开销）。这些数值包含运行时的内存占用，而不仅仅是 GGUF 文件在磁盘上的大小。

Q2_K（≈13 GB）
可在 RTX 4070 / 4060 Ti 16 GB 上运行。质量损失明显，尤其是在编程和多步推理方面。仅适合应急使用。
Q3_K_M (≈ 17 GB)
在上下文较短的情况下，可装入 RX 7900 GRE / 4080 / 5070 Ti 的 16 GB 显存。用于一般法语聊天时，效果仍然尚可。
Q4_K_M（≈22GB）
最佳平衡点。在 RTX 3090 / 4090 / 7900 XTX（24 GB）和 RTX 5090（32 GB）上运行游刃有余。默认推荐。
Q5_K_M（≈26 GB）
需要 32 GB 显存（RTX 5090），或配备至少 36 GB 内存的 Mac M 系列机型。相比 Q4，质量提升不大，但代码任务除外。
Q6_K（≈ 30 GB）
仅适用于 RTX 5090、Mac Studio 或多 GPU 配置。用户看到的输出与 Q8 相比差异极小。
Q8_0 (≈ 37 GB)
Mac Studio M2/M3/M5 Ultra，或双 GPU（2×3090）配置。质量接近 FP16。
FP16（≈ 70 GB）
研究、微调、在生产环境中使用 vLLM。对大多数本地配置而言并不适用。
→
选择何种量化方式
对于 95% 的使用场景，Q4_K_M 是合适的默认选择：它能保留大部分质量，节省显存，并提高吞吐量。只有在明确观察到模型对您的提示词的表现有所退步时，才改用 Q5/Q6。

#使用Ollama进行安装

Ollama 仍然是最直接的途径。如果尚未安装，请安装它（请参见对应操作系统的安装指南）。一旦守护进程在 11434 端口启动，只需一条命令即可。

下载并启动
ollama run qwen3.6:35b-a3b-q4_K_M

下载大小约为21GB。首次输入提示词时，模型会加载到显存中；只要模型仍在内存中保持运行，后续启动几乎都能瞬间完成。

检查 GPU 分配情况
ollama ps

PROCESSOR列应显示100% GPU。若出现CPU/GPU混合使用情况，说明显存不足：请尝试更激进的量化方式（Q3_K_M），降低num_ctx，或接受吞吐量的损失。

i
扩展上下文
默认情况下，Ollama 将上下文限制为 2048 个 token。对于文档摘要或长对话，请创建一个 Modelfile，将 num_ctx 强制设置为 8192 或 16384——上下文长度每翻一倍，都会额外消耗数百 MB 的 VRAM。
最简 Modelfile
# fichier : Modelfile.qwen36-long
FROM qwen3.6:35b-a3b-q4_K_M
PARAMETER num_ctx 16384
PARAMETER temperature 0.7

# build
# ollama create qwen36-long -f Modelfile.qwen36-long

#使用 llama.cpp 进行安装

对于希望精细控制专家部署位置、批处理或 KV 缓存的用户，llama.cpp 更为灵活。从 Hugging Face 下载一个 GGUF Q4_K_M 模型（由 Qwen 团队或 bartowski/unsloth 发布），然后启动兼容 OpenAI 的服务器。

llama.cpp 服务器
./llama-server \
  -m ./models/Qwen3.6-35B-A3B-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 16384 \
  -ngl 99 \
  --flash-attn \
  --threads 8
-ngl 99
将所有层放到 GPU 上运行。设为 0 表示仅使用 CPU，或设为较小的层数，让部分层在 GPU 上运行，其余层在 CPU 上运行。
-c 16384
上下文长度。每超过默认值 4k，KV 缓存额外占用约 0.5 GB。
--flash-attn
如果您使用的编译版本支持 Flash Attention（CUDA、Metal），就启用它。在长上下文下，内存节省效果明显。
--threads 8
主要在部分计算由 CPU 承担时有用。完全使用 GPU 时，影响很小。
→
MoE和专家卸载
llama.cpp 的近期构建版本支持 --override-tensor，可将部分专家放到系统内存中。在配备 12 GB 显存的 4070 上，这样就能容纳 Q4_K_M 量化版本，但会牺牲一部分吞吐量。如需深入了解，请查找“expert offload”相关文档。

#实测推理速度

测量采用 Q4_K_M 量化，上下文长度为 4 096，使用短提示词（约 200 个 token），生成 512 个 token，批大小为 1。数据包含提示词评估阶段和生成阶段。

RTX 5090 32GB
生成速度约为 110–125 个 token/秒。提示词评估阶段的速度超过 4000 个 token/秒。上下文长度不超过 32k 时，使用起来很舒适。
RTX 4090 24 GB
约 80–95 token/秒。Q4 模型配合 16k 上下文可装入显存，不会超出容量。
RTX 3090 24 GB
≈ 55–70 tok/s。二手购入时性价比出色，但显存带宽低于 4090。
Mac Studio M5 Max 64 GB
在Q4_K_M下约为60–75 tok/s，在Q8_0下约为45–55 tok/s。适合24/7静音服务器使用。
Radeon RX 7900 XTX 24 GB (ROCm)
约 45–60 token/秒。支持 Ollama，也可使用搭配 ROCm/Vulkan 的 llama.cpp。
RTX 4070 Ti Super 16 GB (Q3_K_M)
约 50–65 token/秒，上下文长度限制为 4k。在这一配置档位下，Qwen 14B 稠密模型通常仍是更合适的选择。
i
MoE 与长上下文
生成阶段的吞吐量仍然很高，但输入 16k 的上下文时，提示词评估阶段的耗时会迅速增加。这是正常的：在处理提示词的过程中，所有专家都会在某个时刻被调用。对于 RAG，请批量处理请求。

#有用的优化

  1. 01
    启用 Flash Attention
    在 Ollama 中，较新的 GPU 会自动启用此功能。在 llama.cpp 中，添加 --flash-attn。上下文长度从 8k 起，显存节省就很明显。
  2. 02
    量化KV缓存
    llama.cpp 支持 --cache-type-k q8_0 --cache-type-v q8_0。可节省缓存所占显存的约 30%，质量损失几乎为零。
  3. 03
    减少激活的专家数量
    部分变体支持--override-kv qwen3moe.expert_used_count=2（默认为4或8）。运行更快，但质量略有下降。
  4. 04
    将 num_ctx 限制在所需范围内
    16k 对大多数聊天场景来说已绰绰有余。只有在总结长文档时，才有必要使用 32k 或更长的上下文。
  5. 05
    交互式聊天建议使用batch=1
    MoE 在大批次场景下优势减弱：如果同时为多个用户提供服务，可以考虑选用 vLLM 而不是 Ollama。

#故障排除

在 RTX 4090 上加载时出现 OOM 错误
将 num_ctx 降至 4096，并检查是否有其他 GPU 进程正在运行（浏览器、游戏）。Q4_K_M 应该能装入显存，并留下 2 至 3 GB 的余量。
RTX 4090 上 5 个标记/秒的生成速度
模型有一部分被卸载到 CPU 上运行。ollama ps 会显示 CPU/GPU 混合运行。关闭所有应用，重启 Ollama，或改用 Q3_K_M。
法语回答逻辑混乱
请确保使用 Instruct 版本而非 Base 版本。MoE 路由对系统提示的表述非常敏感——请保持简洁直接。
首个token响应极慢（>10秒）
提示词评估阶段耗时较长：MoE 模型处理较大的上下文时，这是正常现象。请在请求之间复用提示词缓存（llama.cpp 的 --prompt-cache 选项）。
在 Ollama 上未找到模型
精确标签可能有所不同（qwen3.6 vs qwen3_6 vs qwen36）。在输入命令前，请先在 ollama.com/library 搜索确认。

#深入了解

现在 Qwen3.6 35B-A3B 已在本地运行，以下是一些优化部署的建议：

选择量化方案（Q4、Q5、Q8、FP16）
帮助您准确理解 MoE 模型在 Q3、Q4 和 Q5 量化下有何变化。
使用 Ollama 的 Open WebUI
一个类似 ChatGPT 的界面，提供历史记录和 RAG 功能，以您本地运行的 Qwen3.6 为底层模型。
为本地 AI 选择 GPU
如果您在二手 3090、4090 或 5090 之间犹豫，不知该选哪款来运行此类 MoE 30B+ 模型。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。