HuggingFace镜像/Ternary-Bonsai-27B-gguf
模型介绍文件和版本分析

Bonsai

Prism ML 官网  |  白皮书  |  演示与示例  |  Discord

Ternary Bonsai 27B — GGUF

基于三元Transformer权重实现完整的27B级别推理能力,适用于llama.cpp(支持CUDA、Metal、CPU)

约9.4倍小于FP16(理想情况下)| 保留95% FP16智能 | 在Apple M5 Pro笔记本电脑上约26 tok/s

亮点

  • 约7.2 GB部署占用空间(从FP16的约54 GB降低)——在标准笔记本电脑或单GPU上实现完整的27B级别推理
  • 保留95%的FP16智能:在15项思维模式基准测试中平均得分为80.49——比传统IQ2_XXS版本(72.73)得分更高,而占用空间不到其的三分之二
  • 在低于4位的范围内仍保持思考、推理和智能体行为,传统低位表示在此范围内会失效:数学能力接近全精度(93.40,仅差2分),代码能力85.96,智能体工具使用能力74.01
  • 端到端三元语言权重,覆盖嵌入层、注意力投影层、MLP投影层和LM头,真正实现每权重1.71位——没有以低位标签为幌子的高精度"逃生舱";视觉塔以紧凑的4位HQQ格式提供
  • 262K令牌上下文在设备端运行,通过Qwen3.6-27B混合注意力架构(约75%线性注意力)和4位KV缓存量化保持实用性
  • GGUF Q2_0_g128格式,为llama.cpp(CUDA、Metal)配备自定义2位混合注意力内核——打包权重直接使用,无需扩展回FP16
  • 附带DSpark推测解码引导层,针对Bonsai 27B目标模型训练——在CUDA服务路径上实现无损1.34倍解码加速
  • MLX版本:另提供Bonsai-27B-mlx-2bit,适用于原生Apple Silicon推理
  • 1位版本:面向手机级别的运行点(约3.9 GB),可在iPhone 17 Pro Max上运行,以GGUF格式发布为Bonsai-27B-gguf

资源

  • 白皮书 — 完整方法论、基准测试和测量说明
  • 演示与示例 — Bonsai 的部署、基准测试和集成指南
  • 低比特内核:llama.cpp 分支(CUDA + Metal)· MLX 分支(Apple Silicon)· mlx-swift 分支(iOS/macOS)
  • Discord — 加入社区获取支持、参与讨论和获取更新

模型概述

项目规格说明
基础模型基于 Qwen3.6-27B 衍生,为 270 亿参数混合注意力因果语言模型(架构未作改动)
参数数量~273 亿三元语言权重(64 个块中约 248 亿主干参数 + 约 25 亿嵌入/LM 头参数)+ ~4.6 亿视觉塔(27 个块)
架构混合注意力(约 75% 线性注意力 / 约 25% 全注意力)、SwiGLU MLP、RoPE、RMSNorm
上下文长度262K tokens(设备端支持全上下文,由以线性注意力为主的主干实现)
KV 缓存近乎无损的 4 比特 KV 量化;混合主干仅在 64 层中的 16 层使用全注意力缓存(262K 窗口下约 4.3 GB)
权重格式GGUF Q2_0_g128:2 比特槽位中的 {−1, 0, +1} 权重,采用 FP16 分组缩放
低比特覆盖范围嵌入层、注意力投影层、MLP 投影层、LM 头
视觉塔HQQ 4 比特;可选 ~0.63 GB mmproj 数据包(Q8_0 容器),仅在输入图像时加载
部署大小~7.2 GB(理想情况下为 5.9 GB,即 1.71 比特/权重;详见下文)
加速提供 DSpark 推测解码草稿层
后端支持llama.cpp(CUDA、Metal、CPU)
许可证Apache 2.0

权重表示:Q2_0_g128

每个权重取值为 {−1, 0, +1},每 128 个权重共享一个 FP16 缩放因子。一个三值携带 log₂3 ≈ 1.585 比特的信息,因此有效存储成本为 约 1.71 比特/权重(三值编码 + 在 128 个权重上分摊的 16 比特缩放因子)—— 与 FP16 相比,理想情况下减少约 9.4 倍。

与二进制格式相比,额外的零状态提供了更具表现力的权重集合,并能更好地恢复全精度模型的性能,这使得三值成为 Bonsai 27B 系列的注重质量的操作点。

内存需求

格式实际比特/权重理想大小部署大小理想压缩比
FP16(基准)16.0~54 GB—1.0x
GGUF Q2_0_g1281.715.9 GB~7.2 GB~9.4x

当前的内核将每个三值存储在 2 比特的槽位中(部署时为 2.125 比特/权重),因此在原生三值内核缩小差距之前,部署时的内存占用高于该表示的信息论最小值。部署大小仅描述语言模型本身——这是文本推理时必须驻留的唯一组件;一小部分可忽略的归一化和缩放参数仍保留较高精度。

与传统的低位构建不同——它们宣传的标签低估了其真实平均位宽(一个广泛使用的 Qwen3.6-27B“2 比特”构建实际上是 2.8 比特/权重,大小为 9.4 GB)——Bonsai 表示的位宽与其名称相符。

附带组件

语言模型附带两个可选组件(磁盘大小):

组件打包方式大小驻留情况
语言模型2 比特 g128 槽位 (Q2_0)7.17 GB常驻
DSpark 草稿器Q4_1(默认)1.95 GB可选 — 用于投机解码
DSpark 草稿器bf16(参考)7.29 GB可选
视觉塔mmproj HQQ 4 比特(Q8_0 容器)0.63 GB可选 — 仅用于多模态输入
视觉塔mmproj BF16(参考)0.93 GB可选

视觉塔通常会被卸载:它不占用加速器的常驻预算,仅在实际接收到图像时才会加载,因此纯文本服务永远无需为其付费。我们还发布了 group-64 三值打包版本(7.59 GB),匹配 llama.cpp 中的 64 值组 Q2_0 打包方式——相同的原生 g128 表示,但每个缩放因子在每 64 值块中重复。

上下文峰值内存

设备实际必须容纳的是峰值内存——权重加上KV缓存,再加上激活值和运行时缓冲区(跨后端约1.3 GB)。测量时仅包含语言模型,不使用KV缓存压缩(大小单位为十进制GB;Q4_K_XL行是根据其权重占用空间加上相同的测量缓存及开销累积得出,其他所有行均为直接测量值):

构建版本权重(GB)4K上下文10K上下文100K上下文
Ternary Bonsai(llama.cpp Q2_0)7.158.48.714.7
Qwen3.6-27B "4-bit"(Q4_K_XL)17.619.219.625.6
27B 16-bit(GGUF bf16)51.2552.653.359.3

三元构建版本在不使用任何KV缓存压缩的情况下,以14.7 GB内存支持100K token上下文——这一内存需求完全适配主流笔记本电脑;而传统的Q4_K_XL构建版本在加载第一个长文档前就需要约25.6 GB内存。这些峰值是保守情况,缓存保留为FP16格式。启用4位KV缓存可将上下文相关项缩减约4倍:100K上下文的峰值内存降至约10.1 GB,完整的262K窗口则可在约12.8 GB的峰值内存下运行。

最佳实践

生成参数

参数建议值
Temperature0.7
Top-p0.95
Top-k20

这些是所有报告的基准测试结果(思考模式)所使用的设置。

系统提示词

您可以使用简单的系统提示词,例如:

You are a helpful assistant

快速入门

llama.cpp(CUDA)

# Clone the PrismML fork of llama.cpp (includes the Q2_0_g128 hybrid-attention kernels)
git clone https://github.com/PrismML-Eng/llama.cpp
cd llama.cpp

# Build with CUDA support
cmake -B build -DGGML_CUDA=ON && cmake --build build -j

# Download the 2-bit GGUF weights
hf download prism-ml/Ternary-Bonsai-27B-gguf Ternary-Bonsai-27B-Q2_0.gguf --local-dir .

# Run inference
./build/bin/llama-cli \
    -m Ternary-Bonsai-27B-Q2_0.gguf \
    -p "Explain quantum computing in simple terms." \
    -n 256 \
    --temp 0.7 --top-p 0.95 --top-k 20 \
    -ngl 99

llama.cpp(Metal / macOS)

# Build with Metal support (default on macOS)
cmake -B build && cmake --build build -j

# Run inference
./build/bin/llama-cli \
    -m Ternary-Bonsai-27B-Q2_0.gguf \
    -p "Explain quantum computing in simple terms." \
    -n 256 \
    --temp 0.7 --top-p 0.95 --top-k 20 \
    -ngl 99

llama.cpp 服务器

./build/bin/llama-server \
    -m Ternary-Bonsai-27B-Q2_0.gguf \
    --host 0.0.0.0 --port 8080 -ngl 99

在 http://127.0.0.1:8080 打开 Web UI,或查看我们的 llama.cpp fork 获取更多示例。

要部署到手机? 三元构建版本(约 7.2 GB)超出了 iOS 每应用约 6 GB 的内存预算,仅适用于笔记本电脑/GPU。请使用 1 位伴随版本(约 3.9 GB),该版本可通过 MLX Swift 在 iPhone 17 Pro Max 上运行。

跨平台吞吐量

tg128 是生成 128 个令牌时的令牌生成吞吐量(内存带宽受限的交互阶段);pp512 是处理 512 个输入令牌时的提示处理吞吐量(计算受限阶段)。两者均以令牌/秒为单位,通过此 GGUF 包上的 llama-bench(自定义低位内核)进行测量。

平台占用空间TG128 (令牌/秒)PP512 (令牌/秒)
笔记本电脑 (Apple M5 Max, Metal)7.2 GB44.0830
笔记本电脑 (Apple M5 Pro, Metal)7.2 GB26.2393
笔记本电脑 (Apple M4 Pro, Metal)7.2 GB18.0125
单 GPU (H100, CUDA)7.2 GB98.02596

在笔记本电脑上,FP16 基准版本(约 54 GB)甚至传统的“4 位”构建版本(17.6 GB)根本无法运行——有意义的说法不是加速比,而是 27B 模型可以在日常笔记本电脑上进行交互式运行。在 M5 Pro 上测得的解码流权重约为 186 GB/s,证实了低位表示旨在利用的内存带宽主导特性。H100 一行是证明规则的例外:在批处理大小为 1 时,数据中心 GPU 受限于内核启动和同步延迟,而不是权重带宽,因此三元和二元变体在那里性能趋同(98 vs 104.8 令牌/秒),尽管它们每步的字节差异约为 1.9 倍。

推测解码:DSpark

Ternary Bonsai 27B 附带了一个针对低位目标训练的 DSpark 草稿层——一种具有置信度调度验证的半自回归草稿器。推测解码是无损的:验证精确地保留了目标分布,因此接受的令牌与普通生成无法区分。

草稿器是一个紧凑的 六层块并行 transformer,其条件是从目标的五个均匀间隔层中提取的隐藏状态;其草稿器独有的权重在服务精度下大约增加 0.5 GB(嵌入和输出头与驻留目标共享)。它遵循 DSpark 方案,具有扩散风格的块去噪目标、生存概率加权蒸馏、每源归一化隐藏状态抽头,以及根据服务堆栈的测量验证成本模型选择的草稿块大小。草稿器以 4 位量化形式提供——约 1.95 GB 的 Q4_1 包是默认选项;它比 bf16 参考版本草稿速度更快,且草稿质量基本不变,并且由于验证精确地保留了目标分布,草稿器精度仅影响速度,从不影响输出质量。

在 CUDA 服务路径上,草稿器被测量为净收益——在草稿深度 k = 4 时,接受长度 τ ≈ 3.7,在 H100 上实现了 1.34 倍 的端到端解码加速(98 → 131.8 令牌/秒)。在 Apple Silicon 上,批处理 1 的验证传递尚未摊销,因此在设备上默认不启用草稿器层。

基准测试

在相同的基础设施、解码和评分条件下,使用 EvalScope + vLLM 在 NVIDIA H100 上以思考模式进行评估——在此模式下,模型的完整推理能力得到充分施展,传统方法在 4 位以下出现的性能崩溃问题最为明显。测试涵盖六个技能类别的 15 项基准。为便于跨系列比较,表格中还包含了同能力层级的模型 Gemma-4-31B 及其传统低比特版本——4 位以下的性能崩溃是这些方法本身的特性,而非特定基础模型的问题。比特宽度为真实平均值;“vs FP16”是相对于 Qwen3.6-27B FP16 参考版本的性能比例。

变体真实比特/参数 (bpw)内存占用思考模式平均分相对 FP16
Qwen3.6-27B FP1616.054 GB85.07100%
Qwen3.6-27B Q4_K_XL(“4 位”)5.217.6 GB84.9999.9%
Qwen3.6-27B IQ2_XXS(“2 位”)2.89.4 GB72.7385.5%
Gemma-4-31B FP1616.061.5 GB84.5899.4%
Gemma-4-31B QAT(“4 位”)6.023.3 GB83.4198.0%
Gemma-4-31B Q2_K_XL(“2 位”)3.011.8 GB73.3186.2%
Ternary Bonsai 27B1.715.9 GB80.4994.6%
1-bit Bonsai 27B1.1253.9 GB76.1189.5%

Ternary Bonsai 27B 仅占用 5.9 GB 内存,却以不到传统 4 位以下模型一半至三分之二的体积,在分数上领先这些模型超过 7 分。

综合差距还低估了传统模型的失败方式:它们的性能退化具有选择性,主要集中在需要持续推理链的基准测试上。例如,IQ2_XXS 在 AIME26 上得分降至 57.5,在 LiveCodeBench 上降至 56.4,但在 MMLU-Redux 上仍能获得 88.93 的高分——这也是为什么常规测试容易忽略这种性能崩溃。而 Ternary Bonsai 恰恰在这些基准上表现稳定,AIME 保持在 87.5–90.8,LiveCodeBench 保持在 82.8。

按技能类别划分

类别基准测试FP16Ternary 27B
知识与推理MMLU-Redux, MuSR83.1576.96
数学GSM8K, MATH-500, AIME25, AIME2695.3393.40
编码HumanEval+, MBPP+, LiveCodeBench88.7485.96
指令遵循IFEval, IFBench78.4771.77
智能体/工具调用BFCL v3, τ²-Bench80.0074.01
视觉MMMU-Pro, OCR Bench v272.6165.19
总体(15项)85.0780.49

推理核心完好无损:数学性能保持在全精度的两个百分点以内(93.40),编码性能为85.96,并且三元模型利用其额外的存储空间保留了要求最高的类别——智能体工具使用(74.01)和视觉(65.19),这些是传统4位以下表示最先丢失的能力。

完整的基准测试结果

展开完整的基准测试结果(思考模式)
基准测试FP16Ternary 27B
MMLU-Redux93.4288.05
MuSR72.8865.87
GSM8K95.3096.06
MATH-50099.4099.20
AIME2593.2990.84
AIME2693.3387.50
HumanEval+95.1293.90
MBPP+83.3381.22
LiveCodeBench87.7782.75
IFEval88.9185.03
IFBench (prompt-loose)68.0358.50
BFCL v377.1074.41
τ²-Bench82.9073.61
MMMU-Pro79.9468.96
OCR Bench v265.2861.42
平均值(15项)85.0780.49

智能密度

智能密度体现了模型能力与其部署规模之间的比率:

D = -log2(1 - score/100) / size_GB
变体大小 (GB)基准测试平均值智能密度 (1/GB)
1-bit Bonsai 27B3.976.110.530
Ternary Bonsai 27B5.980.490.400
Qwen3.6-27B IQ2_XXS9.472.730.199
Gemma-4-31B Q2_K_XL11.873.310.162
Qwen3.6-27B Q4_K_XL17.684.990.155
Gemma-4-31B QAT23.383.410.111
Qwen3.6-27B FP165485.070.051
Gemma-4-31B FP1661.584.580.044

Ternary Bonsai 27B 的密度是最密集传统构建版本(IQ2_XXS 为 0.199)的 2 倍,几乎是 FP16 的 8 倍——Qwen3.6-27B 或 Gemma-4-31B 的传统构建版本智能密度均未超过 0.2。每存储 1GB 都能转化为更多可用智能。

应用场景

  • 笔记本本地 27B 智能体:在标准笔记本电脑上以约 26 tok/s 的速度实现完整的 27B 推理和工具使用,262K 上下文可用于长文档分析、全仓库代码处理以及其他依赖于在上下文中保持大型工作集的任务
  • 隐私敏感和离线环境:设备端执行确保提示词和数据始终保留在设备上,并可在网络断断续续或无网络连接的情况下工作
  • 单 GPU 和消费级 GPU 服务:通过单块消费级或入门级数据中心 GPU 即可获得 27B 级别的质量,并有足够空间支持更大批量、更长上下文或共存模型——结合 KV 缓存量化,在单块 24 GB GPU 上实现高吞吐量服务和长上下文文档分析成为可能
  • 质量优先的低位部署:当部署目标具备笔记本级内存或更高配置时,三值化是保留全精度模型行为最多的操作点

局限性

  • 质量与存储占用的权衡:三元模型保留了全精度模型平均性能的94.6%,性能差距适中且可预测——推理核心能力(数学、编码)与基准水平仅相差几个百分点,差异主要集中在要求最高的任务类别上。
  • 无法在手机上运行:三元模型构建版本约7.2 GB,超过了iOS系统每个应用约6 GB的内存预算;若需在手机上部署,请使用1位伴生模型,可通过MLX Swift获取。
  • 当前以2位插槽形式提供:已部署模型的存储占用(约7.2 GB)高于其原生目标表示的约5.9 GB;原生三元内核是当前积极的工程目标,实现后将直接把剩余的带宽和存储占用优势转化为延迟和能耗的改善。
  • 智能体编码能力(长周期、多文件、运行-测试-修复工作流)尚未成为此版本的重点优化目标;专为智能体编码优化的Bonsai 27B变体将是路线图上的下一个项目。
  • KV压缩潜力:此版本采用4位KV缓存作为标准配置;早期结果显示,键缓存可被压缩至2位以下——这为在固定设备内存预算内实现更长上下文提供了途径。

引用

如果您使用Ternary Bonsai 27B,请引用:

@techreport{bonsai27b,
    title   = {Bonsai 27B: Full 27B-Class Reasoning in Binary and Ternary
               Transformer Weights --- on Laptops and Phones},
    author  = {Prism ML},
    year    = {2026},
    month   = {July},
    url     = {https://prismml.com}
}

联系方式

如遇问题、反馈或合作咨询,请联系:contact@prismml.com