Qwen 3.6 27B 是本地开发的理想选择

过去我对本地模型一直很失望。但后来我试了 Qwen3.6，我惊呆了。对我来说，这是第一个真正能作为通用智能说得通的本地模型。

它有两个变体，一个是混合专家模型 Qwen3.6 35B A3B，另一个是稠密模型 Qwen3.6 27B——更慢，但更强大。我推荐的是后者！

让我分享一下我的感受，并向你展示你也能运行它。

Thermal camera image — 它很烫，字面意义上的烫。当我的膝盖开始融化时，我抓起一个连接手机的热成像相机拍了一张照片。

Qwen3.6 理所当然地在 Hacker News 上获得了大量报道。关于 Qwen3.6 27B 最常见的说法是它超出了自身量级的预期——参见 Will it Mythos?。我认为这个评价当之无愧。它会让你的电脑发烫，但值得！

试水

Simon Willison 用“一只骑自行车的鹈鹕”作为冒烟测试（参见 Qwen3.6 35B A3B，然后是 Qwen3.6 27B）。我通常用受限写作。

Chat about quantum mechanics with Qwen3.6 — 一年前，这类东西还是最前沿的技术，需要一个独一无二且极其昂贵的 GPT-4.5，参见 vibe translating Quantum Flytrap。

我还让它写了一首关于 Zouk 舞和量子物理的 8 行诗，见对话记录。它的思考过程很合理，无论是对量子术语的斟酌，还是押韵方面。

然后我在 OpenCode 中要求用 pnpm 创建一个六边形扫雷游戏。它成功了：

Hexagonal minesweeper with Qwen3.6 27B in OpenCode

它一次就成功了，仅凭一条提示词，还生成了规范的 Node 包。混合专家架构的 Qwen3.6 35B A3B 速度更快……但它忽略了我创建包的要求，而是用单个 index.html 完成了。

实际工作

当然，关于量子力学的创意写作，或者又一个扫雷游戏克隆，很少是日常工作。但 Qwen3.6 27B 在常规任务上也相当不错。

Maciej Cielecki's candle-shop prompt running in OpenCode — 由我的朋友 Maciej Cielecki 在 AI Tinkerers Warsaw 提供的提示词。

它运行了几分钟，然后创建了这个：

A landing page by Qwen3.6 27B — Qwen3.6 27B 制作的一个落地页——查看实时页面。

以当前前沿模型的标准来看，这并不出众。但它已经是一项实用的工作。它成功了，响应式布局，默认样式也不错——全都来自一条简短的提示词。

用 llama.cpp 在本地运行 Qwen3.6

运行本地模型比以往任何时候都更容易。几行 CLI 命令就能搞定。

我推荐 llama.cpp——一个直接、开源的工具，可以在各种设备上运行模型。你不需要 Ollama，而且坦率地说——出于伦理考量，我建议不要使用它。

首先，我们去 Hugging Face 获取合适的量化版本，也就是体积缩减后的模型——流行的有 unsloth 或 bartowski 等。默认模型通常以 BF16 精度提供。常见的 8-bit 量化能节省一半空间，而质量几乎无损。再往下走，模型会更小（也可能更快），但代价是质量下降，参见这个 27B 的对比以及另一个针对 35B A3B 的对比。

我们选用 unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0，这是一个支持多 token 预测（MTP）的 8-bit 量化版本。

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

它的作用：

-hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 从 Hugging Face 获取，后续运行会复用该文件
-m ~/models/Qwen3.6-27B-Q8_0.gguf 如果你已经有了，就用这个代替
draft-mtp 我们用一个快速模型来预测后续 token，从而加速
-ngl 999 用于将所有层放到 GPU 上
-fa on flash attention 已开启
-c 65536 上下文大小设为 64k tokens（这一项我们可以调整，因为 Qwen3.6 27B 的原生上下文是 256k）
--port 8080 最好固定端口，因为其他配置也会用到它

如果你打开 http://127.0.0.1:8080，就可以直接和它对话。

完全相同的服务器也可以用于 vibe coding。智能体的选择既取决于你的目标，也取决于主观偏好——全能型的选 OpenCode，极简主义的选 Pi，自我改进型的选 Hermes。

对于 OpenCode，只需将其添加到 ~/.config/opencode/opencode.jsonc 中即可：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama": {
      "name": "llama.cpp (local)",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1",
        "apiKey": "local"
      },
      "models": {
        "qwen3.6-27b": { "name": "Qwen3.6-27B Q8 +MTP" }
      }
    }
  },
  "model": "llama/qwen3.6-27b"
}

如果你只是想聊天，而且是终端的忠实粉丝，那么不要用 llama-server，改用 llama-cli：

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

测量性能

它够快吗？

我在我的 MacBook M5 Max 128 GB 上跑了几项测试（源码在 GitHub 上），分别在启用和不启用多 token 预测的情况下运行，并将两者与 35B A3B 模型以及一个量化版 DeepSeek V4 Flash DwarfStar4 进行了对比。

tokens / s

内存

Qwen3.6-35B-A3B

· 8-bit

MLX

85 tok/s

37 GB 内存

37 GB

llama.cpp

93 tok/s

44 GB 内存

44 GB

llama.cpp + MTP

105 tok/s

105

45 GB 内存

45 GB

Qwen3.6-27B

· 8-bit

MLX

17 tok/s

28 GB RAM

28 GB

llama.cpp

18 tok/s

41 GB RAM

41 GB

llama.cpp + MTP

32 tok/s

42 GB RAM

42 GB

DeepSeek-V4-Flash

· Q2–Q4

llama.cpp

33 tok/s

103 GB RAM

103 GB

每秒 30 tokens 不算差，完全落在典型前沿模型 API 的范围内。虽然 mlx-lm 正是针对 Apple 芯片设备打造的，AI 智能体也大力推荐它，但结果 llama.cpp 反而更快。它占用了 95% 的 GPU，这意味着它在高效利用可用资源。

MacBook M5 Max 是一头猛兽（至少对笔记本而言），但在其他设备上它也应该能有不错的表现。如你所见，两个 Qwen3.6 变体都能在 48 GB 的 Apple 芯片共享内存内运行。4-bit 量化不到 18 GB，应该能在 32 GB 的设备上运行。在消费级 NVIDIA RTX 显卡上，你需要激进地量化，但推理运行得甚至更快。

我今天在我的 5090 上以 Q6_K 量化、Q4_0 KV 配置好了这套方案，在 123k 上下文下稳定跑到 50 tokens/s，通过 LM Studio 使用了约 28/32gb 显存。 - Hacker News 上的 gfosco

虽然 35B A3B 快 3 倍，但我更喜欢 27B。我宁愿只生成三分之一的代码量，但质量更高。

它们与之前的最先进模型相比如何？

人工检查很好，但基准测试有助于为直觉提供依据。以下是 Artificial Analysis 的评分，将其与前沿模型进行对比：

Gemma 4 31B

≈ 2024 年末

o1 / Claude 3.5 Sonnet

Qwen3.6-35B-A3B

≈ 2025 年初

o3 / Claude 4 Sonnet

Qwen3.6-27B

≈ 2025 年中

GPT-5 / Claude Sonnet 4.5

DeepSeek-V4-Flash

≈ 2025 年末

GPT-5.2 / Claude Opus 4.5

还有几个基准测试在这些笔记里，但精神是类似的。这里补充了Gemma 4 31B，因为很多人把它当作本地编程的默认选择。但无论是基准测试还是网上的普遍看法，都大幅偏向 Qwen3.6 27B。

这里有一个需要注意的地方——Qwen3.6 的 8 位量化很可能对结果影响不大，但 DwarfStar4 对 DeepSeek V4 Flash 使用了激进得多的量化，只有 2-4 位。可以肯定它比完整模型要差。我个人的印象是，在这些量化版本中，Qwen3.6 27B 与 DwarfStar4 一样好（或者可能略好一点）。不过，如果是在更长上下文的项目中，DS4 有优势我也不会感到意外。

接下来会怎样

我认为我们正在进入一个迷人的时代，运行自己的模型变得可行了。

专有前沿模型的现状将进一步推动这一变化。Claude Fable 5 被下架了。其他前沿模型都在以巨额补贴运行，每月付 100 美元就能获得价值数千美元的 token。趁折扣还在，赶紧用吧！

本地运行的模型可以根据我们的需求进行微调，而且不会被夺走。企业可以将其用于专有和敏感数据。我们个人可以用它来做离线项目，或者在我们不愿意把最深的秘密或医疗数据分享给美国或中国的时候使用。

随着前沿级开放权重 GLM 5.2的发布，一个新时代到来了。Qwen3.6 是垫脚石，而如今连前沿的GLM 5.2 都能在本地运行。它跑不了你的 MacBook 或单块 RTX 5090。但即便如此，用公司的预算还是能应付的。

此外，我坚信我们将拥有比当前最先进水平更聪明的模型，同时还能在本地设备上运行，甚至可能在智能手机上运行。当前的模型将原始智能和事实性知识融合在同一组权重中。未来的模型很可能会将二者分离，把大量知识卸载到工具调用中。

在 Hacker News、LinkedIn 或 X 上参与讨论。

敬请期待后续文章和发布

或