Qwen3.8-27B 发布后，一个关于 Anthropic 的玩笑被当成新闻在 X 上传播。

“Anthropic CEO Dario Amodei 得知一个 27B 模型在 LiveCodeBench 上得分超过 Opus 4.6 Max，还能在一张 900 美元的二手显卡上离线运行后，紧急要求与立法者开会。”

发布者随后澄清：除了“紧急开会”，其他细节都是真的。

这个玩笑能以假乱真，一方面是因为 Anthropic 对中国开源模型的敌意；另一方面，Qwen3.8-27B 确实交出了一组足够醒目的成绩。

Qwen3.8-27B 是一个 27B 参数的原生多模态稠密模型，采用 Apache 2.0 协议开源，量化后可以部署在消费级 GPU、个人工作站甚至部分高配笔记本上。按照 Qwen 公布的评测结果，其整体表现超过 Qwen3.7-Plus，提升尤其集中在编程和 Agentic 任务。在 Agentic Coding（SWE-bench Pro、DeepSWE 1.1）、软件工程（QwenSWEBench）、长周期办公任务（CoWorkBench）、竞争性编程（LiveCodeBench v6）和指令遵循（IFBench） 等项目上，Qwen3.8-27B 的得分高于同一榜单中的 Claude Opus 4.6 Max。

它的多模态能力也延续了这一特点。Qwen3.8-27B 原生支持图像和视频理解，在计算机操作（OSWorld-Verified）、移动端操作（AndroidWorld）、多模态软件工程（SWE-MM）等项目上的得分高于 Claude Opus 4.6 Max；在应用创建、浏览器操作和视觉 Web 开发等任务上，也较 Qwen3.6-27B 有明显提升。在视觉数学、通用视觉推理、科学图表分析等通用多模态任务中，它同样保持了较高水平。

这些能力让它尤其适合前端开发、GUI Agent 等需要同时理解视觉界面、代码并与软件环境交互的场景。

长期测评本地模型、在 YouTube 拥有 7 万余名订阅者的 Bijan Bowen 就将 Qwen3.8-27B 称为本地大模型用户“最期待、最令人兴奋”的发布之一。他认为，Qwen 3.6-27B 等前代模型已经是同尺寸里能力很强、硬件覆盖范围也很广的本地模型，而 Qwen3.8-27B 又在此基础上进一步提高了能力上限。

在测试中，Bowen 使用 Q8 量化版本，在 RTX Pro 6000 上连续跑了浏览器 OS、3D CAD、FPS 游戏、C++ 游戏、多模态建模等任务。他认为，Qwen3.8-27B 在多数测试中的表现明显超出其参数规模，尤其在网页生成、3D 场景和游戏开发上表现突出。

社区很快用真金白银给出了支持。

Qwen3.8-27B 开源不到 12 小时便进入 Hugging Face 历史最受欢迎模型 TOP 4 以及 Trending 榜首。开源两天，下载便超过 100 万次，社区自发贡献约 500 个量化版本。正式发布之前，倒计时页面已经有上千名用户等待。

更能体现这种热度的是围绕模型迅速形成的工程生态。NVIDIA、AMD、平头哥、沐曦、联发科、摩尔线程等芯片厂商很快完成适配；vLLM、SGLang、Ollama、LM Studio 等推理和本地运行工具也第一时间跟进。

SGLang 开发者在发布当天就开始测试如何把模型跑得更快，通过 NVFP4 等优化，单张 RTX 5090 的 decode speed 已经可以超过 200 tokens/s。

美国 AI 芯片与推理服务公司  ⁠Cerebras 在模型发布后表示，将为 Qwen3.8-27B 提供专属部署，并计划将其加入 Shared Tier。

从个人电脑、工作站，到数据中心 GPU 和云端推理服务，Qwen3.8-27B 发布后的几天里，很快获得了不同层级的部署支持。

对开发者来说，模型开源只是起点。Qwen3.8-27B 发布后，社区的讨论很快从“能力怎么样”转向“怎样把它跑得更好”，去解决稠密模型无法回避的工程问题。稠密模型每生成一个 token 都需要调用完整模型，参数规模增加后，计算量和推理延迟也随之上升。相比每个 token 只激活部分参数的 MoE，Qwen3.8-27B 要在本地硬件上发挥能力，更依赖量化和推理侧优化。

因此，模型发布后，社区很快开始围绕量化精度、推理配置等方面展开测试，同时尝试利用 MTP 提高生成速度，并持续验证它在 Apple Silicon、消费级 GPU 等不同硬件上的部署效果。

Qwen 开放、开源的生态，促成了这种自发参与。此前，Qwen 已累计开源 460 余个模型，全球下载量超过 30 亿次，衍生模型超过 30 万个。在 Hugging Face 最新发布的《开源模型现状：2026 夏季观察》报告中也提到，2026 年前七个月，Qwen 仅在 Hugging Face 的下载量就达到 20.45 亿次，衍生模型超过 15 万个，平均每天新增约 200 个。

对一个开源模型而言，这种持续的使用、适配和二次开发，也证明了它的生命力和影响力。

拆解 Qwen3.8- 27B 

Qwen3.8-27B 是一个 64 层的原生多模态稠密模型，沿用了 Qwen3.5 建立的 Gated DeltaNet 与 Gated Attention 混合架构。模型以“三层 Gated DeltaNet + 一层 Gated Attention”为一个基本组合，重复 16 次：四分之三的网络层采用线性注意力路线的 Gated DeltaNet，四分之一使用完整的 Gated Attention。

根据新加坡发展银行的资深数据工程师 Mehul Gupta 分析，这套混合架构的一个重要价值，在于提高长上下文处理的效率。全注意力机制需要显式计算 token 之间的注意力关系，上下文越长，计算和 KV Cache 的压力越大。Gated DeltaNet 通过更紧凑的状态表示处理历史信息，降低长序列处理成本；Qwen 同时周期性保留完整注意力层，以维持对复杂 token 依赖关系的建模能力。Qwen3.8-27B 原生支持 262K 上下文，并可以通过 YaRN 扩展至 100 万 token。

尤其值得注意的设计是多 Token 预测（MTP，Multi-Token Prediction）。传统自回归模型生成文本时，一次前向计算通常预测一个 token，再把结果送回模型继续生成；Qwen3.8-27B 则训练了多步 MTP，为同时预测后续多个 token 提供了基础。

这对于 27B 稠密模型尤其重要。稠密模型生成每个 token 都需要完整模型参与计算，解码速度因此成为本地部署时非常现实的问题。利用 MTP 进行推测解码，可以一次提出多个候选 token，再由主模型批量验证，从而减少逐 token 串行生成带来的开销。Qwen3.8-27B 发布后，MTP 也很快成为社区提高生成速度的主要优化方向之一。

Qwen3.8-27B 还允许开发者控制模型思考时间。模型默认开启思考模式，可以通过 reasoning_effort 调节推理深度，也可以通过 enable_thinking 关闭思考；在多轮 Agent 任务中，preserve_thinking 还能控制是否保留此前的推理内容。

不过，稠密架构本身也可能带来效率代价。

以 27B Dense 和 30B-A3B MoE 为例，两者总参数量看起来接近，实际运行方式却完全不同。27B 稠密模型生成每个 token 时，全部 27B 参数都会参与计算；30B-A3B MoE 虽然拥有约 30B 总参数，每个 token 实际只激活约 3B 参数。

因此，MoE 可以通过较少的激活参数降低每 token 的计算量，并获得更高的生成吞吐；稠密模型没有专家路由，每次生成都需要完整模型参与计算。对于本地部署来说，两种架构对应的是不同的内存、算力和速度取舍。

在稠密架构具有自身局限性的情况下，如何通过工程化处理，逼出模型最佳性能？Qwen3.8-27B 发布之后，海外开发者开始用实践贡献答案。

寻找任务质量与推理成本的最佳平衡 

Qwen3.8-27B 支持 low、medium、xhigh 等不同推理强度。更长的思考可以帮助模型处理复杂任务，但对于一个 27B 稠密模型来说，也意味着更多生成 token 和更长的等待时间。模型开源后，社区很快开始寻找任务质量与推理成本之间的平衡。

前文提到的测评者 Bijan Bowen 使用 Q8 量化版本测试时，特意将模型设置为 xhigh thinking。测试显示，在生成一个 C++ 滑板游戏的过程中，模型多次准备开始写文件，又停下来继续思考。Bowen 观察到类似循环至少出现了 5—10 次。随后模型用了一个多小时持续编写、编译和修复程序，最终仍然卡在一个无法自行解决的 bug 上。

Hacker News 上的一名用户也记录了类似的情况。Qwen3.8-27B 是继 Gemma 4 之后，第二个通过其私人推理测试的可本地部署模型，但消耗的 token 大约是后者的 5 倍；即使开启 MTP，整个任务仍耗时 12 分 30 秒。

这些测试指向了一个更实际的问题：并非所有任务都需要最高的推理强度。对于简单任务，可以减少思考；遇到真正困难的编程和推理任务，再增加推理时计算量。如何根据任务难度分配计算预算，开始成为开发者优化 Qwen3.8-27B 使用体验的一部分。

Qwen3.8-27B 发布后，开发者开始检查 reasoning_effort 在不同推理框架中的传递方式，并修改 chat template、sampler 和 tool calling 配置。社区甚至出现了专门修订 Qwen3.5、3.6、3.8 Jinja template 的版本。

这类讨论背后有一个容易被忽略的问题：对于开源模型，权重并不等于最终体验。同一份模型权重经过不同 chat template、sampler 和 inference backend，可能产生不同的 reasoning 长度、生成速度和工具调用表现。模型发布之后，社区实际上还需要完成一轮“推理侧工程”。

其中，利用 MTP 给模型提速，成为社区最活跃的优化方向之一。

Qwen3.8-27B 发布几个小时后，开发者 Sudo Su 就建立了 qwen38-mtp 项目，测试如何利用模型自带的多 Token 预测头（MTP head）进行推测解码。在 A/B 测试中，同一张 RTX 3090、同一份模型，解码速度从 31.0 tokens/s 提高到 41.3 tokens/s；RTX 5090 Mobile 则从 36.7 tokens/s 提高到 50.9 tokens/s。

更多开发者随后加入测试。项目记录的结果显示，RTX 4090 从 47.7 tokens/s 提升至 76.3 tokens/s，RTX A6000 从 26.7 tokens/s 提升至 52.5 tokens/s，AMD RX 7900 XTX 也从 30.7 tokens/s 提升至 43.9 tokens/s。项目启动两天后，已经积累了 21 名贡献者和 27 组配置。

Qwen3.8-27B 发布时已经提供了 MTP 能力，但本地部署仍然存在大量工程工作。这部分工作正在由社区共同完成，这正是开源的魅力。

Apple Silicon 上也出现了类似尝试。

Qwen3.8-27B 发布后，开发者 Kydo 发起了一项针对该模型的性能优化挑战。他认为，Apple Silicon 的统一内存架构能够容纳总参数量较大的 MoE 模型；对于稠密模型，每生成一个 token 都需要访问完整模型权重，解码更容易受到内存带宽限制。因此，他把 Qwen3.8-27B 当作一个专门的优化对象，尝试寻找此前没有被充分挖掘的性能空间。

按照 Kydo 公布的结果，挑战开始不到 16 小时，参与者已经将 Qwen3.8-27B 的运行性能相对项目基线提高了 153%，达到默认 MTP 解码性能的约 2.5 倍。下一步，他们计划把同样的优化方式扩展到 CUDA 平台。

结语 

Qwen3.8-27B 已经能在编程、Agent、多模态和复杂推理任务上体现出相当强的能力，也迅速激起了开源社区的参与热情。

模型开源后，开发者很快把它部署到个人工作站、Mac 和消费级 GPU 上，在真实任务中测试、量化和适配，并不断寻找模型效果、推理速度与硬件成本之间的平衡。

模型的能力不止由训练过程决定，来源模型部署到本地，还有大量工程工作需要做。不同的量化方案、推理配置、框架和硬件，都会影响模型最终呈现出的速度和效果。Qwen3.8-27B 发布之后，开发者正在共同完成这一过程。

对一个开源模型而言，这比下载量和榜单排名更能说明它的生命力。