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 官方倉庫