PrismML Bonsai 27B：27B 级模型首次跑进手机
“
27B 参数 的模型压缩到 3.9 GB 同时保留 90% 的推理能力——这扇门一旦推开，本地模型的格局就彻底改变了
—— 实测手记
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
极端量化实测
02
76 tok/s 的 27B
03
262K 上下文实测
01
INTRO
Bonsai 27B 是什么
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
2
常规 4-bit（Q4_K_XL）：17.6 GB——笔记本勉强能用，手机不可能
3
常规 2-bit（IQ2_XXS）：9.4 GB——但真实 bpw 是 2.8，标签虚标
4
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
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 文件。
2
GPU 绑定：llama-server 绑定到 GPU1（–main-gpu 1 –split-mode none），端口 8002，避免与 GPU0 上的 Ollama 冲突。
3
视觉塔：可选加载 629 MB 的 mmproj（4-bit HQQ 视觉投影层），支持图片输入。
4
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
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 vs gemma4 e4b 性能对比（tok/s × 首 Token 延迟）
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
EXPERIENCE
使用体验
长上下文实测
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 批量推理路径上生效。
∞
THE END
总结与建议
PrismML Bonsai 27B 是极端量化的里程碑。它证明了三件事：
1
1-bit 权重可以承载 27B 级推理——AIME 数学 >87、编码 >81，知识密集型任务没有崩溃
2
27B 模型可以上手机——3.9 GB 部署体积在物理上可行
3
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 进入主流。
END
我是 {{作者名}}，一个热衷于探索本地 AI 部署极致的开发者。
如果你觉得今天这篇有收获，欢迎 **点赞、在看、转发** 三连，我们下篇见。
PrismML Bonsai 27B：27B 级模型首次跑进手机
https://maoyu92.github.io/2026/07/15/07 AI笔记/AI工具与模型/a051_PrismML Bonsai 27B：27B 级模型首次跑进手机/