7.2GB 跑 27B 大模型！三进制极限压缩，普通显卡能用来跑 Agent 吗？

一个 27B 参数的大模型，如果把 GGUF 权重压缩到只有 7.2GB，它到底还剩下多少能力？

这是我测试 Bonsai 2 之后最想搞清楚的问题。

因为单从体积来看，它确实非常夸张。

这次参与测试的两个模型分别是：

也就是说，Bonsai 2 的权重体积只有 Qwen Q4_K_M 的大约 42%，运行时显存占用也接近减半。

但模型压缩真正有价值的前提，不是“能装进去”。

而是：

装进去以后，它还能不能真正完成任务？

所以这次测试，我没有把重点放在显存和 Token 速度上，而是把两个模型直接扔进 Agent 工作流。

让它们自己读代码、分析问题、修改文件、运行测试、处理失败，然后决定什么时候结束任务。

我们到底在测什么？

测试环境尽量保持一致。

两个模型分别绑定独立 GPU 和独立 llama-server 端口，上下文统一为 131072，采样参数统一为：

temperature = 1.0
top_p      = 0.95
top_k      = 20
min_p      = 0
Thinking   = Medium

Agent 层统一使用 Pi CLI，并关闭额外 skills、extensions 和 prompt templates，只开放标准的读文件、修改代码、执行命令等开发工具。

测试不是简单问答，而是分成两个阶段。

第一阶段先确认模型的基础能力有没有因为极限量化出现明显损失。

第二阶段再把它们放进真正的代码项目里，看 Agent 能不能稳定把任务做完。

第一阶段：7.2GB 并没有出现明显的“智力塌缩”

前四道题分别覆盖：

逻辑推理、知识理解、严格格式遵循，以及约 90K Token 的长上下文信息定位。

结果非常整齐：

尤其是 L1。

实际输入长度达到了 90,610 Tokens，真正需要的信息被埋在大量相似内容中。两个模型最终都成功找到了目标，没有在长上下文里迷失。

这至少说明一件事：

PQ2_0 这种极端压缩，并没有让 Bonsai 2 在基础推理、信息召回和长上下文任务上直接崩掉。

如果测试到这里结束，我甚至很容易得到一个结论：

7.2GB 和 17.1GB，好像没什么明显差别。

但真正有意思的事情，是从代码 Agent 开始发生的。

一进入 Agent，两个模型开始表现出完全不同的性格

代码任务和普通问答最大的区别是：

模型不是给出一个答案就结束。

它必须经历：

理解项目
→ 阅读文件
→ 判断问题
→ 修改代码
→ 执行测试
→ 根据结果继续调整
→ 判断任务是否完成

这时候，“会不会做”只是其中一部分。

另外一个非常重要的能力是：

什么时候应该停。

第一阶段很快就暴露出了这个问题。

C1 是计费引擎 Bug 修复。Bonsai 成功完成，而 Qwen 当时因为工具执行异常最终撞上超时。

C2 则反过来：Qwen 很快完成，而 Bonsai 的代码其实已经接近正确，但它继续检查、继续执行，最终超过了严格的 Agent Step 上限。Phase 1 的 C1、C2、P1、A1 已经明显表现出两个模型不同的收敛方式。

这时候我意识到：

TIMEOUT 并不等于不会做。

至少要区分两种情况：

一种是真的没找到正确方案。

另一种是方案已经正确，但模型不知道自己什么时候应该收工。

因此第二阶段，我把复杂任务单独重新跑了一遍。

Phase 2：把 Agent Budget 放宽以后发生了什么？

第二阶段只重新测试四个真实代码任务：

C1：计费引擎 Bug 修复
C2：跨文件订单聚合重构
P1：CSV 流式导出服务
A1：并发库存扣减 API

并根据任务复杂度，把最大 Agent Steps 放宽到 20～30 步。

最终结果：

这里真正值得看的，不是简单的 3:4。

而是它们怎么完成任务。

C1：代码都能修，但路径差得非常大

C1 里面有三个典型 Bug。

一个是把 float 转换为 Decimal 导致货币精度问题；一个是折扣和计税顺序错误；还有一个是退款边界判断错误，导致全额退款被拒绝。

Qwen 的处理非常直接。

它大致走的是：

读代码
→ 验证判断
→ 修改三处问题
→ pytest
→ PASS

总共只用了 5 Steps，39.2 秒。

而 Bonsai 用了 13 Steps，159.6 秒。

它也正确找到了问题，但修改以后还继续检查 Decimal 的舍入行为、构造新的边界用例、再次执行验证，最终才结束。

两边最终代码都正确。

区别不是能力有没有。

而是：

Qwen 在寻找“任务完成条件”，Bonsai 在不断寻找“还有没有可能出问题”。

这两个目标其实并不完全一样。

P1：今天最能说明问题的一道题

P1 是一个 CSV 流式导出服务。

任务涉及 HTTP 服务、流式输出、CSV 转义以及客户端连接生命周期等问题。

Qwen 只用了：

7 Steps
66.8 秒
406 Thinking Tokens

直接 PASS。

而 Bonsai 发生了一件非常典型的事情。

它完成主要功能以后，没有结束。

它继续启动服务、继续验证输出、继续测试边界、继续确认 CSV 行为。

最终：

26 / 25 Steps
551.6 秒
11,383 Thinking Tokens

因为超过了 25 步限制，Benchmark 按规则必须记录：

TIMEOUT

但是测试结束以后，再运行 hidden validator：

代码能够通过。

也就是说：

Bonsai 把题做对了，却因为继续工作，把一个原本应该成功的任务变成了 TIMEOUT。

这一题几乎把 Bonsai 当前最明显的 Agent 问题完整暴露了出来。

A1：复杂任务它不是不会做

A1 是整个测试中最复杂的一题。

它需要处理 SQLite 并发库存扣减，既不能出现负库存，又需要应对高竞争状态下的锁冲突。

第一阶段严格限制 Agent Steps 时，两个模型都没完成。

第二阶段放宽到 30 Steps 后：

Qwen：
15 Steps
175.7 秒
PASS

Bonsai：
19 Steps
226.3 秒
PASS

Qwen 使用事务和重试处理并发问题。

Bonsai 则进一步采用了原子条件更新等方式保证库存不会被扣成负数，最终两边都通过并发验证。

这道题很重要。

因为它说明：

第一阶段的 TIMEOUT，并不能简单解释成“这个模型没有能力做复杂 Agent”。

当任务预算合理以后，Bonsai 确实能够完成这种多步骤工程任务。

真正拉开差距的，是 Thinking Token

如果只看最后生成的代码，很多任务其实看不出那么大的区别。

但把整个 Phase 2 的 Thinking Token 统计出来以后，情况一下变得非常清楚。

四道复杂任务累计：

Bonsai 2
22,831 Thinking Tokens

Qwen3.8
3,568 Thinking Tokens

Bonsai 大约是 Qwen 的：

6.4 倍

这个数字基本解释了前面所有现象。

Bonsai 并不是生成速度慢。

恰恰相反，在很多纯 Decode 场景里，它的生成速度甚至更高。

问题是它生成得太多了。

以 C1 为例：

Bonsai：4372 Thinking Tokens
Qwen：   299 Thinking Tokens

P1 更夸张：

Bonsai：11383
Qwen：     406

所以 Agent 的实际效率不能只看：

tokens / second

还要看：

完成同一个任务
到底需要生成多少 Token
到底需要多少 Agent Steps

一个模型即使每秒生成得更快，如果为了完成同一个任务需要多思考五六倍，最终端到端耗时依然可能更长。

所以 Bonsai 到底损失了什么？

这次测试下来，我觉得一个很容易产生的误解可以先排除：

7.2GB 并没有把一个 27B 模型直接压成“只能聊天的小模型”。

至少在这套测试中，Bonsai 能完成：

长上下文信息检索、逻辑任务、代码 Debug、跨文件重构、API 开发以及并发数据处理。

它真正明显落后于 Qwen 的地方，是 Agent 收敛能力。

从完整 Session 可以看到，Bonsai 很喜欢自我审查。

代码修改完成以后，它经常不会马上结束，而是继续构造测试、验证假设、寻找潜在边界问题。

Qwen 则明显更加“任务导向”。

找到问题、修改、测试。

如果测试通过，而且需求已经满足，就结束。

报告里统计出的两种行为模式也非常明显：Bonsai 更倾向于高密度自检与反证，而 Qwen 则倾向于利用工具反馈快速推进任务。

这并不能简单理解成谁“更聪明”。

它更像是两种不同的 Agent 行为策略。

7.2GB 真正带来的价值是什么？

Bonsai 最吸引人的地方依然是体积。

Qwen3.8-27B Q4_K_M 的 GGUF 大约 17.1GB。

Bonsai PQ2_0 只有 7.2GB。

权重体积减少接近 58%。

这意味着 27B 级模型的部署门槛被明显降低。

不过这里必须强调：

7.2GB 模型文件，不等于只需要 7.2GB 显存。

实际运行还包括：

KV Cache
Context Length
运行时 Buffer
Batch
后端本身的显存开销

本次测试中 Bonsai 的实际运行显存大约是 12.2GB，而 Qwen 约 23.8GB。

所以它真正改变的是：

以前需要接近 24GB 显存才能舒服运行的 27B 级模型，现在开始有机会进入 12GB～16GB 这一档消费级设备。

这可能比单纯“跑分提升几个百分点”更有现实意义。

最终结论：7.2GB 保住了能力，但还没有保住 Agent 效率

如果只看前四个基础任务，我可能会说：

Bonsai 和 Qwen 的差距并不明显。

如果只看第一阶段的 TIMEOUT，又很容易得出另一个结论：

Bonsai 做复杂 Agent 不稳定。

但把第二阶段完整跑完，再结合 Agent Session 和 Thinking Token 数据以后，更准确的结论是：

Bonsai 2 并没有表现出明显的“极端量化导致复杂能力消失”。

它能理解任务，也能写出正确代码。

真正明显的代价，是：

更多 Thinking
更多 Agent Steps
更长执行路径
更高的超时风险
更弱的停止判断

而 Qwen3.8 Q4_K_M 的优势，则不是“它能做而 Bonsai 不能做”。

而是：

它更容易在正确的时间结束任务。

这对 Agent 非常重要。

因为真正进入生产环境以后，每一次无意义的继续思考、每一次重复测试、每一次多余工具调用，最终都会转化成：

Token、延迟、算力和失败概率。

所以这次测试让我对 Bonsai 2 的认识发生了一个变化。

它当前最值得解决的问题，可能已经不是：

“7.2GB 以后还够不够聪明？”

而是：

“已经足够聪明以后，怎么让它少想一点，并且知道什么时候该停？”

这可能才是三进制大模型真正走进 Agent 场景之后，下一阶段最值得关注的问题。

测试边界

最后需要说明，这并不是一个能够代表所有场景的通用 Benchmark。

测试使用固定模型量化版本、固定 Medium Thinking、固定 Pi CLI Agent、固定任务集和固定硬件环境。

因此这些数据更适合回答：

在相同 Agent 框架和接近相同配置下，这两个模型完成真实任务时表现出了什么差异？

而不是简单得出“哪个模型绝对更强”。

但至少从这次测试来看，一个结论已经比较清楚：

7.2GB 的 27B，不只是能跑。

它是真的能干活。

只是目前，它还需要学会一件 Agent 非常重要的能力：

做完以后，停下来。

About The Author

玩客

See author's posts