Prism ML 官网 | 白皮书 | 演示与示例 | Discord
基于三元Transformer权重实现完整的27B级别推理能力,适用于llama.cpp(支持CUDA、Metal、CPU)
约9.4倍小于FP16(理想情况下)| 保留95% FP16智能 | 在Apple M5 Pro笔记本电脑上约26 tok/s
| 项目 | 规格说明 |
|---|---|
| 基础模型 | 基于 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 |
每个权重取值为 {−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_g128 | 1.71 | 5.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.15 | 8.4 | 8.7 | 14.7 |
| Qwen3.6-27B "4-bit"(Q4_K_XL) | 17.6 | 19.2 | 19.6 | 25.6 |
| 27B 16-bit(GGUF bf16) | 51.25 | 52.6 | 53.3 | 59.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的峰值内存下运行。
| 参数 | 建议值 |
|---|---|
| Temperature | 0.7 |
| Top-p | 0.95 |
| Top-k | 20 |
这些是所有报告的基准测试结果(思考模式)所使用的设置。
您可以使用简单的系统提示词,例如:
You are a helpful assistant# 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# 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./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 GB | 44.0 | 830 |
| 笔记本电脑 (Apple M5 Pro, Metal) | 7.2 GB | 26.2 | 393 |
| 笔记本电脑 (Apple M4 Pro, Metal) | 7.2 GB | 18.0 | 125 |
| 单 GPU (H100, CUDA) | 7.2 GB | 98.0 | 2596 |
在笔记本电脑上,FP16 基准版本(约 54 GB)甚至传统的“4 位”构建版本(17.6 GB)根本无法运行——有意义的说法不是加速比,而是 27B 模型可以在日常笔记本电脑上进行交互式运行。在 M5 Pro 上测得的解码流权重约为 186 GB/s,证实了低位表示旨在利用的内存带宽主导特性。H100 一行是证明规则的例外:在批处理大小为 1 时,数据中心 GPU 受限于内核启动和同步延迟,而不是权重带宽,因此三元和二元变体在那里性能趋同(98 vs 104.8 令牌/秒),尽管它们每步的字节差异约为 1.9 倍。
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 FP16 | 16.0 | 54 GB | 85.07 | 100% |
| Qwen3.6-27B Q4_K_XL(“4 位”) | 5.2 | 17.6 GB | 84.99 | 99.9% |
| Qwen3.6-27B IQ2_XXS(“2 位”) | 2.8 | 9.4 GB | 72.73 | 85.5% |
| Gemma-4-31B FP16 | 16.0 | 61.5 GB | 84.58 | 99.4% |
| Gemma-4-31B QAT(“4 位”) | 6.0 | 23.3 GB | 83.41 | 98.0% |
| Gemma-4-31B Q2_K_XL(“2 位”) | 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 仅占用 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。
| 类别 | 基准测试 | FP16 | Ternary 27B |
|---|---|---|---|
| 知识与推理 | MMLU-Redux, MuSR | 83.15 | 76.96 |
| 数学 | GSM8K, MATH-500, AIME25, AIME26 | 95.33 | 93.40 |
| 编码 | HumanEval+, MBPP+, LiveCodeBench | 88.74 | 85.96 |
| 指令遵循 | IFEval, IFBench | 78.47 | 71.77 |
| 智能体/工具调用 | BFCL v3, τ²-Bench | 80.00 | 74.01 |
| 视觉 | MMMU-Pro, OCR Bench v2 | 72.61 | 65.19 |
| 总体(15项) | 85.07 | 80.49 |
推理核心完好无损:数学性能保持在全精度的两个百分点以内(93.40),编码性能为85.96,并且三元模型利用其额外的存储空间保留了要求最高的类别——智能体工具使用(74.01)和视觉(65.19),这些是传统4位以下表示最先丢失的能力。
| 基准测试 | FP16 | Ternary 27B |
|---|---|---|
| MMLU-Redux | 93.42 | 88.05 |
| MuSR | 72.88 | 65.87 |
| GSM8K | 95.30 | 96.06 |
| MATH-500 | 99.40 | 99.20 |
| AIME25 | 93.29 | 90.84 |
| AIME26 | 93.33 | 87.50 |
| HumanEval+ | 95.12 | 93.90 |
| MBPP+ | 83.33 | 81.22 |
| LiveCodeBench | 87.77 | 82.75 |
| IFEval | 88.91 | 85.03 |
| IFBench (prompt-loose) | 68.03 | 58.50 |
| BFCL v3 | 77.10 | 74.41 |
| τ²-Bench | 82.90 | 73.61 |
| MMMU-Pro | 79.94 | 68.96 |
| OCR Bench v2 | 65.28 | 61.42 |
| 平均值(15项) | 85.07 | 80.49 |
智能密度体现了模型能力与其部署规模之间的比率:
D = -log2(1 - score/100) / size_GB| 变体 | 大小 (GB) | 基准测试平均值 | 智能密度 (1/GB) |
|---|---|---|---|
| 1-bit Bonsai 27B | 3.9 | 76.11 | 0.530 |
| Ternary Bonsai 27B | 5.9 | 80.49 | 0.400 |
| Qwen3.6-27B IQ2_XXS | 9.4 | 72.73 | 0.199 |
| Gemma-4-31B Q2_K_XL | 11.8 | 73.31 | 0.162 |
| Qwen3.6-27B Q4_K_XL | 17.6 | 84.99 | 0.155 |
| Gemma-4-31B QAT | 23.3 | 83.41 | 0.111 |
| Qwen3.6-27B FP16 | 54 | 85.07 | 0.051 |
| Gemma-4-31B FP16 | 61.5 | 84.58 | 0.044 |
Ternary Bonsai 27B 的密度是最密集传统构建版本(IQ2_XXS 为 0.199)的 2 倍,几乎是 FP16 的 8 倍——Qwen3.6-27B 或 Gemma-4-31B 的传统构建版本智能密度均未超过 0.2。每存储 1GB 都能转化为更多可用智能。
如果您使用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