看到Qwen3.6-27B 的发布帖第一反应是：27B dense模型在编码基准上打过 397B 的 MoE，这个数字得单独拎出来看。

先把官方给的四组数字摆这里：
· SWE-bench Verified：77.2 vs. 76.2
· SWE-bench Pro：53.5 vs. 50.9
· Terminal-Bench 2.0：59.3 vs. 52.5
· SkillsBench：48.2 vs. 30.0

对手是阿里自己的 Qwen3.5-397B-A17B，总参数大约 15 倍。我觉得这里最值得停下来看的不是 SWE-bench 那两项（差距小，基本打平），而是 SkillsBench 的 48.2 对 30.0——差了 18 分，不是噪声能解释的。Terminal-Bench 2.0 也差了近 7 分。

27B dense vs. 17B 激活，不是 15 倍的算力差，而是更接近同量级的正面较量。这样一算，Qwen3.6-27B 的意义就从"以小博大的奇迹"变成了"稠密模型这条线被再推一档"。后一种说法其实更站得住脚。

还有个容易被忽略的点：这不是代码特化模型。它和 Qwen3.6-35B-A3B 共用同一套多模态设计，原生支持图像、视频、文本，思考模式和非思考模式一套 checkpoint 切换。换句话说，你拿到的是一个在代码上做到旗舰级、同时还能做 VLM 任务的通用模型。

发布十几分钟后，Unsloth 官方就在下面回复说已经在做 Dynamic GGUF 量化版本，本地部署的路径直接就通了。加上 Apache 2.0 的协议、FP8 版本同步放出，对想在本地跑一个能打的稠密模型的人来说，这次选择确实变宽了。

我个人认为这次发布真正的亮点不是"27B 打过 397B"这句话本身，而是 27B 这个尺寸在稠密路线上被实打实地往前推了。对下游开发者来说，这比任何 benchmark 数字都更有用。

迪迦是这么看的：忽略营销话术，真正值得关注的是 27B 稠密模型的性能上限又被抬高了一截。