Memdoor:由 5 个 Qwen3.8-27B 模型组成的团队在 LiveCodeBench Hard 上击败 Fable 5
一个基于五个 Qwen3.8-27B 开放模型构建的新型多智能体“团队”据称在 LiveCodeBench Hard 编码基准上与 Anthropic 的 Fable 5 打平甚至超越,引发了人们对聪明的运行框架是否能让更小的本地模型媲美专有前沿系统的兴趣。评论者探讨了性能提升有多少来自基于角色的智能体和更好的上下文管理,而非原始模型质量,并质疑像 LiveCodeBench 这类已经饱和、较旧基准的可靠性。讨论还扩展到在平台审查日益收紧、闭源模型快速推进的背景下,如何让强大且不受审查的开放权重模型在消费级硬件上保持可用。
基准测试与报告结果
- Memdoor 使用五个 Qwen3.8‑27B 智能体(planner、ideators、solver、manager、repair)重新实现了之前讨论过的 GVS5H 运行框架。
- 在 LiveCodeBench Hard 的前 10 道题上,它报告的成绩是 9.8/10,而原始框架是 9.6,Fable 5 是 8.0。
- 有人认为这说明,借助良好的运行框架,开放的 27B 模型在这个基准上的编码能力可以与“前沿”模型持平甚至超越。
- 也有人认为样本太小,而且 LiveCodeBench Hard 已经很旧、很可能已饱和/被污染,因此关于持平的说法站不住脚;他们希望看到更新、更广泛的基准,以及速度/成本对比。
运行框架与多智能体“团队”
- 多位评论强调,多智能体设置和运行框架工程(角色划分、迭代循环、基于文件的通信、上下文管理)可以显著提升性能。
- 一种观点认为:团队之所以有效,是因为它们分工明确、限制每个角色的上下文,并过滤掉噪声较大的中间 token,从而有效扩展并聚焦可用上下文。
- 另一种观点则认为:很容易针对某个特定评测调优一个运行框架来取胜,但很难做出能泛化的框架;“一群傻瓜”往往只是在并行地重复循环。
模型质量、量化与替代方案
- 讨论集中在 Bonsai 2-bit 以及其他极低比特量化上:有人说它们速度快,而且“没那么笨”,也有人说 2–3-bit 量化在真实编码任务中明显更差,错误会在长对话中不断累积。
- 更高比特的(Q5/Q6)或较好的 3-bit ISTA 量化被视为可用的折中方案;“达到完整精度 95%”之类的说法则被批评为挑选有利基准。
- 许多人建议尝试 Qwen3.8-Flash-Next 或未来的 Qwen4 变体,基准显示它们更强也更快。
本地模型与专有前沿模型
- 大家强烈希望本地、开放权重模型保持竞争力,以避免依赖超大规模云服务商及其审查/安全政策(例如屏蔽游戏逆向、抓取、某些网页自动化)。
- 有人认为当前的开放模型(Qwen、DeepSeek、GLM)在大多数编码任务中已经“足够好”,前提是人类足够熟练并使用工具/测试。
- 也有人反驳说,专有模型仍然能以更少的迭代、更快的速度解决困难任务,而且开放权重模型若没有持续训练,其内置知识会随着时间变得过时。
硬件与可行性
- 例子从消费级笔记本电脑(M 系列 Mac、配备 16–32GB VRAM 的游戏显卡)上以适中速度运行 27B/Flash-Next,到多 GPU 机器和专用芯片(Cerebras)实现极高吞吐量不等。
- 有人乐观地认为,推理引擎和量化技术的改进会让 Qwen 级模型在消费级硬件上变得又快又便宜,但 16GB VRAM 对严肃的多智能体工作来说仍然偏紧。
开放性、审查与托管
- 有人担心 Hugging Face 之类的平台可能会越来越多地移除“未审查”或“abliterated”模型;帖子里给出了被移除的网络安全调优模型以及记录下架情况的镜像链接。
- 也有人认为这类模型只会转移到其他托管平台或种子下载;“去审查”开放权重的过程已经被充分理解,而且成本相对较低。
现实使用与局限
- 一些人表示,他们正在本地使用 Qwen/DeepSeek/GLM 进行真实编码:查 bug、做小工具、逆向工程和游戏克隆,效果不错,但自动化程度还达不到前沿水平。
- 怀疑者指出,如今很多内容都只是“基准和 tokens per second 的讨论”,而他们还没看到多少主要建立在本地模型上的、相当有分量的生产系统。