Say you want an image endpoint for app mockups, slides and stickers, and Ming-Image-0.1-Design from inclusionAI looks like the right fit. It is MIT licensed and trained for layouts full of text. Its PNGs always carry an alpha channel, a fourth layer that stores the opacity of every pixel. Before you ship it, three things decide whether it behaves: which GPU you rent, how you phrase the transparency request, and what happens when a result is too big to send back.
We ran it on one NVIDIA A100 80GB on our cloud and wrote up every number in the Ming-Image Design test on one A100.
Budget memory from the component list
The model card calls it a 6B model. That figure covers only the diffusion transformer, the part that refines random noise into an image step by step, and it is 12.3 GB on disk. The repository also ships a 34 GB language model that interprets the prompt, a 6.2 GB connector between the two and a 0.25 GB decoder that produces the pixels: 52.9 GB in total.
Once loaded, the model held 46.3 GiB of GPU memory before drawing anything. A 1024 x 1024 image peaked at 50.45 GiB, and a 2048 x 2048 one reached 64.4 GiB. That lines up with the authors' GitHub README, where the smallest setup they validated is one GPU with at least 80 GiB. If your capacity planning starts from a parameter count, add up the folder sizes first.
We also planned to fake a 24 GB card by capping the A100's memory. An open bug kept the new setting from reaching the running model, so nothing under 80 GB is tested.
Treat transparency as a prompt format you have to test
inclusionAI lists ten trigger phrases for transparent output and asks you to open the prompt with a single one. There is no special code path: the decoder always emits four channels, and transparency happens only if the model draws it.
We wrote the request six different ways, and a single version produced a cutout. It started with "RGBA, 4-channel, transparent background" as a line by itself, followed by the fox sticker description: 83.2 % of pixels came out fully transparent. Put a comma after the phrase instead and the fox sat on opaque white, with a minimum alpha of 247. Yet the same newline trick on an app icon still gave a solid background. The newline helped the fox, and it guarantees nothing.
The practical rule is to stop trusting the request and measure the response:
prompt = "RGBA, 4-channel, transparent background\n" + description # newline, not ", " alpha = np.asarray(Image.open("out.png").getchannel("A")) transparent = (alpha == 0).mean() # fox with newline: 0.832, with a comma: 0.0 Retry or reject below a threshold that fits your assets. Our backend (the small server that keeps the model in memory and serves requests) returns this fraction with every image.
Quoted strings are the spec, the rest is filler
In 5 of our 7 layouts, every string we put in quotes was correct. Anything unspecified, such as chart axes or feature cards, filled up with pseudo-words that pass at a glance.
Long lists slip. A 12-line menu asked for in two columns came out in one, with two wrong prices and an invented line. If your output carries prices, someone has to read every line. inclusionAI suggests first rewriting prompts into a structured, Figma-style description with another language model; we did not try that.
Three settings that bite between the model and your client
| What | Why it matters |
|---|---|
| 12 steps, guidance 1.0 | Steps are drawing passes; guidance is how hard the prompt steers them. The authors validated these. Our panel's image tester defaults to 20 and 4.5. |
| 1024 and 2048 only | It draws at the closer level, then resizes: a 1920 x 1080 slide is drawn at 1024. |
| Result size | Our test setup accepted answers up to 8 MB. Two busy 2048 images went over, got discarded, and the client sat until a 300-second timeout. |
Resolution alone does not predict file size: other 2048 images fit. The SDK example's backend now lowers WebP quality until the file fits, tested on saved images only. The long platform wait is still open, and we did not check the hosted limit.
Speed with the authors' untuned script: 6.2 to 7.4 seconds of GPU time per 1024 image over 10 runs, 35.8 seconds per 2048 image. The vLLM-Omni serving engine reports about 2.2 seconds at 1024 on two H100s; we did not run it.
What this does not prove
These are observations, not a quality score: 15 images, one try per prompt, prompts we wrote, one seed (the random starting point), a single GPU model, and requests sent one by one. We did not call the hosted service.
On Python 3.11 the authors' pinned versions did not run as written; slightly newer numpy and torch fixed it. The dependency fixes, per-size memory figures and the full transparency table sit in the engineering appendix. To compare text rendering, our MOSS-Image hands-on test measured the same kind of layouts on one A40.
Credit where it belongs. inclusionAI made Ming-Image-0.1-Design and released it under MIT, inference code and transparency phrases included. It reuses pieces from other teams: Ling for the language model, Qwen2.5 for vision, Qwen2 for the connector, Z-Image for the transformer design and Qwen-Image for the decoder. The vLLM-Omni team contributed a serving recipe plus benchmark numbers, hugging-apps a demo Space, and the AI Search channel is where we first saw the model. We wrote the custom backend, deployed it, fixed the dependencies and took the measurements. Timings, sample images and the deploy walkthrough live in the Ming-Image Design research article on inferencekey.com.
