Hacker News 今天被一篇 Qwen 3.6 27B 的评测轰到 993 分、644 条评论。标题叫 "Qwen 3.6 27B is the sweet spot for local development"，社区情绪一面倒："这是我用过的第一个真正能打的本机模型。"

过去两年，本地跑 LLM 一直有种"我尽力了"的勉强的感觉。7B 太傻，70B 跑不动，中间尺寸的要么 benchmark 虚高实际拉胯，要么中文和代码能力瘸腿。Qwen 3.6 27B 改变了这个局面。

架构上的实打实变化

通义千问团队在 Qwen 3.6 上做了一个值得认真对待的架构决策：引入 Gated DeltaNet 作为主干，只在 1/4 的层用标准注意力。

具体结构是 16 个 block，每个 block 的排列为 3×(Gated DeltaNet → FFN) + 1×(Gated Attention → FFN)。64 层总共 48 层 DeltaNet + 16 层注意力，hidden dim 5120。DeltaNet 部分用 48 head（V）和 16 head（QK），头维度 128；注意力部分用 24 head（Q）和 4 head（KV），头维度 256，RoPE 维度 64。

这不是小修小补。Gated DeltaNet 是一种线性注意力变体——计算复杂度 O(n) 而非 O(n²)——意味着长序列推理时显存和计算量都更友好。Qwen 团队保留的那 16 层标准注意力做的是什么？我的猜测是：DeltaNet 负责高效吞吐和长程信息压缩，注意力层负责需要精确 token 级别对齐的任务（代码补全、精确引用），两套机制各司其职。

这个混合架构直接体现在两个关键指标上：原生 256K 上下文，可扩展到 101 万 token。27B 这个体量的模型能跑满 256K 不崩，DeltaNet 的线性复杂度功不可没。

另外值得一提的是，Qwen 3.6 训练时自带了 MTP（Multi-Token Prediction），推理时每步可以预测多个 token，在 llama.cpp 里配合 --mla 和 --mtp 参数能再挤出 15-20% 的吞吐。

编码能力：跟 Claude Opus 正面碰

直接看官方 benchmark 对比表（Qwen 3.6 27B vs. Qwen 3.5 27B vs. Claude 4.5 Opus）：

基准 Qwen3.5-27B Qwen3.6-27B Claude 4.5 Opus
SWE-bench Verified 75.0 77.2 80.9
SWE-bench Pro 51.2 53.5 57.1
Terminal-Bench 2.0 41.6 59.3 59.3
SkillsBench Avg5 27.2 48.2 45.3
Claw-Eval Pass³ 46.2 60.6 59.6
NL2Repo 27.3 36.2 43.2
LiveCodeBench v6 80.7 83.9 84.8
AIME 26 92.6 94.1 95.1

几个值得展开的点：

Terminal-Bench 打平 Opus。Terminal-Bench 测的是用命令行完成实际系统操作任务的能力——装包、配环境、排查问题。这个事情非常吃模型对工具使用的可靠性，而不仅仅是"聪明"。一个 27B 能跟 Claude 顶级模型持平，说明架构上的效率提升不是 benchmark 特化，是真实推理能力的提升。

SkillsBench 和 Claw-Eval Pass³ 反超 Opus。SkillsBench 是在 OpenCode agent 框架下测 78 个编码任务（5 次平均），Claw-Eval Pass³ 是测一次性通过率。两项都超过 Opus 意味着什么？在 agentic coding 场景下——给模型工具、让它迭代——Qwen 3.6 27B 的表现比账面纯推理分数看起来更强。这个现象和社区反馈吻合：Quesma 的 Piotr Migdał 用 OpenCode + Qwen 3.6 跑 hex minesweeper，一句 prompt 一次过，而 MoE 版的 35B A3B 反而出错。

SWE-bench Verified 从 75 跳到 77.2。看起来只涨了 2.2 分，但 SWE-bench 这个区间每 2 分都是实打实的——它测的是真实 GitHub issue 修复，不是多选题。从 Qwen 3.5 27B 到 3.6 27B，参数没涨，靠架构和训练改进硬拉上去，说明方向是对的。

还要注意 Qwen 3.6 的定位——官方 README 第一条就写 "Agentic Coding" 和 "Thinking Preservation"。加入了多轮推理中保留历史思维链的能力，对迭代开发场景（修 bug → 跑测试 → 修下一个 bug）特别有用。这是面向 agent 设计的，而不是面向 chatbot 设计。

本地跑起来：llama.cpp 一条龙

Quesma 的文章给了完整的命令行，我综合了一下社区最佳实践：

下载模型（推荐 unsloth 的 GGUF，带 MTP 支持）：

llama-cli --hf-repo unsloth/Qwen3.6-27B-MTP-GGUF \
  --hf-file Qwen3.6-27B-MTP-Q8_0.gguf \
  -o ~/models/Qwen3.6-27B-Q8_0.gguf

启动 server（核心参数）：

llama-server \
  -m ~/models/Qwen3.6-27B-Q8_0.gguf \
  -ngl 99 \
  -fa \
  -c 65536 \
  --mla \
  --mtp 2 \
  --port 8080

参数解释：

  • -ngl 99：所有层上 GPU，别让 CPU 拖慢
  • -fa：flash attention，省显存
  • -c 65536：上下文 64K（实际可以开到 131072 甚至更高，64K 是日常够用的平衡点）
  • --mla：multi-head latent attention，llama.cpp 的优化实现
  • --mtp 2：同时预测 2 个 token，提速

不想用命令行可以走 LM Studio，一键下载运行。

接入编程 agent（以 OpenCode 为例，~/.config/opencode/opencode.jsonc）：

{
  "provider": {
    "llama": {
      "name": "llama.cpp (local)",
      "@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"
          }
        }
      }
    }
  }
}

Hermes、Pi、Aider 同样的方式——只要是 OpenAI-compatible endpoint，直接指过去就行。

显存与速度：不同硬件的真实数据

以下是社区实测数据汇总：

Mac 平台（统一内存）：

配置 量化 速度 显存
M5 Max 128GB Q8_0 ~30 tok/s ~28GB
M5 Max 128GB Q4_K_M ~38 tok/s ~17GB
M3 Pro 36GB Q4_K_M ~22 tok/s ~17GB
M2 24GB IQ4_XS ~15 tok/s ~14GB

NVIDIA 平台：

配置 量化 速度 显存
RTX 5090 32GB Q6_K ~50 tok/s ~28GB
RTX 4090 24GB Q4_K_M ~45 tok/s ~17GB
RTX 3090 24GB Q4_K_M ~35 tok/s ~17GB
RTX 4060 Ti 16GB IQ4_XS ~25 tok/s ~14GB

关键结论：32GB 统一内存 / 24GB 显存就能跑 Q4 量化版，速度够日常 agent 使用（25-45 tok/s 对于编码场景完全够用，比大多数 API 的速率还高）。Q8 量化需要 28GB，RTX 5090 勉强够，Apple Silicon 128GB 则轻松。

M5 Max 跑 Q8_0 时 GPU 利用率到 95%——说明 llama.cpp 的 Metal 后端对这个架构利用得很充分，没有明显瓶颈。

MoE 版的 Qwen 3.6 35B A3B（35B 总量，3B 激活）速度约 90 tok/s，是 27B 的三倍，但 Quesma 的作者和 HN 上多位用户一致认为：27B 的代码质量明显更好。"宁要 1/3 速度的高质量输出，不要快但需要反复改的"，这个取舍在编码场景下是正确的。35B A3B 更适合需要高吞吐但单次质量要求不那么极端的场景——批量文档处理、翻译、摘要。

跟 DeepSeek V4 Flash 本地版的对比

社区最常拿来比较的是 DwarfStar4——DeepSeek V4 Flash 的 2-4 bit 极限量化版，也能在消费级设备跑。Piotr 的评测结论是：Qwen 3.6 27B Q8 和 DwarfStar4 在代码质量上相当，甚至 Qwen 略好。但 DeepSeek 在超长上下文（100K+）场景下可能有优势——毕竟是 MoE 架构出身，长程依赖处理有先天优势。

不过有一点 Qwen 3.6 赢得很稳：生态兼容性。llama.cpp 原生支持，GGUF 格式可以直接被几乎所有制程工具链消费：OpenCode、Aider、Continue、Cline、Cursor（通过 local endpoint）。DeepSeek 的量化和工具链支持目前还没到这个程度。

我的判断：本地模型正在跨过"能用"门槛

HN 上 644 条评论里反复出现一个观点："It punches above its weight"——越级打怪。这个感觉我完全理解。跑一个 27B 的模型，感受像是在用 GPT-4 级别的能力，而且没有速率限制，没有审查过滤（可以自己控制），数据不出本机。

去年我还在用 DeepSeek-Coder 6.7B 凑合写代码，质量像 Intern-level；今年初换了 Qwen 3.5 14B，能把简单任务办妥但复杂点就翻车。Qwen 3.6 27B 是第一个让我觉得"日常编码可以靠它"的本地模型。

但这不意味着可以扔掉 API。27B 跟 Claude Opus 的差距仍然存在——SWE-bench 差 3.7 分，NL2Repo 差 7 分。复杂的多文件重构、需要深层领域知识的问题，我还是会用 API。本地模型的价值不在"比云端强"，而在"大部分时候够用 + 数据不外传 + 零边际成本"。

最后说一个容易被忽视的点：Qwen 3.6 支持图片输入（pipeline tag 是 image-text-to-text），意味着你可以截图代码错误喂给它分析，或者把设计稿扔过去生成前端代码。这个能力在 27B 模型里极少见，之前基本是 70B+ 的专属。

开源社区今年很热闹。GLM 5.2 在前沿能力上更进一步（但 744B 参数跑本地不现实），Llama 4 还在路上，Mistral 的新模型暗示了更激进的架构。Qwen 3.6 27B 恰好卡在了一个关键位置上：个人开发者买得起的硬件跑得动，能力上足够替代大部分 API 调用。这个时间点，值得囤一块大显存显卡或者加内存了。