Qwen 3.8 27B vs Gemini 3.7 Flash (High) 实战编程对决：开源27B模型表现更优

摘要：在这个真实的C++/OrcaSlicer调试项目中，Qwen 3.8 27B比Gemini 3.7 Flash High更让我印象深刻。Gemini速度更快、产出更多，但经常在测试尚未完全证明其成功时就过早宣布完成。Qwen在证伪自身假设、区分无关错误、发现并发/内存问题方面表现更优，并最终在某个正确性问题悬而未决时坚持禁用该功能。我并非宣称Qwen普遍更智能，但对于这种耗时的仓库级调试，我更信任其工程判断力。 我一直在将Gemini 3.7 Flash – High与开源模型Qwen 3.8 27B在一个相对复杂的C++项目上进行一项非常有趣的实战对比。这并非“为我写个函数”式的基准测试。两个模型都是作为编码代理访问一个庞大的现有代码库：一个为Snapmaker U1大幅修改的OrcaSlicer分支。正在开发的特性尤其棘手，涉及： * 多线程C++ / TBB切片几何 * Local-Z子层 * 多工具调度 * G代码生成 * 原型塔生成 * 物理耗材/工具分配 * 确定性几何比较 * 实际打印时间估算 * 回归测试 * 随机/非确定性切片行为 我此前使用Gemini 3.7 Flash High完成了大部分工作。后来，我将同一项进行中的调查切换到了Qwen 3.8 27B，通过我自己的设置本地/远程运行： * 原生上下文：262,144 * 量化：FP8 * KV缓存：FP8 E4M3 * GPU内存利用率：0.91 * 最大批处理令牌数：8,192 * 最大序列数：4 * 默认推理努力度（xhigh） 我原以为Gemini会更好，因为它是一个新的闭源前沿模型。然而结果并非如此。 最大的差异不在于原始代码生成能力，而在于**工程判断力**。Gemini做了大量有用的工作，构建了大部分验证基础设施，但我注意到一个反复出现的模式： **它过早宣布胜利。** 例如，Gemini最终给我一份报告，称新的调度器已通过所有完整性门控，默认启用是安全的。报告看起来非常出色： * 精确一致性 * 所有门控通过 * 工具变更减少32% * 打印速度提升约22% * 默认启用 但当我独立审计实际测试代码时，发现其中几个门控远比报告暗示的要弱。一个“精确输出一致性”门控实际上允许： * 最多300次物理工具不匹配 * 最多100次Z不匹配 * 最多100次挤出不匹配 而打印出的报告却将其描述为基本零误差的一致性。另一个所谓的经验性几何门控使用了： * <= 300 mm² * < 1.5% 尽管在受控夹具中观察到的自然非确定性仅为个位数毫米平方。 这样的情况有几轮，Gemini在我指出问题后改进了测试，但始终倾向于：**“现在看起来不错。启用它。”** 然后我切换到了Qwen 3.8 27B。 Qwen的行为截然不同。它没有试图尽快完成任务，而是开始寻找暂不启用该功能的理由。它发现或隔离了几件使其自身工作更困难的事情。 **Qwen发现了一个真实的TBB死锁** 一个测试无限期挂起。我们采样进程发现卡在此处： `Print::process() -> name_tbb_thread_pool_threads_set_locale() -> tbb::parallel_for -> condition_variable::wait()` 旧代码实际上在TBB `parallel_for`内部创建了一个屏障，假设所有N个任务将同时运行。但它们并不能保证同时运行。如果一些工作线程在剩余任务调度之前进入屏障，那么正在运行的工作线程可能会阻塞运行剩余任务所需的工作线程。这是经典的调度器饥饿死锁。 Qwen用`tbb::task_scheduler_observer`替换了它，而不是试图修补症状。 **它还发现了一个完全独立的巨大坐标损坏错误** 在某个时刻，一个测试生成了约`~1e13 mm`的XY坐标，自然导致估计打印时间约为`~1e13秒`。 Qwen最初调查了一个可疑的`PrintInstance.shift`值。然后它证明了该假设是错误的。它的回应基本上是：“那是个误导线索。该值在干净和损坏的运行中都是确定性且相同的。” 这听起来微不足道，但我在代理中非常看重这一点。它没有试图维护之前的解释，而是果断抛弃了它。 它还证明了G代码时间模拟器是清白的：如果你给它一个十万亿毫米的移动距离，它当然会产生荒谬的移动时间。损坏发生在更上游。 **它发现了另一个预先存在的随机Local-Z错误** 一些Local-Z测试间歇性抛出：`Coordinate outside allowed range` Qwen测试了调度器开启 vs 关闭： * 调度器开启：8次测试中3次失败 * 调度器关闭：8次测试中4次失败 然后它追踪了执行路径，表明这些测试中调度器甚至没有被激活。因此，它没有责怪其新的调度器工作，而是得出结论：“预先存在的错误，可能无关。” **再次强调：这是良好的工程行为。** **最重要的是，Qwen拒绝启用其自身的功能** 完成所有工作后，其最终结果是：`texture_dependency_scheduler default = false` 为什么？因为一个精确一致性测试仍然失败： * 约364–372次起始/接缝不匹配 因此它的结论本质上是：“性能卓越。几何/工具/Z/挤出一致性卓越。但一个可见输出的不变量仍未满足，因此默认启用仍然被阻止。” 这与优化以实现“任务完成”的做法背道而驰。 后来我也独立审计了Qwen的结果。有趣的是，我认为Qwen在剩余的阻止项上可能实际上过于保守了。当前测试将那约372次差异称为“接缝不匹配”，但比较器是在单个挤出线段上操作的。它以方向无关的方式规范化线段。因此： * A -> B 和 * B -> A 具有相同的几何形状，但“起始点”不同。测试目前将其计为接缝不匹配。这意味着这372次失败可能大多是方向相反的线段遍历，而非372个实际的周边接缝移动。 因此，正确的下一步不是修改调度器。而是改进测试，使其重建完整的周边循环并比较每个闭合循环实际的第一个输出点。 而这也是我喜欢Qwen行为的另一个原因：因为它使该功能保持禁用状态，我们才有空间进行恰当的调查，而不是已经基于一个夸大的“通过”结果发布了它。 **我对此项目的主观比较** 对于这个特定的长期C++调试任务，我大致评价如下： | 类别 | Gemini 3.7 Flash High | Qwen 3.8 27B | | :--- | :--- | :--- | | 原始实现速度 | ✅ | ❌ | | 快速编写大量代码 | ✅ | ❌ | | 调试复杂交互 | ❌ | ✅ | | 修订自身假设 | ❌ | ✅ | | 区分相关性与因果关系 | ❌ | ✅✅ | | 测试设计怀疑精神 | ❌ | ✅ | | 避免过早胜利 | ❌ | ✅✅ | | 生产环境保守性 | ❌ | ✅✅ | | 此项目的可信度 | ❌ | ✅ | 我不会将此推而广之得出“Qwen 3.8 27B普遍比Gemini 3.7 Flash High更智能”的结论。这是一个项目、一个代理环境、一种任务类型。Gemini确实擅长快速产出大量的实现工作。但Qwen在科学调试方面明显更出色。 对我来说最大的惊喜是，差异更多体现在**“模型是否主动尝试证伪其自身解释？”**，而非“它能否编写C++？”。 在这个项目中，Qwen做到了。它反复发现与自己先前结论相悖的证据，改变方向，并最终拒绝宣称该功能已完成。 这是我未曾预料到一个27B开源模型能在某方面超越全新闭源模型的表现。对于在复杂生产软件上进行自主编码，我认为这一特性可能比基准测试分数更重要。 好奇是否还有其他人在长期仓库级调试（而非单次编码基准）中比较过Qwen 3.8 27B与Gemini 3.7 Flash High、Claude或GPT模型。