真代码任务三轮实测 4.33:4.33 打平：22G 显卡下 Qwen 3.8-27B 和 3.6-35B-A3B 到底差在哪

上篇 Gemma 4 发出去之后，评论区有三条反馈扎到了一起，指向同一个问题——我的测试方法该升级了。

一条是读者在 22G 显存的场景下推荐了一个魔改版 Qwen3.6-27B-Fable-Fus-711，说还没见过 3.8 打得过它的；一条是批评我一直拿”9.11 和 9.9 谁大”这种题测模型，太像鱼缸里比鲨鱼海豚谁游得快，根本测不出编程差距；还一条是断言 3.8-27B 早就吊打 35B。三条凑一起，结论只有一条：这次必须换成真实的编程任务来测。

先说结论

这次搭了一个真实的 Python 小项目（约 200 行的任务队列库 jobqueue/，6 个文件互相调用），配了 6 个真实的修 bug / 实现功能任务，并采用隐藏测试打分——模型全程看不到评分标准，跑完之后才把测试文件拷进去验证，杜绝照标准答案抄的可能。

每个模型独立跑了 3 轮（Claude Code × 2 + Codex × 1），成绩如下：

• Claude Code 第 1 轮：35B-A3B 4/6，3.8-27B 5/6，Fable-711 3/6
• Claude Code 第 2 轮：35B-A3B 5/6，3.8-27B 5/6，Fable-711 3/6
• Codex 轮：35B-A3B 4/6，3.8-27B 3/6，Fable-711 3/6

三条反馈的答案依次是：

• 读者推荐的 Fable-711：三轮全部 3/6，零方差，是三个模型里唯一”次次垫底”的
• “鱼缸”批评：方向是对的，但补测之后要把草稿里”3.8 反超”的结论往回收
• “3.8 吊打 35B”：不支持。两个模型三轮平均分完全打平（4.33:4.33）

真正测出来的核心信号不是谁赢了，而是：同一个模型换个 Agent CLI（Claude Code / Codex），分数波动能到 2 分。这个波动比”谁赢了”更值得记住。打平不是碾压，”4.33:4.33″回答不了谁更强，但 Fable-711 的零方差垫底扎实地回答了谁更弱。

这次测试是怎么设计的

一句话说：之前是让模型做脑筋急转弯，这次是让模型真干一份程序员的活，而且背对背改卷子，答案它偷不到。

改动一：造一个”真项目”，而不是零散问答题

写了一个约 200 行的任务队列库，覆盖后台系统常见的能力：按优先级排队处理任务、失败自动重试、重试耗尽进死信队列、限速器、性能记录、存盘与恢复。六个文件互相调用，结构接近真实项目。6 个任务对应六类日常开发活：

• T1 修”偶尔崩溃”的 bug：优先级相同时程序报错
• T2 照需求文档从零实现一个功能模块：重试的退避算法
• T3 修不报错但结果不对的隐藏 bug：该进死信队列的任务没被扔进去
• T4 从零实现经典算法：限速用的令牌桶
• T5 修长期运行才暴露的隐患：内存泄漏
• T6 打通完整链路并顺手修掉一个连带 bug：存盘 / 读盘

改动二：像真人一样上手干活，而不是把问题喂到嘴边

不指出 bug 位置问”这段哪错了”，而是把需求一句话丢给 CLI（比如 T4 就是”帮我实现一下这个限速器”），模型自己打开项目、定位文件、理解现有设计、动手改，改完通常还会自己写几行验证代码。等价于真实场景里”把需求甩给同事，等他自己搞定”。

改动三：评分标准隐藏，事后才打分

这是这次设计里最关键的一点。考试前发标准答案，考满分只能证明会抄。之前不少模型测评把评分标准（比如”必须包含关键词 XX”）和题目一起喂给模型，等于提前漏题。这次跑完才拷入测试，模型无法针对标准优化输出，”看起来对了但没真懂”的情况会被直接拦下来。

一个有意思的现象：Fable-711 那几轮翻车里，有”函数签名对不上任务要求”这种错误——任何熟练工程师一眼就能避开的低级问题，在真代码任务里暴露得很清楚，换回”数字比大小”的题就完全不会显现。

逐条回应

给推荐 Fable-711 的读者： 认真测了，而且不是一遍——三轮独立测试、两个不同 CLI，六题里稳定对三题，是唯一”次次垫底”的。翻车高度重合：T3 有两轮直接调错死信队列的方法名；T6 三轮全灭，一轮是循环导入直接崩，另外两轮是函数参数签名对不上要求。具体错误不完全重样、但成绩始终垫底，这个模式比单次翻车有说服力。不排除它在对话 / 角色扮演类任务上确实更强，但”coding 更强”这个具体说法，三轮数据都不支持。

给提”鱼缸”的读者： 方向对了，但补测后结论要往回收。草稿只跑了第一轮 Claude Code，看到 3.8-27B 5:4 反超，差点以为已经回应完了；加测两轮后 35B-A3B 追平到 4.33:4.33。真正被”鱼缸”批评证实的，不是”3.8 更强”，而是”之前的测试环境测不出旗舰模型之间的真实差距”。

给说”3.8 吊打 35B”的读者： 这次数据更不支持了——平均分完全打平，且两个模型在同一道死信队列的题上犯了几乎一样的错。更准确的说法是：这套编程任务上目前测不出显著差距，真正拉开差距的是用什么 CLI 驱动，不是版本号。

写在最后

这篇其实”逐条回应”之前已经完整写过一版：结论是”3.8-27B 以 5:4 反超”，逻辑通顺、三条反馈都对得上，看着可以收工了。但一轮数据撑不起一个”反超”结论，不踏实，就加测了两轮，结果原结论没扛住，被自己现场推翻。

这已经是这个系列第二次因为不放心推翻刚写完的结论（上一次是第 5 篇”魔改 vs 官方不同源”那次）。两次的共同点：发布前”看起来说得通”，恰恰是最该多测一轮的信号，而不是收工的信号。

这次补测下来，几条具体教训：

• 验证”编程能力”的题目，本身就得是编程任务
• 隐藏测试挡住了很多”看起来对、其实没理解”的情况，测试标准可见时很可能被绕过而不是露馅
• 打平回答不了谁更强，但零方差垫底扎实回答了谁更弱——同一份数据能回答什么、不能回答什么要分开说
• 同一个模型换 CLI 分数能浮动 2 分，只用一个 CLI 测很容易把 CLI 差异错当成模型差异
• 样本量仍是短板：6 任务 × 3 轮，和 30 题 × 3 次的量级没法比，”4.33:4.33″应解读为”目前样本量下测不出显著差距”，不是”证明两者一样强”。下一步大概率把任务量和轮次再扩大一截

这个系列到现在，最管用的纠错机制一直是读者而不是我自己的复盘。这次算是自己给自己挑了一次毛病，不算坏事。

系列文章

这是本地部署系列的第九篇，前八篇：

• 12GB 显存跑 35B 大模型，还支持多模态——我是怎么做到的
• 千问 35B 本地部署提速实录：换张 2198 元的显卡，17 → 93 tok/s
• 2080Ti 22G 跑 qwen 千问 35B，Claude Code、Codex、OpenClaw 全接
• Qwen3.8-27B 对决 Qwen3.6-35B-A3B：一张 2080Ti 22G 塞三个模型，10 道题见真章
• 千问 Qwen3.6 好还是 3.8 好？22G 显存实测，结果有点意外
• Qwen2.5-Coder-32B 和 Qwen3-Coder-30B-A3B 实测：代码专用模型换不换？
• DeepSeek 也测了：22G 显卡代码模型选型追加两个候选
• Gemma 4 26B 能不能跑？22G 显卡实测出了个最接近 Qwen3 32B 的挑战者

参考

llama.cpp 官方仓库 (https://github.com/ggml-org/llama.cpp)