Bonsai Image 4B Runs a FLUX-Class Model on an iPhone. The 95% Number Hides Where It Costs You.
A 4B diffusion transformer squeezed to 1.21 GB with three-value weights, what it actually costs in image quality, and how to run it on a Mac this afternoon.
Every weight in the matrix-heavy layers of Bonsai Image 4B is one of three numbers. Minus one, zero, or plus one, with a single shared scaling factor per group of 128 weights doing the work of restoring range. That covers all 100 matmul-heavy linears across the model's 25 transformer blocks. A remainder of under 5% of the parameters, the modulation streams and embedders and output norm, stays at FP16 because the quality falls apart otherwise.
The model this came from, FLUX.2 Klein 4B, ships a 7.75 GB transformer in FP16. PrismML's ternary version is 1.21 GB. Same architecture, same block count, same parameter count. They did not prune anything or distill a smaller student. They changed what a weight is allowed to be, and the file got 6.4 times smaller.
The interesting part is not the compression. It is that PrismML published the quality cost in enough detail to argue with, and the number most people repeated is not the number that will bite you.
The claim, and the number underneath it
PrismML released Bonsai Image 4B on May 26, 2026, under Apache 2.0, in two variants. The binary version uses two-value weights and lands at 0.93 GB, an 8.3x reduction. The ternary version adds the zero state, lands at 1.21 GB, and is the one they recommend.
The headline in the launch post and in most of the coverage that followed: the ternary model retains 95% of FLUX.2 Klein 4B's quality across GenEval, HPSv3, and DPG-Bench. That figure is real. PrismML does not state how they arrived at it, but the arithmetic only works one way, and their own benchmark table on the model card is where the 95% falls apart into something more useful.
The first four columns below are PrismML's, including their descriptions of what each benchmark measures. The Retained column is mine, calculated from their numbers.
| Benchmark | What it measures | FLUX.2 Klein 4B | Ternary Bonsai 4B | Retained |
|---|---|---|---|---|
| GenEval | object composition, attribute binding | 0.819 | 0.723 | 88.3% |
| HPSv3 | human preference, aesthetics | 12.84 | 12.22 | 95.2% |
| DPG-Bench | dense prompt following | 0.853 | 0.851 | 99.8% |
Average those three ratios and you get 94.4%, which is the 95% everyone quoted. It works the same way for the binary variant, whose three ratios average to 88.4% against a published claim of 88%. So the method is not in doubt. But those three benchmarks are not interchangeable, and they do not fail in ways you notice equally.
DPG-Bench barely moves. Aesthetic preference gives up about 5%, which in practice means the pictures still look good. GenEval drops 11.7% relative, and GenEval is the one that measures whether the model puts the right number of the right objects in the right spatial relationship with the right attributes attached.
That is the failure mode you hit on your third prompt. Two red mugs on the left, one blue bowl on the right. The ternary model is measurably worse at that specific job than the model it came from, and no amount of aesthetic polish covers it. The binary variant is worse still, at 0.671 GenEval.
Two things keep that from being a hit piece. First, 0.723 still beats FLUX.1-schnell at 0.716, and schnell carries a 23.8 GB transformer. It buries SDXL at 0.300 and PixArt-Sigma XL 2 at 0.541. Against anything in its own size class, this model is not close to being beaten on composition. The deficit only exists relative to the model it was compressed from.
Second, PrismML published the disaggregated table themselves. They did not hide it. The averaging happened downstream, in the summaries, and it is worth undoing before you plan a workflow around this model.
One caveat that cuts against my own argument, and PrismML flags it on the card: GenEval was run using the official 512 by 512 protocol, while HPSv3 and DPG-Bench were evaluated at 1024 for larger-backbone models. So the benchmark I am leaning on hardest was measured at the resolution I will later tell you to treat as a preview. That does not make the gap disappear, but it does mean nobody has published a composition score for this model at its native resolution. Nor has anyone outside PrismML published an evaluation of it at all. Every number in this article is the vendor's own, and it should be read as directionally useful until someone independent runs it.
Where the size actually goes now
The second thing the launch framing obscures is that the transformer stopped being the big file.
The Apple Silicon deployment payload for the ternary model is 3.88 GB. It breaks down like this: 1.43 GB for the MLX-packed diffusion transformer, 2.28 GB for the compressed text encoder, and 0.17 GB for the FP16 VAE. The text encoder is a 4-bit Qwen3-4B, and it is now the largest single component by a wide margin.
Note also that 1.43 GB and not 1.21 GB. The 1.21 GB figure is the model-level ternary representation. The MLX deployment pack stores ternary values in 2-bit slots with the fourth code unused, plus alignment overhead, so what you actually download is 18% larger than the number in the headline. PrismML says this plainly in the model card. It is the sort of gap that usually goes unmentioned.
Run the arithmetic on what further compression buys. Going from ternary to binary shrinks the transformer from 1.21 GB to 0.93 GB, and the whole payload from 3.88 GB to 3.42 GB. That is a 12% smaller download, and it costs another seven points of relative benchmark performance by PrismML's own accounting. The transformer is no longer the constraint. Their limitations section says as much: once the transformer is compact, the VAE becomes a more visible memory bottleneck, which the runtime handles with tiled decoding at 128-pixel tiles rather than by shrinking it further.
That reframes what this release is. It is not a step on a road toward ever-smaller diffusion transformers. It is the point at which the diffusion transformer stopped being the interesting part of the memory budget.
The speed numbers, measured on real devices
At runtime the text encoder is offloaded after it encodes the prompt, so the denoising loop only holds the compact transformer and the VAE. That is why mean-active memory is much lower than the payload size.
On an M4 Pro at 1024 by 1024, mean-active memory is 2.38 GB against 14.39 GB for the stock FP16 MFLUX pipeline. Generation takes 24.26 seconds, about 5.6x faster than stock FP16. At 512 by 512 it is 5.78 seconds.
On an iPhone 17 Pro Max, which has 12 GB of unified memory, a 512 by 512 image takes 9.4 seconds and a 1024 by 1024 image takes 34 seconds. The full-precision FLUX.2 Klein 4B pipeline does not fit on that phone at all. PrismML claims this is the first image model in its parameter class to run directly on an iPhone, and I have not found a counterexample, though "in its parameter class" is doing some work in that sentence.
The sampler is four steps of FlowMatchEuler at guidance 1.0 and shift 3.0. No classifier-free guidance, which means no negative prompts and no doubled compute per step. The model card is explicit that running more than four steps does not meaningfully help and can introduce artifacts. Believe them on this. The step count is baked into the design, not a knob to tune.
Put this into practice
The lowest-friction path takes about two minutes and no install.
1. Try it hosted first. PrismML runs a Space at huggingface.co/spaces/prism-ml/Bonsai-Image-Demo, and the webml-community group maintains a separate WebGPU build at huggingface.co/spaces/webml-community/bonsai-image-webgpu that generates in the browser tab. The WebGPU one still pulls weights down before it runs, so it is not instant, and I have not confirmed it uses the same ternary pack rather than its own conversion. Either way, give it a composition prompt with counted objects. That is the axis where this model is weakest, so test the weakness before you commit disk space to it.
2. Run it locally on a Mac. The demo repo sets up a FastAPI backend and a Next.js frontend in one pass:
git clone https://github.com/PrismML-Eng/Bonsai-Image-Demo.git
cd Bonsai-Image-Demo
./setup.sh
./scripts/download_model.sh # ternary is the default
./scripts/serve.sh
The download step is the slow part. Everything else is quick. If you only want a single image and no web interface:
./scripts/generate.sh --prompt "A bonsai tree in a quiet ceramic studio, soft morning light"
3. Ask for 1024 explicitly. This is the setting people get wrong, and the tooling works against you: the demo scripts default to 512 by 512 as a fast preview, while the model card says 1024 by 1024 is the design target and 512 is for quick looks. Pass --size 1024x1024 when you want the real thing. On an M4 Pro the difference is 5.78 seconds against 24.26 seconds, which is real but not painful. Use 512 for scanning through seeds, then rerun your keeper at 1024. The demo repo's own FAQ lists out-of-memory at 1024 as a known Windows failure, so on CUDA check your headroom first.
4. Write prompts for a no-CFG model. Guidance is fixed at 1.0 and there is no classifier-free guidance, so negative prompts have nothing to act on. PrismML's card says only that they "are not required"; my read of a no-CFG pipeline is that they do nothing at all, and that is my inference rather than their claim. Drop the "highly detailed, 8k, masterpiece" tail too, since the model was not trained to respond to that kind of steering. Plain descriptive language does better. Aspect ratios work at any multiple of 32, including 832 by 1248 and 1248 by 832.
5. If you are on NVIDIA, use the gemlite pack. There is a bonsai-image-ternary-4B-gemlite-2bit build for CUDA on Linux and Windows. There is also an unpacked FP16 safetensors repo, which exists so you can run the model in stock diffusers or anything else that does not speak PrismML's low-bit packs yet. It works, it is just full size and gives you none of the speed or memory advantages, and PrismML strongly recommends the optimized packs instead.
For iOS, PrismML ships Bonsai Studio on the App Store with ternary as the default variant, which is the fastest way to see phone-side generation without writing Swift.
Where it breaks
The composition weakness is the big one, and I have already made that case. Small text, fine detail, object counts, and strict spatial constraints are all named in the model card's own limitations list. If your work is product shots with legible packaging, or anything where "three of these, two of those" has to be exactly right, run your own comparison before committing.
It is not bit-identical to FLUX.2 Klein 4B, and PrismML says so directly. This matters if you were hoping to prototype locally and render the same seed on a server. You will not get the same image.
There is no standard native ternary execution path in today's commodity inference stacks, which is PrismML's own phrasing and worth keeping precise. The gains come from MLX's low-bit kernels on Apple Silicon and gemlite's low-bit GEMM on CUDA, both of which route a format the tooling does not speak natively through the closest thing it does. Performance is therefore tied to those two projects staying maintained, and it is why the theoretical 9.4x storage reduction shows up as a practical 6.4x.
The benchmarks were run on H100s at matched settings, not on the devices this model targets. Nothing wrong with that methodology, but the quality numbers and the speed numbers come from different hardware, and the model card is clear about which is which.
Adoption is modest rather than absent, and the shape of it is interesting. Across the Bonsai Image collection the six repos pull roughly 5.6k downloads a month, with the CUDA gemlite pack at about 3.1k outdrawing the Apple Silicon MLX pack at about 1.9k by nearly two to one. The demo repository has 531 stars. The WebGPU Space has 336 likes. So the on-device story that got the headlines is not where most of the actual usage is going. Three months after release, for an Apache 2.0 model that fits on a phone, that is a smaller number than the pitch implies and a more lopsided one than I expected.
What I would do with it
If I were shipping a creative app right now, this changes the calculation in one specific way: the marginal cost of a generation goes to zero. The iterative loop that makes image work actually work, where you generate twenty variations and keep two, stops being something a user has to meter against a credit balance.
That is worth more than the last few points of GenEval for a lot of products, and worth nothing at all for others. A moodboard tool wants volume and does not care much about exact object counts. A packaging mockup tool cares about almost nothing else.
The question I keep turning over is what happens to the text encoder. It is 2.28 GB of a 3.88 GB payload and it runs exactly once per prompt. Nobody has published a ternary text encoder for a diffusion pipeline that I can find, and if PrismML applies the same treatment there, a 4-bit encoder at 1.71 effective bits lands near 0.97 GB and the whole payload drops under 3 GB. That is the point where this stops being a model you download and starts being a model you ship inside an app bundle.
If you run the composition comparison against stock FLUX.2 Klein on your own prompt set, I would like to see the numbers. My read of the GenEval gap is that it shows up worst on counted objects and least on single-subject scenes, but that is inference from one benchmark score, not something I have measured properly.
Sources
- PrismML launch post, May 26, 2026: prismml.com/news/bonsai-image-4b
- Model card and benchmarks: prism-ml/bonsai-image-ternary-4B-mlx-2bit
- Unpacked FP16 repo and its warning: prism-ml/bonsai-image-ternary-4B-unpacked
- Demo repo: PrismML-Eng/Bonsai-Image-Demo
- Base model: black-forest-labs/FLUX.2-klein-4B
Medium metadata
- Title: Bonsai Image 4B Runs a FLUX-Class Model on an iPhone. The 95% Number Hides Where It Costs You.
- Subtitle: A 4B diffusion transformer squeezed to 1.21 GB with three-value weights, what it actually costs in image quality, and how to run it on a Mac this afternoon.
- Tags: AI Image Generation, Local AI, Apple Silicon, Machine Learning, Open Source
- Suggested publication: Tkay Nation's Writes
- Estimated read time: 8 minutes