MOSS-Image: a 5B DiT that renders text and layout

MOSS-Image targets readable text and placed elements

Most text-to-image models handle words badly, and they place objects wherever the sampler feels like putting them. MOSS-Image is built around those two problems. The project describes it as a 5B-parameter base diffusion transformer with high-quality text rendering, layout generation and efficient fine-tuning, and the feature list in the README names layout control for the placement of text and visual elements, strong text rendering for clear and accurate text within images, and long-prompt support for text prompts of up to 4K tokens.

That is a narrow product definition, and narrowness is useful here because it makes evaluation tractable. You can check whether a model renders a given headline correctly and whether it honours a placement instruction. There is no claim of a general purpose state of the art image generator in the README, and there is no benchmark table to argue about.

The model is presented in two visual registers, anime and photorealistic, which is what the version listing means by versatile visual styles. The README also records heterogeneous GPU training, that is, the training run used GPU platforms other than a single vendor's hardware, which is a statement about the training setup rather than about your inference options.

The audience for this model is narrower than for a general image generator: teams building posters, slides, product mockups or any graphic where words are part of the design, plus researchers who want a base checkpoint small enough to fine-tune on a modest cluster.

Two checkpoints: a base model and a curated fine-tune

MOSS-Image ships as two checkpoints, both published on Hugging Face and ModelScope under the OpenMOSS and openmoss organizations. MOSS-Image-Base is the base text-to-image model. MOSS-Image-SFT is described as fine-tuned from MOSS-Image-Base on curated data.

The README explains the difference with a worked example rather than an abstract description. In the same prompt, SFT produces clearer text grouping and a more organized whiteboard layout, and the repository carries side by side comparison images under assets/comparison/. That is the entire claim, and it is a claim about layout organisation and text grouping, not about colour fidelity or realism.

For an adopter this shapes the choice. If you are fine-tuning on your own corpus, MOSS-Image-Base is the starting point, and the README describes the base model as easy to fine-tune. If you want the curated behaviour out of the box, SFT is the one to download.

The size of the backbone also matters for planning. The project advertises compact and efficient image generation with a 5B backbone, and a comment inside the README records the components as a 42-layer diffusion transformer, a Qwen3.5-9B text encoder and a FLUX.2 VAE. Whatever the intended deployment, you are looking at loading a transformer, a text encoder and a VAE into GPU memory before the first sample.

Cloning into a virtualenv with an editable install

The repository ships a pyproject.toml, so the setup path is a clone, a virtual environment and a pip install:

git clone https://github.com/OpenMOSS/MOSS-Image.git
cd MOSS-Image
python -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt

After activating the environment you should be able to import the project modules. The requirements file contains a single line, `-e .`, which means an editable install of the project itself rather than a pinned dependency list. The dependency set comes from pyproject.toml instead: torch 2.9 or later, diffusers 0.38 or later, transformers 5.3 or later, accelerate 1.10 or later, safetensors 0.6 or later and Pillow 10 or later. Python 3.10 is the floor.

Two optional groups are declared. The dev group brings pytest and ruff, and the ui group brings gradio 6.30 or later for the interface in gradio_app.py. The ruff configuration sets a line length of 110 and targets py310, and the pytest configuration points at a tests directory with the repository root on the path.

One packaging detail deserves attention. The setuptools configuration lists license-files as LICENSE and LICENSES/*.txt, so the project carries a directory of third-party licence texts alongside its own, and those files are part of what gets distributed.

The Diffusers path loads a custom pipeline by repository name

The README's Python example begins with the standard Diffusers entry point:

import torch
from diffusers import DiffusionPipeline

The example then constructs a DiffusionPipeline from the pretrained identifier `OpenMOSS-Team/MOSS-Image-Base` with `custom_pipeline="pipeline_moss_image"`. That second argument is the mechanism that matters: rather than a generic text-to-image pipeline, the loader is pointed at a pipeline implementation named pipeline_moss_image, which is what the project packages and exposes for this model. The repository layout supports that reading, since inference_runtime.py, gradio_app.py and gradio_presets.py are declared as top level modules in the packaging configuration and are shipped as part of the distribution.

The structure is worth understanding before you write your own code. The model is not a special case bolted onto Diffusers, it is a Diffusers pipeline with a custom name, so anything you already know about loading and offloading pipelines applies, and the weight identifiers are plain Hugging Face repositories that you can point at your own mirror if you need to.

What the README does not give you is a complete example script. The listing in the README stops partway through the constructor, and the guidance on recommended inference settings, sampling parameters, memory notes and layout input formats is delegated to the English user guide, USERGUIDE.md, with a Chinese version alongside it.

A prompt enhancer skill that never calls a generation service

The repository includes a skill folder at skills/moss-image-prompt-enhancer, described as the MOSS-Image Prompt Enhancer. It turns image ideas into detailed captions or spatial Layout prompts, and it is designed for GPT-6-family agents that have local file and Python tools available.

The design choice is the interesting part. The bundled script converts pixel-coordinate drafts into compact JSON with integer centered coordinates, and it does not call an image-generation service. So the skill is a deterministic compiler: you describe the image, the agent reasons about it, and the script emits the coordinate JSON and the caption that MOSS-Image expects as input. Nothing in it needs a GPU.

The workflow it supports is documented in the README. Install the skill folder in your agent's skills directory, invoke $moss-image-prompt-enhancer with the image idea, the desired caption or Layout output, and any canvas dimensions, then paste the compiled result into MOSS-Image's positive prompt. For Layout prompts, the generation dimensions should match the ones used when compiling the layout.

That last constraint is the one to internalise. Layout is expressed in coordinates against a canvas, so producing a layout for one canvas size and generating at another will not line up.

Three serving paths beyond the in-process pipeline

The news entries dated 2026-10-16 record day-0 support for MOSS-Image in SGLang, in vLLM-Omni and in ComfyUI, on the same day that the Base and SFT models and code were released. The technical report followed on 2026-10-19, available on arXiv as 2610.23374.

Each path serves a different need. The Diffusers route keeps the model inside your Python process, which is what you want for a service with custom logic around sampling. SGLang and vLLM-Omni are server style runtimes, so the model lives behind an endpoint and your application talks to it over HTTP, which fits multi-user deployment. ComfyUI is a node graph environment, and this repository ships a native MOSS-Image plugin for it, installable by searching for MOSS-Image in ComfyUI Manager, with an example workflow at comfyui/moss-image/example_workflows/moss-image.json. The project states that it is actively working toward integration into the official ComfyUI repository, so today the plugin is installed as a third party add-on rather than shipped upstream.

The two hosting platforms for the weights, Hugging Face and ModelScope, matter for the same reason the inference paths do. ModelScope entries are listed under the openmoss organization and the Hugging Face entries under OpenMOSS-Team, and a Hugging Face Space is provided as a demo, so you can evaluate the model without hosting it yourself.

Licence handling and a repository without releases

MOSS-Image is published under Apache-2.0, and the repository root holds a LICENSE file. The packaging configuration also pulls in every file under LICENSES/, which is where third-party licence texts for the components you redistribute would live. For a model release that depends on an existing VAE, a text encoder and the PyTorch and Diffusers stack, keeping those notices intact is the practical obligation to watch. This is a packaging note rather than a legal opinion.

On maintenance, the last push to main was on 2026-10-19, the same day the technical report was posted, so the repository is being worked on. There are no GitHub releases, so there is no version tag to pin and no published changelog in the repository listing. The project version in pyproject.toml reads 0.1.0, which fits a repository whose real artefacts are the model weights and the inference code rather than a pip distribution you would depend on.

The structure of the repository reinforces that reading. There is a website/ directory, a paper/ directory, a scripts/ directory, a skills/ directory, assets/ with the logos and prompt defaults, and an images package with webp, png and json data files included as package data.

Where MOSS-Image is the wrong tool

There is a case where a diffusion model is the wrong instrument for rendering text, and it is not a rare one. If the words in your image must be exactly right, for instance a price, a legal disclaimer or a product name, then a model that generates glyphs will eventually produce a wrong character, and no amount of prompt engineering guarantees it does not. The alternative approach is to generate the picture without the words and composite the text on afterwards with a font library and an image library, which gives exact strings at the cost of a less integrated look. MOSS-Image's own framing, strong text rendering and layout control, describes a probabilistic route to that result.

The second limit is deployment cost. A 5B backbone plus a 9B text encoder plus a VAE is a substantial download and a substantial memory footprint, and the README does not publish a minimum GPU specification. The memory and performance discussion is delegated to the user guide, so anyone without that document open should treat the hardware question as unanswered.

The third limit is the fine-tuning story. The README says the base model is easy to fine-tune and points to LoRA training guidance in the user guide, but the repository's own top level carries no training scripts beyond the scripts/ directory, and the LoRA section of the README is a pointer rather than a walkthrough. If your requirement is a house style image model, the guidance exists but you will be reading it in the user guide, not here.

Editorial conclusion

Adopt MOSS-Image when your product needs generated images that contain readable text or elements placed at chosen positions, and when you want a base checkpoint you can fine-tune for a house style. Skip it when you need photoreal fidelity above all else, when you cannot host multi-gigabyte weights yourself, or when correct text matters more than an integrated look, in which case compositing drawn text onto a generated image is the safer approach. Verify three things first: that MOSS-Image-SFT suits your layout and grouping needs better than MOSS-Image-Base, that the memory and sampling settings in USERGUIDE.md fit your GPU, and that the licence files bundled under LICENSES/ match the components you redistribute. The last push to main was on 2026-10-19 and there are no GitHub releases, so track the repository commits rather than a version tag.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OpenMOSS/MOSS-Image on GitHub
4. Project website
5. README