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

Source: https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit 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)

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#1-bit-bonsai-27b1比特 Bonsai 27B

二进制Transformer权重中实现完整的27B级推理——首款可在手机上运行的27B级模型

~14.2x小于FP16 |~90%的FP16智能保留 |~11 tok/s在iPhone 17 Pro Max上

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

• ~3.9 GB部署占用（从~54 GB FP16缩减而来）——适配高端手机（如iPhone 17 Pro Max）的每应用内存预算
• 保留思考、推理和智能体行为，深入低于4比特的区域，而传统低比特表示在此处会崩溃——15个思考模式基准测试平均分为76.11（FP16的89.5%），包括数学91.66和编程81.88
• 端到端二进制语言权重，涵盖嵌入、注意力投影、MLP投影和LM头，真正实现每权重1.125比特——无低比特标签后的高精度后门；视觉塔采用紧凑的4比特HQQ
• 设备端262K令牌上下文，由Qwen3.6-27B混合注意力骨干（约75%线性注意力）和4比特KV缓存量化保持实用
• 首款在手机上实现交互式27B级生成：iPhone 17 Pro Max上约11 tok/s；Apple M5 Pro笔记本电脑上约44 tok/s
• Apple MLX（Python、Swift）和CUDA上的自定义1比特混合注意力内核——直接使用打包权重，从未扩展回FP16
• 附带针对Bonsai 27B目标训练的DSpark推测解码草稿层——在CUDA服务路径上实现无损1.37倍解码加速
• 三进制伴侣：也提供三进制Bonsai 27B (https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit)，适用于笔记本电脑和GPU的注重质量的操作点（~7.2 GB，FP16的95%）

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#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/Bonsai-27B-mlx-1bit#model-overview模型概览

项目规格基模型源自Qwen3.6-27B，一个27B混合注意力因果语言模型（架构未变）参数27.3B二进制语言权重（跨64个块的24.8B骨干 + 2.5B嵌入/LM头）+ 0.46B视觉塔（27个块）架构混合注意力（75%线性 / 25%全注意力），SwiGLU MLP，RoPE，RMSNorm上下文长度262K令牌（设备端支持全上下文，得益于以线性注意力为主的骨干）KV缓存近乎无损的4比特KV量化；混合骨干仅在64层中的16层增长全注意力缓存（完整262K窗口时为4.3 GB）权重格式Binary g128：{−1, +1}权重，带有FP16组级缩放低比特覆盖率嵌入、注意力投影、MLP投影、LM头视觉塔HQQ 4比特；可选的0.63 GB mmproj包，仅在图像输入时加载部署大小3.9 GB（比FP16小14.2倍）加速提供DSpark推测解码草稿层后端Apple MLX（Python、Swift）和CUDA许可证Apache 2.0

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#weight-representation-binary-g128权重表示：Binary g128

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

每权重有效比特：1.125（1个符号位 + 16位缩放分摊到128个权重）——与FP16相比实现了理想化的14.2倍缩减。这是Bonsai 27B家族中最激进的操作点：它既最小化存储占用，也最小化每个解码步骤产生的权重流量，从而将27B模型纳入手机的内存预算。

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

格式真实位/权重大小缩减比FP16（基线）16.054 GB1.0xBinary g1281.1253.9 GB****14.2x 二进制构建以其原生1比特g128布局部署，因此理想大小与部署大小一致。部署大小描述的是语言模型本身——这是文本推理必须常驻的唯一组件；归一化和缩放参数的微小尾巴以更高精度保留。

与传统低比特构建不同——其宣传标签低估了真实平均位宽（Qwen3.6-27B广泛使用的“2比特”构建实际为2.8比特/权重，9.4 GB）——Bonsai表示的位宽与其名称相符。

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#shipped-components已提供组件

语言模型附带两个可选组件（磁盘大小来自GGUF打包）：

组件打包格式大小驻留方式语言模型1比特 g1283.9 GB常驻DSpark草稿器Q4_1（默认）1.79 GB可选——推测解码DSpark草稿器bf16（参考）7.29 GB可选视觉塔mmproj HQQ 4比特（Q8_0容器）0.63 GB可选——仅多模态输入视觉塔mmproj BF16（参考）0.93 GB可选 视觉塔通常被卸载：它位于加速器常驻预算之外，仅在有实际图像输入时加载，因此纯文本服务永远不会为其付费。

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

已发布的MLX包磁盘大小为5.13 GB（safetensors，视觉塔打包在同一文件中）。MLX的分组低比特格式每分组存储一个缩放和一个偏置；Bonsai的仅缩放权重通过设置s_mlx = 2·s_g和bias = −s_g来打包，精确重现±s_g——偏置不携带新信息——但每分组存储两个FP16值，而原生格式只存储一个。因此有效率为1.25比特/权重，而原生为1.125。这是MLX当前的限制；一旦MLX支持仅缩放分组格式，MLX包将与原生速率匹配。

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

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

构建4K上下文10K上下文100K上下文1比特 Bonsai（llama.cpp Q1_0）3.795.25.611.61比特 Bonsai（MLX 1比特）4.215.96.312.2Qwen3.6-27B “4比特”（Q4_K_XL）17.619.219.625.627B 16比特（GGUF bf16）51.2552.653.359.3 1比特构建在无任何KV缓存压缩的情况下，以11.6–12.2 GB容纳100K令牌上下文——这一预算可直接满足主流笔记本电脑；传统的Q4_K_XL构建在加载第一个长文档之前就需要约~25.6 GB。这些峰值是保守情况，缓存保留为FP16。启用4比特KV缓存可将上下文相关项缩小约4倍：1比特构建的100K峰值降至约6.8 GB，完整262K窗口适应于约9.4 GB峰值。

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

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

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

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

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

You are a helpful assistant

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

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

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

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#ios–macos-swiftiOS / macOS（Swift）

使用mlx-swift分支 (https://github.com/PrismML-Eng/mlx-swift)在iPhone和iPad上运行1比特Bonsai 27B。约~3.9 GB的模型适配iPhone 17 Pro Max的每应用内存预算，并为KV缓存和激活值留有余量。

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

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

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

tg128是生成128个令牌时的令牌生成吞吐量（内存带宽受限的交互阶段）；pp512是处理512个输入令牌时的提示处理吞吐量（计算受限阶段）。两者均以令牌/秒表示。笔记本电脑和GPU行使用llama.cpp（Metal/CUDA，自定义低比特内核）在相同权重的GGUF包上测量；iPhone行使用MLX Swift运行时。

平台占用TG128（tok/s）PP512（tok/s）笔记本电脑（Apple M5 Max, Metal）3.9 GB66.4874笔记本电脑（Apple M5 Pro, Metal）3.9 GB44.2421笔记本电脑（Apple M4 Pro, Metal）3.9 GB26.0133iPhone 17 Pro Max（A19 Pro）3.9 GB11.0111单GPU（H100, CUDA）3.9 GB104.82755 1 在手机上，解码受热限制：持续生成略低于冷启动峰值——一次连续电池消耗运行维持在10.8 tok/s，每1%电量生成672个令牌（满电约67,000个令牌）。

在边缘平台上，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/令牌）。本地推理不仅私有且低延迟，而且在能量上也非常便宜。

https://huggingface.co/prism-ml/Bonsai-27B-mlx-1bit#speculative-decoding-dspark推测解码：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的验证传递尚未摊销，因此设备上默认不启用草稿器层。

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

使用EvalScope + vLLM在NVIDIA H100上评估，基础设施、解码和评分完全相同，采用思考模式——此时模型的全部推理能力得到发挥，传统方法的低于4比特崩溃最为明显。涵盖六个技能类别的15个基准测试。为提供跨家族背景，表格中还包括Gemma-4-31B（同一能力等级模型）及其传统低比特构建——低于4比特的崩溃是方法本身的属性，而非单一基模型的特性。比特宽度为真实平均值；“对比FP16”是相对于Qwen3.6-27B FP16参考。

变体真实bpw占用思考平均对比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 27B (https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit)1.715.9 GB80.4994.6%1比特 Bonsai 27B1.1253.9 GB76.1189.5% 总和差距还低估了传统构建的失败方式：它们的退化是选择性的，集中在需要持续推理链的基准测试上。IQ2_XXS在AIME26上降至57.5，在LiveCodeBench上降至56.4，但在MMLU-Redux上仍得88.93——这就是随意测试会错过崩溃的原因。1比特Bonsai恰好维持了这些基准测试，在AIME上保持87以上，而占用仅为IQ2_XXS的三分之一。

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

类别基准测试FP161比特27B知识与推理MMLU-Redux, MuSR83.1573.39数学GSM8K, MATH-500, AIME25, AIME2695.3391.66编程HumanEval+, MBPP+, LiveCodeBench88.7481.88指令遵循IFEval, IFBench78.4765.74智能体/工具调用BFCL v3, τ2-Bench80.0066.03视觉MMMU-Pro, OCR Bench v272.6159.57总体（15项）85.0776.11 推理骨干完整无损：数学保持在91.66——在全精度的四个百分点击范围内——编程为81.88，这些是传统低于4比特表示最先丢失的行为。1比特模型用三进制模型在最苛刻类别上的一部分余量换取了更小的占用，从而将27B模型放到手机上。

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