PrismML 宣布推出基于 Qwen3.6 的多模态模型 Bonsai 27B，并声称它能在保留约 90% 智能水平的同时，于配备 12GB 内存的 iPhone 17 Pro 上本地运行。真正值得关注的并不只是“27B 参数进入手机”，而是低比特权重、统一内存和端侧推理正在共同改变移动 AI 的部署边界。
3-bit 与 1-bit 版本解决的是不同问题
根据公开介绍，Bonsai 27B 提供 3-bit 和 1-bit 两种变体。3-bit 版本使用三进制权重，模型文件约为 5.9GB，定位偏向性能，也可以在普通笔记本电脑上运行。摘要没有给出 1-bit 版本的准确文件大小、速度和质量数据，因此不宜据此推算具体指标。
低比特量化的核心收益是减少权重占用和内存带宽压力。一个 27B 模型若以 FP16 保存，仅原始权重理论上就需要约 54GB；量化后，权重文件才有机会进入移动设备可承受的范围。不过，文件能存进手机并不等于模型就能稳定运行。
推理期间还需要容纳运行时、图像编码中间结果、激活值、KV Cache 以及操作系统和其他应用。iPhone 的统一内存由 CPU、GPU 和系统共同使用，不能把标称 12GB 全部交给模型。5.9GB 权重只是内存预算的起点。
“保留 90% 智能”需要基准和场景定义
PrismML 使用“保留 90% 智能”描述量化后的能力，但这个数字只有在给出基准模型、评测集、任务权重和推理参数后才容易复现。文本问答、代码生成、OCR、视觉理解和长上下文推理对量化误差的敏感程度并不相同。
团队评估这类模型时，可以把抽象的百分比拆成可验证指标：
- 首个 token 延迟和持续生成速度；
- 峰值内存与长对话中的内存增长；
- 固定测试集上的准确率或人工评分；
- 图片输入后的温升、耗电和崩溃率；
- 3-bit 与 1-bit 在同一提示词、同一采样参数下的输出差异。
端侧多模态模型还应单独测试图片尺寸。高分辨率图片可能产生更多视觉 token，并显著抬高推理内存和延迟。
先做内存预检，再接入移动端
由于摘要没有披露 Bonsai 27B 的层数、KV Head 数、上下文上限和官方运行时接口，下面是一个可直接运行的预算工具，而不是 Bonsai 的官方配置。把参数替换为实际模型配置后，它可以粗略估算 KV Cache，并检查 12GB 设备还剩多少余量。
将下面内容保存为 memory_budget.py，然后运行 python memory_budget.py --help 查看参数：
#!/usr/bin/env python3
import argparse
GIB = 1024 ** 3
def gib(value: int) -> float:
return value / GIB
def main() -> None:
parser = argparse.ArgumentParser(description="Estimate on-device LLM memory usage")
parser.add_argument("--weights-gb", type=float, default=5.9)
parser.add_argument("--device-gb", type=float, default=12.0)
parser.add_argument("--system-reserve-gb", type=float, default=3.0)
parser.add_argument("--runtime-gb", type=float, default=1.0)
parser.add_argument("--layers", type=int, default=64)
parser.add_argument("--kv-heads", type=int, default=8)
parser.add_argument("--head-dim", type=int, default=128)
parser.add_argument("--tokens", type=int, default=4096)
parser.add_argument("--kv-bytes", type=int, default=2,
help="Bytes per KV element, for example 2 for FP16")
args = parser.parse_args()
kv_bytes = (
2 # key and value
* args.layers
* args.tokens
* args.kv_heads
* args.head_dim
* args.kv_bytes
)
kv_gb = gib(kv_bytes)
estimated = args.weights_gb + args.runtime_gb + kv_gb
available = args.device_gb - args.system_reserve_gb
margin = available - estimated
print(f"Weights: {args.weights_gb:.2f} GiB")
print(f"KV cache: {kv_gb:.2f} GiB")
print(f"Runtime/working: {args.runtime_gb:.2f} GiB")
print(f"Usable memory: {available:.2f} GiB")
print(f"Estimated margin: {margin:.2f} GiB")
print("Result:", "likely fits" if margin >= 0 else "over budget")
if __name__ == "__main__":
main()
例如，可以这样比较 4K 与 16K 上下文。这里的模型结构参数只是演示假设，必须根据实际配置修改：
python memory_budget.py --tokens 4096
python memory_budget.py --tokens 16384
这个估算仍未覆盖所有激活值、视觉编码器缓存和运行时临时缓冲区，因此不能替代真机峰值内存测试。它的作用是在集成前暴露明显不可行的配置。
适合落地的路径
Bonsai 27B 所代表的方向很明确：高参数量模型正在通过极低比特量化进入手机和普通笔记本电脑。本地运行可以减少网络依赖，让敏感图片和文本留在设备上，也能避免云端推理的逐次调用成本。
采用前应核对四件事：模型许可证是否允许目标用途；1-bit 与 3-bit 的真实任务质量是否达标；目标设备在长上下文和图片输入下是否会触发内存压力；运行时是否能利用 Apple GPU 或 Neural Engine，而不是仅仅做到“可以加载”。
对于生产应用，更稳妥的策略是先用 3-bit 版本建立质量基线，再评估 1-bit 版本能否换取足够明显的速度、内存或能耗收益。端侧模型的最终标准不是参数量，也不是权重文件大小，而是它能否在真实设备上持续、稳定并可预测地完成任务。