Qwen 3.6 27B 是本地开发的理想之选
Piotr Migdał 2026年6月29日
过去我对本地模型一直很失望。但当我试了 Qwen 3.6 之后，我大为惊叹。对我来说，这是第一个真正意义上可以当作通用智能来用的本地模型。
它有两个版本：一个混合专家模型 Qwen 3.6 35B A3B，以及一个稠密型模型 Qwen 3.6 27B——速度较慢，但能力更强。我推荐的就是这个版本！
让我分享我的使用感受，并告诉你你也可以运行它。
它真的很烫，字面意义上的。当我的膝盖开始融化时，我抓起一个手机外接的热成像相机拍了张照片。
Qwen 3.6 理所当然地在 Hacker News 上获得了大量报道。关于 Qwen 3.6 27B 最常听到的评价是它表现超出自身规模——详见 Will it Mythos?。我认为这种评价实至名归。它会让你的电脑发烫，但完全值得！
初试身手
Simon Willison 用“企鹅骑自行车”作为烟雾测试（参见 Qwen 3.6 35B A3B 以及 Qwen 3.6 27B）。我通常使用有约束的写作来测试。
一年前，这类事情还是最前沿的，需要用到独一无二且极其昂贵的 GPT-4.5，参见翻译 Quantum Flytrap 的体验。
我还让它写一首关于 Zouk 舞蹈和量子物理的八行诗，详见对话记录。它的思考过程在量子术语和押韵方面都很有道理。
接着我在 OpenCode 中让它用 pnpm 创建一个六边形扫雷游戏。它成功了：
一次就成功，仅凭一条提示词，生成了一个完整的 Node 包。混合专家模型 Qwen 3.6 35B A3B 速度更快……但忽略了我让它创建包的要求，而是直接做成了单个 index.html。
实际工作
当然，写关于量子力学的创意文章，或者又克隆一个扫雷游戏，通常不是日常工作。但 Qwen 3.6 27B 在处理常规任务方面也表现不错。
这是朋友 Maciej Cielecki 在 AI Tinkerers Warsaw 上使用的提示词。
它运行了几分钟，生成了这个：
按照当前前沿模型的标准来看，它并不出众。但它已经可以完成实际工作了。它成功了，具有响应性，默认设置也很棒——全部来自一条简短的提示词。
使用 llama.cpp 在本地运行 Qwen 3.6
运行本地模型比以往任何时候都更简单。几条命令行就能搞定。
我推荐使用 llama.cpp——一个直接、开源的工具，可以在各种设备上运行模型。你不需要 Ollama，坦白说——基于道德理由，我建议不要使用它。
首先，我们去 Hugging Face 获取合适的量化版本，即缩小尺寸的模型——流行的版本来自 unsloth 或 bartowski 等。默认模型通常使用 BF16 精度。常见的 8 位量化能节省一半空间，且几乎不影响质量。进一步降低量化时，模型会更小（可能更快），但会牺牲质量，请参阅这个针对 27B 的对比，以及另一个针对 35B A3B 的对比。
我们下载 unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0，这是一个支持多 token 预测（MTP）的 8 位量化版本。
llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
--spec-type draft-mtp -ngl 999 -fa on -c 65536 --jinja --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 开启 flash attention
-c 65536 上下文窗口设置为 64k token（这个可以调整，因为 Qwen 3.6 27B 原生上下文是 256k）
--jinja 启用工具调用支持
--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-cli 而不是 llama-server：
llama-cli -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
-ngl 999 -fa on -c 65536 --jinja
性能测试
它足够快吗？
我在我的 Macbook Max M5 128 GB 上运行了一些测试（源码在这里），分别测试了开启和关闭多 token 预测的情况，并与 35B A3B 模型以及量化版 DeepSeek V4 Flash 的 DwarfStar4 进行了对比。
token / 秒
内存
Qwen3.6-35B-A3B · 8 位
MLX
85 tok/s 85
37 GB 内存 37 GB
llama.cpp
93 tok/s 93
44 GB 内存 44 GB
llama.cpp + MTP
105 tok/s 105
45 GB 内存 45 GB
Qwen3.6-27B · 8 位
MLX
17 tok/s 17
28 GB 内存 28 GB
llama.cpp
18 tok/s 18
41 GB 内存 41 GB
llama.cpp + MTP
32 tok/s 32
42 GB RAM 42 GB
DeepSeek-V4-Flash · Q2–Q4
llama.cpp
33 tok/s 33
103 GB RAM 103 GB
每秒30个token并不差，完全在典型前沿模型API的范围内。虽然mlx-lm专门针对苹果Apple Silicon设备优化，并且AI智能体强烈推荐它，但llama.cpp实际上更快。它使用了95%的GPU，这意味着它在高效利用可用资源。
Macbook Max M5是一款性能猛兽（至少对于笔记本而言），但在其他设备上也能有不错的表现。对于消费级的Nvidia RTX显卡，一方面模型需要量化，另一方面，速度甚至更快。
我今天在我的5090上以Q6_K量化和Q4_0 KV量化设置了这个，在123k上下文下稳定获得了50 tokens/s，使用了约28/32GB的显存，通过LM Studio运行。——来自Hacker News的gfosco
虽然35B A3B快了三倍，但我更喜欢27B。我宁愿生成少三分之一的代码，但质量更高。
它们与之前的最先进模型相比如何？
人工检查很好，但基准测试有助于让直觉有据可依。以下是来自Artificial Analysis的分数，与前沿模型对比：
Gemma 4 31B
29
≈ 2024年底
o1 / Claude 3.5 Sonnet
Qwen3.6-35B-A3B
32
≈ 2025年初
o3 / Claude 4 Sonnet
Qwen3.6-27B
37
≈ 2025年中
GPT-5 / Claude Sonnet 4.5
DeepSeek-V4-Flash
40
≈ 2025年底
GPT-5.2 / Claude Opus 4.5
这些笔记里还有几个基准测试，但精神是相似的。这里加入了Gemma 4 31B，因为很多人将其作为本地编程的默认选择。但无论是基准测试还是网络上的普遍评价，都大幅倾向于Qwen 3.6 27B。
这里有一个说明——8-bit量化可能对结果影响不大，但DwarfStar4对DeepSeek V4 Flash使用了更激进的量化（2-4位）。这肯定比完整模型差。我个人印象是，在这些量化范围内，Qwen 3.6 27B与DwarfStar4一样好（或者可能稍好一点）。不过，如果对于更长上下文的项目，DS4有优势，我也不会感到惊讶。
接下来是什么
我认为我们正在进入一个迷人的时代，运行自己的模型变得可行。
这一趋势将进一步受到闭源前沿模型现状的推动。Claude Fable 5 已经下架。其他前沿模型目前以大幅补贴的方式运营——每月支付 100 美元，就能获得价值数千美元的模型 token。趁还在补贴期，赶紧用吧！
本地部署的模型可以根据我们的需求进行微调，并且不会被下架。企业可以将其用于专有和敏感数据。个人也可以在离线项目中使用，或者当不愿意与美国或中国分享自己最深的秘密或医疗数据时使用。
随着前沿级开源权重模型 GLM 5.2 的发布，一个新时代到来了。虽然 Qwen 3.6 是铺路石，但即使是前沿级别的 GLM 5.2 也可以在本地运行。它无法在你的 Macbook 或单张 RTX 5090 上运行，但仍可用公司预算来管理。
此外，我坚信未来会出现比当前最先进模型更智能的模型，同时能够在本地设备甚至智能手机上运行。目前的模型将原始智能和事实知识放在同一组参数中。未来的模型很可能会将两者分离，将大量知识转移到工具调用上。
敬请关注后续文章和发布
或通过 RSS 订阅
Antigravity 感觉沉重，Claude Skills 则轻巧
比较 Google Antigravity 和 Claude Code 在 AI 辅助工作流中的表现，以及为什么自定义 Claude Skills 可能是更好的方案。
Piotr Migdał 2025 年 12 月 16 日
阅读更多
HN
CompileBench：AI 能编译 22 年前的代码吗？
我们测试了 19 个 LLM 处理实际软件工程任务的能力，例如编译旧代码和交叉编译。来看看 Anthropic、OpenAI 和 Google 的模型在我们的新基准 CompileBench 中表现如何。
Piotr Grabowski 2025 年 9 月 17 日
阅读更多
沙箱化 AI 生成代码：为何我们从 WebR 迁移到 AWS Lambda
为什么我们将 AI 图表生成器从浏览器内的 WebR（WASM）迁移到 AWS Lambda。这是一个关于运行 AI 生成的 R 和 ggplot2 代码在实际环境中权衡取舍的案例研究。
Piotr Migdał & Przemysław Hejman 2025 年 8 月 7 日
阅读更多
Antigravity 感觉沉重，Claude Skills 则轻巧
比较 Google Antigravity 和 Claude Code 在 AI 辅助工作流中的表现，以及为什么自定义 Claude Skills 可能是更好的方案。
Piotr Migdał 2025 年 12 月 16 日
阅读全文
HN
CompileBench：AI能编译22年前的代码吗？
我们测试了19个大语言模型处理真实软件工程任务的能力，例如编译老旧代码和交叉编译。看看Anthropic、OpenAI和Google的模型在我们的新基准测试——CompileBench——中表现如何。
Piotr Grabowski 2025年9月17日
阅读全文
AI生成代码的沙箱化：为何我们从WebR迁移到AWS Lambda
为何我们将AI图表生成器从浏览器内的WebR（WASM）迁移到AWS Lambda。这是一份关于运行AI生成的R语言和ggplot2代码所面临现实权衡的案例研究。
Piotr Migdał & Przemysław Hejman 2025年8月7日
阅读全文
