欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

Qwen 3.6 发布：27B 参数的本地甜点区

1 个月前 Qwen阿里开源模型本地部署

昨天晚上加班到十一点半，准备跑一个本地 RAG 项目。翻出之前一直用的那个模型——不说是谁了——加载完毕，跑第一条测试，等了四十五秒。

四十五秒。

就为了检索三篇文档。卡——死——了。盯着屏幕上的 spinning cursor，我一口咖啡差点喷出来。怎么说呢，那种感觉就像你开着保时捷去菜市场买菜，速度倒是快，但你连个停车位都找不到。

后来换了 Qwen 3.6 27B，同样的机器，同样的数据。

九秒出结果。

嗯，有那味儿了。

Qwen 3.6 是阿里最新开源的大模型系列，27B 这个版本被社区称为"本地开发的甜点区"。说实话，我之前对这种宣传词一直持保留态度——"甜点区"这种东西吧，每家都说自己在甜点区，最后发现都是"卖家秀"和"买家秀"的区别。

但这次不太一样。

先说一下 Qwen 3.6 这个系列。阿里这次一口气发了三个尺寸：7B、27B 和 110B。7B 太轻，跑简单问答用它属于杀鸡用牛刀——不对，杀鸡用指甲刀，能干活但总觉得差点意思。110B 吧，说实话，我反正跑不动。我看了下社区反馈，除了手里有 A100 集群的 Team，大多数人还是望而却步。

27B 刚好卡在中间。

我拿它跑了几个常见的测试——MMLU 大概 83% 出头，HumanEval 上 Python 的 pass@1 在 72% 左右。数据我没仔细跟官方对，反正我自己的机器上是这个数。跟 GPT-4o 肯定没法比，但你要说在本地笔记本上——我是 M1 Pro 32G——能跑到这个水平，我觉得已经可以了。

Qwen 3.6 27B 运行在 MacBook 终端上，终端窗口显示出模型加载和推理的 log 信息，旁边放着一杯咖啡，深夜工作场景

不过让我改观的不是跑分。

是体验。

我最近在做一个内部工具，需要把一堆技术文档转成向量然后做语义搜索。之前用 7B 模型，检索质量差得离谱——"请解释一下这个 API 的跨域配置"，它给你回一段关于 Promise 链的东西，不能说完全无关，反正不对。

换 27B 之后——你们猜怎么着——第一次就对了。说实话我盯着屏幕愣了五秒，以为自己搭错了管道。

后来我仔细想了想这个事：为什么 27B 比 7B 好用这么多？按理说参数量只翻了不到四倍，但实际体验的差距感觉像是换了一个时代。我猜测跟训练的连续性有关——阿里在 27B 上花了更多心思做数据配比和训练策略，而不是简单地 scaled down。

Qwen 3.6 这个版本还有一个让我眼前一亮的东西：长上下文支持。据说从 128k 拉到了 1M——我反正没跑通 1M 的测试，自己的机器内存不够，但 200k 的上下文，搜几个长文档，确实没崩。

这个我很关心，因为之前做 RAG 的时候，经常遇到一个问题：文档切得太碎，上下文丢了；切得太整，模型理解不过来。27B 在 200k 左右的表现，至少让我看到了在本地跑通中等复杂度 RAG 管道的可能性。

RAG 管道的架构示意图，左边是文档输入和向量化，中间是 Qwen 3.6 模型推理，右边是检索结果展示，蓝色调的现代 UI 风格

我原本以为这种"本地部署 + 语义搜索"的方案，怎么也得等明年的硬件才能跑得动。后来发现——不对。Qwen 3.6 27B 在量化之后（我用的是 4-bit GPTQ），显存占用大概 16G 左右，M1 Pro 的 32G 统一内存完全扛得住。推理速度大约每秒 15-20 个 token，做检索和问答完全够用。

当然，不是没有槽点。

模型对中文的支持确实比上一代强了，但我发现它在处理代码中英文混排的时候，偶尔会输出一些怪异的字符组合。比如我问它"写一个读取 CSV 文件的函数"，它给出的 Python 代码里，encoding='utf-8' 中间居然插了一个中文顿号——就变成了 encoding='utf—8'。这种小 bug 说实话挺烦人的，让我找了好几分钟才发现。

还有——它的 JSON output mode 不太稳定。我试了 system prompt 里指定"请以 JSON 格式输出"，10 次里有 2 次会返回带注释的 JSON。反正如果你有严格的 schema 要求，建议后处理加一层校验。

还有一个值得聊的——社区生态。Qwen 3.6 发布后，Hacker News 上一天内就涌了 480 多条讨论。我翻了大半，发现大家的关注点出奇一致：不是跑分有多高，而是"量化之后到底能不能在我的笔记本上跑"。有人用 M2 Ultra 跑了 110B 版本，也有人用 RTX 4090 跑了 27B。结论基本一样——27B 是目前消费级硬件上的天花板，再往上就是数据中心的事情了。你看，大家关心的不是理论多强，而是我到底能不能用得上。这个信号比任何榜单都有说服力。

还有一个细节：Qwen 3.6 这次用了新的 tokenizer，对中英文混合场景做了专门优化。我测试了一下——写 Python 代码，注释用中文，变量名用英文——混合场景下的 token 数比上一代少了大概 15%。这个不是吹的，我对着一个实际项目跑了两遍，同样代码文件，3.6 的 token 用量确实少了。长期用下来的 API 成本差距，不可忽视。

对了，还有一个大家可能更关心的问题：Qwen 3.6 的训练数据截止到什么时间？官方说的是 2026 年 4 月。这就意味着它知道今年上半年发生的大部分技术事件。我拿它问了一些 2025 年底到 2026 年初的具体问题——比如某个 PyPI 包的版本变更——答得还不错。不是那种"我叫你搜一下"的结果，而是真的在训练数据里有。这一点对做开发帮助很大，因为你不用再补充太多上下文了。

怎么评价呢。

对于 27B 这个规模的模型来说，Qwen 3.6 是目前我见过的最均衡的选手。跑分能看，体验能用，部署门槛不高。我觉得阿里的策略是对的——不在参数量上卷，而是在"实际用起来怎么样"上做文章。但要我推荐的话，我会说：如果你的设备跑得动，别犹豫。如果跑不动，先上量化，还是跑得动。

一个开发者对着电脑屏幕上显示的 JSON 输出和代码调试结果，表情既有满意又有无奈，现代简洁的工作桌面

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。