Qwen3.6-35B-A3B 本地部署：GGUF、llama.cpp、顯存與 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 型別。 量化怎麼選

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 和執行時開銷仍然決定機器能否穩定執行。 參考資料

• Qwen3.6-35B-A3B 官方模型
• Qwen3.6-35B-A3B 官方釋出說明
• llama.cpp