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

1-bit Bonsai 27B — GGUF

全量 270 亿参数级推理能力，采用二进制Transformer权重，适用于llama.cpp（支持CUDA、Metal、CPU）

约14.2倍小于FP16模型 | 约90% 保留FP16模型智能 | 在Apple M5 Pro笔记本电脑上约44 tokens/秒

亮点

• 约3.9 GB 部署占用空间（相比FP16的约54 GB大幅降低）——实现270亿参数模型在日常笔记本电脑和单GPU上运行
• 在低于4比特的极限压缩下仍保持思考、推理和智能体行为，这是传统低位表示方法会失效的区域——在15项思考模式基准测试中平均得分为76.11（达到FP16的89.5%），其中数学能力为91.66，编码能力为81.88
• 端到端二进制语言模型权重，覆盖嵌入层、注意力投影层、MLP投影层和语言模型头，实现真正的1.125比特每权重——没有以低位标签为幌子的高精度"逃生舱"；视觉编码器采用紧凑的4比特HQQ格式
• 262K token上下文长度在设备端实现，得益于Qwen3.6-27B混合注意力架构（约75%线性注意力）和4比特KV缓存量化
• GGUF Q1_0_g128格式，为llama.cpp（CUDA、Metal）配备定制1比特混合注意力内核——压缩权重直接使用，无需扩展回FP16
• 内置DSpark推测解码引导层，针对Bonsai 27B目标模型训练——在CUDA服务路径上实现无损1.37倍解码加速
• MLX版本：同时提供Bonsai-27B-mlx-1bit，支持原生Apple Silicon推理，包括iPhone（通过MLX Swift在iPhone 17 Pro Max上约11 tokens/秒）
• 三值版本：注重质量的运行版本（约7.2 GB，达到FP16的95%）也已在GGUF格式中发布，即Ternary-Bonsai-27B-gguf

资源

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

模型概述

权重表示：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 位”构建实际上是 2.8 位/权重，大小为 9.4 GB）——Bonsai 表示的位宽与其名称相符。

附带组件

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

视觉塔通常会被卸载：它不占用加速器的常驻预算，仅在实际接收到图像时才加载，因此纯文本服务永远不会为其消耗资源。

上下文峰值内存

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

1位构建版本在不使用任何KV缓存压缩的情况下，以11.6 GB内存即可容纳100K token的上下文——这一内存需求完全适合主流笔记本电脑；而传统的Q4_K_XL构建版本在加载第一个长文档之前就需要约25.6 GB内存。这些峰值是保守情况，缓存保留为FP16格式。启用4位KV缓存可将上下文相关部分缩减约4倍：100K上下文的峰值内存降至约6.8 GB，而完整的262K窗口峰值内存约为9.4 GB。

最佳实践

生成参数

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

系统提示词

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

You are a helpful assistant

快速入门

llama.cpp（CUDA）

# Clone the PrismML fork of llama.cpp (includes the Q1_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 1-bit GGUF weights
hf download prism-ml/Bonsai-27B-gguf Bonsai-27B-Q1_0.gguf --local-dir .

# Run inference
./build/bin/llama-cli \
    -m Bonsai-27B-Q1_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 Bonsai-27B-Q1_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 Bonsai-27B-Q1_0.gguf \
    --host 0.0.0.0 --port 8080 -ngl 99

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

要部署到手机？ iPhone 部署使用 MLX Swift 运行时 — 详见 Bonsai-27B-mlx-1bit（在 iPhone 17 Pro Max 上约为 11 tok/s）。

跨平台吞吐量

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

在边缘平台上，FP16 基线（约 54 GB）甚至传统的“4 位”构建（17.6 GB）根本无法运行 —— 有意义的说法不是加速比，而是 27B 模型首先能够在设备上运行。H100 一行是证明这一规则的例外：在批大小为 1 时，数据中心 GPU 受限于内核启动和同步延迟，而非权重带宽，因此二进制和三进制变体在此处收敛（104.8 vs 98 tok/s），尽管它们每步的字节差异约为 1.9 倍。

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

推测解码：DSpark

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

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

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

基准测试

在 NVIDIA H100 上使用 EvalScope + vLLM 在相同的基础设施、解码和评分条件下进行评估，采用思考模式——在此模式下，模型的完整推理能力得到充分发挥，传统方法在 4 位以下出现的性能崩溃问题最为明显。测试涵盖六个技能类别的 15 项基准。为便于跨系列比较，表格中还包含了同能力级别的模型 Gemma-4-31B 及其传统低比特版本——4 位以下的性能崩溃是这些方法的固有特性，而非特定基础模型的问题。比特宽度为真实平均值；“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位以下表示最先丢失的性能。1位模型以家族中最小的内存占用为代价，部分牺牲了三元模型在最具挑战性类别上的优势。

完整的基准测试结果

智能密度

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

D = -log2(1 - score/100) / size_GB

1-bit Bonsai 27B 的密度约为最密集传统版本（IQ2_XXS 为 0.199）的 2.7 倍，是 FP16 的 10 倍以上——Qwen3.6-27B 或 Gemma-4-31B 的任何传统版本均未超过 0.2。每存储 1GB 都能转化为更多可用智能。

用例

• 笔记本本地 27B 智能体：在任何标准笔记本电脑上实现完整的 27B 推理和工具使用，速度约为 26–66 tok/s（从 M4 Pro 到 M5 Max），262K 上下文可用于长文档分析和全仓库代码处理
• 隐私敏感和离线环境：设备端执行确保提示和数据始终保留在设备上，并且在网络断断续续或无连接的情况下也能工作
• 单 GPU 和消费级 GPU 服务：通过单块消费级或入门级数据中心 GPU 即可获得 27B 级别的质量，并有足够空间容纳更大批量、更长上下文或共存模型——结合 KV 缓存量化，在单块 24 GB GPU 上实现高吞吐量服务和长上下文文档分析变得切实可行
• 通过 MLX 在手机部署：相同权重已发布为 Bonsai-27B-mlx-1bit——首个可在手机上运行的 27B 级模型

局限性

• 质量与存储占用的权衡：二进制模型保留了全精度模型平均性能的89.5%，差距不大且可预测——推理核心能力（数学、编码）与基准水平仅相差几个百分点，差异主要集中在要求最高的任务类别中；如果质量是首要考虑因素，可考虑三进制GGUF版本（94.6%）
• 智能体编码能力（长周期、多文件、运行-测试-修复工作流）并非此版本的重点优化目标；针对智能体编码进行调优的Bonsai 27B变体已列入后续开发计划
• KV压缩潜力：本版本采用4位KV缓存作为标准配置；Bonsai对KV缓存误差的容忍度随上下文长度增加而提高，初步结果显示键缓存可进一步压缩至2位以下——这为在固定设备内存预算下实现更长上下文提供了可能

引用

如果您使用1-bit 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