跳转至

Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices

Ch01.518 Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices

📊 Level ⭐⭐ | 6.8KB | entities/news-bonsai-image-4b.md

Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices

→ 原文存档

摘要

PrismML 发布 Bonsai Image 4B——基于 FLUX.2 Klein 4B 架构的两种极低比特扩散 Transformer 实现（1-bit 二值化与 Ternary 三值化）。在保持 88-95% 原模型生成质量的前提下，把扩散 Transformer 体积压缩 6.4-8.3 倍，让 4B 级图像生成首次能够本地运行在 iPhone 上。

核心要点

  • 两种变体各有所长：1-bit Bonsai（1.125 有效比特/权重）追求极致压缩，三元 Bonsai（1.71 有效比特/权重）用 0 状态换更好视觉质量与提示词保真度
  • 关键工程改造集中在 Diffusion Transformer：text encoder 与 VAE 仍保留 FP16/FP32，仅对反复运行的 transformer 权重做低比特化
  • 部署栈覆盖 Apple Silicon 与 CUDA：用 MLX low-bit 路径跑 Apple 端，用 Gemlite low-bit GEMM kernel 跑 NVIDIA 端
  • 质量几乎无损：Ternary 在 GenEval/HPSv3/DPG-Bench 三项基准上保留 FLUX.2 Klein 4B 95% 精度；1-bit 保留 88%
  • 开源 Apache 2.0：白皮书、HF 权重、WebGPU demo、iOS App（Bonsai Studio）一并发布

深度分析

量化的"帕累托前沿"被显著外推

扩散 Transformer 的体积从 7.75 GB 压到 0.93-1.21 GB（6.4-8.3 倍），但同参数级别（4B）的精度只损失 5-12%。这不是"为了小而牺牲质量"，而是重新界定了小模型的可用边界：以往要 1 GB 以内只能用 SDXL（5.14 GB）、BK-SDM-Small（0.98 GB, 42% 精度）、SD 1.5（1.72 GB, 51% 精度）这类弱能力模型；现在 Bonsai Image 用同等体积跑出 88-95% 的 FLUX.2 Klein 4B 精度。这是"质量-体积"曲线的实质性外推，不是同曲线上的滑动。

端侧激活内存比部署体积更关键

表格对比中容易被忽视的是 mean-active memory（生成 512x512 图时）——1-bit 与 Ternary 分别只要 1.5 GB 与 1.96 GB，而原模型要 11.74 GB（降 6-7.8 倍）。原因是 text encoder 在 prompt 编码完成后就被 offload，留下的 VAE + 低比特 transformer 是真正的运行常驻集。对消费级设备的"能不能跑起来"问题，部署体积是必要条件，激活内存才是充分条件——FLUX.2 Klein 4B 即使能装下，iPhone 17 Pro Max 也放不下激活集；Bonsai 两种变体都过了这道门槛。

低比特路径必须在硬件栈里实现才有意义

文章明确点出两条 kernel 路线：MLX（Apple 端）和 Gemlite（CUDA 端）。这是 low-bit 量化的硬约束——如果只用 PyTorch 的 torch.quantization 把权重存成 int1/int2 但 GEMM 仍用 fp16 算，推理时还是要做 dequantize 回 fp16，反而增加带宽和延迟 1。Bonsai Image 之所以能跑到 9.4s/图（iPhone 17 Pro Max）和 6s/图（M4 Pro），前提是 MLX/Gemlite 这两条专属 low-bit GEMM kernel 把乘法直接做在量化域内。这意味着"量化推理"不是模型文件属性的事，而是部署栈属性的事——同组权重换一套栈可能慢 3-10 倍。

推理 PaaS 化的反向趋势

文章最后一段（"Why this is important"）的潜台词是"图像生成从云 API 主导转向本地推理成为可行选项"。这与 LLM 领域的端侧化（Apple Intelligence、Gemini Nano、Phi-3-mini）节奏一致。区别在于：图像生成的迭代密度更高（用户改 prompt 是常态），所以每轮 round-trip 的边际成本对创作流的影响被放大。这不是简单的"离线也能跑"，而是把图像生成重新变成"产品内嵌能力"而不是"远程服务"——比如相机 App 内实时风格化、Notion 类工具内即时配图、隐私场景下不外传 prompt 与生成图。

与之前 Bonsai 语言模型一脉相承

文章最后一段提到"同样的帕累托迁移我们在之前的 Bonsai 语言模型上就看到过"。这暗示 PrismML 的技术栈是把通用低比特 transformer 训练框架先在 LLM 上验证（语言模型允许的精度损失更宽容），再迁移到扩散 Transformer 上。给业界信号：low-bit 不是某个垂类模型的孤立技巧，而是 transformer 通用架构属性，扩散 / 语言 / 多模态都可以共享同一套低比特训练范式。

实践启示

  1. 评估低比特方案时用"激活内存"而非"模型体积"做端侧准入判据：模型文件 0.93 GB 不代表能在 2 GB 内存的设备上跑——问清楚 mean-active memory，再决定是否值得接入
  2. 检查部署栈是否原生支持低比特 GEMM：如果只有 PyTorch eager 模式，再小的权重也会被 dequantize 回 fp16 算，得不偿失。生产部署前先在目标硬件上实测端到端延迟
  3. 隐私/低延迟场景优先考虑本地推理：涉及医疗/法律/内部数据的图像生成、UI 实时样式迭代、AR/VR 内即时生成等场景，端侧是云 API 无法替代的选择
  4. 二值化/三值化是 quality-footprint 权衡的硬工具：要极致体积选 1-bit（精度换 12%），要更高保真选 Ternary（精度换 5%）。不要直接套用 4-bit/8-bit 的直觉——在 1-2 比特域内，模型质量曲线非线性
  5. 关注同公司的 Bonsai LLM 进展：PrismML 表明其 low-bit 训练栈是跨模态的，后续多模态/视频模型可能也走这条路，跟踪可提前布局

相关实体

  1. 量化域内 GEMM（如 Gemlite、bitsandbytes、MLX）是低比特推理能跑出真实速度的前提——若权重存为 int1 但乘法仍转 fp16，则收益仅是存储，带宽与延迟不会降低。 ↩