27B 模型塞进手机：PrismML Bonsai 27B 把权重压到 1-bit

27B 模型塞进手机：PrismML 的 Bonsai 27B 把权重压到 1-bit

2026 年 7 月 14 日，从加州理工学院分拆出来的初创公司 PrismML 发布了 Bonsai 27B——一个把 270 亿参数的 Qwen3.6-27B 模型压缩到 3.9 GB 的开源模型。这个数字本身已经足够扎眼：同样参数规模在 16-bit 精度下要 54 GB，连主流的 4-bit 量化版本也要 13–18 GB，而 1-bit Bonsai 27B 把它压到了约原来的十四分之一。PrismML 给出的部署场景更激进：在一台 iPhone 17 Pro 上能跑出 11 tokens/s 的生成速度。

这次发布值得单独拆开看的原因，在于它把 1-bit/ternary 量化这条路线第一次推到了 27B 参数级别的可用区间。下文按"压缩原理 → benchmark 表 → 架构亮点 → 端侧约束 → 开发者怎么跑"的顺序展开。

1-bit 和 ternary 到底在压缩什么

先回到参数存储的本质。一个 27B 模型有 270 亿个权重，常规训练用 FP16（每个权重 16 bit），存储成本就是 27B × 2 字节 ≈ 54 GB。主流的 4-bit 量化（GGUF 的 Q4_K_M、Q4_K_XL）把每个权重压到 4 bit，体积降到约 13–18 GB。Bonsai 更进一步：

关键在于"端到端"三个字。PrismML 的做法是从 embedding、attention 投影、MLP 投影一直到 LM head，所有语言权重都压到 1-bit 或 ternary，没有在部分层保留高精度作为逃生通道，只在 group 维度保留一个 FP16 的 scale 因子来补偿精度损失。视觉塔（vision tower）保留 4-bit。这跟早期 BitNet 系列只在 attention 里做实验性 1-bit 的路线不同——Bonsai 是把整张网络压到底再训练补偿。

至于"压缩到 1-bit 还能保持能力"的数学框架，PrismML 公开信息指向 Caltech 的研究，但具体的训练稳定化技术在官方白皮书中才有完整展开。从已公开的资料看，团队把这个过程描述为"在压缩之后重新训练让模型重新学会推理"，而非对已经训练好的权重做后置量化。

15 项基准：哪里掉、哪里不掉

PrismML 在 HuggingFace 的 prism-ml/Ternary-Bonsai-27B-gguf model card 里给出了完整的 per-benchmark 数据，第三方 together.ai 的托管版本也复现了同一组数字。这里把 ternary 变体的逐项得分整理出来（thinking mode，与 FP16 基线对比）：

按类别看，数学几乎不掉（GSM8K 甚至略涨，AIME25 只掉 2.5），编码掉 1–5 分也在可接受区间。真正掉得明显的是三类：多步 agentic 任务（τ²-Bench 掉 9.3）、复杂指令遵循（IFBench 掉 9.5）、视觉理解（MMMU-Pro 掉 11.0）。这与社区实测反馈一致：ternary 版本在处理复杂任务时仍会出现幻觉增加和 agent 循环问题，相比常规的 Q4_K_XL 量化版本更明显。

1-bit 变体（3.9 GB）的退化曲线更陡：overall 76.1，agentic/tool use 从 80 掉到 66，vision 从 72.6 掉到 59.6。换句话说，1-bit 是"塞进手机"的极限形态，ternary 才是"日常工作还能用"的形态。

Intelligence Density：一个值得单独看的指标

PrismML 在 model card 里定义了一个新指标——Intelligence Density：

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

分子是把 benchmark 平均分转换成"正确率的信息量"（用负对数避免高分时趋平），分母是部署体积。这个公式的好处是把"又小又准"折成单个数字：

1-bit 变体的密度是常规最强量化（IQ2_XXS）的 2.7 倍，是 FP16 的 10 倍。这个指标的真正价值不在于绝对数字，而在于提供了一个横向比较"单位存储能换来多少智能"的尺子。对端侧部署来说，它直接对应"我能用多少 RAM 换来多少可用能力"。

架构层面：为什么 262k 上下文在手机上还能跑

Bonsai 27B 的另一个容易被忽略的设计是混合注意力骨干（hybrid-attention backbone）。大约 75% 的层用线性注意力（linear attention），其余用标准的 softmax 注意力。线性注意力的计算成本对序列长度近似线性增长，而不是标准注意力的平方级增长——这就是为什么 Bonsai 能在端侧硬件上撑住 262k token 的上下文窗口，而不是像纯标准注意力那样在长上下文时 KV cache 爆内存。

Qwen3.6 27B 本身就用这个混合架构，Bonsai 继承了它。这一点对开发者实际意义不小：常规 27B 模型即便能塞进内存，长上下文场景下的 KV cache 也是主要内存消耗项，而混合注意力把这块的膨胀曲线压平了。

推理加速方面，PrismML 提供了 DSpark 投机解码（speculative decoding）——用一个轻量的 drafter 模型批量提议 token，主模型一次前向验证。在 H100 上吞吐量提升约 1.37×，且输出分布不变。苹果 Silicon 上还没默认启用，但官方表示在路线图里。

端侧部署的真实约束

"54 GB 压到 3.9 GB"听起来夸张，但端侧部署的真正瓶颈在于手机能给单个 app 分配多少内存，模型体积只是表层约束。PrismML 在公告里把这个算账算得很清楚：

A 12 GB iPhone offers about 6 GB for the model to use on-device, and the model shares that budget with its KV cache and activations.

一台 12 GB 内存的 iPhone，第三方 app 实际能拿到的内存预算大约 6 GB，而且这块预算要同时承载模型权重、KV cache、activations 三部分。常规 4-bit 量化（17–18 GB）连边都摸不到；即便是最激进的 2-bit 量化（IQ2_XXS，9.4 GB）也超了。1-bit Bonsai 27B 的 3.9 GB 是第一个能在这条内存预算内塞下、还能留出空间给 KV cache 跑起来的 27B 模型。

能耗方面，PrismML 给出的实测数据是 1-bit Bonsai 8B 在 iPhone 17 Pro Max 上 0.068 mWh/token，对比同参数 4-bit 模型的 0.132 mWh/token，单位 token 能耗降了约一半。背后的逻辑是 token 生成受内存带宽限制——搬运 1–1.58 bit 权重比搬运 16 bit 少一个数量级的内存流量，解码速度自然上去。

怎么本地跑

PrismML 提供了一个开源 demo 仓库 PrismML-Eng/Bonsai-demo，macOS / Linux 一条命令完成环境搭建：

bash
git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo

# 默认下载 Ternary-Bonsai-27B
./setup.sh

# 启动带 chat / vision / tools 的服务
./scripts/start_llama_server.sh
# → http://localhost:8080

几个细节：

• 27B 权重目前 gated，需要 HuggingFace token，export BONSAI_TOKEN="hf_..."。8B/4B/1.7B 不需要。
• 默认走 PrismML 自己 fork 的 llama.cpp，Q1_0（1-bit）已合并进 mainline llama.cpp，Q2_0（ternary）在 CPU 和 Metal 上已 mainline，Vulkan 还在 review。
• 也可以走 MLX（1-bit 用 MLX 1-bit 格式，ternary 用 MLX 2-bit），适合 Apple Silicon 原生路径。
• 生态已经接入 Together AI、HuggingFace、llama.cpp、LM Studio、Xenova 的 WebGPU 内核（用 Fable 5 和 GPT-5.6 Sol 构建，可直接在浏览器里跑）。

社区实测数据可以参考：HN 用户在 Ryzen 7 5700X + 48G RAM 上跑 CPU 推理，binary 版本 9 t/s prompt、6 t/s generation，ternary 版本因 CPU 内核还没优化只有 0.7 t/s。kubesimplify 的实测在 RTX PRO 6000 上 ternary 28.5 tg、1-bit 42.8 tg，DGX Spark 上略低。

苹果为什么在接触 PrismML

据 The Information 报道，苹果正在与 PrismML 接触评估其压缩技术，PrismML CEO Babak Hassibi 随后向 CNBC 确认了这一接触。双方目前处于早期评估阶段，未披露具体合作形式。

苹果的动机有迹可循。苹果目前在 Apple Intelligence 里跑的端侧模型约 3B 参数，能力限于摘要和翻译；iOS 27 公测版的改版 Siri 仍重度依赖云端。Morgan Stanley 预计内存成本上涨可能让 iPhone 18 售价提高约 200 美元。在这种约束下，能把 27B 模型压到 4 GB 以下的技术对苹果有结构性吸引力——意味着不增加内存就能把端侧模型能力提升一个数量级。

落地仍有障碍。PrismML 的训练方法是 Caltech 的专有 IP，目前不公开，想自己 bonsai 化一个模型还做不到。苹果是否接受依赖第三方专有训练框架的方案，是个独立问题。

谁应该关注这条路线

Bonsai 27B 的发布本身是个技术里程碑事件，但它更大的意义在于把"1-bit LLM 是不是可行路线"这个长期悬而未决的问题推到了"至少在 27B 这个量级是可行的"的位置。对几类人值得跟进：

• 做端侧 AI 的工程师：1-bit/ternary 第一次让 27B 级模型进入手机内存预算，agent 工作流在端侧的可行性边界被推开了。
• 关注模型压缩的研究者：PrismML 的 Caltech 框架还没公开，但 benchmark 数据已经证明端到端 1-bit 训练在 27B 上能保持 90% 能力，这给学术界的 BitNet 系列工作提供了工业级参照。
• 关心开源生态的人：Apache 2.0 协议，权重在 HuggingFace，推理走 mainline llama.cpp 和 MLX，Together AI 提供托管 API——整条链路都是开放的。

需要保持清醒的点是 agentic 能力的退化。τ²-Bench 掉 9.3、BFCL v3 掉 2.7，意味着在复杂多步工具调用场景下，ternary 版本相比 FP16 基线有可感知的能力损失。把它当成本地跑的日常推理和编码助手没问题，但如果工作流重度依赖 agent 循环，目前还是建议留一个高精度模型做兜底。

模型权重在 HuggingFace prism-ml 组织下，demo 仓库在 GitHub PrismML-Eng/Bonsai-demo，文档站 docs.prismml.com 有完整的 quickstart 和量化原理逐层讲解。

参考来源：

• PrismML 官方公告：Bonsai 27B
• HuggingFace model card：Ternary-Bonsai-27B-gguf（完整 per-benchmark 数据）
• PrismML 文档：1-bit 和 1.58-bit 原理
• Together AI 托管页：架构细节
• GitHub：Bonsai-demo 快速上手
• The Information：苹果接洽 PrismML（原始报道）
• kubesimplify 实测：RTX PRO 6000 vs DGX Spark