27B大模型塞进5.9GB？开源模型Ternary Bonsai 2-27B发布实测
开源模型Ternary Bonsai 2-27B发布，将Qwen3.8 27B压至5.9GB，保留98.2%基准性能，262K上下文与多模态能力不变，12GB显卡即可本地运行，开源权重采用Apache 2.0协议。
一、从95%到98.2%：一次“压缩”的实质性跃迁
2026年7月，PrismML发布了第一代Bonsai 27B，证明27B级多模态模型可以被压缩到足够小，在手机上流畅运行。两个月后，开源模型Ternary Bonsai 2-27B正式发布，基于Qwen3.8 27B重新构建，将聚合基准性能保留率从上一代的95%提升至98.2%。
这个数字变化的含义，远超表面上的3.2个百分点。在低比特量化的语境里，95%意味着“能用但有损”，而98.2%意味着“几乎感觉不到差异”——尤其是当损失的3.2%中，大部分集中在模型对提示词的细微响应风格上，而非推理能力本身。
PrismML在这款开源模型Ternary Bonsai 2-27B中采用的是一套端到端的三值量化方案：每一个语言权重只取{−1, 0, +1}三个值，配合每128个权重共享一个FP16缩放因子，实现1.76有效比特/权重的存储效率。整个语言模型——嵌入层、注意力投影、MLP投影、语言模型头——全部使用三值表示，没有任何“高精度后门”。
这意味着什么？开源模型Ternary Bonsai 2-27B的发布，标志着超低比特量化从“极端实验”迈入了“工程可交付”的阶段。
二、基准测试：强在哪，弱在哪
整体表现
在覆盖推理、数学、编程、指令跟随、视觉理解和工具调用的15项基准测试中，Ternary Bonsai 2-27B取得83.9的综合成绩，对比全精度Qwen3.8 27B的85.4，保留率98.2%。
分项透视
真正值得关注的是能力保留的“形状”，而非总分：
| 能力维度 | 全精度FP16 | Ternary 27B | 保留率 |
|---|---|---|---|
| 数学推理 | 95.33 | 93.40 | 98.0% |
| 代码生成 | 88.74 | 85.96 | 96.9% |
| 智能体/工具调用 | 80.00 | 74.01 | 92.5% |
| 知识理解 | 83.15 | 76.96 | 92.6% |
| 指令跟随 | 78.47 | 71.77 | 91.5% |
| 视觉理解 | 72.61 | 65.19 | 89.8% |
| 综合 | 85.07 | 80.49 | 94.6% |
注：上表数据为第一代Ternary Bonsai 27B的分项基准结果，用于展示能力保留分布的特征。Bonsai 2的整体保留率已提升至98.2%，分项数据以官方白皮书为准。
关键洞察藏在分项数据里：数学和编程能力几乎未受压缩影响，而指令跟随和视觉理解则出现了相对明显的下降。这不是偶然——三元量化在面对需要“精确响应提示词”的任务时，天然比面对“需要结构化推理”的任务更容易出现偏差。数学题有对错，提示词跟随有风格。
横向对比
| 模型 | 每权重比特 | 体积 | 综合得分 | 保留率 |
|---|---|---|---|---|
| Gemma-4-31B QAT (4-bit) | 6.0 | 23.3 GB | 83.41 | 98.0% |
| Gemma-4-31B Q2_K_XL (2-bit) | 3.0 | 11.8 GB | 73.31 | 86.2% |
| Ternary Bonsai 27B | 1.71 | 5.9 GB | 80.49 | 94.6% |
| 1-bit Bonsai 27B | 1.125 | 3.9 GB | 76.11 | 89.5% |
Ternary Bonsai 27B以不到Gemma-4-31B QAT四分之一的体积，取得了接近其94%的得分。而对比同为基础模型压缩的Q2_K_XL版本，它在体积减半的情况下领先超过7分。
独立验证数据
根据benchlm.ai在2026年9月17日发布的快照，Ternary Bonsai 2-27B在BFCL v3工具调用基准上以74.9%领跑公开榜单，在CharXiv视觉理解基准上以80.0%同样领先，在A-OKVQA视觉问答基准上取得86.8%的成绩。
这些独立数据说明：开源模型Ternary Bonsai 2-27B的发布，不只是模型卡上的自报数据好看，第三方评估同样支持其能力主张。
三、硬件适配：12GB显卡的“甜蜜点”
实测反馈
一位拥有RTX 3060（12GB显存）的用户的实测记录，可能是目前最有说服力的部署参考：
“整个27B模型占用约7GB显存，无需任何卸载到系统内存。在100K上下文窗口下，生成速度稳定在25-27 tok/s。它读取了一张真实的暖通空调工程图纸并正确描述了内容，还能理解工程代码库中的专业逻辑。”
这意味着开源模型Ternary Bonsai 2-27B发布后，一个被长期困在“只能跑14B以下模型”的消费级显卡用户，第一次获得了接近云端中等模型的本地推理体验。
各平台推理速度
| 硬件平台 | 推理速度 |
|---|---|
| RTX 5090 | 最高143 tok/s |
| Apple M5 Max | 约47 tok/s |
| Apple M5 Pro | 约26 tok/s |
| RTX 3060 (12GB) | 25-27 tok/s（100K上下文） |
PrismML官方数据同时披露了能效表现：RTX 5090上每token仅消耗0.582mWh，RTX 4090上为0.714mWh。以当前消费级GPU的负载水平来看，本地运行一个27B级模型正在变得比想象中“安静”。
但需注意，部分独立测试显示实际吞吐率波动较大，范围在7-44 tok/s之间，且Mac平台上的速度受MLX框架版本影响明显。
四、部署路径：从下载到运行的完整链路
三种主流方式
PrismML提供了三种官方部署路径：
llama.cpp（最推荐） ：模型已发布为GGUF格式，支持CUDA、Metal和CPU推理。一条命令即可启动本地服务：llama serve -hf prism-ml/Ternary-Bonsai-27B-gguf:F16。需要注意，完整的三值内核支持需要PrismML的llama.cpp分支，主线版本尚未合并。
MLX（Apple Silicon） ：PrismML为Apple MLX框架提供了专门的分支版本，包含2-bit混合注意力内核，打包权重被直接消费，不会展开回FP16。在M5 Pro笔记本上可达到约26 tok/s。
DGX Spark：社区已构建了针对NVIDIA DGX Spark的本地聊天栈，使用PrismML的llama.cpp分支配合文本UI，从HuggingFace缓存加载权重。
部署中的真实坑
社区反馈揭示了几个实际部署中容易踩到的坑：
- 不要用Q2_0_g128版本：部分用户报告该版本在加载后输出乱码，应使用Q2_g64版本。
- CPU推理性能堪忧：纯CPU环境下仅0.75 tok/s，比常规Q4_K_M量化还慢3倍以上。
- DSpark投机解码需要额外显存：该加速层在RTX 3060等12GB显卡上空间不足，但在更大显存的GPU上可带来约1.34倍的解码加速。
五、隐藏的裂缝：推理循环与长链路退化
任何关于开源模型Ternary Bonsai 2-27B发布的讨论，如果只谈优势而不触及短板，都算不上完整。
推理循环问题
多位独立测试者报告，模型在特定提示词下容易陷入推理循环——反复输出相似的思考步骤而不收敛。在Hacker News的讨论中，有用户明确指出“它大约和底层Qwen 27B一样快，但很容易卡在推理循环里”。
explainx.ai的评测文章也确认了这一点，将“至少一次明确的循环失败”列为社区反馈中的核心关切之一。
长链路工具调用的断崖
一份中文评测报告的数据更为严峻：在长链路终端工具调用场景中，Ternary Bonsai 2-27B的任务完成率降至7.9%。
这与分项基准中“智能体/工具调用92.5%保留率”形成了鲜明对比。原因在于：基准测试衡量的是单步或短链路的工具选择准确率，而实际智能体工作流往往需要连续执行十步以上的工具调用。三元量化在每一步引入的微小误差，在多步累积后会急剧放大。
传统低比特量化的对比
传统2-bit量化（如IQ2_XXS）在长链推理基准上会出现选择性崩溃：AIME26降至57.5，LiveCodeBench降至56.4。Ternary Bonsai在同样场景下保持了AIME 87.5-90.8、LiveCodeBench 82.8的水平，差距非常显著。但这并不意味着三元量化没有代价——它的代价从“特定基准的崩溃”转移到了“长链路的误差累积”。
六、为什么这件事比“又一个量化模型”更重要
从“能不能跑”到“跑得好不好”
过去两年，本地AI部署的核心矛盾是“模型太大、硬件太小”。量化技术一直在解决“能不能跑”的问题，但大多数方案在4-bit以下就会显著退化。
开源模型Ternary Bonsai 2-27B的发布，将这条线推进到了一个不同的区间：在1.76比特/权重的极端压缩下，模型的主要推理能力——数学、编程、结构化思考——基本保持完整。这意味着对于私有文档分析、代码辅助、多模态调试等场景，本地27B级模型已经具备了实际工作能力。
混合编排的可能性
PrismML在白皮书中提出的“混合编排”模式值得认真对待：本地模型处理敏感或高频任务，当遇到超出能力边界的复杂请求时，选择性地升级到云端模型。
这种架构的可行性依赖于本地模型的能力下限。如果本地模型只能做简单分类和摘要，混合编排就只是“云端模型的廉价前端”。但如果本地模型能独立完成80%以上的日常推理和工具调用任务，混合编排才真正有架构层面的价值。Ternary Bonsai 2-27B将这条能力线推到了后者。
一个被忽视的约束
然而，必须指出一个常被讨论忽视的现实：社区反馈中反复出现的推理循环问题、长链路工具调用的断崖式退化，以及PrismML自有llama.cpp分支带来的工具链锁定，构成了这款模型当前阶段的三重约束。
“近乎无损”的宣称，在基准测试的均值和实际长链路任务之间，存在一道尚未弥合的沟壑。这道沟壑的宽度，取决于应用场景对“连续性推理”的依赖程度。
七、FAQ
Q：Ternary Bonsai 2-27B和第一代Bonsai 27B有什么区别？
A：核心区别在于基础模型从Qwen3.6 27B升级为Qwen3.8 27B，聚合基准性能保留率从约95%提升至98.2%，在推理、编程、视觉和长时智能体任务上有明显改善。
Q：运行Ternary Bonsai 2-27B需要什么硬件？
A：GGUF格式的部署占用约5.9-7.2GB。RTX 3060（12GB）可完整运行，无需显存卸载。Apple Silicon Mac需要至少16GB统一内存。纯CPU推理速度极低（约0.75 tok/s），不推荐。
Q：模型支持多模态吗？
A：支持。模型包含一个4-bit量化的视觉塔组件，可处理图像和文本混合输入，支持262K token上下文窗口。
Q：和直接使用Qwen3.8 27B全精度版本相比，差距大吗？
A：在数学和编程基准上差距极小（1-2个百分点），但在指令跟随和视觉理解上差距较明显（5-8个百分点）。在长链路智能体任务中，误差累积效应可能导致更大的实际差距。
Q：社区反馈中提到的“推理循环”问题严重吗？
A：多位测试者报告了该问题，在特定提示词下模型可能反复输出相似内容。建议使用repeat-penalty参数进行缓解。对于需要连续多步推理的生产场景，建议先进行充分测试。
Q：是否必须使用PrismML的llama.cpp分支？
A：完整的三值内核支持目前需要PrismML的分支版本。主线llama.cpp对三元量化的原生支持尚在推进中。部分社区用户反馈g64版本的GGUF可以直接在KoboldCpp中运行，无需分支。
Q：模型的许可证是什么？可以用于商业项目吗？
A：Apache 2.0许可证，允许商业使用、修改和再分发。
Q：1-bit Bonsai 27B和Ternary版本怎么选？
A：1-bit版本仅3.9GB，适合手机端部署（iPhone 17 Pro级别内存预算）；Ternary版本5.9GB，性能保留率更高（95% vs 90%），适合笔记本和桌面GPU。