27B 的多模态大模型，被压到 5.9GB：一张 8G 显卡，终于能跑\"能干活\"的模型了

原创

维度攻防
维度攻防

维度攻防

2026年11月2日 10:36
安徽

去阅读

一、先把这件事说清楚

2026 年 9 月 17 日，一家叫 Prism ML 的团队（出自 Caltech）放出了 Ternary Bonsai 2 27B。

底模是阿里 8 月 14 日开源的 Qwen3.8-27B，Apache 2.0，原生 262K 上下文，支持文字 + 图像输入。

Bonsai 2 干的事只有一件：把这个模型的权重，从 FP16 的 约 54GB，压到 5.95GB。

压缩比接近 9 倍。平均每个权重只占 1.72～1.76 bit。

作为参考，你可能很熟悉的 Q4\_K\_M 量化，同样这个模型大概要 16GB 上下。也就是说，它比大家公认\"已经很省\"的 4bit 版本，又小了将近三分之二。

而它给出来的成绩单是：综合保留 98.2%。

一句话概括：以前你要 24GB 显存才敢碰的 27B，现在一张 8GB 的消费级卡就能装进去，甚至能留出空间开上下文。

二、5.9GB 到底是怎么塞进去的

先说结论：这不是\"4bit 再往下压一点\"，而是换了一套表示法——三值量化（ternary）。

每个权重不再是 16 位浮点数，而只取三个值之一：-1、0、+1。

理论上 \\log_2 3 \\approx 1.58 bit 就能存一个权重。27B 参数 × 1.58 bit，加上缩放因子等开销，落在 5.9GB，账是算得平的。

但问题来了：为什么以前的极低比特量化，一压就崩？

因为深度网络里存在\"离群值\"——极少数激活值特别大，却对结果起决定性作用。你粗暴地把所有数值都四舍五入到 {-1, 0, +1}，这些关键值就被抹平了，深层注意力矩阵直接失真。这就是很多 2bit 模型\"能说话但不能思考\"的原因。

Bonsai 2 用了三招解决：

第一招：旋转权重基底。量化之前，先做一次正交变换（块级 Hadamard 旋转），把权重矩阵\"转个角度\"。效果是把那些扎堆的极端峰值均匀摊开，离群值在数学上被消掉了。而且这个旋转是离线折叠进存储权重里的，运行时不多占一分钱空间。

第二招：三值映射 + FP16 分组缩放。主体权重全部映射到 {-1, 0, +1}，但每 128 个权重共享一个 FP16 缩放因子（g128）。这样既保住了量级信息，又把平均位宽压到 1.72 bit。

第三招：手写内核。Prism ML 给 NVIDIA CUDA 和 Apple MLX 各写了一套低比特 GEMM 内核，直接在三值位宽上运算，不解量化回高精度浮点。这一步决定了它不只是\"文件小\"，而是\"跑得动、跑得快\"。

行业里有个常见的猫腻：号称 2bit 的模型，实际位宽是 2.8bit，藏了个\"高分辨率逃生舱\"。Bonsai 这个 1.72 bit，是明码标价的。

三、98.2% 是真的吗？拆开看

这是全文最该冷静的部分。

官方给的两组基准数据（注意，他们自己公布的口径就有 20 项和 14 项两个版本，引用时得留个心）：

看这张表，能读出三个信息：

1. 数学和代码，几乎无损。 差 0.5 分，基本在噪声范围内。LiveCodeBench 上甚至打平（90.07 vs 90.05），AIME26 上压缩版还高了 1.25 分（这种小分差别当真，但至少说明没退化）。

2. 知识和推理掉了 2.7 分，视觉掉了 3 分。 这是真正的代价。视觉模块是单独一个 0.63GB 的 mmproj 文件解耦挂载的，恰恰是三元化最不友好的部分——视觉特征分布更连续，压成三值损失最大。

3. \"综合 98.2%\" 是个平均值，而平均值会藏东西。 如果拿数学和代码撑起来的综合分去推\"什么都能干\"，就要出问题。做截图理解、长链条工具调用、复杂 Agent 编排的场景，必须自己实测。

还有一个必须说的前提：所有分数都是厂商自报，目前没有独立的第三方复现。Hugging Face 上 GGUF 文件下载量已经到 358 万次（截至 9 月底），跑的人很多，但系统性的独立评测还没出来。

四、速度：这才是\"能用\"的分水岭

压缩模型最怕的不是\"降智\"，而是\"降速\"——省了显存，换来一个字一个字往外挤，等于没用。

官方给的端到端解码速度（batch size = 1）：

• RTX 5090：约 143 token/s

• RTX 4090：约 96.7 token/s

• Apple M5 Max：约 46.8 token/s

• Apple M5 Pro：约 27.7 token/s

143 token/s 是什么概念？比大多数人正常阅读速度快得多，你根本感知不到\"这是个压缩模型\"。

46.8 token/s 在笔记本上，也算流畅的交互体验。这些数字不是论文里那种\"理论峰值\"，是实打实的解码吞吐。

另外还报了个能耗数据：RTX 4090 上 0.714 mWh/token，官方说比一个 FP16 的 8B 模型还省 40%。这条如果成立，意味着\"用更大的模型反而更省电\"——三值运算把大量乘法变成了加法和跳过，这是架构层面的红利。

五、想上手？三条路，坑我先说

路线 A：Mac 用户（最省事）走 MLX 2-bit 包，LM Studio 里直接能搜到。不用编译，不用折腾，24GB 统一内存的 Mac 就很宽裕。

路线 B：N 卡用户（要注意）下载 GGUF 的 PTQ1\_0（5.95GB，1.75 bit）或 PQ2\_0（7.21GB，2.13 bit）。

这里有个大坑：标准版 llama.cpp 加载不了这个格式，必须用 Prism ML 自己 fork 的那一版。 这是目前最劝退的一步，也是很多\"下载完发现跑不起来\"的原因。

路线 C：只想试试（零成本）官方有个 WebGPU 浏览器 Demo，不装任何东西就能玩。

配置建议：

• 8GB 显存：PTQ1\_0，上下文先开 8K～16K

• 16GB 显存：PQ2\_0，上下文可以大方点开到 32K

• 追求长文档：注意 KV cache 和循环状态会随上下文线性吃内存，262K 是架构上限，不是你的机器上限

六、泼三盆冷水

第一盆：它绑定私有运行时。格式不通用、内核不开源到主流栈，这意味着你被锁在 Prism ML 的节奏里。他们不更新，你就卡在那儿。对一个想长期用的生产环境，这是实打实的风险。

第二盆：中文能力没有官方数据。所有公布的基准都是英文语境。繁中、简中表现如何，官方一个字没提。如果你是拿它做中文内容处理，做好\"自己当小白鼠\"的准备。

第三盆：Agent 场景要谨慎。工具调用掉 2.17 分，在单轮对话里无感，但在十几步的长链条 Agent 里，误差会累积放大。做 computer-use、复杂工具图的，务必先用自己真实的 workflow 跑一遍再决定。

七、我的判断

第一代 Bonsai 是 3.9GB，保留 95%，当时的评价是\"惊艳但不敢用\"。 两个月后的第二代，5.93GB，保留 98.2%，评价变成了\"好像没什么理由不用\"。

这个转变很关键。 它说明压缩技术已经越过了那条线——从一个\"技术奇观\"，变成了一个\"默认选项\"。

过去两年，本地部署的核心矛盾是\"能不能跑起来\"；现在这个矛盾正在变成\"用哪种打包方式最省事\"。

而 27B 装进 5.9GB 这件事，真正的价值不在参数，在于它把多模态 + 262K 上下文 + 可商用（Apache 2.0）这三样东西，一起塞进了一台普通笔记本。

对做本地知识库的人来说，这意味着：合同、病历、判决书、内部文档，全程不出本机，还能带图理解，还不用付 token 费。

这才是\"端侧 AI\"该有的样子——不是把云端模型缩小一点塞进手机当玩具，而是在你的机器上，跑一个真的能干活的模型。

至于那 1.8% 的差距？ 用九分之一的体积换回来，我觉得这笔账，划算。