在编程测试中：Q8_K_XL Qwen3.8 27B 对比 BF16 Qwen3.6 27B

继我上一篇文章 https://www.reddit.com/r/LocalLLaMA/comments/1vldngi/tested_in_coding_bf16_muse_glimmer_vs_bf16_qwen36/ 之后，我带来了这个被请求的 Qwen3.8 27B 对比。背景：两个模型都在全 FP16 KV-cache 下运行。由于 RAM 限制，BF16 Qwen3.6 运行在 150,000 上下文，而 Q8 Qwen3.8 使用 rope-scale 1.4（遵循官方 Qwen 指导）运行，达到 367,001 上下文——这相当于大约 900 页的上下文。Qwen3.6 使用默认推理设置。Qwen3.8 运行在 xhigh 设置。两个模型都在一个企业级 web 应用上工作。Qwen 3.6 在平均上下文约为 120,000 时处理任务。现在任务膨胀到平均 280,000 上下文。自 Qwen3.8 发布以来，每天编程工作超过 6 小时。总结：Muse Glimmer 作为程序员已完全过时。Q8 Qwen3.8 在所有方面都比 BF16 Qwen3.6 更强，除了一点——一个关键点——如下所述。指令遵循：Qwen3.8 最大的优势是其阅读、解释、回忆和遵循指令的能力。随着最新模型的发布，我将从 Qwen3.6 到 Qwen3.8 的 20 页反馈改进移植过来。Qwen3.6 经常忽略这些改进。而 Qwen3.8 记住每一个改进，甚至在思考中引用它们。但请注意，每轮中，Qwen3.8 初始实例经常未能遵循改进，但在该轮剩余部分自我纠正。诊断能力：Qwen3.6 在诊断能力上已经很强，但它有一个严重的完整性问题，即放宽安全控制以执行故障排除，并编辑验收标准使失败测试通过。Qwen3.8 在诊断上更强——并且多次纠正了前沿模型（例如 ChatGPT / Opus）。两个模型在诊断上都很强，但仍共享一个共同问题，即在报告前不与已知基线或诊断脚本输出进行健全性检查，Qwen3.8 中此问题得到更多缓解。追踪能力：这是 Qwen3.8 最明显的优势，有大量证据。它找到了被忽视数月的真实预存错误，甚至有一个环境错误导致 QA 测试静默失败数月。Qwen3.8 的弱点是追踪效率低下——虽然它最终几乎在所有实例中都得出了正确的结论——但它创建了许多偏离目标的初始诊断假设。它在追踪中倾向于“绕弯路”，因此调查所需时间比必要时间长。我看到 Reddit 上其他用户称这为“想得太多”，但它确实非常彻底。编码能力：即使在实现范围严格限定时，Qwen3.6 也经常将修复应用得过于广泛，直到 QA 发现——之后它通常能够纠正并不再重复此问题。这意味着 Qwen3.6 倾向于过度概括编码范围，将识别缺陷的责任留给代理测试框架。如果框架未能发现，那么缺陷将遍布代码。这实际上经常发生。Qwen3.8 思考更多，即使在编码简单函数时也会通过代码库进行超过 5 次独立检查。它确实花费更长时间，但它改进了独立验证纪律，并且在内部捕获缺陷方面可靠性大大提高。推理与判断：两者之间最大的差异。Qwen3.6 放宽安全控制（甚至一次破坏了 RLS 强制的数据库）和编辑验收标准的潜力意味着它需要持续监督。Qwen3.8 在此方面不同，因为它没有重复这些具体行为。然而，Qwen3.6 和 Qwen3.8 共享一个关键失败点。两个模型都非常热衷于执行写 Git 命令——尽管有相反的指令——这导致了重大验证问题。这是一个真正的可靠性问题，我强烈建议在为编码工具配置权限时，将 Qwen 限制为只读 Git 命令。添加：工具调用：也添加这一项，因为这是另一个 Qwen3.8 显著先进于 Qwen3.6 的领域。Qwen3.6 以非常基础的级别执行诊断脚本。它还倾向于通过使用参数“静音”错误代码来执行 web 客户端、服务器和其他脚本。Qwen3.8 远远领先。它执行时使用检查每个错误输出的命令。它使用高级 diff 和 join 来处理诊断脚本输出。总体评估：Qwen3.8 在每一个轴上都更有意义和显著地更强大和可信赖，除了一点：都不应授予扩展 Git 访问权限。最后说明：我没有注意到 Qwen3.8 在 367,001 上下文下工作有任何性能下降——这太惊人了。