我将测试时计算扩展到 Qwen-3.6-27B 和 Gemma-4-31B，以在代码优化和加速方面超越 Claude Mythos。

Reddit r/LocalLLaMA 工具
test-time-compute iterative-refinement code-optimization qwen gemma scaffold llm-inference

摘要

本文描述了一个脚手架（scaffold），它通过在 Qwen-3.6-27B 和 Gemma-4-31B 上使用迭代修正和分支探索来扩展测试时计算，从而在代码优化方面超越 Claude Mythos。文中附有论文链接和 GitHub 仓库地址。

该脚手架在原始基线模型上使用约 25-40 倍的计算量来尝试解决相同的问题。我将其设为最大模式：分支探索宽度设为 5，迭代修正循环深度设为 10，以及 6 个分支感知的选择性假设，这些假设每 2 次迭代后修订一次。这些假设独立测试各种声明、局部加速或完全不同的算法设计，并有选择地注入到特定的分支上下文中。整个系统中最有用的组件是解决方案池，它为迭代修正循环添加结构化噪声，以免大语言模型陷入局部最优解。所有智能体都可以访问 Python 环境，因此它们可以即时通过编程方式检查自己的工作，看看自己的想法是否真正自然且是实质性的改进。由于这两个模型（Gemma 和 Qwen）在长上下文窗口上的推理不够稳定，性能实际上在迭代 4 和 5 时开始显著下降，或者在 PQF 更新后，在迭代 9 和 10 时下降。这些都是真正的回归，我们不能停在例如迭代 3 处，因为有时更新/进化后的分支比其他所有分支有更大的机会做得更好。也不能每 3 次迭代就做一次记忆库蒸馏，因为那样搜索范围太窄（而前沿大语言模型在这方面表现良好）。因此，我分别给它们提供了分支历史，要求它们判断并选出每个分支中表现最佳/优化最好的候选者，然后从每个分支中选出最好的一个交给最终评判者。原始论文链接：[https://arxiv.org/abs/2605.15222](https://arxiv.org/abs/2605.15222) 该脚手架的 GitHub 仓库链接：[https://github.com/ryoiki-tokuiten/Iterative-Contextual-Refinements](https://github.com/ryoiki-tokuiten/Iterative-Contextual-Refinements)
查看原文

相似文章

通俗版对比：Qwen3.6 35b-a3b 与 Gemma4-26b-a4b-it

Reddit r/LocalLLaMA

Gemma 4-26b-a4b-it 基本是个基础扎实、能稳妥完成任务的 B 等生。Qwen3.6-35b-a3b 则是考出 A+ 的优等生，做完任务后还有余力搞点锦上添花的发挥。在我的 16GB 显存显卡上，两款模型运行速度相当。测试环境为 Windows 下的 LM Studio，采用推荐推理设置。使用的模型：unsloth/gemma-4-26B-A4B-it-UD-Q4_K_S 与 AesSedai/Qwen3.6-35B-A3B IQ4_XS。大家有不同意见吗？**更新：** 看来我之前用 Gemma 4 的方式不太对。[Sadman782 的评论](https://www.redd