三值权重把 27B 模型压进 5.9GB98.2% 的性能是怎么算出来的TL;DR 速览事件PrismML 于 9-17 发布Ternary Bonsai 2 27B基于 Qwen3.8 27B 做三值量化5.9GB 体积、Apache 2.0 开源权重可下载原理差别普通量化是压窄位宽、值仍在连续尺度上三值量化让每个权重只剩−1 / 0 / 1三种状态矩阵乘更接近带符号加法位数账三态理论上需要 1.585 位加上每组存一个 FP16 缩放系数落到1.76 有效位/权重98.2% 的含义20 项基准综合83.9 vs 85.4。分项里指令遵循 82.66 反超原版 81.25但视觉 −3.05、知识推理 −2.71、agentic/工具调用 −2.17—— 损失并不均匀必须一起读的限定全部分数为厂商自测无第三方评估稳妥的说法是按其公布的 20 项基准9 月 17 日PrismML 发布了 Ternary Bonsai 2 27B。这是一家 Caltech 孵化的公司投资方包括 Khosla Ventures、Cerberus、Google 和三星。这次发布的是一个 278 亿参数的多模态模型在 5.9GB 内存占用下跑起来官方称保留了全精度版本 Qwen3.8 27B 综合基准性能的 98.2%协议是 Apache 2.0权重可以直接下载。对做端侧部署的人来说这个数字组合值得细看因为压缩比和性能保留率通常很难同时好看。上一代 Bonsai 27B 距这次只隔了两个月官方说这一版最大的变化是质量相对全精度的保留率从约 95% 提到了 98% 以上。一、三值量化改的不是位宽是状态数这是理解后面所有数字的前提。普通的低比特量化做的是压窄表示宽度从 16 位降到 8 位或 4 位每个权重能取的值变少了但取值仍在一个连续尺度上——8 位就是 256 个档位4 位就是 16 个档位。三值量化是另一种动作每个权重只剩下三个状态——正、零、负。用产品化的说法是开、关、反向开。带来的直接后果是矩阵乘法里原本的浮点乘加退化得更接近带符号加法。PrismML 关于速度和功耗的说法根源都在这里。代价也很清楚连续尺度被丢掉了。三个状态能表达的相对关系非常粗所以必须靠外挂的缩放来补偿——这就是下一节那笔位数账。二、1.76 有效位是怎么算出来的三值量化不是不存缩放而是分组存权重本身每个只占三种取值理论上 1.585 位log₂3就够。每组一个 FP16 缩放系数这一层把三值的粗粒度重新映射回可用的数值范围。两者相加落到1.76 有效位/权重。也就是说1.76 与 1.585 之间那 0.175 位的差额就是缩放系数摊到每个权重上的开销。这笔账的结果是体积278 亿参数在 1.76 位下的占用是5.9GB相比全精度缩小 9 倍以上。同时保留的能力项包括262K token 上下文和文本加图像的输入。理解这层结构之后很多工程判断就顺了分组越细缩放带来的精度越好但位宽开销越大。三值量化的调参空间主要在这里而不是在权重的取值本身。三、98.2% 是平均数分项账才是重点厂商公布的是一套 20 项基准的对比这里把七类分项抄全因为压缩带来的损失从来不是均匀分布的类别Bonsai 2 27BQwen3.8 27B差值综合20 项83.985.4−1.5保留 98.2%指令遵循82.6681.251.41唯一反超数学96.5797.06−0.49编码81.5882.17−0.59Agentic 与工具调用77.5779.74−2.17知识与推理83.9586.66−2.71视觉78.5981.64−3.05两个观察掉得最多的是视觉其次是知识推理。这符合直觉——视觉输入本身信息密度高、对数值精度更敏感被三值粗粒度削得最狠。指令遵循反而涨了。这一项通常是低比特量化里最容易被拉低的格式遵循、约束满足对权重扰动敏感这里却出现了小幅反超。官方没有解释原因从工程角度看比较可能的解释是量化后的后训练或校准数据在这个方向上有针对性。但要注意单看 1.41 不足以支撑量化能提升指令遵循的结论更稳的说法是这一项没有损失。四、为什么低比特先崩 agent这次没崩低比特量化历史上有个稳定的失效顺序编码 agent、工具调用、长程工作流最先崩。原因是这类任务的误差会复合——单步错一点看不出来几十步之后轨迹就跑偏了。所以很长一段时间里能塞进 6GB和能拿来干活是两件互斥的事。这次厂商重点强调的恰恰是这两块守住了编码 −0.59、agentic 与工具调用 −2.17。如果这个结果站得住它带来的变化是很实际的本地跑编码 agent 从不可能变成可行。6GB 以内是主流消费级显卡的入门档位也是很多笔记本能腾出来的空间。长程任务不用每一步都回云端。工具调用链、文档处理、多轮检索这类任务对延迟和隐私都敏感能在本地闭环价值很大。但这里必须把限定条件说清楚全部分数为 PrismML 自测没有第三方评估98.2% 这个结论只在它自己公布的这 20 项基准内部成立。不同任务上的表现差异官方这次没有展开哪些能力保住了、哪些被牺牲了仍然需要独立复现。引用时建议原文照抄按其公布的 20 项基准。我处理这类厂商自测数据有个固定习惯把基准名称、评测方、是否第三方复核这三项一起记下来而不是只存那个百分比。不然过一个月回头看会分不清 98.2% 和 96% 分别是哪个口径。墨衍 里我把素材、选题和分发记录攒在同一处核对口径时省掉来回翻文件。五、部署口径它在什么硬件上跑得动厂商给出的运行数据同样为自测环境吞吐NVIDIA GeForce RTX 5090CUDA143 tokens/sM5 MaxMLX覆盖 Mac / iPhone / iPad46.8 tokens/s浏览器内 WebGPU 演示可运行能效这条值得单独看在 RTX 4090 上是0.714 mWh/token比一个全精度的 8B 模型省 40%。这个对比的方向很有意思——它说明低比特不只省显存也能省电而每瓦能出多少 token在移动端和端侧常驻场景里往往比绝对性能更重要。训练用的是 Google v5 TPU。与运行环境无关但说明这条技术路线的成本结构里量化后的模型是在通用硬件上训练的。浏览器内跑 27B 是这次最有传播力的一个点。WebGPU 让打开网页就能用一个 27B成为可演示的事实。虽然按 46.8 tokens/s 这类口径推算浏览器里的交互体验仍有上限但用于演示、原型验证和隐私敏感的一次性任务已经够用。六、适用边界与取舍什么时候值得用。设备显存或统一内存在 6–8GB 区间、又需要多模态与工具调用能力的场景这个体积档位几乎没有替代品。隐私敏感场景——文档分析、本地知识处理——不离开设备这一点本身就是需求。什么时候别用。对视觉精度要求高的任务分项里掉得最多要谨慎评估。需要高保真推理链、长文档精确理解的场景建议先用自己的一批样本跑对比而不是直接看综合分。需要自己验证的三件事。第一你的任务落在哪一类。综合分 98.2% 是平均如果你的任务是视觉或深度推理分项差值才是参考值。第二长程任务的实际轨迹长度。低比特的误差复合效应在 40 步以上才会显现短任务测不出来。第三量化版与全精度的部署成本差是否值得。5.9GB 换来的可能不只是省钱也是能不能在一台普通笔记本上跑的差别——这类问题没有通用答案取决于你的设备基线。七、一句话总结这个方向把这段和昨天那批用结构化、可枚举的接口替代大模型自由发挥的做法放在一起看方向是一致的不追求单点更强而是把资源花在刀刃上。三值量化砍掉的是表示精度换回来的是27B 级能力能不能落到普通设备上这个问题的一个肯定答案。对读者最实际的动作建议是别只看 98.2%去下载权重在你自己的任务上跑一遍。厂商自测数字的作用是决定要不要花这个时间不是替代这个时间。