Qwen 3.6 深度解析：27B 稠密模型 vs 35B MoE，誰才是本地部署的王者？

前言

前陣子看到一篇來自 Quesma 的文章，作者在他的 MacBook Max M5（128GB RAM）上跑了 Qwen 3.6 系列模型後，得出一個頗具爭議的結論：27B 稠密模型在本地開發中才是最佳選擇，而不是 35B MoE 版本。

這個說法在 Reddit 的 LocalLLaMA 社群引發了熱烈討論——有人認同、有人反對。作為一個長期關注開源模型本地部署的人，我覺得這正是個好機會，把 Qwen 3.6 整個系列徹底盤點一遍，讓大家在實際部署前有個清晰的認知。

Qwen 3.6 家族全覽

Qwen 3.6 是阿里通義千問團隊在 2026 年 4 月推出的新一代模型家族，主要分為三大版本：

1. Qwen 3.6-Plus（旗艦閉源版）

• 透過阿里雲百煉 / DashScope API 提供
• 預設 100 萬 token 上下文視窗
• 採用混合線性注意力（Linear Attention）+ MoE 架構
• 估計活躍參數超過 4000 億
• 定價約 $0.29/100 萬輸入 token、$1.65/100 萬輸出 token，比 Claude Opus 4.6 便宜約 12 倍、GPT-5.4 便宜約 6 倍

2. Qwen 3.6-35B-A3B（開源 MoE 版）

• 2026 年 4 月 14 日發布，Apache 2.0 授權
• 350 億總參數，但僅活躍 30 億參數
• 預設 262K token 上下文（透過 YaRN 可擴展至 100 萬）
• API 名稱為 qwen3.6-flash

3. Qwen 3.6-27B（開源稠密版）

• 2026 年 4 月 21 日發布，Apache 2.0 授權
• 270 億參數的稠密模型
• 同樣預設 262K token 上下文（YaRN 擴展至 100 萬）
• 支援 FP8 量化版本

這三個版本各有定位：Plus 適合需要極長上下文和最高品質的雲端任務；35B-A3B 適合追求極致推理效率的 MoE 場景；27B 則專注於稠密模型的高品質輸出。

核心架構創新：Gated DeltaNet + Gated Attention

Qwen 3.6 系列最引人注目的技術突破，在於其混合架構設計。以 27B 稠密模型為例，它的子層結構遵循以下模式：

這裡有兩個關鍵組件：

Gated DeltaNet：提供 O(n) 線性複雜度，比傳統 O(n²) 的自注意力機制在速度和記憶體效率上更優異。這使得模型能夠處理更長的上下文而不致記憶體爆炸。

Gated Attention：每第四個子層使用標準注意力機制，確保長距離依賴的推理品質。KV head 配置為 4 個頭，在品質和記憶體之間取得平衡。

這種混合架構讓 Qwen 3.6 在保持高效推理的同時，不犧牲複雜任務的表現。對於 MoE 版本（35B-A3B），則採用 10 組重複的 Gated DeltaNet + Gated Attention 層，進一步放大了這種優勢。

benchmarks 大比拼

編程能力

幾個值得注意的點：

1. 27B 在 SWE-bench Verified 上以 77.2 分逼近 Claude 4.5 Opus 的 80.9 分——這意味著一個只有 270 億參數的開源稠密模型，在真實程式碼修復任務上幾乎追上了業界頂級閉源模型。

2. 27B 的 SWE-bench Pro 得分 53.5，超越了 Qwen 3.5 的 397B MoE 版本（50.9）。這是一個非常強的信號：在編程智能上，參數密度和訓練品質比單純堆參數更重要。

3. Terminal-Bench 2.0 上，27B 以 59.3 分與 Claude 4.5 Opus 並列，顯示其在終端操作和 agent 任務上的能力已經達到第一梯隊。

推理與通用能力

兩者在數學推理（AIME）和科學推理（GPQA）上都表現出色，27B 在 AIME 上甚至略勝一籌。

27B vs 35B-A3B：本地部署的現實考量

這才是重點。理論上 MoE 模型效率更高，但實際部署時，選擇取決於你的使用場景。

硬體需求對比

Qwen 3.6 的 GGUF 量化版本由 Unsloth 提供，品質經過實測驗證，在 22 項測試中有 21 項達到 SOTA 帕累托前沿。

速度對比（MacBook Max M5，128GB，llama.cpp + MTP）

35B-A3B 的速度確實是 27B 的三倍多，這是 MoE 架構的天然優勢——每次推理只激活 30 億參數。但問題來了：速度夠快就夠了嗎？

社群實測反饋

Reddit 上一位用戶的測試顯示，在編寫單個 HTML 檔案的任務中，35B-A3B 速度更快但輸出品質較差，而 27B 雖然慢但輸出更精確、更符合指令。另一位用戶表示：

“27B 在程式碼生成和指令遵循上真的很好用。35B 在通用 agent 任務上更強，但如果你要的是高品質的程式碼輸出，27B 更可靠。”

這其實呼應了 Quesma 文章的核心觀點：MoE 的「快」不等於「好」。在需要反覆校驗和精細調整的編程場景中，27B 稠密模型的輸出品質往往更勝一籌。

MTP：多-Token 預測加速

Qwen 3.6 支援 Multi-Token Prediction（MTP），這是一種預測解碼技術，類似 speculative decoding。透過預言後續 token，模型可以並行驗證多個 token，顯著提升推理速度。

實測數據顯示：

• 稠密模型（27B）可獲得約 1.4 倍加速
• MoE 模型（35B-A3B）可獲得約 1.15-1.2 倍加速

使用 llama.cpp 時，搭配 --spec-type draft-mtp --spec-draft-n-max 2 即可啟用。注意：草稿 token 數量不要超過 2，接受率會從 83% 急降到 50%，反而拖慢速度。

llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
  -ngl 999 -fa on -c 65536 --jinja --port 8080

Thinking Preservation：多輪對話的殺手鐧

Qwen 3.6 引入了一個名為 preserve_thinking 的新參數。傳統上，多輪對話中模型會重新進行 Chain-of-Thought 推理，造成 token 浪費。preserve_thinking 讓模型保留前一轮的推理鏈，直接基於既有推理繼續，不僅節省 token，還能保持推理的一致性。

在 API 呼叫中使用：

{
  "chat_template_kwargs": {
    "preserve_thinking": true
  }
}

在 llama.cpp 中：

--chat-template-kwargs '{"preserve_thinking":true}'

對於需要多輪協作的 agent 場景（比如程式碼重構、多檔案編輯），這個功能非常實用。

本地部署推薦方案

方案一：llama.cpp（推薦）

最直接、最開源的方式。適合需要精細控制的進階用戶。

llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
  -ngl 999 -fa on -c 65536 --jinja --port 8080

參數說明：

• -hf：從 Hugging Face 直接拉取 GGUF 檔案
• -ngl 999：將所有層推到 GPU（如果有的話）
• -fa on：啟用 Flash Attention
• -c 65536：上下文長度設為 64K（建議至少 128K 以確保推理能力）
• --jinja：使用 Jinja 模板引擎解析 chat template

方案二：Unsloth Studio（新手友好）

如果你想快速上手，Unsloth Studio 提供了一個開源的 Web UI：

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 127.0.0.1 -p 8888

一鍵下載 GGUF、自動調參、內建自我修復的工具呼叫功能，對新手非常友善。

方案三：vLLM / SGLang（生產環境）

如果需要高併發的 API 服務：

vllm serve Qwen/Qwen3.6-27B \
  --tensor-parallel-size 1 \
  --max-model-len 262144 \
  --trust-remote-code \
  --port 8000

方案四：整合到開發工具

Qwen 3.6 完全相容 OpenAI API 協議，可以直接接入各種開發工具：

Claude Code：

OpenCode / Codex：

{
  "provider": {
    "local": {
      "name": "llama.cpp (local)",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1",
        "apiKey": "local"
      },
      "models": {
        "qwen3.6-27b": { "name": "Qwen3.6-27B Q8 + MTP" }
      }
    }
  },
  "model": "local/qwen3.6-27b"
}

參數調優建議

根據 Unsloth 的實測，不同任務類型的最佳參數設定：

Thinking 模式（推理模式）：

• 通用任務：temperature=1.0, top_p=0.95, top_k=20
• 精確編程：temperature=0.6, top_p=0.95, top_k=20

Instruct 模式（非推理模式）：

• temperature=0.7, top_p=0.8, top_k=20, presence_penalty=1.5

⚠️ 注意事項：

• CUDA 13.2 會導致輸出亂碼，請使用 CUDA 13.3 或更低版本
• 如果輸出出現亂碼，嘗試增加上下文長度或使用 --cache-type-k bf16 --cache-type-v bf16
• 建議將上下文長度設為至少 128K，以確保模型的推理能力不被削弱

多模態能力

別忘了，Qwen 3.6 是原生多模態模型，內建視覺編碼器，支援：

• 文件分析：PDF、掃描檔的文字提取與理解
• UI 截圖分析：從截圖中識別元素和佈局
• 圖片理解：通用圖像描述和細節分析
• 影片輸入：支援影片幀的時序分析

對於需要視覺輔助的編程任務（比如從截圖生成前端程式碼），這個能力非常實用。

總結：該怎麼選？

回到最初的問題：27B 還是 35B-A3B？

選 27B 如果：

• 你追求最高品質的程式碼輸出
• 你的硬體記憶體有限（16-31GB 即可運行 Q8 量化）
• 你需要精確的指令遵循能力
• 你更看重輸出品質而非推理速度
• 你的場景需要反覆校驗和精細調整

選 35B-A3B 如果：

• 你需要極致的推理速度（105 tokens/s vs 32 tokens/s）
• 你的硬體記憶體足夠（至少 39GB 運行 Q8）
• 你的場景偏向通用 agent 任務而非純編程
• 你能接受稍低的輸出品質換取速度

選 Plus 如果：

• 你需要 100 萬 token 的超長上下文
• 你願意為最高品質付費
• 你的任務對品質要求極高且不在乎延遲

對我來說，27B 是目前本地部署的甜蜜點——它不需要專業繪圖卡、不挑硬體、輸出品質可靠，而且完全開源。在 AI 模型正在從「閉源巨獸」走向「人人可用」的過渡期，Qwen 3.6-27B 確實是一個值得關注的里程碑。

參考資源

• Qwen 官方部落格
• Qwen 3.6-27B Hugging Face
• Qwen 3.6-35B-A3B Hugging Face
• Unsloth Qwen 3.6 部署指南
• Qwen Studio
• llama.cpp 官方文件