从53.80GB到5.93GB，改变的是部署门槛
PrismML发布的Ternary Bonsai 2 27B保留了Qwen3.8 27B的架构，参数量为27.36B，却把语言模型权重从FP16的53.80GB压到5.93GB。按照发布方的说法，这使它可以在16GB笔记本或单张24GB显卡上运行。对于过去需要更大显存才能装载的27B级模型，这不是单纯的文件瘦身，而是本地部署边界的一次移动。
压缩的核心是把绝大多数权重映射为-1、0、+1三个值。每128个权重共享一个FP16缩放因子，只有循环状态路径和归一化权重等极少数参数保留更高精度，保留部分约占总参数的0.0976%。三值本身只需约1.585比特，再加上分摊到每组权重上的缩放因子，理论存储约为1.71比特每权重，实际PTQ1_0打包后为1.76比特每权重、5.93GB。另一种PQ2_0格式为7.25GB，牺牲空间换取更容易的解包。
三值权重并不等于把模型简单四舍五入
低比特表示会放大异常值带来的误差，因此Bonsai 2在量化前对权重做了块级Hadamard旋转，块大小为1024。这个正交变换不会改变整体能量，却能把集中在少数位置的峰值分散开，再配合运行时对激活执行匹配变换，让三值权重的近似更容易维持原有计算结果。旋转被折叠进离线存储的权重，不增加额外比特，但白皮书仍把batch-1场景下的旋转开销列为需要面对的问题。
这也解释了为什么5.93GB不是一个脱离软件的数字。模型需要PrismML的llama.cpp fork或MLX运行时，原版llama.cpp无法直接加载。专用打包格式和计算内核必须一起工作，才能把“低比特存储”转换成实际推理速度；否则，节省下来的显存可能会被解包、旋转和其他运行时成本部分抵消。
98.2%的平均分，掩盖了代理任务的断层
PrismML报告称，Bonsai 2在20项基准上的平均成绩达到父模型的98.2%。这说明三值量化并没有把模型退化成只能完成简单问答的版本，部分能力甚至接近原始模型。材料给出的测试是在thinking模式和较高推理强度下进行的，因此这个百分比首先是特定评测设置下的结果，而不是所有工作负载的通行证。
一旦任务需要持续修改代码、调用工具并维持较长的中间状态，差距就明显扩大。SWE-bench Verified中，Bonsai 2为60.8，Qwen3.8 27B为80.6；Terminal-Bench 2.1中则是52.8对69.7，LiveCodeBench v6为70.05对90.07。也就是说，它更像是把通用推理能力搬到了本地，而不是在不牺牲可靠性的情况下复制了原模型的长程软件工程能力。
“能装下”之后，工程团队要重新算一遍预算
对部署团队而言，5.93GB只能回答“语言模型权重能否装载”，不能回答“一个完整应用是否能稳定运行”。KV缓存、激活和运行时还要占用额外内存，262K上下文并不会免费获得；如果输入图像，还要额外加载约0.63GB的视觉塔。单张24GB显卡能够启动模型，与它能否在长上下文、视觉输入和工具调用场景中持续工作，是两个不同的判断。
因此，适合把Bonsai 2纳入评估的场景，是本地推理、单卡应用和对云端调用有成本或隐私要求的工具，而不是只看权重大小就替换现有编码代理。实际验证至少应分别记录权重格式、可用上下文长度、KV缓存余量、解码速度和长任务成功率。材料中的速度和质量结果来自PrismML自己的测试，且三值分配规则尚未公开，是否能进入上游llama.cpp也仍是开放问题。对技术负责人来说，最稳妥的结论是：它已经把“装不下”变成了“可以开始测”，但还没有把“可运行”证明成“可依赖”。