一台 iPhone 跑 4B 级图像生成模型，这件事最反常的地方，不是“手机又变强了”，而是模型没有被砍到很小。
PrismML 在 5 月 26 日发布 Bonsai Image 4B 系列，基于 FLUX.2 Klein 4B，提供 1-bit 和 ternary 两个低比特版本。目标很直接：让扩散推理在 iPhone、Mac 和 CUDA GPU 等本地设备上跑起来。
公司称，这是其所知首个能直接在 iPhone 上运行的同参数级图像模型。这个说法目前仍是厂商口径，不能当成第三方验证过的行业结论。
我更在意的是另一件事：Bonsai Image 4B 是否真的把 4B 图像模型推进到本地可用区间，而不是只做了一次参数压缩展示。
先看内存账：它确实把 4B 模型压进了端侧门槛
Bonsai Image 4B 的路线不是重做一个小模型，而是保留 FLUX.2 Klein 4B 的架构，改写扩散 Transformer 的权重表示。
1-bit 版本使用 {-1,+1} 权重，并配合 FP16 分组缩放，等效 1.125 bit/weight。ternary 版本使用 {-1,0,+1}，等效 1.71 bit/weight。
这不是一句“低比特”能概括的事。端侧部署要看三笔账：扩散 Transformer 体积、完整部署包、运行时平均活跃内存。只看压缩率，很容易误判。
| 项目 | FLUX.2 Klein 4B | 1-bit Bonsai | Ternary Bonsai |
|---|---|---|---|
| 扩散 Transformer 体积 | 7.75GB | 0.93GB | 1.21GB |
| Apple Silicon 部署包 | 15.97GB | 3.42GB | 3.88GB |
| 512x512 平均活跃内存 | 11.74GB | 1.5GB | 1.96GB |
| iPhone 17 Pro Max 生成 512x512 | 无法装入内存 | 约 9.4 秒 | 约 9.4 秒 |
| Mac M4 Pro 生成 512x512 | — | 约 6 秒 | 约 6 秒 |
这张表里最关键的是 iPhone 17 Pro Max 那一行。原始全精度 FLUX.2 Klein 4B 无法装入内存，Bonsai 两个版本可以生成 512x512 图片。
这就从“理论上能压缩”变成了“至少在指定旗舰设备上能跑”。门槛不一样。
但也要把边界说清楚。扩散 Transformer 从 7.75GB 降到 0.93GB，不等于完整 App 只有 0.93GB，也不等于运行时只吃 0.93GB。部署包、缓存、运行时内存，都是另外的账。
对端侧 AI 应用开发者来说，这个变化的直接含义是：可以把本地图像生成重新放进原型验证清单里。以前很多团队默认走云端，现在至少可以评估“部分生成任务放本地”。
但不适合立刻全量迁移。尤其是面向大众设备的产品，不能把 iPhone 17 Pro Max 的结果外推到旧款 iPhone、Android 或 Windows 设备。PrismML 目前没有给出这些平台的速度数据。
再看画质账：ternary 像工具，1-bit 更像极限体积方案
低比特图像模型最容易被一句话带偏：体积小了，能跑了，好像就够了。
不够。图像生成不是只看能不能出图，还要看提示词遵循、构图稳定性、细节质量和连续重试时的表现。
按 PrismML 给出的 GenEval、HPSv3、DPG-Bench 综合数据，Ternary Bonsai 保留 FLUX.2 Klein 4B 约 95% 的表现，1-bit 版本约 88%。
这组数字给出的取舍很清楚：
| 版本 | 权重表示 | 等效位宽 | 质量保留 | 更适合的取向 |
|---|---|---|---|---|
| 1-bit Bonsai | {-1,+1} + FP16 分组缩放 | 1.125 bit/weight | 约 88% | 体积优先、下载敏感、轻量试验 |
| Ternary Bonsai | {-1,0,+1} | 1.71 bit/weight | 约 95% | 画质优先、本地应用原型、交互式生成 |
我的判断是，ternary 才是更值得开发者先看的版本。它多占一点体积，但换来更高的质量保留。对贴纸、草图、设计预览、试衣这类场景，稳定性往往比极限压缩更重要。
1-bit 也有价值，但定位要准。它更像“能不能把包压到更小”的方案，不是最佳画质方案。
这里有一个行业现实对照。过去端侧图像生成常见路线，是使用更小的 Stable Diffusion 1.5、SDXL 剪裁版，或移动端专门模型。优点是容易塞进设备，问题是能力上限也容易被一起剪掉。
Bonsai 的思路不同。它没有先把模型规模打小，而是把较大的 4B 模型低比特化。若后续数据能被独立复现，它给开发者多了一个中间选项：不必每次都上云，也不必直接退回“小模型低能力”。
但现在不能把它写成全精度模型的平替。1-bit 和 ternary 都有损失，尤其 1-bit 的取向很明确：用画质换体积。
对开发者的影响：先改验证顺序，不急着改产品架构
本地图像生成的价值，主要落在三件具体事上：成本、隐私、交互速度。
云端生成每次调用都有推理成本。用户改一次提示词、换一组图、重试一次，都是服务器账单。端侧推理把成本更多转成下载包、本地算力和电量消耗。
这对高频迭代场景很有吸引力。比如草图、贴纸、商品预览、轻量修图、试衣效果图。用户不一定要一张终稿，常常要的是连续试十几次。
隐私也不是虚话。很多提示词会带产品图、室内照片、未发布素材或个人肖像。模型在本地跑，不能自动解决全部合规问题，但能减少远程传输和云端留存带来的顾虑。
所以，最相关的两类人可以这么做：
- 端侧 AI 应用团队.先用 ternary 做本地原型验证，把 1-bit 留给下载体积极敏感的功能点，不要一上来押注全量替代云端。
- 技术决策者或采购方.可以延后“必须云端生成”的默认判断，但迁移决策要等第三方复现、连续运行数据和目标设备覆盖情况。
接下来真正该看的不是发布页里的单张样图，而是三组变量。
第一，Apache 2.0 下开放的权重与代码，社区能不能复现 PrismML 给出的速度和质量保留。能复现，才有工程讨论的基础。
第二，Bonsai Studio iOS 应用在真实负载下的发热、耗电和稳定性。9.4 秒生成一张图是起点，连续用 20 分钟才接近真实体验。
第三，设备覆盖能不能从 iPhone 17 Pro Max 和 Mac M4 Pro 扩到更多用户手里的机器。目前没有 Android、Windows、旧款 iPhone 或其他芯片的数据，就不能替它们下结论。
这也是 Bonsai Image 4B 最有意思的地方：它不是把问题彻底解决了，而是把问题从“4B 图像模型能不能上手机”推进到“上了手机后能不能长期好用”。
前者是技术门槛，后者才是产品门槛。