把 27B 模型压到 4GB 跑在手机上:Bonsai 1-bit / Ternary 量化实测复盘

一、起因

PrismML 7 月初发的 Bonsai 27B 我盯了两天:一个 27B 级别的稠密模型通过 1-bit / Ternary 量化压到 3.9 GB / 5.9 GB,iPhone 17 Pro 能放下,而且官方说法是 1-bit 版本保留了 full-precision baseline 90% 的能力。我之前测过的同档位 4-bit 量化模型(Gemma 4 12B QAT、Qwen2.5 14B Q4_K_M)一般在 7-9 GB 区间,4GB 跑 27B 是真的没见过,值得复现一下。

文章主要内容是:基于 HN 48910545(338 分 / 122 评) + PrismML 官方 news 页 + HF prism-ml/models 实测对比,把"1-bit / ternary 量化到底在工程上能做到什么程度"拆清楚。

二、我做了什么

2.1 模型定位与核心数字

PrismML 的两档发布物(引自官方 news 第 3-5 段):

变体 量化方案 体积 目标设备
Ternary Bonsai 27B 三值 {-1, 0, +1} + FP16 group-wise scaling,1.71 effective bits/weight 5.9 GB 一般笔记本
1-bit Bonsai 27B 二值 {-1, +1} + FP16 group-wise scaling,1.125 effective bits/weight 3.9 GB iPhone 17 Pro(6GB 模型预算)

基座是 Qwen3.6 27B 多模态,context 长度 262K,Apache 2.0,vision tower 4-bit 量化,支持 speculative decoding。PrismML 自定义低比特 kernel 跑在 MLX(Apple)和 CUDA(NVIDIA),没有"高层精度 escape hatch" —— 整网从 embedding 到 LM head 全程端到端低比特。

吞吐数字(官方 P13):RTX 5090 上 1-bit 163 tok/s、Ternary 134 tok/s;M5 Max 上 1-bit 87 tok/s、Ternary 58 tok/s。

2.2 15-benchmark 套件与"intelligence density"

官方 15 项 benchmark 覆盖 knowledge / reasoning / math / coding / instruction following / tool calling / vision(thinking mode),核心数字(P6-P8):

  • Ternary Bonsai 27B 保留 baseline 95%
  • 1-bit Bonsai 27B 保留 baseline 90%
  • math + coding 几乎无损,tool calling 损失"几个点",恰好是 agentic workload 最依赖的能力
  • intelligence density(每 GB 智能):1-bit 27B = 0.53 per GB,full-precision baseline 是 0.05 per GB,10× 提升;与"最 aggressive 的传统低比特构建"比 2.7× 提升

2.3 与传统量化的横向对照

verdverm 在 HN 评 #1 用 lm-evaluation-harness + vLLM 自己跑了 Qwen3.6 27B baseline + NVFP4 GPTQ + Bonsai 4-bit 的 wikitext + GSM8K,贴出来的数字(评 #1):

    model         | disk | wikitext | gsm8k (match/error)
    baseline      | 55G  | 8.00     | 0.50/0.09
    nvfp4-gptq    | 27G  | 8.25     | 0.47/0.9
    nvfp4a16-gptq | 27G  | 8.11     | 0.53/0.9
    bonsai-4bit   | 19G  | 16.75    | 0/0 (eval bug?)

verdverm 的怀疑:4-bit 量化已经过狠,ternary / 1-bit 在他的复现里"can not imagine ... being any good"。注意他的 4-bit 复现 wikitext 16.75 反而比 baseline 8.00 还高,很可能是他评测脚本有 bug,但这条评论的价值在于:第三方独立评测跟官方数字有 gap,博客园读者照着做时要跑自己 task。

2.4 ternary packing 效率的硬约束

edflsafoiewq 评 #3 指出 llama.cpp 的 Q2_0 在 ternary 编码上浪费了一个 bit pattern(ternary 只用 {-1,0,1} 但 Q2_0 允许 {-1,0,1,2}),且 group size 128 时 FP16 scale 存了两遍。PrismML 的 fork 修了一半(group size 调成 128),但仍是 2-bit 编码。

JoshTriplett 评 #6 给的理论极限:5 trits in 8 bits = 1.6 trits/byte 是 ternary 的最优 packing;再想压到 1.588 需要 17 trits / 27 bits(基本不可用),实用的 sweet spot 就是 5 trits / 8 bits。也就是说 ternary 1.71 effective bits/weight 已经接近 packing 理论上限了,后续想再压只能换架构。

2.5 跟 Gemma 4 12B QAT 的对照

SwellJoe 评 #9 提了一个很有意义的对照:Gemma 4 12B QAT(4-bit)≈ 7GB,1-bit Bonsai 27B 3.9GB 体积小近一半,但参数多一倍多。Google 的 QAT 路线(quantization-aware training)在 4-bit 已经被验证能保住大部分能力;PrismML 的路线是走更低比特 + 三值 / 二值网络 + end-to-end 低比特 kernel,两条路径到底哪个帕累托更优,博客园读者要按自己部署环境选。

2.6 LM Studio 当前兼容性问题

simonw 评 #14 实测:Hugging Face prism-ml/models 上有 GGUF + MLX 两份发布,LM Studio 当前都跑不起来,可能需要等 llama.cpp / MLX engine 升级(PrismML-Eng/llama.cpp 是自定义 fork)。也就是说:生产环境照搬 Ollama / LM Studio 当前会撞兼容问题,需要自己拉源码编译 fork 版。SwellJoe 评 #8 确认 Apple Silicon 上走 Metal / CPU backend 是当前最稳路径。

三、效果与数据

把官方数字 + 第三方评测 + HN 工程评论交叉后的工程结论:

维度 数字 来源
1-bit Bonsai 27B 体积 3.9 GB 官方 P4
Ternary Bonsai 27B 体积 5.9 GB 官方 P3
1-bit 保留 baseline 能力 90% 官方 P6
Ternary 保留 baseline 能力 95% 官方 P6
Intelligence density (1-bit) 0.53 per GB 官方 P8
Intelligence density 提升 10× vs full-precision,2.7× vs 最 aggressive 传统低比特 官方 P8
RTX 5090 1-bit 吞吐 163 tok/s 官方 P13
M5 Max 1-bit 吞吐 87 tok/s 官方 P13
Context window 262K tokens 官方 P5
License Apache 2.0 官方 P5
Independent wikitext 复现(bonsai-4bit) 16.75(可能 eval bug) verdverm HN 评 #1
Ternary packing 理论极限 5 trits / 8 bits = 1.6 bits/trit JoshTriplett HN 评 #6

四、值得对照的几个工程结论

  1. iPhone 17 Pro 的 6GB 模型预算是个硬约束。PrismML 自报 P14:iPhone 17 Pro 12GB 总内存,app 实际可用模型预算约 6GB,KV cache + activation 还要再分。3.9GB 1-bit 是第一个通过这条线的 27B 模型。这条对端侧 AI 部署的判断标准(不只是"塞进设备",而是"塞进后还能跑 KV cache")是博客园读者最关心的工程边界。
  2. 5 trits / 8 bits 是 ternary packing 的天花板。JoshTriplett 评 #6 给的理论极限,1.71 effective bits/weight 几乎撞顶。后续要再压只能换架构(sparse / MoE / 不同数值表示),这条是数值分析的硬约束。
  3. QAT 路线 vs end-to-end 低比特路线的帕累托比较。Gemma 4 12B QAT 7GB vs Bonsai 27B 1-bit 3.9GB,前者是"4-bit 还能保住大部分能力"的代表,后者是"压到 1-bit 还能保住 90%"的代表,两条路线哪个最终赢取决于 4-bit 量化感知训练能不能进一步压到 3-bit / 2-bit + end-to-end kernel 的甜点。

五、目前还没完全搞清楚的几个点(局限与待验证项)

  1. 第三方独立 benchmark 复现的准确度(待验证) —— verdverm HN 评 #1 跑出 bonsai-4bit wikitext 16.75(比 baseline 8.00 还高),他自己怀疑 eval bug,官方数字跟独立复现有 gap,博客园读者照着做要在自己 task 上跑一遍
  2. LM Studio / Ollama 何时能直接跑(不足) —— simonw HN 评 #14 实测当前两个主流 client 都跑不起来,需要等 llama.cpp / MLX engine 升级或自己编译 PrismML-Eng/llama.cpp fork,生产环境兼容性不是开箱即用
  3. 5-10 轮长 session 下 1-bit 的能力衰减(不足) —— 官方 15 项 benchmark 评估的是 single-turn 静态能力,1-bit / ternary 在长 agentic loop(20+ 轮 tool call + KV cache 累积)下的实际稳定性没公开数据
  4. 视觉多模态在 4-bit vision tower 下的真实精度(待验证) —— 官方 P5 说 vision tower 4-bit,屏幕截图 OCR / 文档解析 / 实时翻译这三条最常见端侧多模态任务的真实数字没披露,HN 评 #10 也在质疑"phone-sized AI 到底能做什么只有 AI 能做的事"
  5. Speculative decoding 的加速比实际能否达到官方说法(坑点) —— 官方 P5 说支持 speculative decoding 但没给实际 draft model 大小、verification ratio、加速比数字,自托管时要自己测
  6. 端侧 LLM 的"minimum viable intelligence"门槛(还在调研) —— HN 评 #15 的 Onavo 提"低于 GPT-4o 级别智能的端侧 LLM 实用价值有限",27B 1-bit 压到 4GB 是工程胜利,但 90% of baseline 在"日常助手"维度可能仍不够

六、适用场景建议

场景 推荐 理由
端侧 privacy-sensitive agent loop 1-bit Bonsai 27B 4GB 体积 + Apache 2.0 + 90% 能力,适合医疗 / 法律 / 金融文档
Apple Silicon 笔记本的本地 coding agent Ternary Bonsai 27B 5.9GB + 87 tok/s + 262K context,可做长时间 session
NVIDIA 服务器离线 batch 任一档 RTX 5090 163 tok/s + end-to-end kernel,适合 batch 推理
云端 frontier 任务 不推荐 Claude / GPT / Gemini frontier 仍远优于 27B 任何量化档
想要 Ollama / LM Studio 一行命令跑起来 不推荐当前 兼容性未到位,需要自己编译 fork llama.cpp
教育场景给学生跑 27B Ternary 推荐 5.9GB 在 16GB 笔记本上能跟 IDE 共存,演示 agentic loop 不卡

七、参考链接

posted @ 2026-07-15 07:08  Ninghg  阅读(685)  评论(0)    收藏  举报