有个 3.6 GB 的本地模型，在一项智能体写代码的测试里，把大厂走云端的轻量模型压在了下面。消息不大，但挺有意思：一个装进笔记本就能跑的模型，开始在一些真实修 bug 的活儿上够得着云端主力了。

这是一位开发者的实测。他把一个 4B 参数的小模型做成量化版，取名 SharpSpark，拿去跑了 SWE-bench-Live，一共 17 道题。结果是：量化版解出 5.7 道，大厂的轻量模型 Haiku 4.5 解出 5.0 道，没经过这套改造的底座模型只有 3.7 道。

量化只是入场券，真正下功夫的是这四步

一提把大模型塞进本地，很多人的第一反应就是量化：把权重精度往下压，体积小一半，质量跟着掉一截。这次的路子不太一样，体积从 4.3 GB 压到 3.6 GB，解题能力反倒涨了。差别在于量化之外还做了四件事。

• 修过一遍的对话模板
• 为工具调用回路专门调过的系统提示词
• 自定义的重要性矩阵，把对写代码起决定作用的权重单独保住
• 按张量逐个分配比特数，不再一刀切地全压成同一个精度

最后一条是关键。传统的均匀量化把所有层当成一回事，可写代码的本事恰恰集中在少数地方，一刀下去先伤的就是它们。改成逐张分配之后，模型小了，解题能力没跟着塌。

一张图看完三个模型的差距

左边一栏是 17 道题里解出的数量，右边一栏是每道题的平均耗时。三行从上到下依次是改造后的量化版、大厂的轻量模型、没改造的底座模型。

数据摆在一张图上，看得更清楚。解题数量上，量化版 5.7 道，云端轻量模型 5.0 道，未量化的底座 3.7 道。体积上，量化版 3.6 GB，底座 4.3 GB，云端模型不占本地硬盘。耗时差别最大，量化版每题 74 分钟，云端模型 21 分钟，底座 145 分钟。

慢工出细活，前提是你等得起

74 分钟对 21 分钟，速度差了三倍多。云端那个模型每道题二十来分钟就给答案，本地这个得泡杯茶再回来。可要是活儿本身不着急，任务排好队，睡前挂上跑一夜，第二天早上收结果，这个差价就不算贵。

更值得看的是底座那一行。同一个模型，没做这套改造，每题要跑 145 分钟，还比改造后的版本少解出两道题。也就是说，量化加提示词这一套组合拳，把本地推理的时间砍掉了将近一半。省下来的时间会变成电费、循环调用次数，还有你盯着屏幕的耐心。

别急着封神，这只是一份自测跑分

「干翻大厂主力」这个说法读着爽，但话得说完整。

17 道题，3 个随机种子，出卷子和批分的都是作者自己。样本小，题目取自哪些仓库、难度怎么分布，外人都看不到。它能证明一件事：这款量化版确实比自己的底座强，同源同题，这个对比赖不掉。但要拿它证明 4B 小模型整体超过大厂轻量模型，证据还不够。

及之而后知，履之而后艰，这话放在跑分上格外合适。SWE-bench-Live 本身就是一把不留情面的尺子：题目全部来自 2024 年以后真实提交的代码仓库问题，每道题配了独立的容器环境，还藏着回归测试，专门抓那种修好一个 bug、顺手弄坏另一个的改动。公开数据显示，几个主流的智能体方案在静态榜上能解掉四成以上的题，换到这套实时榜上，掉到两成以下。改动只落在一个文件里的题，成功率约 48%；一旦要跨 7 个以上文件，直接归零。

把这套尺子的严苛程度和 17 道题的小样本放在一起看，结论就很清楚：这次的成绩说明方向走对了，不说明对手不够看。

想在自己电脑上跑，怎么用才划算

对普通开发者来说，这件事真正的价值不在排名，在可选性。以前想在本地跑一个能干的编程智能体，体积和机器配置两道坎就劝退大半人，如今 3.6 GB 这个量级，一台带独显的游戏本、一台大内存的 Mac，都有机会试试。

几类活儿适合交给它：改动范围清楚的重构、批量补测试、从日志里翻原因、给老项目补文档注释。这些活儿对延迟不敏感，对准确率有要求，正好是本地模型吃得最顺的地方。

有几处坑得提前知道。一是别拿它做实时补全，七十多分钟的响应速度能把人逼疯，那种活儿交给云端小模型更合适。二是别只看体积挑量化版本，同样的 4B 底座，均匀量化和带重要性矩阵的量化，出的活差着两道题。三是提示词和工具调用链路要当主角对待，这次的成绩里，修模板、调提示词、改工具回路出的力不比量化小。

最实在的验证办法，是从自家仓库里翻出十到二十个已经修过的 bug，原样喂给它跑一遍。跑分榜上是别人的题，自己的题才有答案。

一叶知秋，从 3.6 GB 这个数字能看出的趋势是：能干的编程智能体正在从云端下到本地。但趋势兑不兑现，还得看这些亮眼数字离开作者的机器之后，在别人的复现里能剩多少。真有本事，就不怕多几轮大浪淘沙。

原文链接：
https://x.com/jurlycat/status/2102229154905391262