1.58 bit 量化刚试完没多久，又来了更狠的：直接把 27B 模型压到 1 bit，权重只有 +1 和 -1，文件从 54GB 砍到 3.9GB。PrismML 的 Bonsai 27B 发布时我就好奇，这种极端量化到底是能用，还是只能拿来跑分？
我手头是一台 16GB 的 Mac，没 iPhone 17 Pro，也没 RTX 5090。所以这篇文章主要记录我按官方 demo 把它跑起来的过程，以及我怎么看这个方向。
两种版本，差距比数字大
Bonsai 27B 基于 Qwen3.6-27B，做了两个量化档：
- Ternary（三值）：权重 {-1, 0, +1}，约 1.71 bit/weight，5.9GB。官方说保留了 FP16 约 94.6% 的智力。
- 1-bit：权重 {-1, +1}，约 1.125 bit/weight，3.9GB。保留约 89.5%。
如果只看聊天、整理资料、简单代码，1-bit 掉那点分不太明显。但官方自己也标了：agentic/tool-calling 从 80 掉到 66，vision 从 72.6 掉到 59.6。所以这两个版本不是”哪个更小更好”，而是两个完全不同的使用场景。
我选的是 Ternary 版。原因很简单：16GB Mac 上，5.9GB 权重加 4K context 峰值约 7.8GB，不闪崩；1-bit 虽然更省，但我更想先看看质量损失到底有多少。
安装比想象中省事
官方仓库提供了 setup.sh，基本是一键：装 uv、建 venv、下模型、下预编译二进制、拉起 Open WebUI。27B 目前还在私有期，需要 HuggingFace read token；8B 和 1.7B 已经是公开可下。
我没直接上 27B，先拿 8B Ternary 探路。模型不到 2GB，setup 跑完就能用。脚本会自动判断后端：Apple Silicon 走 MLX fork，其他走 llama.cpp。Mac 上默认会尝试用 Metal offload。
有个小坑：Python 不能是 3.13，因为 Open WebUI 0.10.2 还依赖 audioop。我本地之前升了 3.13，结果脚本报错，手动切到 3.12 才过。这个点仓库 README 写了，但我没细看，算自己的问题。
跑起来什么感觉
8B Ternary 在 Mac 上 CPU+Metal 混合跑，日常问答基本跟普通 Q4 量化的 8B 差不多。复杂数学题和代码题能感到一点”钝”，但不是那种完全不能用的崩法。最让我意外的是上下文：8B 标称 65K，我试了 30K 左右的文档摘要，没有明显掉链子。
至于 27B，我没下。3.9GB/5.9GB 只是权重大小，真正跑起来还有 KV cache、activations、runtime buffer。官方给的参考是 27B Ternary 在 4K context 下峰值约 7.8GB，100K context 会涨到 13.7GB；开了 4-bit KV cache 后 100K 能压到 9.2GB。16GB Mac 理论上能跑，但已经比较紧张，再多开几个浏览器标签就得小心。
iPhone 上跑 27B？能，但有条件
这是 Bonsai 最大的噱头。官方数据：iPhone 17 Pro Max 上 1-bit 27B 约 11 tok/s，M5 Max 87 tok/s，RTX 5090 163 tok/s。11 tok/s 不快，但作为一个本地、离线、不上云的 27B 助手，已经能用了。
不过要注意，iPhone 给单个 app 的内存上限大约 6GB。3.9GB 权重加 runtime 后，官方说峰值约 5.5GB（4K context），刚好挤进去。上下文稍微拉长就会吃紧。所以这个”能跑”是有严格前提的：短上下文、低并发、纯聊天。
1-bit 量化到底图什么
我觉得 Bonsai 的价值不是让 27B 模型跟满血版一样强，而是把”大模型随身携带”这件事从 demo 变成了产品级可能。以前 27B 是工作站 GPU 的事，现在 3.9GB 文件加普通手机就能加载。
代价也明明白白：最难的任务掉分最多，vision 和 agentic 现在还不是它的主场。对我来说，Ternary 版更实用——质量损失小、Mac 能跑、上下文够长。
下一步我想等 27B 公开后，直接在我这台 16GB Mac 上跑长上下文，看看到 100K 时会不会把内存吃满。如果 4-bit KV cache 能稳定，以后本地处理长文档就不用再盯着 7B 小模型了。