Qwen 3.6 27B：本地 LLM 開發的最佳切入點

Qwen 3.6 27B 為本地部署帶來前沿級智慧

Qwen 3.6 27B 是一個密集模型，為本地開發帶來了在通用智慧上的顯著飛躍，常在程式編寫與複雜推理任務中超出其規模。雖然有 Mixture-of-Experts（MoE）變體（Qwen 3.6 35B A3B）可提供更快的推理速度，但 27B 密集模型普遍被視為在高品質輸出方面更強大且更可靠的選擇。

程式編寫與創意任務的表現

在實際測試中，Qwen 3.6 27B 展現出強大的零樣本能力。它能從單一提示成功產生複雜專案——例如使用 pnpm 的六角形掃雷——而 MoE 變體有時會忽略結構指令（例如建立套件），改為產出較簡單的單檔 HTML。它同時能處理受限寫作與複雜主題合成（例如結合量子物理與舞蹈），其深思熟慮與推理程度以往僅限於如 GPT-4.5 等昂貴的前沿模型。

使用 llama.cpp 進行本地部署

在本地執行 Qwen 3.6 27B 時，使用 llama.cpp 效率最高，因為它支援廣泛的裝置相容性，且避免了額外封裝層的開銷。

建議配置：

  • 量化： 建議使用 8 位元 (Q8_0) 量化，以節省記憶體且品質損失可忽略不計。
  • 多標記預測 (MTP)： 使用 MTP 可顯著提升每秒標記數 (TPS)，在某些配置下幾乎翻倍速度。
  • 範例指令：
    llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 --spec-type draft-mtp -ngl 999 -fa on -c 65536 --jinja --port 8080

硬體基準測試與資源需求

執行 27B 參數模型需要相當的硬體資源，導致使用者體驗因可用 VRAM 與系統記憶體的不同而產生差異。

Apple Silicon 效能（MacBook Max M5 128GB）

  • llama.cpp + MTP： 約 32 tok/s
  • llama.cpp（標準）： 約 18 tok/s
  • MLX： 約 17 tok/s

NVIDIA 與其他硬體

  • RTX 5090： 使用 Q6_K 量化時，使用者報告在 123k 上下文下持續約 50 tok/s 的速度。
  • 雙 RTX 3090： 部分使用者在短提示下報告最高可達 140 tok/s，密集 27B 模型則約 40 tok/s。
  • AMD Radeon AI Pro 9700： 雙卡（64GB VRAM）使用 vLLM 搭配 FP8 與 MTP 可達約 50 TPS。
  • 預算替代方案： Intel Arc Pro B70（32GB RAM）被視為需要 VRAM 而不想支付 NVIDIA 高價的可行且較低成本的選擇。

比較分析：本地 vs. 雲端

智慧基準測試

根據 Artificial Analysis 的資料，Qwen 3.6 27B（得分 37）優於 Gemma 4 31B（29）與 Qwen 3.6 35B A3B（32），其表現更接近 2025 年中期的前沿模型。然而，使用者指出，對於龐大的現有程式碼庫，雲端模型如 Claude 3.5/4 Sonnet 在上下文處理與可靠性方面仍具顯著優勢。

經濟爭論

有關本地硬體成本與雲端 API 點數的爭議在社群中相當激烈：

「看到有人花上千美元購買 128GB 的 MBP 來執行客觀上遠不如 SOTA 的模型，我感到自己快要瘋了，且花費遠超過實際需求。」

相對地，支持本地模型的人認為隱私、免訂閱費用以及能在敏感資料上微調模型的能力足以證明投資的合理性。其他人則建議採用「混合」硬體方式，例如在另一個房間使用 Mac Mini M4 作為無頭伺服器，以避免筆記型電腦在高負載推理時產生的熱量與風扇噪音。

主要取捨與限制

  • 熱度節流： 高參數本地模型會產生劇烈熱量。使用者回報在持續的代理程式編寫任務中，MacBook Pro 會熱到無法觸摸。
  • 密集 vs. 稀疏： 相較於稀疏 MoE 模型（如 DeepSeek-V4-Flash），密集模型（如 Qwen 27B）在統一記憶體架構上通常較慢，因為後者啟動的參數較少，可提供更高的每秒標記數。
  • 上下文載入： 雖然模型支援大型上下文視窗，但在消費者硬體上初始提示處理（prefill）可能緩慢，導致在倉庫探索期間出現顯著的等待時間。
  • 工具呼叫： 雖然 Qwen 3.6 有能力，但部分使用者發現較小的模型（低於 9B）仍在可靠的工具呼叫與代理工作流程上掙扎。

Sources

相關