加州初创团队PrismML在2026年9月17日正式发布Ternary Bonsai 2 27B。这是一款基于阿里Qwen3.8 27B底座深度改造的离散三元权重模型,研发团队把全精度需要消耗54GB显存的庞然大物,硬生生压缩至5.9GB的极小体积,不仅能在消费级显卡上跑出143 token/s的高吞吐,还宣称守住了基模98.2%的综合跑分。

这项技术让很多苦于显存不足的端侧开发者眼前一亮,但发布会上的跑分表掩盖了低比特量化的真正硬伤。在复杂的真实工具调用与代码执行环境中,微小的位宽精简引发了不可逆的误差放大,纸面上的高智能密度距离工业级落地仍有一道显存之外的鸿沟。

5.9GB背后的显存算术题

端侧运行大模型最大的现实壁垒从来不是算力,而是显存与内存带宽。传统的27B级别全精度模型动辄需要50GB以上显存,直接将24GB显存的RTX 4090或RTX 5090阻隔在外。行业长期依赖4-bit后量化进行折中,而进一步下探到1-bit或2-bit往往伴随语言组织瓦解或逻辑混乱。

跑满长上下文与对齐槽位后,实际显存占用直逼消费级显卡上限
跑满长上下文与对齐槽位后,实际显存占用直逼消费级显卡上限

Ternary Bonsai 2 27B采用离散的三元权重,将每个参数限制在{-1, 0, +1}三个状态。三元权重的理论信息下限为log2(3)约1.585 bit,PrismML通过每96个权重共享一个FP16缩放因子,加上索引元数据,最终交出了1.76 bpw的有效位宽。在官方提供的数据中,该模型在RTX 5090上达到143 token/s,在苹果M5 Max芯片上也有46.8 token/s的表现,功耗仅为0.714 mWh/token。

端侧部署的真实显存分层拆解 静态存储 官方TQ1_0 GGUF权重文件 约 5.95 GB 执行槽位 Q2_0内存对齐展开与必要缓冲区 约 7.21 GB 运行时增量 外置视觉投影模块 + 262K长上下文KV Cache 动态吞噬显存 注:宣称的5.9GB仅包含基础语言模型权重,不代表多模态长文本真实运行时占用。

宣传中的5.9GB不能直接等同于设备可用空间。官方发布的GGUF格式中,TQ1_0权重虽然只有5.95GB,但如果要以硬件直接对齐执行的Q2_0槽位加载,体积立刻膨胀到7.21GB。如果要启用多模态功能,还得额外加载外置的视觉投影模块。一旦把上下文拉长,庞大的KV Cache会迅速将消费级显卡的余量挤压殆尽。

  • 提醒.不要把静态权重文件大小当成硬件门槛,实际跑满长上下文与图像输入时,单卡显存水位依然吃紧。

跑分表的胜利与真实环境的雪崩

在评估标准上,官方给出了极具说服力的数字。综合涵盖数学AIME 2026、代码LiveCodeBench与常识推理的测试集,Ternary Bonsai 2 27B拿到了83.9的均分,与基模的85.4相比,能力保留率高达98.2%。但这份漂亮成绩单的前提,是严格限定在EvalScope和vLLM环境下开启思考模式测得。

单步高分无法掩盖三元精度缺失在长链路调用中引发的连锁崩溃(示意图)
单步高分无法掩盖三元精度缺失在长链路调用中引发的连锁崩溃(示意图)

只要离开这种标准化的问答环境,三元模型的底层脆弱性就会暴露无遗。

离散量化守住了单步推理的均分,却在长链路反馈中丢掉了容错率。

在社区进行的Terminal-Bench 2.0测试中,面对89项复杂的终端多步工具调用任务,该模型的通关率骤降至7.9%。横向对比来看,参数量接近的Qwen3.6-35B-A3B获得了24.3%的成功率,甚至连原生较小尺寸的Qwen3.5-9B也跑出了9.2%的成绩。

工具调用真实通关率横向对照(Terminal-Bench 2.0) Qwen3.6-35B-A3B 24.3% Qwen3.5-9B(原生基模) 9.2% Ternary Bonsai 2 27B 7.9% 多步Agent任务中,单步小幅输出偏差会在长链路反馈中呈指数放大,最终导致任务中断。

多步智能体与单次代码生成有着本质区别。在这类任务中,模型需要调用终端命令、解析报错并自主修复。三元量化强行舍弃了大部分连续精度,导致微弱的注意力权重被截断。在单轮输出中这种扰动尚能被掩饰,一旦进入多步循环,前序步骤产生的细微格式偏差或参数理解错误就会快速传导,引发系统性的执行崩溃。

开源权重背后的工程壁垒

PrismML宣布以Apache 2.0协议开源模型权重,但开源社区很快指出了其中的局限。项目虽然公开了网络最终产物,却并未公开将FP16全精度蒸馏并重构至1.76 bpw的核心训练流水线。这种不透明让外部开发者难以把同样的极低位宽技术复现到其他开源基座上。

开源权重虽然开放获取,但高效运行仍被专有硬件内核锁死(示意图)
开源权重虽然开放获取,但高效运行仍被专有硬件内核锁死(示意图)

运行环境的兼容性同样存在断层。第三方复现验证显示,该模型的高效推理依赖PrismML自行修改的特定llama.cpp私有分支内核。如果脱离该分支使用主流的推理引擎,推理效率与输出质量都会出现折扣。这说明三元量化在大规模走向通用软件栈之前,依然被严密包裹在专有软硬件调优的保护壳内。

  • 结论.对于需要长链路自主作业的智能体项目,原生小参数模型配合适度量化,目前依然比激进压缩的三元大模型更稳健。

把27B模型塞进5.9GB是一次了不起的压缩尝试,它证明了三元网络在保留语言表层感知上的潜力。但在真正的生产环境里,决定工具可用性的往往不是平均准确率,而是长调用链条中的最差表现。在解决极低位宽引发的多步错误雪崩之前,三元模型依然更适合扮演高吞吐的单轮查询助手,而非独当一面的全自动管家。