AI工具

Qwen3.6-35B-A3B 本地部署：GGUF、llama.cpp、显存与 API 验证

以官方 Qwen3.6-35B-A3B 权重为基准，说明 GGUF 量化选择、llama.cpp 启动参数、显存判断、视觉投影文件和 OpenAI 兼容 API 的验证步骤。

Qwen3.6-35B-A3B 是 Qwen 官方开放权重的多模态 MoE 模型。名称中的 35B 是总参数规模，A3B 表示每个 token 约激活 3B 参数。它的计算量可以低于同规模稠密模型，但加载时仍要容纳全部专家权重，不能把它当成 3B 小模型估算内存。

本文只讨论官方基础模型及其 GGUF 转换。第三方标注为 Uncensored、Aggressive 或“越狱版”的权重不属于 Qwen 官方发布，训练数据、对齐修改和能力声明需要由发布者单独证明，因此不把它们作为部署基准。

部署前先确认三件事

模型来源

官方模型 ID 是：

1

Qwen/Qwen3.6-35B-A3B

下载 GGUF 时还要核对转换仓库是否清楚注明：

  • 基础模型 commit；
  • llama.cpp 转换版本；
  • 量化方法和分片清单；
  • 是否提供与模型匹配的 mmproj；
  • 文件校验值或 Hugging Face LFS 元数据。

只有仓库名字包含 Qwen3.6，不足以证明它与官方权重一致。

可用内存

GGUF 文件大小接近权重加载的下限，不等于最终显存占用。实际运行还要给 KV cache、计算缓冲区、视觉投影和运行时留空间。

对单张 24GB 显卡，Q4 量化通常是更合理的起点；16GB 或 12GB 显存往往需要更低量化、CPU/RAM 分层加载或更短上下文。这里是工程估算，不是本站在每一种显卡上的实测结论。

推理后端

先记录版本，避免出现“同一个命令在不同版本行为不一致”却无法定位：

1
2

.\llama-server.exe --version
nvidia-smi

需要保存的基线包括 llama.cpp commit、GPU 型号与驱动、系统内存、GGUF 文件名、上下文长度和 KV cache 类型。

量化怎么选

目标 可先尝试 主要代价
先验证能否加载 IQ2 / IQ3 输出质量和长任务稳定性下降
质量与容量折中 Q4_K_M 或同级动态量化 需要更多显存或部分 CPU offload
更重视质量 Q5 / Q6 文件、显存和加载时间继续增加
对照精度 Q8 / FP8 / BF16 通常超出普通单卡的舒适范围

A3B 主要降低每个 token 的计算负担，不会把 35B 总权重压缩成 3B。选择量化时应以文件总大小和运行时报告为准。

Windows 上启动 llama-server

先从文本模式、短上下文和仅本机监听开始。PowerShell 的续行符是反引号，不是 CMD 的 ^：

1
2
3
4
5
6
7
8

.\llama-server.exe `
  -m "D:\models\Qwen3.6-35B-A3B-Q4_K_M.gguf" `
  --host 127.0.0.1 `
  --port 8080 `
  -c 8192 `
  -n 2048 `
  -ngl 999 `
  --jinja

参数作用：

  • -m：主模型 GGUF；分片模型应指向第一片。
  • -c 8192：先用 8K 上下文验证，避免一开始把 KV cache 拉到 128K。
  • -ngl 999：请求尽可能多地放入 GPU；最终是否全量进入 GPU 要看日志。
  • --jinja：使用模型聊天模板，避免直接拼接消息。
  • --host 127.0.0.1：只接受本机访问，避免未经认证的服务暴露到网络。

如果启动失败，先把 -ngl 调低，确认是否为显存不足；如果仍失败，再检查模型文件、后端和驱动，而不是继续降低量化后盲试。

从启动日志判断是否成功

保留启动终端输出，并检查三类信息：

  1. 模型元数据和架构是否识别为 Qwen3.6 MoE；
  2. 有多少层或张量进入 GPU；
  3. KV cache 与计算缓冲区占用是否在预期内。

如果进程直接退出并出现内存分配失败，优先降低 -c 或 GPU offload。只有在小上下文也无法加载时，才说明权重本身已经超过当前组合的容量。

验证本地 API

服务启动后，先验证健康状态：

1

Invoke-RestMethod http://127.0.0.1:8080/health

再查看模型端点：

1
2

Invoke-RestMethod http://127.0.0.1:8080/v1/models |
  ConvertTo-Json -Depth 6

最后发出最小聊天请求：

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

$body = @{
  model = "Qwen3.6-35B-A3B"
  messages = @(
    @{ role = "user"; content = "只回复 READY" }
  )
  temperature = 0
  max_tokens = 16
} | ConvertTo-Json -Depth 6

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

验收标准不是必须逐字返回 READY，而是 HTTP 请求成功、返回结构中存在 assistant 消息、终端没有模板或解析错误。

加载视觉投影文件

确认文本请求正常后，再加入与同一模型匹配的 mmproj：

1
2
3
4
5
6
7
8

.\llama-server.exe `
  -m "D:\models\Qwen3.6-35B-A3B-Q4_K_M.gguf" `
  --mmproj "D:\models\mmproj-Qwen3.6-35B-A3B.gguf" `
  --host 127.0.0.1 `
  --port 8080 `
  -c 8192 `
  -ngl 999 `
  --jinja

主模型和 mmproj 不匹配时，常见结果是启动报维度错误、图片请求失败或模型完全忽略图像。视觉功能应单独验收，不要因为文本聊天正常就认定多模态已经生效。

显存和速度如何记录

推理期间另开终端，每秒观察一次：

1
2

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

至少记录两组数据：

  • 模型刚加载完成、尚未请求时的显存；
  • 固定提示和固定输出长度生成时的峰值显存与速度。

一条可比较的记录应写成：

1
2
3
4
5
6
7
8
9

GPU：具体型号与显存
后端：llama.cpp commit
模型：完整 GGUF 文件名
上下文：8192
KV cache：默认或具体量化
GPU offload：日志中的实际结果
提示词：固定测试文本
输出：固定上限
结果：加载显存、峰值显存、prompt tok/s、generation tok/s

没有这些条件，只写“24GB 能跑”或“速度很快”都无法复现。

常见失败与恢复

启动即 OOM

依次降低上下文、并发和 GPU offload；关闭其他占用 GPU 的程序。仍然失败时换更小量化，或者让更多权重进入系统内存。

输出重复、角色混乱

确认使用最新版 llama.cpp，保留 --jinja，并检查 GGUF 是否包含正确聊天模板。不要同时让客户端和服务端重复套模板。

接入客户端后 404

llama-server 提供的是 OpenAI 兼容的 Chat Completions 接口。客户端如果只支持 Responses API，不能仅修改 base_url；需要协议转换层。这个问题与模型是否加载成功无关。

退出和回滚

在服务终端按 Ctrl+C 停止进程。部署初期不要注册成开机服务；先保存一条能够稳定启动的基线命令，再逐项增加上下文、视觉和远程访问。

安全边界

  • 默认只监听 127.0.0.1。
  • 不把未认证的推理端口直接暴露到公网。
  • Agent 接入文件、Shell 或浏览器时使用最小权限和人工确认。
  • 第三方微调权重需要单独核对来源、许可证、数据和行为差异。
  • 本地运行只解决数据传输路径的一部分，不自动保证输出正确或系统安全。

结论

Qwen3.6-35B-A3B 的本地部署应从官方模型身份、短上下文文本服务和 API 验证开始，再逐步增加 GPU offload、视觉投影和 Agent 接入。MoE 可以减少计算量，但完整权重、KV cache 和运行时开销仍然决定机器能否稳定运行。

参考资料