prism-ml/Ternary-Bonsai-27B-mlx-2bit · Hugging Face

来源：https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit Bonsai

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

在三元Transformer权重中实现完整的27B级推理——在普通笔记本电脑上即可运行

比FP16缩小约9.4倍（理论值）|保留FP16的95%智能|约26 tok/s（在Apple M5 Pro笔记本电脑上实测）

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#highlights亮点

• 部署占用约7.2 GB（相比FP16的约54 GB大幅缩减）——在标准笔记本电脑或单GPU上实现完整的27B级推理
• 保留FP16的95%智能：在15个推理模式基准测试中平均得分80.49——比传统IQ2_XXS构建方式（72.73分）的得分更高，而体积仅为后者的三分之二以下
• 在低于4比特的极端低位区域保留思考、推理和智能体行为，而传统低位表示在该区域会失效：数学得分距全精度仅差两个点（93.40），编码得分为85.96，智能体工具使用得分为74.01
• 端到端的三元语言权重覆盖嵌入层、注意力投影层、MLP投影层和LM头部，实现真正的1.71比特/权重——而不是在低位标签背后隐藏高精度的后门；视觉塔以紧凑的4位HQQ格式提供
• 设备端支持262K令牌上下文，得益于Qwen3.6-27B混合注意力骨干网络（约75%线性注意力）和4位KV缓存量化，得以在实际设备上运行
• 在Apple MLX（Python、Swift）和CUDA上提供自定义2位混合注意力内核——打包后的权重直接使用，从未还原回FP16
• 附带针对Bonsai 27B目标训练的DSpark投机解码草稿层——在CUDA服务路径上实现无损的1.34倍解码加速
• 1位版本：同时提供1位Bonsai 27B (https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit)（约3.9 GB），适合iPhone 17 Pro Max的手机级运行版本

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#resources资源

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

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#model-overview模型概述

项目规格基础模型源自Qwen3.6-27B，一个27B混合注意力因果语言模型（架构未变）参数量约27.3B三元语言权重（约24.8B骨干网络，跨越64个块 + 约2.5B嵌入/LM头部）+ 约0.46B视觉塔（27个块）架构混合注意力（约75%线性 / 约25%全注意力），SwiGLU MLP, RoPE, RMSNorm上下文长度262K令牌（设备端支持完整上下文，得益于以线性注意力为主的骨干网络）KV缓存近无损4位KV量化；混合骨干网络仅在64层中的16层维护全注意力缓存（完整262K窗口下约4.3 GB）权重格式三元g128：{−1, 0, +1}权重，附带FP16分组缩放低位覆盖嵌入层、注意力投影层、MLP投影层、LM头部视觉塔HQQ 4位；可选约0.63 GB mmproj包，仅在图像输入时加载部署大小约7.2 GB（理论值5.9 GB，按1.71比特/权重计算；见下文）加速功能提供DSpark投机解码草稿层后端Apple MLX（Python、Swift）和CUDA许可协议Apache 2.0

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#weight-representation-ternary-g128权重表示：三元g128

每个权重取值来自{−1, 0, +1}，每128个权重为一组共享一个FP16缩放因子。每个三元值携带约1.585比特信息（log2³），因此有效存储成本约为1.71比特/权重（三元编码 + 分摊到128个权重上的16位缩放）——相比FP16理论上缩小约9.4倍。

相比二进制格式，额外的零状态提供了更具表达力的权重字母表，恢复更多全精度模型的行为，这使得三元成为Bonsai 27B系列面向质量的最佳运行点。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#memory-requirement内存需求

格式真实比特/权重理论大小部署大小缩小倍数（理论）FP16（基线）16.0约54 GB—1.0x三元g1281.715.9 GB约7.2 GB约9.4x 当前的内核将每个三元值存储在一个2位槽中（部署后为2.125比特/权重），因此部署后的占用空间高于该表示在信息论上的最小值，直到本地三元内核缩小这一差距。部署数值描述的是语言模型本身——即文本推理必须常驻的唯一组件；归一化和缩放参数的少量尾随部分保留在更高精度中。

与传统低位构建方式不同——后者宣传的标签往往低估其真实的平均位宽（Qwen3.6-27B广泛使用的“2位“构建实际为2.8比特/权重，占用9.4 GB）——Bonsai表示的位宽与其名称完全一致。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#shipped-components附带组件

两个可选组件随语言模型一起提供（磁盘大小来自GGUF打包格式）：

组件打包大小常驻状态语言模型2位g128槽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可选 视觉塔通常被卸载：它位于加速器常驻预算之外，仅在真正接收到图像时加载，因此纯文本服务永远无需为其付费。同时还发布了一个组大小为64的三元打包版本（7.59 GB），与llama.cpp中的64值组Q2_0打包方式匹配——相同的本地g128表示，每个缩放因子在每64值块中重复。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#mlx-packagingMLX打包

已发布的MLX包在磁盘上占用8.49 GB（safetensors格式，视觉塔捆绑在同一文件中）。MLX的分组低位格式每组同时存储一个缩放因子和一个偏置；Bonsai仅含缩放因子的权重通过设置s_mlx = 2·s_g和bias = −s_g进行打包，这将精确复现±s_g——偏置不携带任何新信息——但每组存储两个FP16值，而本机格式每组仅存储一个。因此有效位率为2.25比特/权重，而部署版本为2.125。这是当前MLX的一个限制；一旦MLX支持仅含缩放因子的分组格式，MLX包将与本地位率一致。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#peak-memory-at-context上下文峰值内存

设备实际需要容纳的是峰值内存——权重加上KV缓存加上激活值和运行时缓冲区（约1.3 GB，跨后端一致）。实测仅语言模型，无KV缓存压缩（数值以十进制GB为单位；Q4_K_XL行的数据来自其权重占用加上相同的实测缓存和开销累积，其他所有行均为直接实测）：

构建方式权重4K上下文10K上下文100K上下文三元Bonsai (llama.cpp Q2_0)7.158.48.714.7三元Bonsai (MLX 2位)7.579.29.615.5Qwen3.6-27B “4位” (Q4_K_XL)17.619.219.625.627B 16位 (GGUF bf16)51.2552.653.359.3 三元构建在无任何KV缓存压缩的情况下，100K令牌上下文仅需14.7–15.5 GB——这一预算可直接适配主流笔记本电脑；而传统Q4_K_XL构建在加载第一个长文档之前就需要约25.6 GB。这些峰值是保守情况，缓存保持FP16精度。启用4位KV缓存可将上下文相关部分缩小约4倍：三元构建的100K峰值降至约10.1 GB，完整的262K窗口在约12.8 GB峰值内即可容纳。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#best-practices最佳实践

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#generation-parameters生成参数

参数建议值温度0.7Top-p0.95Top-k20 这些是所有报告的基准测试结果（推理模式）所使用的设置。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#system-prompt系统提示词

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

You are a helpful assistant

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#quickstart快速开始

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#mlx-apple-silicon–macMLX（Apple Silicon — Mac）

使用Bonsai-demo仓库 (https://github.com/PrismML-Eng/Bonsai-demo) 在MacBook上运行三元Bonsai 27B。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#cuda-nvidia-gpusCUDA（NVIDIA GPU）

CUDA推理使用相同权重的GGUF包：我们llama.cpp分支 (https://github.com/PrismML-Eng/llama.cpp) 中的融合2位GEMM内核会在矩阵乘法内部解包三元编码并应用分组缩放——模型从未在内存中展开为密集的FP16张量。请参阅**Ternary-Bonsai-27B-gguf (https://huggingface.co/prism-ml/Ternary-Bonsai-27B-gguf)**获取完整的CUDA、Metal和服务端快速入门指南。

**要部署到手机上？**三元构建（约7.2 GB）超过了iOS约6 GB每应用内存预算，仅适用于笔记本电脑/GPU。请使用1位版本 (https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit)（约3.9 GB），该版本可适配iPhone 17 Pro Max。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#cross-platform-throughput跨平台吞吐量

tg128是生成128个令牌的令牌生成吞吐量（内存带宽受限的交互阶段）；pp512是处理512输入令牌的提示处理吞吐量（计算受限阶段）。两者单位均为令牌/秒。各行使用llama.cpp（Metal/CUDA，自定义低位内核）在相同权重的GGUF包上实测。

平台占用空间TG128 (tok/s)PP512 (tok/s)笔记本电脑（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 tok/s），尽管它们每步的字节数相差约1.9倍。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#speculative-decoding-dspark投机解码：DSpark

三元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 tok/s）。在Apple Silicon上，批大小为1的验证过程目前尚无法摊销成本，因此设备端默认不启用草稿器层。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#benchmarks基准测试

使用EvalScope + vLLM在NVIDIA H100上评估，采用相同的基础设施、解码方式和评分方法，在推理模式下进行——该模式下模型的完整推理能力得到充分锻炼，传统方法在4比特以下的崩溃最为明显。涵盖六个技能类别的15项基准测试。为提供跨系列背景参考，表中还包含了同一能力层级的Gemma-4-31B模型及其传统低位构建方式——低位崩溃是方法的固有属性，而非特定基础模型的问题。位宽为真实平均值；“vs FP16“是相对于Qwen3.6-27B FP16基准的得分。

变体真实bpw占用空间推理平均vs FP16Qwen3.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%**三元Bonsai 27B1.715.9 GB80.4994.6%**1位Bonsai 27B (https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit)1.1253.9 GB76.1189.5% 在5.9 GB的占用空间下，三元Bonsai 27B的得分比两种4比特以下的传统构建方式高出七分以上，而体积仅为后者的二分之一到三分之二。

总分的差距也低估了传统构建的失败方式：它们的退化是选择性的，集中在需要持续推理链的基准测试上。IQ2_XXS在AIME26上降至57.5，在LiveCodeBench上降至56.4，而在MMLU-Redux上仍能获得88.93分——这就是为什么简单的测试会遗漏崩溃现象。三元Bonsai在这些基准测试上均保持稳定，AIME保持在87.5–90.8分，LiveCodeBench保持在82.8分。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#by-skill-category按技能类别

类别基准测试FP16三元27B知识与推理MMLU-Redux, MuSR83.1576.96数学GSM8K, MATH-500, AIME25, AIME2695.3393.40编码HumanEval+, MBPP+, LiveCodeBench88.7485.96指令跟随IFEval, IFBench78.4771.77智能体/工具调用BFCL v3, τ2-Bench80.0074.01视觉MMMU-Pro, OCR Bench v272.6165.19整体（15项）85.0780.49 推理骨干网络完好无损：数学距全精度仅差两个点（93.40），编码得分为85.96，而三元模型将其额外的占用空间用于维持最具挑战性的类别——智能体工具使用得分为74.01，视觉得分为65.19——这些正是传统4比特以下表示首先丢失的行为。

https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit#full-per-benchmark-results完整逐项基准测试结果

展开完整逐项基准测试结果（推理模式）基准测试FP16三元27BMMLU-Redux93.4288.05MuSR72.8865.87GSM8K95.3096.06MATH-50099.4099.20AIME2593.2990.84AIME2693.3387.50HumanEval+95.1293.90MBPP+83.3381.22LiveCodeBe