FLUX vs Ming-Image: 2,078 seconds for an unreadable poster

Ming-Image-0.1-Design comes from the same lab as LLaDA-Image and is released under the MIT licence. It is aimed at design work: posters, layouts, typography. We ran the full chain on a Mac mini M4 with 16 GB of unified memory. It executes completely and returns an image in 2,078 seconds — roughly 44 times the cost of FLUX at the same resolution — and the text in that image is unreadable. Here is what the failure proves, and why it is more interesting than a simple verdict.

Why it matters

Most image models are evaluated on photographs. Ming-Image is not aimed at photographs. Its stated purpose is designed output — a poster with a caption, a layout with positioned elements, a card with a headline — which is exactly the class of image where a text-to-image model either becomes useful to a working developer or does not. If a model can produce a legible poster from a prompt, it replaces an hour of layout work. If it produces convincing-looking glyph-shaped noise, it produces something worse than nothing, because it looks finished at thumbnail size.

The reason to test this rather than trust it is that text rendering is where generative image models have historically failed hardest, and where marketing examples are least representative. A model can be excellent at composition and useless at typography in the same checkpoint. Those are separate capabilities in the architecture, and they fail separately.

So the question we took to this model was narrow: asked for an infographic carrying specific words, does it produce those words? It does not. The reason it does not is documented below, and it is the reason this test was worth the electricity.

What we ran

The chain has four stages, and all four ran on this machine — Mac mini M4, 16 GB, macOS 27.0, PyTorch with the Metal backend:

• A multimodal language model of 34 GB, quantised to 4 bits: 14,696 linear layers compressed, 57 mixture-of-experts routers left in full precision to avoid destabilising routing. It holds at 9.18 GB on the GPU.
• A connector of 5.8 GB in bf16, which pairs with the quantised language model at 12.33 GB on the GPU.
• A conditioning pass: 29 seconds of computation, 223 seconds of wall time, producing a condition_embeds tensor of shape (1, 256, 2560) — a 16×16 grid of query tokens.
• A diffusion transformer of 12.56 GB in bf16, running 12 steps in 2,078 seconds, followed by a VAE in bf16.

For comparison, the model this machine runs in production — FLUX.2 Klein 4B at 4 bits through mflux — needs 47 seconds for a 1024×1024 image and 4.3 GB on disk. Ming-Image needs 49 GB on disk and about 44 times the compute at the same resolution.

Three of the four stages worked on the first correct configuration. The failures we hit and refuted, one variable at a time:

Attempt	Change	Result
1	Transformer int4 (3.27 GB on GPU)	black image
2	Transformer bf16 (12.56 GB)	still black — quantisation was not the cause
3	VAE fp16	black
4	VAE bf16	761 KB, 48,967 colours — first non-black image
5	Connector int4	pseudo-text
6	Connector bf16	identical pseudo-text — refuted

That third row is the one to remember. The authors' generator passes a single dtype to the transformer and to the VAE, so switching the transformer to fp16 to save memory breaks the VAE instead, and the symptom is a pair of identical failures that points at the wrong component. Setting the VAE to bf16 — its intended precision — was the fix.

The data

	FLUX.2 Klein 4B (mflux)	Ming-Image-0.1-Design
One image at 1024×1024	47 s	2,078 s
Per diffusion step	~12 s	173 s
Weights on disk	4.3 GB	49 GB
Peak GPU memory	12.37 GB	12.56 GB (transformer alone)
Recommended resolution	1024	2048
Text in the image	n/a	unreadable
Relative cost per image	1×	~44×

The evidence that makes this diagnosis solid rather than a guess is inside the failed output. The pseudo-text in our 1024×1024 attempt contains fragments that read as subtitle "3000 words, 8 languages", three cards at the bottom — the sentence we asked for, partially realised in broken glyphs. The model received the right instruction and tried to write the right words. The conditioning carries the exact semantics; the glyph renderer cannot hold them.

That acquits the quantised language model, which is the part we expected to be the culprit, and moves the fault downstream into the diffusion stack. It also means a better prompt would not have saved it. The instruction was understood.

One more measurement worth recording: changing the transformer from int4 to bf16 changed nothing at first, because both attempts were black for a different reason. A quantised transformer does not raise an exception — it returns a plausible image. Two failure modes stacked on each other, each masking the other, and the only way through was to change one thing at a time and look at the result.

The trap to avoid

The resolution trap, and a warning about the hardware. Ming-Image's documentation recommends 2048×2048 by default; the accepted bucket is 1024 or 2048, and 2048 is the documented default. We tested at 1024, the fast bucket, and got unreadable glyphs. The untested hypothesis is that 2048 is where the text becomes legible — 2048 requires the 12.3 GB transformer plus four times the latent tokens, which is beyond what this machine survived.

It is worth being precise about "survived". Running the transformer at 12.34 GB on the GPU with a desktop application open did not merely slow the machine down: it panicked the kernel. The watchdog gave up after 459,997,223 memory compression cycles and the machine was unresponsive for 92 seconds before rebooting. Nothing was lost, and the machine came back healthy, but a 12.3 GB workload on a 16 GB box has no margin. Add the footprints up before launching, run one heavy load at a time, and do not retry automatically after a failure.

And a portability detail to check in any model you take from research to a Mac. Ming-Image's code calls torch.cuda.amp.autocast, which is a CUDA-only API and is silently inactive on the Metal backend — the library warns about it at load time and moves on. Their internal precision handling therefore does nothing on this hardware, and every dtype has to be set by hand. If a port behaves strangely, check whether the library's own precision management is actually executing.

The authors' native prompt format is also not free text but a structured object — canvas_settings plus layers with coordinates and hex colour codes, as in their reference example. We prepared that case and never saw its output: the machine panicked during its diffusion. The conditioning is saved and intact, so it is resumable, but it is untested, and we are not going to claim a result we did not see.

The verdict

Not in production here. At 44 times the compute of the tool we already run, producing an image whose text cannot be read, Ming-Image fails this machine on arithmetic rather than on quality. Its recommended operating point — 2048×2048 — needs more memory than a 16 GB Mac can give it alongside anything else, and its only tested operating point returns text that is not text.

The MIT licence is real and the model is genuinely interesting: a design-oriented generator that gets the semantics of a complex request right is doing something harder than it looks, and the failure we found is narrow. On a machine with 64 GB of memory, at 2048, the question would be worth asking again. What we can state from measurement is what 16 GB buys: 35 minutes, one unreadable poster, and one kernel panic.

References

1. Ming-Image-0.1-Design model card, InclusionAI — https://huggingface.co/inclusionAI/Ming-Image-0.1-Design (MIT, checked 2026-09-26)
2. Ming repository, InclusionAI — https://github.com/inclusionAI/Ming (multimodal understanding and generation)
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)