Qwen3.6:27b 一次尝试即修复了 CSS UI 错误，而 Gemma4:26B 却无用空转了 15 分钟

警告：前方长文。不过好消息是，这是 100% 人工撰写的，包括所有的错别字。没有任何 AI 生成的废话用于生成以下帖子。请读者朋友们沉浸在我们日益稀少的共同人性的温暖光辉中。只想汇报一下我今晚的本地模型编码体验。我的一个桌游爱好网站（托管在 Github Pages 上的静态站点）出现了一个恼人的 UI 错误，可以从上面的“修复前”图片中看到：当点击“工具”导航按钮时，下拉菜单会出现在视口左侧的一半屏幕外。于是，我启动了本地 LLM 编码设备来修复它。硬件：MacBook Pro M4 Max，配备 64Gb 内存。模型后端：oMLX。模型：Gemma4-26B-A4B-it-oQ6。智能体框架：Pi。这款 Gemma4-26B MoE 模型在我的机器上运行速度相当快：提示处理速度为 800 词元/秒，词元生成速度为 63 词元/秒。Qwen3.6-35B 是我日常使用的模型，到目前为止我只将 Gemma4 用于聊天目的。但今晚我决定测试一下它的编码能力。我用语言向 Gemma4 描述了 UI 错误，由于它具有视觉理解能力，我还截图了问题并上传到模型中，以确保万无一失。起初一切看起来很有希望。Gemma4 分析了问题，认为找到了根本原因，并开始读取网站 CSS 文件以便在正确位置插入修复代码。就在这时，事情开始偏离轨道。Gemma4 陷入了读取、编辑、失败、再次读取的递归死循环。几次我停止了模型，告诉它正在死循环，问我能如何帮忙。Gemma4 道歉了，承认它陷入了循环，甚至似乎识别出了循环的原因，说它会尝试不同的方法，然后再次陷入死循环。在浪费了大约 15 分钟尝试引导 Gemma4 之后，我说“受够了”，然后加载了重型武器：Qwen3.6-27B-UD-MLX-8bit。没错——我们将要用 270 亿密集参数来对付这个 CSS 错误。没有什么花里胡哨的 MoE 玩意。是时候卷起（虚拟）袖子认真干活了。我不常使用密集模型进行编码，因为它在我的 Mac 上要慢得多。提示处理速度为 190 词元/秒，词元生成速度相比之下更是如冰川般缓慢，仅为 13.2 词元/秒。但 Qwen3.6-27B 在速度上的不足，用其推理能力和编码质量弥补了回来。我启动了一个新的 /new Pi 会话，加载了 qwen3.6-27B。用语言描述了 UI 错误。甚至懒得上传截图。这足以让 Qwen3.6-27B 理解问题所在。然后它开始思考。它消耗了我大约四分之一的上下文窗口，仅用于从各个角度弄清楚这个 bug，一段又一段地与自身进行来回推演。“我能看到问题……但等等……问题是……其实……等等，那应该没问题……哦等等，我看到问题了……让我重新检查……除非……最干净的修复方法是……”经过所有这些思考之后，Qwen3.6-27B 一次性修复了该错误。正如你在上面的“修复后”图片中所见。对我来说，这是对我在探索本地模型的几个月中所做的某些假设的明确现实说明和证实。1. MoE 模型速度更快，但更容易出错和陷入循环。2. 密集模型速度较慢，但准确度和精确度要高得多。3. Gemma4 在编码方面不如 Qwen3.6 有用。Qwen3.6-35B（MoE）仍将作为我的日常主力，因为它在极速和可接受的准确性之间取得了良好的平衡。但当情况危急时，能够拿出一个密集模型来摆脱困境是很不错的。TL; DR：Gemma4 MoE 速度快但容易陷入死循环，而 Qwen3.6（密集模型）速度慢但准确无误。编辑：添加了“密集”一词。