Bonsai：把 27B 大模型塞进手机的极端量化方案，到底靠不靠谱？

Bonsai把 27B 大模型塞进手机的极端量化方案到底靠不靠谱来源PrismML-Eng/Bonsai-demoGitHub README交叉验证信源博客园 ninghg《把 27B 模型压到 4GB 跑在手机上》、Microsoft Azure Labs《BitNet b1.58 2B4T》核心观点PrismML 发布的 Bonsai 系列是一组以Qwen3.6 27B 为基底、通过端到端而非事后压缩极端量化训练得到的语言模型。旗舰是 Bonsai-27B分两个量化档1-bit Bonsai有效比特数 ~1.125 bpw模型文件3.9 GB目标跑上 iPhone 17 Pro6 GB 内存预算Ternary-Bonsai有效比特数 ~1.71 bpw打包为 2-bit 加速核模型文件5.9 GB官方默认推荐质量更高两个家族均支持视觉、工具调用OpenAI 风格 tool_calls MCP、长上下文256K和推理思考reasoning effort 可调。关键机制量化不是压缩而是训练方式理解 Bonsai 最关键的一个点它不是把已有的 FP16/BF16 大模型事后量化而是从训练阶段就把权重约束为极端低比特{-1, 1} 或 {-1, 0, 1}再配合 FP16 的 group-wise scaling factor 做补偿。这和传统 GPTQ/AWQ/4-bit PTQ 的逻辑根本不同后者在一个已经训练好的全精度模型上做近似损失是累积叠加的而 BitNet/Bonsai 路线让模型在训练时就学会用极端低比特表达信息理论上损失更小、泛化更自然。这也是 Microsoft BitNet b1.58W1.58A8同为三值权重 训练时设计最核心的贡献——它们共享同一个范式都在挑战表达能力必须依赖高比特宽度这个长期默认假设。Ternary 的理论存储下限是 5 trits/8 bits ≈ 1.6 bits/tritBonsai Ternary 实际达到了 1.71 bpw已经非常接近理论极限——这意味着后续在当前架构下靠 packing 继续压缩的空间几乎没有了下一步必须动架构MoE、稀疏、不同数值格式。性能数据指标1-bit Bonsai-27BTernary-Bonsai-27B有效比特1.125 bpw1.71 bpw模型大小3.9 GB5.9 GBvs baseline 能力保留~90%~95%RTX 5090 吞吐163 tok/s134 tok/sM5 Max 吞吐87 tok/s58 tok/s智能密度per GB0.53baseline 的10×—Context 长度256K256KMath/Coding 损失极小Tool Calling 损失几个点官方说法——恰好是 Agentic 场景最依赖的能力这个损失值得警惕。快速上手代码示例# 克隆仓库 git clone https://github.com/PrismML-Eng/Bonsai-demo.git cd Bonsai-demo # 设置 HuggingFace token27B 私有期需要 export BONSAI_TOKENhf_your_token_here # 一键安装依赖 下载模型默认 Ternary-Bonsai-27B ./setup.sh # 启动本地服务器支持聊天/视觉/工具调用 ./scripts/start_llama_server.sh # 访问 http://localhost:8080切换模型家族和尺寸# 下载并运行 Ternary-Bonsai 4B更小适合低内存机器 BONSAI_FAMILYternary BONSAI_MODEL4B ./scripts/download_models.sh BONSAI_FAMILYternary BONSAI_MODEL4B ./scripts/run_llama.sh -p Hello! # 用 mainline llama.cpp 跑CPU/Metal无需 fork hf download prism-ml/Ternary-Bonsai-4B-gguf Ternary-Bonsai-4B-Q2_0_g64.gguf --local-dir models模型尺寸矩阵系列1.7B4B8B27B含视觉1-bit Bonsai✅ GGUF/MLX✅✅✅Ternary-Bonsai✅ GGUF/MLX(2bit)✅✅✅默认后端支持现状2025年7月1-bitQ1_0已完整合并进 llama.cpp 主线所有后端可用。TernaryQ2_0/Q2_0_g64仍处于分批合并中当前状态后端状态CPUARM NEON generic✅ 已合并主线Metal✅ 已合并主线Vulkan PR 审核中CUDA PR 审核中x86 AVX-512-VNNI⏳ 待开发实际结论Mac 用户用 mainline llama.cpp *-Q2_0_g64.gguf无需 forkCUDA 用户目前需要用 PrismML 的 fork 预编译二进制不能开箱即用 Ollama/LM Studio。交叉验证信源一博客园 ninghg《把 27B 模型压到 4GB 跑在手机上》总体认同官方核心主张并补充了独立实测数据和批判性发现实测吞吐数字RTX 5090 163 tok/s、M5 Max 87 tok/s与官方数字吻合指出了 LM Studio / Ollama 当前均无法直接运行需要自编译 PrismML fork——这是官方 README 没有明确强调的引用了 HN 用户 verdverm 的第三方评测wikitext 困惑度 16.75 vs 官方数字与官方数字存在显著 gap作者认为可能是 eval bug但无法完全排除模型实际质量的问题明确指出Tool Calling 损失几个点这一点对 Agentic 场景是实质性风险不是可以忽略的尾注独立结论端侧隐私敏感场景有真实价值但一行命令快速部署的叙事当前不成立信源二Microsoft Azure Labs《BitNet b1.58 2B4T》提供了技术路线的背景参照系部分佐证了 Bonsai 的底层逻辑但并不直接评价 BonsaiBitNet b1.58同为三值权重、训练时极端量化在 ARM CPU 上实现 1.37x–5.07x 加速能耗降低 55–82%证明这条路线在 2B 规模确实成立然而 BitNet 目前公开验证的最大规模是 2B4 万亿 tokenBonsai 直接做到 27B 是一个规模上的大跳Microsoft 自己在这个参数量上尚未有对应成果BitNet 的核心贡献也强调训练时设计而非事后压缩与 Bonsai 技术路线一致说明这不是 PrismML 孤立的论断而是一个有独立研究支撑的方向综合判断官方的核心技术方向端到端极端量化 事后压缩被 BitNet 路线的学术工作所支持是可信的但 27B 规模下质量保留的具体数字尚未经过充分的第三方独立复现存疑。个人启发该怎么用不该怎么用现在就可以做的隐私敏感的本地 Agent医疗问答助手、法律合同审阅、内部知识库 QAApache 2.0 开源、本地运行、27B 级推理能力这是目前最小内存需求和最强能力的组合有真实的采用价值Apple Silicon 开发者Mac 上 CPU/Metal 已进主线用Ternary-Bonsai-4B-Q2_0_g64.gguf配合 mainline llama.cpp 现在就能稳定跑是代码补全/文档摘要的可用选项希望在端侧跑视觉理解的场景截图分析、文档 OCR 辅助值得试用但要自己验证多模态精度官方未披露详细的视觉 benchmark现在还不适合做的生产环境 CUDA 服务Ternary 的 CUDA kernel 还在 PR 审核中需要依赖 PrismML 私有 fork 的预编译二进制引入了不可控的依赖风险高频 Agentic Tool Calling 流水线Tool Calling 能力有明确损失在多轮 Agent 循环中的可靠性未经验证替代 Claude / GPT-4o 做前沿任务27B 无论量化与否当前能力天花板仍远低于顶级闭源模型这不是量化可以弥补的差距延伸思考端到端训练量化路线的扩展极限在哪里BitNet 和 Bonsai 都证明了 2B–27B 可以做但从 27B 到 100B三值权重能否保持 90% 的能力保留率训练成本和数据需求会不会成为决定性瓶颈让这条路线只能在小公司手里停在 30B 以下极端量化会不会改变参数量的意义当 1-bit 27B 体积和速度都接近甚至优于 4-bit 7BX B 模型的直觉对比就失效了。业界评测体系MMLU、HumanEval 等是否需要专门针对极端量化模型重新设计以更准确反映其真实可用性iPhone 上的 27B LLM 是否真的改变了移动端 AI 的格局官方说 1-bit-27B 能跑上 iPhone 17 Pro但 90% 能力保留 手机 SoC 推理速度远低于 M5 Max 的 87 tok/s的实际用户体验能否超越当前苹果 Intelligence 或 Gemini Nano 的路线还是说这只是一个工程可行性演示并不代表实际产品体验的跃升 参考来源GitHub - PrismML-Eng/Bonsai-demo: Bonsai Demo · GitHub