Qwen 35B-A3B MoE 与 27B dense 本地编码测试对比：速度快约 4 倍，质量差距远小于预期

我在一系列本地代码维护任务中，将 Qwen 35B-A3B MoE 与 Qwen 27B dense 进行了对比。在我的 R9700/llama.cpp 环境中，MoE 模型的生成速度快约 3.9 倍（约 116 对 30 tok/s），但编码质量差异比我预期的要小得多。两者通常都能正确处理普通的 bug 修复和多文件更改。随着我逐步提高测试难度，dense 模型确实展现出了优势——但主要体现在隐式不变量、不常见的边界情况，以及超出字面请求的后果方面，而不是基本正确性上。 模型 Qwen 3.6 35B-A3B — Q5_K_M（MoE） Qwen 3.6 27B BASE — Q4_K_XL（dense） 硬件/运行时 Radeon AI PRO R9700 32 GB Ryzen 9 5950X llama.cpp，Vulkan，全部 GPU 卸载 这些编码测试使用 8K 上下文 一个早期的受控解析器修复测试很能说明问题： 35B-A3B：约 116 tok/s，暂定评分 7/10 27B dense：约 30 tok/s，暂定评分 7/10 单独这一项结果并不能构成我的论点。随后，我进行了一系列难度递增的多文件测试，涉及导入、稳定 ID、冲突处理、数据保留，以及最终在 ID 重新映射时必须保持有效的引用。到目前为止，我的结论刻意限定得很窄：在这些任务中，约 4 倍的吞吐量差异比我观察到的实际编码质量差异要大得多。这是一个小规模本地实验，并非对 MoE 与 dense 架构的普遍性论断。量化方式也不同，所以我不会声称这是一次学术上受控的架构对比。但结果确实让我对将活跃参数数量视为实际能力的直接代理指标持怀疑态度。我保留了原始提示词、源代码夹具、确切的 llama.cpp 命令、原始终端记录，以及难度递增的集成测试。如果有人想深入了解细节，我会在下面的评论中提供更多方法论和示例。