Bonsai 27B 评测：270 亿参数 LLM 真的能在手机上运行吗？

可以，27B 级模型已经能在手机上运行，但有用的答案远比发布标题复杂。PrismML 报告称，Bonsai 27B 的 1-bit 语言权重约为 3.9 GB，在 iPhone 17 Pro Max 上可通过 MLX Swift 达到约每秒 11 token。该模型基于 Qwen3.6-27B，Hugging Face 模型卡标注 Apache 2.0。这是端侧 AI 的真实进展，但并不代表所有 27B 工作负载都能轻松装进所有手机。

同一批证据也说明了压缩的代价。在 PrismML 自己的 15 项基准中，1-bit 版本的平均分达到 FP16 基线的 89.5%。数学和代码保留得较好，指令遵循、视觉和多步骤工具调用下降更明显。质量优先的三值版本保留 94.6%，但当前 GGUF 部署约为 7.2 GB。发布内容常引用的 5.9 GB 是理想表示体积，不是今天实际下载并驻留的 GGUF 体积。

Bonsai 27B 是什么？

Bonsai 27B 是 PrismML 基于 Qwen3.6-27B 制作的 low-bit 模型。原模型是稠密多模态模型，包含 27B 语言主干、视觉编码器和原生 262,144 token 上下文。Qwen 在大部分 block 中使用线性 attention，64 个 block 中只有 16 个使用完整 attention。与全 attention 架构相比，这种混合设计能减慢 KV cache 的增长。

PrismML 提供两个档位。1-bit 版本使用 {−1, +1} 二值权重，每 128 个权重共享一个 FP16 scale，因此实际为每权重 1.125 bit，语言权重约 3.9 GB。三值版本加入零，使用 {−1, 0, +1}，每权重实际 1.71 bit，用更多内存换取更高质量。

这不只是把普通 FP16 checkpoint 导出成通用 1-bit 文件。PrismML 表示，低位宽覆盖 embedding、attention projection、MLP projection 和语言模型 head。定制 CUDA、Metal、MLX 与 WebGPU kernel 会直接读取打包权重，不需要在每个运算步骤中重新展开为 FP16。

27B 模型如何从 54 GB 缩小到 3.9 GB？

FP16 的粗略计算很直接：约 273 亿个语言参数乘以两字节，运行开销之前就接近 54 GB。二值模型为每个权重保存一个符号位，再让 128 个权重共享一个 16-bit scale，结果是每权重 1.125 bit，约为 FP16 的十四分之一。

模型文件大小不等于应用的完整内存需求：

• 驻留语言权重：1-bit 约 3.9 GB，当前三值 GGUF 约 7.2 GB。
• Runtime 与 activation：官方测量在各 backend 上还包含约 1.3 GB。
• KV cache：随实际上下文增长。即使启用 4-bit KV 压缩，完整 262K 窗口仍会让 1-bit 版本的峰值内存达到约 9.4 GB。
• 可选组件：紧凑视觉投影约 0.63 GB，speculative decoding 的 drafter 也会额外占用内存。

这对产品容量规划很关键。权重文件可能满足手机单个 App 的内存预算，最大上下文却未必能装下。最终应在目标设备和目标 runtime 上同时测量权重、真实上下文与运行开销。

Bonsai 27B 真的保留了 Qwen3.6 的 90% 智力吗？

它保留的是厂商基准平均分的 89.5%，不是每项能力都保留 90%。PrismML 使用相同 H100 环境、EvalScope 和 vLLM，在 thinking mode 下评估所有版本。相同条件让横向比较有价值，但这些结果尚未被独立复现，而且平均值掩盖了不同能力之间的大幅差异。

单项结果更能说明问题。1-bit 版的 MATH-500 从 99.40 降至 98.00，BFCL v3 从 77.10 降至 70.72，但更困难的多步骤 τ²-Bench 从 82.90 降至 61.34，IFBench 从 68.03 降至 52.36，MMMU-Pro 从 79.94 降至 60.48。压缩损失恰好落在长链 Agent 最容易累积错误的位置。

PrismML 自己的模型卡也明确表示，涉及多个文件、长周期 run-test-repair 的 agentic coding 还不是该版本的强项。对采购决策来说，这条限制比四舍五入后的 90% 标题更重要。

Bonsai 27B 真的能在手机和笔记本上本地运行吗？

可以，但需要受支持的高端硬件和匹配的 runtime。PrismML 报告 MLX Swift 版本在 iPhone 17 Pro Max 上约为 11 tok/s。1-bit GGUF 的 llama-bench 数据显示，生成 128 token 时，M4 Pro 为 26.0 tok/s，M5 Pro 为 44.2，M5 Max 为 66.4。三值 GGUF 在相同笔记本类别上分别为 18.0、26.2 和 44.0 tok/s。

这些数字不能直接互换。手机、Metal、CUDA 和 WebGPU 使用不同 kernel、上下文长度、功耗限制与测试协议。Prompt processing 和 token generation 也是两个阶段。Decode 很快，并不代表长文档的首 token 延迟一定很短。

浏览器中每秒 90 token 的说法可靠吗？

Joshua Lochner 的 Hugging Face Space证实了最重要的部分：Bonsai 27B 可以通过定制 WGSL compute shader 在浏览器本地运行。页面称 kernel 由 Fable 5 和 GPT 5.6 Sol 编写与优化，并在纳入前针对正确性和具体 tensor shape 做过基准。权重下载完成后，模型推理和对话都留在设备上。

但公开 demo 源码并没有为广泛传播的 90 tok/s 提供硬件型号、浏览器版本、上下文、warm-up 状态或可重复的测试协议。因此应把它视为 demo 结果，而不是容量常数。采购测试应记录浏览器、GPU、功耗模式、输入与输出长度、首 token 延迟、持续 decode、峰值内存以及多轮运行后的温控降频。

Bonsai 27B 可以在哪些场景创造商业价值？

• 私有文档助手：在本地对敏感文件做摘要、分类和抽取，不把内容发送给模型 API，但前提是应用的其他部分也保持本地。
• 离线现场软件：为网络不稳定环境中的技术人员、检查人员和移动团队提供帮助。
• 端侧产品功能：模型部署后，以可预测的本地延迟提供文本辅助，不再按网络 token 付费。
• 混合 Agent 路由：把私密且边界清晰的步骤留在本地，把高难推理或脆弱工具流程交给更强的云模型。
• 单机试点：先在笔记本或中小型 GPU 上评估 27B 级能力，再决定是否采购长期推理集群。

真正有价值的产品仍然是模型周围的系统。Wavect 的 AI enablement 服务覆盖用例选择、eval、数据访问、路由、部署、可观测性与团队交接。Twinsoft AI 案例也说明，生产价值来自工作流和控制措施，而不是参数数量。

企业应该选择哪个 Bonsai 27B 版本？

本文只负责回答 Bonsai 的具体部署问题。更广泛的模型家族选择，请查看我们的 2026 开放权重 LLM 对比。硬件与 API 的财务决策，请使用本地模型与 API 盈亏平衡计算器。分开这三种搜索意图，可以避免产品评测与市场对比、基础设施经济性互相争夺同一主题。

Bonsai 27B 试点应该测量什么？

1. 固定产物和 runtime：记录 Hugging Face revision、权重 hash、backend fork、kernel commit、设备、OS 与 MLX 或浏览器版本。
2. 测量完整内存：包括权重、runtime、预期上下文、KV 格式、视觉投影和可选 drafter。
3. 建立业务 eval：至少使用 50 到 100 个真实任务，覆盖格式约束、工具 schema、拒答和不可接受的失败。
4. 拆分延迟阶段：分别记录首 token、prompt processing、持续 decode 和多轮 warm run。
5. 验证离线与隐私边界：检查模型下载、分析、crash reporting、日志、embedding 与 fallback。模型本地不代表整个应用本地。
6. 按成功结果计算成本：把设备支持、工程、更新分发、监控和 fallback 与托管 API 比较。
7. 设计回滚：为不兼容设备、过载或质量失败保留已验证模型和服务器路径。

我们的 MVP 技术栈选择指南采用同一原则：优先决定未来最昂贵、最难逆转的约束。对端侧 AI 来说，通常是最低支持硬件和最关键工作流的质量，而不是下载文件大小。