Qwen 3.6 35B A3B 对比 Qwen 3.8 27B：3B 激活还是 27B 稠密？

两个数字决定了这一组合，而它们朝相反的方向发力。Qwen3.6-35B-A3B拥有 350 亿参数，但处理任意单个 token 时只激活其中约 30 亿。Qwen3.8-27B则是稠密的：它 270 亿参数中的每一个，都会用于你生成的每一个 token。也就是说，混合专家模型是运行起来更轻的模型，运行而更重的模型则更适合驻留——按各家自己的仓库数据，BF16 权重分别为 71.9 GB 和 55.6 GB——而稠密模型每个 token 所需的算力大约是前者的九倍，占用内存却更少。这两者都不是缺陷。它们是对"我手头有多少机器"这一问题的两种不同回答，而哪个答案属于你，就是整个决策的全部。

这个页面值得你花时间，还有第二个原因。围绕 35B A3B，读者搜索的正是这种对比的形态——该模型小家族中的每一次查询都是它的一个版本——而 Qwen3.6-35B-A3B 在这里从来就没有一个页面来描述它。于是，这个页面在两侧各放一段如实说明，然后进入对比。

35B A3B 构建到底是什么

Qwen3.6-35B-A3B 是阿里巴巴 2026 年 4 月发布的 Qwen3.6 代中的稀疏成员，以 Apache-2.0 许可发布在该厂商自己的 Hugging Face 仓库中，该仓库创建于 2026 年 4 月 15 日。厂商的模型卡将其描述为一个专家混合模型，“总共 35B，激活 3B”，由 256 个专家构建，每个 token 会激活八个路由专家外加一个共享专家。它并非纯文本：模型卡称其为“带视觉编码器的因果语言模型”，并且该仓库带有 image-text-to-text 的 pipeline 标签，因此它接收文本、图像和视频并返回文本。上下文原生为 262,144 个 token，可通过 YaRN 缩放扩展到约 1,010,000。其布局是混合式的——重复十次“三个 Gated DeltaNet 线性注意力块后接一个门控全注意力块”的结构，隐藏维度 2,048，40 层——而模型卡通过点名它强调的两件事，将推销话术与架构区分开来：智能体编码，以及一个“思维保留”选项，用于保留早先轮次的推理上下文。该模型卡上厂商自己的表格将其列为 SWE-bench Verified 73.4、Terminal-Bench 2.0 51.5、MMLU-Pro 85.2、GPQA 86.0 和 LiveCodeBench v6 80.4——全部为厂商报告且未经审计，这也是它们在下文无论何处出现时都带有的标签。

什么是 Qwen3.8-27B

Qwen3.8-27B 是 Alibaba 在 Qwen3.8 代推出的稠密 27B 开放权重模型，以 Apache-2.0 许可发布；其厂商仓库创建于 2026 年 8 月 5 日，最后修改于 8 月 14 日。Qwen 自家的模型卡称其为“一款紧凑、便于部署的稠密模型”，并将其定位为迄今能力最强的开放 Qwen 代系，声称在编程、专业工作、研究和长时程智能体任务上均有提升。它同样是视觉语言模型——“带视觉编码器的因果语言模型”——除文本外还可接受图像和视频，原生上下文为 262,144 个 token，扩展后可达 1,000,000。相比之下，其架构较为常规：64 层，隐藏维度 5,120，中间维度 17,408 的普通前馈网络而非一组专家，以及与同系列模型相同的“三个线性注意力层对一个全注意力层”的节奏。35B A3B 的模型卡谈的是思维保留，而 Qwen3.8-27B 的模型卡谈的是灵活的思维控制——一个 reasoning_effort 设置，默认为 xhigh，可选 medium 和 low，以及 preserve_thinking 默认开启。其模型卡报告 LiveCodeBench v6 90.3、GPQA Diamond 89.2、OSWorld-Verified 84.3、QwenSWEBench 79.0、Terminal Bench 2.1 73.0 和 SWE-bench Pro 61.7——同样为厂商自报、未经审核。其权重总量为 55.6 GB，分布在十八个 safetensors 分片中，算上视觉塔后参数量为 278 亿，这也是该模型被称为 27B 而实测为 27.8B 的原因。

最能决定它的一个数字：激活参数

文件对应的是总参数量，速度对应的是激活参数量。它们是规格表上两个不同的列，而读者常常把它们合并成一个，于是人们会下载一个 22 GB 的混合专家模型，却指望它能塞进 16.5 GB 稠密模型能塞进的地方。

这个机制值得直白说明，因为它就是全部的取舍所在。稠密模型每生成一个 token 都必须读取其全部权重；稀疏混合模型只读取其路由器选中的专家。Qwen3.6-35B-A3B 每 token 大约读取相当于三十亿参数的权重，而 Qwen3.8-27B 读取二百七十亿——所以混合模型在每 token 计算量和解码吞吐上具有结构性优势，而这种优势是真实存在的。但其他专家并非没有代价：它们必须驻留在某处，显存或系统内存中，否则路由器最终就得去取它们，而一次取用可能比它省下的算术开销更高。因此，这一优势的前提是能把整个 35B 都容纳下来。这就是混合专家解码的工作方式，而不是对这两个具体模型的测量结果；这也是为什么“放得下”的问题先于“速度”的问题，而不是反过来。

• 磁盘上的总参数量，BF16 —— Qwen3.6-35B-A3B：35.95B，分布在 26 个 safetensors 文件中，71.9 GB。Qwen3.8-27B：27.78B，分布在 18 个分片中，55.6 GB。依据各厂商自己的 Hugging Face 仓库，读取于 2026-10-13。

• 每个 token 的激活参数量——Qwen3.6-35B-A3B：约 3B。Qwen3.8-27B：全部 27B，因为稠密就是稠密。

• 架构 — Qwen3.6-35B-A3B：256 个专家，每个 token 8 个路由专家加 1 个共享专家，40 层，隐藏维度 2,048。Qwen3.8-27B：单一前馈网络，中间维度 17,408，64 层，隐藏维度 5,120。

• 原生上下文 — 两者均为 262,144 tokens。Qwen3.6-35B-A3B 借助 YaRN 可扩展至约 1,010,000；Qwen3.8-27B 的规格说明中称扩展后可达 1,000,000。

• 许可证——两者均为 Apache-2.0。两者均可从供应商处下载，均为开放权重，且均不附带按席位或按调用计费的条款。

每个 token 你需要为每一项花费多少

两个模型都在 OrcaRouter 上提供服务，因此你无需下载任何内容就能分出高下。以下数据来自我们 2026-10-13 的实时目录，qwen/qwen3.6-35b-a3b 的价格为每百万输入 token 0.248 美元、每百万输出 token 1.485 美元，上下文窗口为 262,144 个 token，最大输出为 65,536 个 token。qwen/qwen3.8-27b在相同的 262,144 token 窗口下，每百万输入 0.330 美元、每百万输出 2.400 美元。这两个模型在我们的目录中还以第二个 host id 列出，价格更高，因此在对比账单之前，请确认你实际调用的是哪个标识符。

在 100 万输入 token 和 25 万输出 token 的工作负载下——对于小型编程智能体部署来说，这可能是合理的一个月用量——算术结果如下。Qwen3.6-35B-A3B：1.00 × $0.248 加 0.25 × $1.485，约合 $0.62。Qwen3.8-27B：1.00 × $0.330 加 0.25 × $2.400，约合 $0.93。在这种流量结构下，较新的稠密模型成本大约要高出五成，而且差距在输出 token 上最大，约为 62%。

有两点随之而来，比数字本身更重要。第一，这些是我们的目录价，我们不会在供应商公布的标价之上加任何加价——因此供应商调价当天，这一页就会同步更新，没有延迟，也不需要另立合同。第二，之所以要用一个密钥而不是两个来比较它们，关键在于切换成本：这两个 id 位于同一个端点之后，所以从其中一个换到另一个只是改一个字符串，而不是做一次迁移，而且自动故障转移意味着你可以把两者中你较不熟悉的那一个跑在一部分流量上，而无需拿一条生产路径去押注它。如果你是因上文提到的算力理由而第一次评估混合专家模型，那正是低成本验证这个理由是否适用于你的工作负载的方式。

什么适合你的机器

这就是两个模型真正存在分歧的问题，而它取决于同样的总量与激活量之分。比较两个模型都有的社区 GGUF 构建——这些是第三方仓库，不是厂商发布版，而且它们的文件名也是各自的——同一个量化标签会给你带来显著不同的文件大小：

• Q3 级别，最小且仍合理的选择 — Qwen3.6-35B-A3B：UD-Q3_K_M 下为 16.60 GB。Qwen3.8-27B：UD-Q3_K_XL 下为 13.15 GB。

• IQ4 左右 — Qwen3.6-35B-A3B：UD-IQ4_XS 下为 17.73 GB，UD-IQ4_NL 下为 18.04 GB。Qwen3.8-27B：UD-IQ4_XS 下为 14.25 GB。

• Q4_K_S — Qwen3.6-35B-A3B：20.89 GB。Qwen3.8-27B：15.36 GB。

• Q4_K_M，通常的默认选项——Qwen3.6-35B-A3B：22.13 GB。Qwen3.8-27B：16.46 GB。

• Q4_K_XL — Qwen3.6-35B-A3B：22.36 GB。Qwen3.8-27B：17.56 GB。

• Q5_K_M — Qwen3.6-35B-A3B：26.46 GB。Qwen3.8-27B：19.77 GB。

• Q8_0 — Qwen3.6-35B-A3B：36.90 GB。Qwen3.8-27B：29.05 GB。

• BF16，出厂配置 — Qwen3.6-35B-A3B：71.9 GB。Qwen3.8-27B：55.6 GB。

• 此外还发布了——Qwen3.6-35B-A3B 在厂商自家仓库中提供了 FP8 检查点，社区构建版本中还有一个 21.71 GB 的 MXFP4 混合版本；Qwen3.8-27B 在厂商自家仓库中也提供了 FP8 检查点。

把这两列互相对照着读，规则就出来了。在每个匹配的标签处，相同的标称压缩率下，混合模型要重四到八 GB，因为文件必须装下全部 35B，而一次只用到其中的 3B。具体来说：一块 24 GB 的显卡能以 Q4_K_M 跑 Qwen3.8-27B，并留出上下文空间；能以 Q3 或 IQ4 跑 Qwen3.6-35B-A3B，但 KV 缓存要争抢空间；而在混合模型上舒适地进行长上下文会话，则要接近 48 GB。如果你想在二者任一上使用图像输入，就再加上视觉塔自己的文件。

基准所处的水平，并非你所希望的那样

在匹配设置下、于具名测试框架上对这两个模型进行的直接对比运行，尚无人发表。我们也不知道有这样的结果，而本页不会暗示证据无法支撑的排名。

确实存在的是基准测试名称上的部分重叠，而它恰恰值得被明确指出，因为它太容易被过度解读了。在两张卡片上都出现的名称上，Qwen3.8-27B 的数值每一次都是更高的那个。SWE-bench Pro：35B A3B 为 49.5，而 27B 为 61.7。LiveCodeBench v6：80.4 对 90.3。HLE：21.4 对 30.8。CharXiv 推理题：78.0 对 83.7。OmniDocBench 1.5：89.9 对 91.1。RealWorldQA：85.3 对 85.9。而在 Terminal-Bench 上，两张卡片甚至无法像这一行所暗示的那样进行比较：35B A3B 卡片报告的是 Terminal-Bench 2.0，为 51.5，而 27B 卡片报告的是 Terminal Bench 2.1（Terminus），为 73.0——这是基准测试的不同版本，因此这一对数值根本不应相互相减。

以上所有内容都附带三点注意事项。这些数字来自两份不同的模型卡，由同一家实验室相隔约四个月发布，且未经审计。每个模型报告的若干基准测试只出现在各自的模型卡上，没有对应项——35B A3B 那边的 SWE-bench Verified 73.4 和 MMLU-Pro 85.2；27B 那边的 OSWorld-Verified 84.3 和 QwenSWEBench 79.0——因此无法将它们对齐比较。而同一产品线中较新的模型比较旧的模型得分更高，本就是预期结果，而非什么发现：它只能告诉你世代在推进，完全无法说明较旧的模型是否更适合你即将发送的那些 token。

如果需要让对比结果具有决定性，最诚实的做法是在你自己的流量上把两者都跑一遍。它们共用一个密钥、共用一个端点，而故障转移让拆分测试变得很便宜。

你应该选哪一个

选Qwen3.6-35B-A3B，前提是你的机器能装下 35B 的权重，且你的工作负载更偏重生成而非一次性推理。以下这些情况它才是正确答案：

• 你有足够的内存——48 GB 或更多，以便舒适地进行长上下文本地使用；或者，如果你能接受更短的窗口，一张 24 GB 显卡配 3-bit 级别的量化——并且你想要每 token 计算开销最低的架构。

• 你的流量属于高并发或长生成场景，此时每 token 成本主导账单，而混合模型的稀疏解码在结构上对你有利。

• 你想要一个接收文本、图像和视频并返回文本的 Apache-2.0 制品，而且你想要这一对中体积更小的那个下载包只有在你自行托管而非下载它时，其输入和输出的每 token 价格才都更低。

• 你是有意停留在 3B 激活参数这一规模上的——你接受在厂商自家的对比表上落后一代，以换取更低的每 token 成本，而且这一切都是在熟悉的工具调用接口背后完成的。

选择 Qwen3.8-27B——如果内存是硬性约束，或者你想要这一组中最新的一代。它成为正确答案的情况：

• 单张 24 GB 显卡，且不打算再买更多。在 Q4_K_M 下它是 16.5 GB，这为上下文留出了实实在在的空间；混合模型则没有。

• 你希望在这对组合中获得厂商报告的最强智能体与编码数据，并且你清楚这些数据来自未经审计的模型卡，且并非匹配对比。

• 你的工作负载是相对较少、相对较大的请求——文档与截图理解、仓库级推理、计算机操作式自动化——在这些场景中，单个请求的吞吐量不如每个请求能否做对来得重要。

• 您想要更小的下载、更快的冷启动以及更短的分片列表来管理。

这些都不能让谁成为赢家。这两个模型并不是在争抢你机器上的同一个位置，上面的数字也不能证明哪一个在哪些方面更好——它们只能说明哪一个对你已有的机器要求更低。

通常最能一锤定音的事实是：磁盘上的文件大小由总参数量决定，而每个 token 的工作量由激活参数量决定。所以，Qwen3.6-35B-A3B 可能是运行更快、却仍然装不下的那个模型，而 Qwen3.8-27B 可能是每 token 开销更大、却仍然是能跑起来的那个。先确定你实际面对的是这两个问题中的哪一个，选择就不再是一场比较了。