本地量化模型 vs Claude:9个真实Bug实测,谁更胜一筹?

开发者用9个真实bug对比本地量化模型与Claude,发现量化代价是思考更久而非分数下降。
一位开发者用自己C++/CUDA推理引擎的9个真实回归bug,在无编译环境的沙箱中对比了本地量化模型与Claude系列的修复能力。Claude Opus 5.5以0.74分领跑,Sonnet 5.5仅用8k tokens取得0.58分;本地Qwen3.8-Flash-Next的NVFP4版得0.50分,超过Claude Haiku 5.5的0.47,但token消耗高达53k。测试最有价值的发现是:3-bit量化的27B模型得分未降,每任务token消耗却增加约40%,量化损伤体现为模型“想得更久”而非答案变差。作者强调token消耗与耗时和分数同等重要,并指出样本量有限、不构成通用排名。
关于本地模型,社区里讨论最多的往往是 tok/s 和量化损失,但真正决定生产力的是:它到底能不能把你手上的 bug 修好。Reddit 上一位开发者用自己引擎的 9 个真实回归 bug 做了一次对比测试,把本地量化模型和 Claude 系列放在同一套评分体系下,结果比单纯的跑分有意思得多。

测试设计:从真实代码库中挖出的9个Bug
测试者从自己开发的 C++/CUDA 推理引擎(capy-flash)的私有提交历史中,挑选了 9 个真实的回归问题,覆盖性能断崖、数值漂移,以及只在 WSL2 双 GPU 环境下才出现的诡异 bug。每个任务都还原到修复前的代码状态,并按照他日常提交 issue 的方式撰写 bug 报告:描述现象、数据、日志,但绝不透露问题所在位置。
所有任务运行在无网络、无 CUDA 工具链的沙箱 Mac 上,模型不能编译或运行代码,只能靠阅读代码来推理病因并给出补丁。每个模型每个任务跑 3 次,最多 80 步。Claude 模型在 Claude Code 中运行,本地模型在 OpenCode 中运行——测试者曾尝试用桥接方式让本地模型跑在 Claude Code 里,但表现明显更差,因此让双方各用最擅长的工具。
NVFP4 与 3-bit 量化
NVFP4 是 NVIDIA 提出的一种 4 位浮点量化格式,专为新一代 GPU(如 Blackwell 架构)的推理加速设计。它采用 E2M1 的尾数-指数分配(1 位符号、2 位指数、1 位尾数),并配合块级缩放因子来保持动态范围,在权重量化场景下通常比传统的 INT4 有更好的精度保持能力。相比之下,社区常说的“3-bit 量化”多为 GPTQ、AWQ 等后训练量化方法产出的低位宽权重格式,压缩率更高但对模型行为的扰动也更大。二者在本文中的对比意义在于:Flash-Next 采用 MoE 架构,专家层参数量大但每次激活少,量化到 3-bit 后得分几乎不变;而稠密的 27B 模型在同样位宽下虽然分数未降,却需要生成显著更多的 token 才能完成同样的推理,说明低位宽量化对推理路径长度的影响比对最终答案正确性的影响更隐蔽。
评分机制:双重打分与一致性验证
每个补丁会被打两次分:一次是自动评分,对照由真实修复构建的隐藏答案键,检查文件、函数是否正确,补丁精度以及若干代码检查项;另一次由 Claude Opus 5.5 作为盲评法官,看到 bug 报告、代码、标注为“一种有效解,非唯一解”的真实修复以及编译器输出,给出 1 / 0.75 / 0.5 / 0.25 / 0 五档分数。无法编译的补丁在两项评分中都被限制在 0.25 以内。
两套评分的逐补丁相关系数为 r = 0.79,模型排序一致。法官比答案键略严格,而且对 Claude 并不偏袒——每个 Claude 模型的“法官分减自动分”都是负值,而 Qwen 系列则接近零。测试者坦言,把真实 bug 转化为公平的评测任务非常耗时,单模型跑完 9 个任务×3 次需要 4 到 8 小时,因此样本量有限,置信区间约 ±0.2,分数相差不到 0.1 的两个模型基本是掷硬币。
盲评法官与答案键
“答案键”(answer key)指评测者预先根据真实修复整理出的标准答案,包含正确的文件、函数、补丁结构等可机器校验的字段,自动评分即对照它逐项比对。盲评法官则是由另一个大模型(此处为 Claude 系列)充当裁判,在不知道补丁来自哪个模型的前提下,结合 bug 报告、代码上下文、标注为“一种有效解、非唯一解”的真实修复以及编译器输出,给出分级分数。之所以要两套评分并行,是因为自动评分对“写法不同但同样正确”的补丁过于苛刻,而模型法官又可能对同族模型存在偏好。作者用逐补丁相关系数 r = 0.79 来量化两者的一致性,并额外检查“法官分减自动分”在各模型上的符号,以验证法官没有系统性偏袒 Claude——结果显示 Claude 模型的该项差值为负,反而更严格,这为评分的可信度提供了旁证。
结果分层:Opus领跑,Flash-Next紧咬Haiku
结果显示,Claude Opus 5.5 以 0.74 分高居榜首,平均每任务消耗 16k tokens、耗时 3 分钟。Claude Sonnet 5.5 以 0.58 分位居第二,仅用 8k tokens 就取得这一成绩,效率惊人。最大的惊喜来自本地模型 Qwen3.8-Flash-Next:NVFP4 量化版得分 0.50,3-bit 量化版 0.48,已经超过 Claude Haiku 5.5 的 0.47,并明显领先于旧版 Sonnet。
Claude Sonnet 5 和 Sonnet 4.5 分别只有 0.28 和 0.19,Haiku 4.5 跌至 0.13。Gemma 4 26B-A4B(thinking 模式)仅得 0.07,几乎不具备 agent 能力——关闭 thinking 时 9 个任务里从未编辑过文件,开启后虽然会编辑,但大多是错的。Qwen3.8-27B 的 3-bit 和 NVFP4 版本分别为 0.39 和 0.34,落后于 MoE 架构的 Flash-Next(配对差异 +0.16,P = 0.92)。
量化损失的真相:不是分数降,而是想得更久
这项测试最有价值的发现,在于量化对模型行为的影响方式。把 Flash-Next 的专家层量化到 3-bit 后,得分只降了 0.02,tokens 消耗仅增加 3%——在 9 个任务的尺度上几乎可以视为免费。但 27B 模型的情况完全不同:3-bit 版本得分反而高了 0.05(在噪声范围内),可每任务生成的 token 数量多了 40%(置信区间 1.25–1.59 倍),重跑新构建后仍有 1.30 倍。
3-bit 的 27B 在测试者的引擎上解码更快(153 vs 132 tok/s),但每任务仍需要 18 分钟而不是 13 分钟。换句话说,量化的损伤没有体现在分数上,而是体现在模型需要“想得更久”才能到达同样的地方。只看 tok/s,3-bit 27B 似乎是更划算的选择;按修好的 bug 数量算,并不是。
这一点对本地部署的决策有直接意义:如果你的工作流对延迟敏感,量化带来的隐性 token 膨胀可能抵消掉解码速度的优势。测试者提到,部分差距来自一个已修复的 3-bit 慢速 prefill 路径,但即便在新构建上,token 消耗仍然高出 30%。
MoE 架构与稠密模型的量化差异
MoE(Mixture of Experts)模型在每一层包含多个专家子网络,但每个 token 只路由到其中少数几个,因此总参数量可以很大而单次激活的计算量相对可控。这种稀疏激活的特性使 MoE 在低位宽量化下更为鲁棒:被量化的专家在单次推理中只承担部分计算,误差不会像稠密模型那样在全参数上累积。本文中 Flash-Next 量化到 3-bit 后得分仅降 0.02、token 消耗仅增 3%,而稠密的 Qwen3.8-27B 在 3-bit 下 token 消耗增加约 40%,正是这一架构差异的体现。对本地部署者而言,这意味着“量化损失”不能只看困惑度或基准分数,还要看模型是否被迫走更长的推理链——后者直接转化为延迟和电费,在 agent 式多步任务中尤为明显。
效率维度:token消耗与耗时同样关键
测试者特别强调,每任务 token 消耗和分数一样重要。Sonnet 5.5 用 8k tokens 达到 0.58 分,而 Flash-Next 需要 53k tokens 才拿到 0.50 分——折算到实际耗时,前者平均 1.5 分钟修一个 bug,后者需要 10 分钟。对于日常使用,这种效率差距可能比零点几分的得分差更有感知。
无法编译的补丁数量也提供了一些侧面信息:Flash-Next 在 3-bit 下为 5/27,NVFP4 下为 1/27;27B 则是 2/27 对 4/27,没有呈现出一致规律。
测试边界与开放问题
测试者明确列出了局限:9 个任务全部来自单一代码库、单一领域(GPU 推理),bug 报告用意大利语撰写;Claude 和本地模型使用了不同的 harness;法官本身是 Claude 模型。由于沙箱不能编译或运行,这项测试衡量的是“读代码诊断并打补丁”的能力,而非完整的编辑—构建—测试闭环。任务本身不会公开,否则就失去评测价值。
他最后向社区提出的问题值得每个本地模型用户思考:如果你在自己的真实工作负载上验证过量化模型,而不是只看困惑度或 KL 散度,是否也观察到同样的模式——分数差不多,但模型思考得更久?
这项测试的样本量确实不足以支撑通用排名,但它提供了一个比 tok/s 更贴近实际的评估框架:用真实 bug 检验模型,同时记录分数、token 消耗和实际耗时。对于考虑本地部署的开发者,这意味着量化模型完全可以在中低难度任务上替代部分云端模型,但需要把“思考成本”纳入账本。
Agent harness 与沙箱限制
“harness”指包裹大模型的智能体运行框架,负责工具调用、文件编辑、多步循环和上下文管理。本文中 Claude 模型跑在 Claude Code 里,本地模型跑在 OpenCode 里,两者在提示模板、工具接口和步数控制上并不相同,这是作者明确列出的混杂因素之一——模型表现部分来自模型本身,部分来自 harness 的设计。另一方面,测试沙箱刻意剥离了编译器和 CUDA 工具链,模型只能静态阅读代码、不能运行验证,因此衡量的是“读代码诊断并打补丁”这一上游能力,而非完整的编辑—构建—测试闭环。真实开发中,能编译、能跑测试的 agent 可以通过错误反馈自我纠正,静态沙箱则会放大一次性推理的难度,这也是解读分数时需要注意的边界。
相关推荐

AI能直接读懂神经网络权重:模型能力已超出预期?
Reddit开发者实验显示,语言模型能直接阅读神经网络权重并推断其功能。Astra、Opus 5.5和Muse Spark 1.3均通过测试,引发对模型泛化能力与训练来源的讨论。

印度微短剧市场爆发:EloElo获NBCUniversal 8000万美元投资
印度社交娱乐平台EloElo获NBCUniversal 8000万美元投资,加码微短剧平台StoryTV。StoryTV月活超3300万,印度微短剧市场正吸引全球资本关注。

多旋翼无人机声学检测:融合手工特征与预训练嵌入
研究揭示无人机声学检测中随机划分导致数据泄漏,提出源不相交评估协议下融合手工声学特征与YAMNet嵌入的堆叠集成方法,准确率达95.29%,为低成本无人机探测提供可靠基准。