FLUX vs LLaDA-Image-Turbo: a 46 GB Chinese image model on a 16 GB Mac

LLaDA-Image-Turbo is an image generator from InclusionAI (Ant Group), released under Apache-2.0 with an open training recipe. We installed it on a Mac mini M4 with 16 GB of unified memory and generated images with it. It works, and it renders readable text — a rare capability. It is also roughly 23 times slower per pixel than FLUX on the same machine, for a weaker result. This is what we measured, including the precision bug that costs most teams half a night.

Why it matters

The image generation stack most Western teams reach for is FLUX, and there is little incentive to look past it: the weights are a few gigabytes, the tooling is mature, and a 1024×1024 image arrives in under a minute on consumer Apple Silicon. That convenience has a cost that rarely gets named. It makes the default invisible, including its licence terms and the fact that a large share of recent progress in image generation is published by Chinese labs that most roundups never evaluate.

LLaDA-Image-Turbo is worth looking at because it makes unusual choices. It is released under Apache-2.0 — a permissive licence that removes the legal review which otherwise stalls adoption inside companies — and, unusually, its authors publish a fully open training recipe rather than weights alone. It is built on a diffusion language model rather than the usual latent diffusion stack, and its stated selling point is text rendering: legible glyphs inside the generated image, the thing that classical diffusion models are worst at.

Text rendering is not a cosmetic feature. It decides whether a generated image can be used at all in a diagram, a poster, a slide, a UI mockup or any graphic where a wrong word is worse than a blurred one. If a model can hold a caption, a label or a percentage steady, the range of usable outputs widens considerably. That is the claim we tested — not on a leaderboard, but by generating infographics and reading them.

What we ran

The two chains, on the same machine — Mac mini M4, 16 GB of unified memory, macOS 27.0, PyTorch with the Metal backend:

• LLaDA-Image-Turbo: 49.2 GB repository, 46 GB once installed. Four diffusion steps at guidance 1.0 in the model's Turbo regime, fixed seed.
• FLUX.2 Klein 4B, 4-bit, through mflux: what this machine already runs in production. 4.3 GB on disk.

Nothing about the model fitted as published. Its text encoder is 32.6 GB of the original weights, which does not fit in 16 GB of memory under any configuration. We quantised that encoder to 4 bits and rebuilt it shard by shard, never materialising the original tensors: it holds at 8.45 GB resident. The encoder turned out to be the right thing to compress — quantisation there only degrades embeddings, whose damage is diffuse, and the diffusion transformer itself stays in bf16, unquantised, at 13.42 GB on the GPU.

Two implementation details decided the outcome. The first is a fill sentinel. The transformer's padding tokens carry the value 7.67×10²⁴. That number is finite in bf16, whose exponent range reaches 3.4×10³⁸. In fp16 it overflows at 65,504, becomes infinity, and the first RMSNorm turns it into NaN. The signature is exact: 62 non-finite values, two channels at 31 padding positions. The fix is to clamp to 180 — the square root of 65,504, because the normalisation squares its input — and only then switch the computation to bf16, in that order.

The second is that the released generator passes a single dtype to both the transformer and the VAE. Setting it to fp16 to save memory silently breaks the VAE, and the symptom misleads: changing the precision of the transformer changes nothing, because the failure is downstream. If two configurations fail identically, suspect a shared parameter rather than the component you just changed.

The data

	FLUX.2 Klein 4B (mflux)	LLaDA-Image-Turbo (bf16)
One image	47 s at 1024×1024	~272 s at 512×512
Per diffusion step	~12 s	68 s
Weights on disk	4.3 GB	46 GB
Peak GPU memory	12.37 GB	13.42 GB
Text in the image	n/a	readable
Relative cost per pixel	1×	~23×

The image LLaDA produced is real. A 512×512 infographic, 319 KB, 36,879 distinct colours: a dark blue grid background, the number "30000" set large, the word "FICHES", a world map with recognisable continents, and a four-bar chart labelled 15%, 40%, 40% and 85%. All of it legible. The model is capable of the thing it advertises.

Its failure is internal coherence, and it is the kind that matters in production: the bar heights do not match the percentages printed beside them — the 15% bar is the tallest. The layout is convincing and the data in it is wrong. A reader who does not check will publish it.

The trap to avoid

Two traps, and neither is documented in the model repository, its open issues, or any forum thread we could find.

A quantised transformer does not crash — it renders plausible noise. Same prompt, same seed: at 4-bit the model returned noise, at bf16 it returned the infographic above. No exception, no NaN, no warning. Nothing in the pipeline distinguishes a failed image from a successful one, so the failure has to be caught by looking at the output.

A counter cannot tell an image from noise. We measured it: pure noise holds 341,491 distinct colours; the real infographic holds 36,879. Noise has more. Three successive automated criteria — colour count, non-empty file, energy ratio — were all satisfied by noise. The only control that held was opening the image.

And a constraint that is not a trap but a hard ceiling: 12.3 GB of transformer plus the VAE, on a 16 GB machine with a desktop application already running, is a kernel panic. We know because we caused one — the compression watchdog gave out after 459,997,223 compression cycles and the machine went down for half an hour. The transformer fits; the transformer plus anything else does not. If you try this model, add up the footprints before you launch, and run one heavy load at a time.

The verdict

Not in production here. LLaDA-Image-Turbo does something FLUX does not — it renders legible text inside an image, at 23 times the compute per pixel, from 46 GB of weights instead of 4.3 GB. On a 16 GB machine the trade is not close, and the internal inconsistency above means its output cannot be trusted without a manual read anyway.

The honest framing is that this is a performance verdict, not a capability verdict. The model works, the licence is genuinely permissive, and 23× is measured on this hardware at this size — on a machine with 64 GB or a rented GPU the arithmetic changes, and text rendering may be worth paying for. What does not change is the maintenance cost: quantising the encoder, clamping a sentinel that no document mentions, and hand-setting every dtype because the authors' own precision handling calls a CUDA-only API that does nothing on Metal.

One candidate remains untested and is worth naming: Janus-Pro-1B, from DeepSeek, is a text-to-image model built on a 1.5-billion-parameter language model, so single-digit gigabytes, under a licence that permits commercial use. It is the only Chinese image model in this class that is safe on 16 GB on paper. We have not run it.

References

1. LLaDA-Image-Turbo model card, InclusionAI — https://huggingface.co/inclusionAI/LLaDA-Image-Turbo (Apache-2.0, checked 2026-09-26)
2. LLaDA-Image: Building Strong Image Generators with Fully Open Training Recipes — https://arxiv.org/abs/2609.03796
3. mflux, MLX-native implementations of FLUX — https://github.com/mflux-community/mflux (MIT)
4. FLUX.2 Klein 4B, mflux 4-bit build — https://huggingface.co/Runpod/FLUX.2-klein-4B-mflux-4bit (Apache-2.0, based on black-forest-labs/FLUX.2-klein-4B)