Bonsai 27B：27B 级模型首次跑进手机，本地部署的新纪元

MODEL REVIEW · 本地实测

   2026.07      

 

   

     27B 模型只能跑在数据中心？        

   

     Bonsai 27B 把答案压缩到          3.9 GB        

   

     手机也能跑 27B 参数        

   

       
   

   

     PrismML · Ternary 7.2GB · 262K 上下文 · 76 tok/s        

 





 

   Bonsai 27B · 双 5070 Ti 实测      

 

   27B        Ternary      









 

   📦 4 Parts + Conclusion      

 

   👉 滑动

PART 01

Bonsai 是什么

INTRO

PART 02

部署实录

DEPLOYMENT

PART 03

性能测评

BENCHMARK

PART 04

使用体验

EXPERIENCE

PART ///

总结与建议

THE END

 7 月 14 日，PrismML 发布了一条炸裂的消息    



 27B 参数，1.125 bpw，3.9 GB，iPhone 17 Pro Max    







 7 月 14 日，PrismML 发布了基于 Qwen3.6-27B 的 Bonsai 27B 模型，提供 1-bit 和 Ternary 两个极端量化版本。1-bit 版本仅 **3.9 GB**，可在 iPhone 17 Pro Max 上运行；Ternary 版本 7.2 GB，保留 95% 全精度性能，面向笔记本和台式机。    



 我在双 RTX 5070 Ti 上完整部署了 Ternary 版本并做了全维度实测，本文是完整的部署记录和性能评估。    







 

   

     01        

   

     PART

Bonsai 27B 是什么

     INTRO · 极端量化        

 





 Bonsai 27B 基于阿里巴巴的 **Qwen3.6-27B**（Hybrid Attention 架构，约 75% Linear Attention + 25% Full Attention），PrismML 在此之上做了端到端的极端量化。两个版本的核心区别：

指标	1-bit Bonsai 27B	Ternary Bonsai 27B
量化格式	Q1_0_g128	Q2_0_g128
真实比特/权重	1.125 bpw	1.71 bpw
部署体积	3.9 GB	7.2 GB
15项基准总分	76.11	80.49
保留性能 (vs FP16)	89.5%	94.6%
上下文长度	262K tokens	262K tokens
视觉输入	✅ 支持	✅ 支持
目标设备	iPhone 17 Pro Max	笔记本/台式机

1-bit 版本的真正意义

 27B 模型装在 3.9 GB 里跑在手机上——这是最令人震惊的数字。对比一下各精度体积：    

   

 

   1

FP16 精度：54 GB——需要数据中心级 GPU

常规 4-bit（Q4_K_XL）：17.6 GB——笔记本勉强能用，手机不可能

常规 2-bit（IQ2_XXS）：9.4 GB——但真实 bpw 是 2.8，标签虚标

Bonsai 1-bit：3.9 GB——真 1.125 bpw，嵌入层到 LM Head 全部二值，没有高精度后门

 PrismML 特意指出了行业潜规则：很多模型标称的 「2-bit」实际平均位宽是 2.8 bpw（因为使用了高精度逃逸口）。Bonsai 的 1-bit 没有这种后门。1-bit 版本在 iPhone 17 Pro Max 上实测约 11 tok/s，足以做交互式对话。

Ternary 版本的质量

 Ternary 版本是 质量导向的选择，7.2 GB 部署体积，94.6% 的 FP16 基准性能。关键能力保留率极高：数学（GSM8K 96.06，超过 FP16 的 95.30）、编码（HumanEval+ 93.90 vs 95.12）、工具调用（BFCL v3 74.41 vs 77.10，保留率 96.5%）。    

   

 和当前最强竞品对比：

模型	bpw	体积	基准分	vs FP16
Qwen3.6 Q4_K_XL	5.2	17.6 GB	84.99	99.9%
Gemma4-31B QAT	6.0	23.3 GB	83.41	98.0%
Qwen3.6 IQ2_XXS	2.8	9.4 GB	72.73	85.5%
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 以 5.9 GB 做到 80.49 分，比 IQ2_XXS 少 3.5 GB 却高 7.76 分——极端量化的收益在此刻体现得淋漓尽致。    







 

   

     02        

   

     PART

部署实录

     DEPLOYMENT · 编译+运行        

 





 由于 PrismML 的 Q2_0_g128 量化格式需要定制化 CUDA kernel，**无法直接通过 Ollama 加载**。部署过程分为编译 PrismML 的 llama.cpp 分支和运行 llama-server 两步。    

   

 

   1

编译：从 PrismML GitHub 克隆 llama.cpp 分支，启用 CUDA 后端（设置 CMAKE_CUDA_ARCHITECTURES=89）。约 3 分钟编译 185 个 CUDA kernel 文件。

GPU 绑定：llama-server 绑定到 GPU1（–main-gpu 1 –split-mode none），端口 8002，避免与 GPU0 上的 Ollama 冲突。

视觉塔：可选加载 629 MB 的 mmproj（4-bit HQQ 视觉投影层），支持图片输入。

systemd 服务：开机自启，故障自动恢复。

GPU0

8.5 GB / 16 GB

Ollama + vLLM

GPU1

9.5 GB / 16 GB

Bonsai 27B Ternary

 GPU1 原来空着约 15.8 GB，现在只用了不到 10 GB，还有大量余量给 KV cache 和并行请求。    

   

 

   ！踩坑提示 🕳      

 

   编译时若未设置 CMAKE_CUDA_ARCHITECTURES，cmake 会编译所有 CUDA arch（约 185 个 kernel 文件），耗时 15 分钟以上。限制为 sm_89（RTX 5070 Ti）后只需 3–5 分钟。      









 

   

     03        

   

     PART

性能测评

     BENCHMARK · 速度+视觉+工具        

 





 以下测试均基于双 5070 Ti 上 GPU1 独占运行的 Ternary Bonsai 27B，对比同一台机器上通过 Ollama 运行的 gemma4 e4b（8B 模型，GPU0）。

测试场景	Bonsai 27B Ternary	gemma4 e4b
Prefill 速度
短文本 ~30 tokens	68.3 tok/s	24.6 tok/s
中等 ~30 tokens	142.0 tok/s	107.5 tok/s
长上下文 3428 tokens	1675.1 tok/s	—（超时）
生成速度
100 tokens	76.2 tok/s	67.1 tok/s
400 tokens	76.9 tok/s	74.6 tok/s
首 Token 延迟
短文本	0.28s	1.22s
中等文本	0.20s	0.33s

 Bonsai 27B 的生成速度稳定在 **76–77 tok/s**，作为 27B 模型居然比 8B 的 gemma4 e4b 还快。原因清晰：Bonsai 走 GPU1 独占 + llama-server 直接 CUDA 推理，而 e4b 走 Ollama，后者有 Go 语言桥接和模型调度开销。

视觉识别

905.3

Prefill tok/s（含视觉）

0.46B

视觉塔参数量（27 blocks）

 Bonsai 的视觉是 「能用」级别——通过 4-bit HQQ 量化的 0.46B 参数视觉塔实现。能正确识别景物、文字等基本要素，更适合辅助性任务（识图理解文档/截图），而非专业图像分析。

工具调用

 Bonsai 27B 的官方基准在 BFCL v3 上达到 74.41（FP16 为 77.10），保留率达 96.5%——是所有能力中保留率最高的。    

   

 

   实测：要求模型调用 get_current_time 函数查询北京时间 → 模型正确返回 get_current_time({"city": "北京"})，参数格式完全正确，可直接对接 Hermes 等 Agent 框架。

与 gemma4 e4b 的定位对比

 需要明确：**Bonsai 27B（27B 参数）和 gemma4 e4b（8B 参数）不是同一定位**。直接比「谁强」不公平，以下是对比维度：

维度	Bonsai 27B	gemma4 e4b
参数规模	27B	8B
部署体积	7.2 GB	9.6 GB
推理速度	76.9 tok/s	74.6 tok/s
上下文	262K	4K–8K
视觉	✅ 支持	✅ 支持
工具调用	✅ BFCL 74.41	✅
目标场景	长上下文/Agent	日常快速问答

 如果你日常跑的都是短文本对话，e4b 更合适。但一旦涉及长文档分析、多轮 Agentic 工作流，Bonsai 的 262K 上下文就是质变。    







 

   

     04        

   

     PART

使用体验

     EXPERIENCE · 长上下文+DSpark

长上下文实测

 262K 上下文的具体含义：可以一次性输入整本小说、整个代码仓库，或者一小时会议的完整转写稿——模型从头到尾都能看到。

上下文长度	Ternary Bonsai	常规 Q4_K_XL
4K	8.4 GB	19.2 GB
10K	8.7 GB	19.6 GB
100K	10.1 GB	25.6 GB
262K	~12.8 GB	—

 在 262K 上下文下仅需约 12.8 GB 峰值显存——我的双 5070 Ti 单卡 16 GB 都够用。这是 Hybrid Attention + 4-bit KV cache 压缩 共同作用的结果。

DSpark 推测解码

 Bonsai 27B 内置了一个 DSpark 推测解码 drafter，六层 block-parallel transformer，在 CUDA 路径上可实现约 1.34x–1.37x 的端到端加速。Drafter 使用 Q4_1 量化（1.95 GB 可选加载），与目标模型共享嵌入层和输出头，验证过程保持输出分布不变——drafter 精度只影响速度，不影响输出质量。目前只在 CUDA 批量推理路径上生效。    







 

   

     ///        

   

     LAST

总结与建议

     THE END · 该不该部署        

 





 PrismML Bonsai 27B 是极端量化的里程碑。它证明了三件事：    



 

   1

1-bit 权重可以承载 27B 级推理——AIME 数学 >87、编码 >81，知识密集型任务没有崩溃

27B 模型可以上手机——3.9 GB 部署体积在物理上可行

Agentic 能力在极端量化下保持最好——工具调用的保留率（96.5%）高于知识/推理能力

维度	评分	说明
技术创新	★★★★★	端到端 1-bit 权重的工程奇迹
部署便利	★★★☆☆	需要编译专用 llama.cpp 分支
推理速度	★★★★☆	76 tok/s，27B 里优秀
质量保留	★★★★☆	95% FP16，数学/编码几乎无损
长上下文	★★★★★	262K，Hybrid Attention 效果显著
生态系统	★★★☆☆	需专用 kernel，Ollama 暂不支持
综合	★★★★☆	技术开创性大于实用紧迫性

如果你的主要需求是 Agentic 工作流和长文档分析

   → ✅ 强烈推荐，262K 上下文是质变。

如果你的 GPU 显存充裕（≥16 GB）

   → ✅ Ternary 版本部署简单、效果好。

如果你只想快速问答

   → ❌ gemma4 e4b 或类似 7–8B 模型更合适。

如果追求手机端部署

   → ⏳ 等 1-bit 版本通过 MLX Swift 进入主流。      









 我是 {{作者名}}，一个热衷于探索本地 AI 部署极致的开发者。    







 既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。    



 

   

   点赞      

 

   

   在看      

 

   

   转发      





 THANKS FOR READING

人工智能

Bonsai 27B：27B 级模型首次跑进手机，本地部署的新纪元

https://maoyu92.github.io/2026/07/15/07 AI笔记/AI工具与模型/a050_Bonsai 27B：27B 级模型首次跑进手机，本地部署的新纪元/

作者

陈文茂

发布于

2026年7月15日

许可协议

多 Agent 并行管理新思路：Orca 想统一你的命令行智能体上一篇

PrismML Bonsai 27B：27B 级模型首次跑进手机下一篇