Qwen 3.6 27B 是「本地 AI coding 的甜蜜点」——一位开发者花了两个月得出的结论,值得所有想在笔记本上跑模型的人读一遍

发布日期:2026-06-29 · 分类:技巧与观点 · 标签:本地模型 / AI coding
来源:Quesma Blog — Qwen 3.6 27B is the sweet spot for local development
原文链接:https://quesma.com/blog/qwen-36-is-awesome

事件内容

6 月 29 日,Piotr Migdał(Quesma 创始人,波兰 AI 圈知名开发者)发了一篇长博客,主题是:「我之前对本地模型一直很失望,但 Qwen 3.6 是第一个让我觉得『这玩意儿真能本地用』的模型。」

他的核心结论:Qwen 3.6 27B(dense,密集模型)是当前本地开发的甜蜜点。 比它小的模型不够用,比它大的模型跑不动。

Qwen 3.6 一共有两个变体:

• Qwen 3.6 35B A3B —— MoE 模型,激活参数 3B,总参数 35B。更快,但代码质量略弱(它在某些任务里会忽略 prompt 里的细节指令,比如让他建一个 npm package,他给你塞进单个 index.html);
• Qwen 3.6 27B —— dense 模型。慢三分之一,但代码质量明显更高。

Migdał 的判断是:「我宁愿生成三分之一的代码量,但质量更高。」

实测性能(Apple Silicon M5 Max 128GB + llama.cpp):

32 tokens/s 在「前沿模型 API 的典型速度区间内」——也就是说,本地 27B 的速度体验和远程 GPT-5.5 是可比的。

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)

注意:DwarfStar4(DeepSeek V4 Flash 量化版)用的是 2-4 bit 激进量化,所以 40 分这个数字是「低位量化」下打出的——同一模型在 BF16 下会更高。

和同尺寸其他模型的对比: Migdał 引用了 Simon Willison 的「penguins on a bicycle」smoke test 和 Hacker News 上的整体社区反馈:Qwen 3.6 27B 「以小搏大」,社区共识倾向于 27B 明显优于 Gemma 4 31B 这个本地默认选项。

一个具体的代码测试: Migdał 朋友给了一个 prompt,要求建一个项目。Qwen 3.6 27B 跑了几分钟,直接生成了一个能跑、反应灵敏、默认值合理的应用。「按前沿模型的标准,这不算惊艳。但这是一个真正能干活的工作。从一个简短的 prompt 开始。」

怎么本地跑起来: 三步走。

1. 去 Hugging Face 拉一个量化版——他推荐 unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0(8-bit + 多 token 预测支持);
2. 用 llama.cpp 直接跑:llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 --spec-type draft-mtp -ngl 999 -fa on -c 65536 --port 8080;
3. 接 OpenCode 之类的 coding agent:在 ~/.config/opencode/opencode.jsonc 里加一个 provider,指向 http://127.0.0.1:8080/v1。

关键参数:-ngl 999 把所有层都丢 GPU,-fa on 开 flash attention,-c 65536 把上下文设到 64K(Qwen 3.6 27B 原生支持 256K)。

Migdał 顺手给了个伦理立场:「不要用 Ollama。」 他给了一个第三方理由(Ollama 走 SaaS 模式、许可证有问题),但更朴素的理由是:llama.cpp 直接、更快、更灵活。

深度剖析

为什么「本地能跑出前沿水平」这件事意义重大?

过去两年,本地模型一直被一个数学诅咒困住:「好用的模型」≈「GPU 跑不动的模型」。GPT-4 级别的模型需要 A100 80GB × 多卡,这是大多数开发者根本买不起的配置。

Qwen 3.6 27B 打破这个诅咒的路径很清晰:

• dense 27B 在 Q8 量化下约 27 GB,Apple Silicon M5 Max 128GB 能轻松放进去(Nvidia RTX 5090 32GB 通过更激进量化也能跑);
• 速度 32 tokens/s + MTP 加速,体验上和远程 API 没本质区别;
• 智能指数 37 分 ≈ GPT-5 / Claude Sonnet 4.5,这是「能干真活」的水平。

这意味着:从今天开始,「本地 AI coding」不再是「穷人替代方案」,而是「隐私敏感 + 离线 + 可微调的开发者默认选项」。

MoE vs dense 这个老话题,这次给出了明确的答案。

MoE 的卖点一直是「更多参数 + 更快推理」——但 Migdał 的实测显示:35B A3B 在某些任务里会忽略 prompt 细节,直接把任务塞进单个 index.html。

这是个具体场景下的反例,但它揭示了 MoE 训练数据路由的本质问题:路由机制可能让某些上下文信号被「跳过」。 在代码生成这种「对细节要求高」的任务上,dense 模型通常更可靠——因为所有参数都对每个 token 生效。

「27B dense > 35B MoE」这个结论可能会让很多「参数越多越好」的论调重新被审视。

「MTP 多 token 预测」是这次体验改善的关键。

Qwen 3.6 系列支持 MTP(Multi-Token Prediction)——模型在每个位置预测多个后续 token,再用一个小模型做 verification。这是个 2024 年 Meta 在 Llama 3 里就提过的概念,但 Qwen 3.6 把它做到了工程化可用。

实测数据显示:MTP 让 Qwen 3.6 27B 的速度从 18 tok/s 翻倍到 32 tok/s——这是一个「几乎免费」的加速,只多了 1 GB 显存。任何在 M1/M2/M3 Mac 上跑过本地模型的人都知道,「快一倍」是个改变体验量级的提升。

和昨天 LongCat Owl Alpha 的张力。

昨天的头条是「美团 LongCat Owl Alpha 在 OpenRouter 上 10T tokens,1.6T MoE,35T tokens 训练,50k 国产 ASIC」——一个超大 MoE 模型。

今天的头条之一是「Qwen 3.6 27B 在笔记本上能跑到 GPT-5 水平」——一个本地小 dense 模型。

这两条消息放在一起,可能代表未来 12 个月的分化方向:

• 「远程 + 超大模型」继续向多模态、多任务、agentic 推进,代表前沿能力;
• **「本地 + dense 模型」**成为开发者工具、隐私敏感场景、可微调需求的默认选项。

两者不是替代关系,是分工。

值得关注的原因

1. 本地 AI coding 从「能跑」走向「能干活」。2024 年的「本地 7B 能跑」是 toy;2026 年的「本地 27B 干到 GPT-5 水平」是 production。
2. 「MTP + flash attention + 8-bit 量化」这套组合成为本地模型的标准配方。任何新发布的开源模型如果不支持 MTP,在本地体验上就输了一半。
3. dense 27B 可能成为新的「最佳尺寸」。这个尺寸在 Apple Silicon 和消费级 Nvidia 卡上都能跑,在 quality/speed/cost 三者间达到了实际最优。
4. 个人开发者第一次拥有「不被供应商绑架」的能力。你可以 fine-tune、可以离线用、可以保留所有数据——这件事在 AI coding 隐私问题日益严重的今天格外有意义。
5. OpenCode + 本地模型 + MCP 的组合,让「不依赖任何云服务的 AI coding 工作流」成为现实。

风险与待观察

• Migdał 的体感评价「比 DeepSeek V4 Flash 略好或相当」是个人意见,长上下文项目上 DeepSeek V4 Flash 可能有 edge——他自己在文末承认了这点;
• 8-bit 量化和 BF16 之间还有约 1-2 分的智能指数差,有些任务可能敏感;
• llama.cpp 的 Apple Silicon 路径和 Nvidia 路径在某些算子上的性能差异不小,需要按硬件分别评估;
• 「不要用 Ollama」这条伦理立场涉及第三方争议,需要读者自行判断——但客观事实是 Ollama 确实在很多场景比 llama.cpp 慢 20-30%。

(写作时间:2026-06-30 17:45 北京时间)