prism-ml/Bonsai-27B-gguf · Hugging Face

来源：https://huggingface.co/prism-ml/Bonsai-27B-gguf Bonsai

Prism ML 官网 (https://prismml.com/)|技术白皮书 (https://github.com/PrismML-Eng/Bonsai-demo)|Demo 与示例 (https://github.com/PrismML-Eng/Bonsai-demo)|Discord (https://discord.gg/prismml)

完整的 27B 级推理能力，采用二进制 Transformer 权重，适用于 llama.cpp（CUDA、Metal、CPU）

约缩小 14.2 倍相较于 FP16 |**保留约 90%**的 FP16 智能水平 |约 44 tok/s在 Apple M5 Pro 笔记本上

亮点

• 部署占用约 3.9 GB（从约 54 GB FP16 压缩而来）—— 27B 模型可运行在日常笔记本和单 GPU 上
• 在亚 4-bit 区间深度保留思考、推理和智能体行为—— 常规低位表示在此区间会崩溃 —— 15 项思考模式基准测试平均分 76.11（FP16 的 89.5%），其中数学 91.66，编程 81.88
• 端到端的二值语言权重覆盖嵌入层、注意力投影、MLP 投影和 LM head，真正的1.125 bits/weight —— 没有低位标签背后的高精度逃生舱；视觉塔以紧凑的 4-bit HQQ 格式提供
• 设备端 262K token 上下文，借助 Qwen3.6-27B 混合注意力骨干（约 75% 线性注意力）和 4-bit KV 缓存量化，保持实用性
• GGUF Q1_0_g128 格式带有针对 llama.cpp（CUDA、Metal）的自定义 1-bit 混合注意力内核 —— 打包权重直接使用，永不解压回 FP16
• 附带 DSpark 投机解码草稿层，针对 Bonsai 27B 目标训练 —— 在 CUDA 推理路径上实现无损1.37 倍解码加速
• MLX 配套版本：也提供 Bonsai-27B-mlx-1bit (https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit) 用于原生 Apple Silicon 推理，包括 iPhone（iPhone 17 Pro Max 上约 11 tok/s，通过 MLX Swift）
• 三值配套版本：质量优先的运行点（约 7.2 GB，FP16 的 95%）也已发布为 GGUF 格式，见 Ternary-Bonsai-27B-gguf (https://huggingface.co/prism-ml/Ternary-Bonsai-27B-gguf)

资源

• 技术白皮书 (https://github.com/PrismML-Eng/Bonsai-demo/blob/main/bonsai-27b-whitepaper.pdf) —— 完整方法论、基准测试和测量说明
• Demo 与示例 (https://github.com/PrismML-Eng/Bonsai-demo) —— 服务部署、基准测试和集成 Bonsai
• 低位内核：llama.cpp 分支 (https://github.com/PrismML-Eng/llama.cpp)（CUDA + Metal）· MLX 分支 (https://github.com/PrismML-Eng/mlx)（Apple Silicon）· mlx-swift 分支 (https://github.com/PrismML-Eng/mlx-swift)（iOS/macOS）
• Discord (https://discord.gg/prismml) —— 加入社区获取支持、讨论和更新

模型概览

权重表示：Q1_0_g128

每个权重是一个单独的符号位：0 映射到 −scale，1 映射到 +scale。每 128 个权重组共享一个 FP16 缩放因子。

实际每权重的比特数：1.125（1 个符号位 + 16 位缩放均摊到 128 个权重）—— 与 FP16 相比理想化地缩小约 14.2 倍。这是 Bonsai 27B 家族中最激进的运行点：它同时最小化存储占用和每一步解码过程中产生的权重传输开销。GGUF Q1_0_g128 包是模型的原生布局——理想大小和部署大小一致。

内存需求

部署数据描述的是语言模型本身——这是文本推理中必须常驻的唯一组件；归一化和缩放参数的微小部分保持在高精度。

与传统的低位构建不同——其宣传的标签往往低估实际平均比特宽度（Qwen3.6-27B 广泛使用的“2-bit“构建实际为 2.8 bits/weight，9.4 GB）——Bonsai 的表示方式与其比特宽度名副其实。

附带的组件

语言模型附带两个可选组件（磁盘大小）：

视觉塔通常被卸载：它位于加速器的常驻预算之外，仅在图像实际到达时加载，因此纯文本推理永远无需为其付费。

上下文峰值内存

设备实际需要容纳的是峰值内存——权重加上 KV 缓存加上激活值和运行时缓冲区（各后端约 1.3 GB）。已测量，仅语言模型，无 KV 缓存压缩（单位：十进制 GB；Q4_K_XL 行由其权重占用加上相同测量的缓存和开销构建得出，其他所有行均为直接测量）：

1-bit 构建在无任何 KV 缓存压缩的情况下，100K token 上下文只需 11.6 GB——这完全适合主流笔记本的预算；而常规的 Q4_K_XL 构建在加载第一个长文档之前就需要约 25.6 GB。这些峰值是保守情况，缓存保持为 FP16。启用 4-bit KV 缓存可将上下文相关项缩小约 4 倍：100K 峰值降至约 6.8 GB，完整 262K 窗口在约 9.4 GB 峰值内即可容纳。

最佳实践

生成参数

这些是所有报告基准测试（思考模式）所使用的设置。

系统提示

你可以使用简单的系统提示，例如：

你是一个有用的助手

快速上手

llama.cpp（CUDA）

``

克隆 PrismML 的 llama.cpp 分支（包含 Q1_0_g128 混合注意力内核）

git clone https://github.com/PrismML-Eng/llama.cpp cd llama.cpp

使用 CUDA 支持进行构建

cmake -B build -DGGML_CUDA=ON && cmake –build build -j

下载 1-bit GGUF 权重

hf download prism-ml/Bonsai-27B-gguf Bonsai-27B-Q1_0.gguf –local-dir .

运行推理

./build/bin/llama-cli
-m Bonsai-27B-Q1_0.gguf
-p “用简单的话解释量子计算。”
-n 256
–temp 0.7 –top-p 0.95 –top-k 20
-ngl 99 ``

llama.cpp（Metal / macOS）

``

使用 Metal 支持进行构建（macOS 默认）

cmake -B build && cmake –build build -j

运行推理

./build/bin/llama-cli
-m Bonsai-27B-Q1_0.gguf
-p “用简单的话解释量子计算。”
-n 256
–temp 0.7 –top-p 0.95 –top-k 20
-ngl 99 ``

llama.cpp 服务器

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

打开网页 UI 访问 http://127.0.0.1:8080/，或查看我们的 llama.cpp 分支 (https://github.com/PrismML-Eng/llama.cpp) 获取更多示例。

要部署到手机上？ iPhone 部署使用 MLX Swift 运行时——见 Bonsai-27B-mlx-1bit (https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit)（iPhone 17 Pro Max 上约 11 tok/s）。

跨平台吞吐量

tg128 是生成 128 个 token 的 token 生成吞吐量（内存带宽受限的交互阶段）；pp512 是处理 512 个输入 token 的提示处理吞吐量（计算受限阶段）。单位均为 tokens/s，使用 llama-bench 在此 GGUF 包（自定义低位内核）上测量。

在边缘平台上，FP16 基线（约 54 GB）甚至常规的“4-bit“构建（17.6 GB）根本无法容纳——有意义的不在于加速比，而在于一个 27B 模型首次能够在该设备上运行。H100 这一行是例外证明了规则：在 batch size 1 时，数据中心 GPU 受限于内核启动和同步延迟而非权重带宽，因此二值和三值变体在此收敛（104.8 vs 98 tok/s），尽管它们每步字节数相差约 1.9 倍。

M5 Pro 上的解码能量消耗为 0.275 mWh/token（启用 DSpark 草稿器）—— 每 token 能量效率比数据中心 GPU 高一个数量级（GPU 类别间为 0.63–1.32 mWh/token）。本地推理不仅私密且低延迟，而且能源成本低廉。

投机解码：DSpark

1-bit Bonsai 27B 附带一个DSpark草稿层，针对低位目标训练——一个半自回归草稿器，带有置信度调度的验证机制。投机解码是无损的：验证精确保留目标分布，因此被接受的 token 与普通生成无异。

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

在 CUDA 推理路径上，草稿器是一个实测的净收益——在草稿深度 k = 4 时，接受长度 τ ≈ 3.6 转化为 H100 上 1.37 倍的端到端解码加速（104.8 → 143.8 tok/s）。在 Apple Silicon 上，batch-1 验证传递尚未实现摊销，因此草稿层在设备端默认不启用。

基准测试

在 NVIDIA H100 上使用 EvalScope + vLLM 在完全相同的基础设施、解码和评分条件下，以思考模式进行评估——此时模型的完整推理能力得到充分展现，常规方法在亚 4-bit 区间的崩溃最为明显。涵盖六个技能类别的 15 项基准测试。为了跨系列对比，表格还包含了 Gemma-4-31B（同一能力层级的模型）及其常规低位构建——低于 4-bit 的崩溃是方法本身的属性，而非特定基础模型的问题。比特宽度为实际平均值；“vs FP16“是相对于 Qwen3.6-27B FP16 参考。

总体的差距还低估了常规构建的失败方式：它们的退化具有选择性，集中在需要持续推理链的基准测试上。IQ2_XXS 在 AIME26 上降至 57.5，在 LiveCodeBench 上降至 56.4，而在 MMLU-Redux 上仍得 88.93——这就是为什么随意测试会错过崩溃。1-bit Bonsai 恰好维持了这些基准测试，在仅占用 IQ2_XXS 三分之一空间的情况下，将 AIME 保持在 87 以上。

按技能类别

推理骨干完好无损地保留下来：数学保持在 91.66——距全精度仅差 4 分——编程为 81.88，这些是常规亚 4-bit 表示最先丢失的行为。1-bit 模型将三值模型在最具挑战性类别上的部分余量换成了家族中最小的占用空间。

完整逐项基准测试结果

展开完整逐项基准测试结果（思考模式）

智能密度

智能密度衡量的是模型能力与部署大小的比率：

D = -log2(1 - 得分/100) / 大小_GB

1-bit Bonsai 27B 提供的智能密度约为最密集常规构建（IQ2_XXS 的 0.199）的 2.7 倍，是 FP16 的 10 倍以上——Qwen3.6-27B 或 Gemma-4-31B 的常规构建均未超过 0.2。每个存储的 GB 被转化为更多可用的智能。