MOSS-Image: OpenMOSS-Team's ComfyUI ripack, workflows and real requirements

MOSS-Image is an open-source image-generation model with 5 billion parameters, and the story is not the model: it is that on the day of release (October 16, 2026) it was already inside ComfyUI, with the files cut into the right formats and four workflows ready to load. That is the difference between buying a used car you have to fix up and receiving one that starts at delivery: here the weights, the encoder and the config files sit exactly where ComfyUI expects them, and the only real decision is how much space your GPU has.

What MOSS-Image is

MOSS-Image is a DiT (Diffusion Transformer) with 5B parameters, published by OpenMOSS-Team under the Apache 2.0 license, weights and code included. The full architecture that runs on your hardware has three parts:

• The 5B base DiT — the generator itself, in the MOSS-Image-Base checkpoint (the starting point, the one to fine-tune from) and MOSS-Image-SFT (refined on curated data: better text grouping and cleaner layout).
• The Qwen3.5 9B text encoder — reads the prompt, up to 4,000 tokens, and hands the representation to the DiT.
• The FLUX.2 VAE — compresses and decompresses the image; the ripack ships the full version and a "small" one.

Three things set it apart from the image models you already know. Layout control: you can include a JSON structure with bounding boxes in the prompt and tell the model where to put each element. Text rendering: text inside the image is one of the declared strengths. And styles: anime and photorealistic are both covered, with no third-party LoRA. The default settings, as documented in the official repository, are flow-matching Euler sampler, 50 steps, CFG 3, shift 5.

The ComfyUI ripack: installation

On release day, Comfy-Org integrated MOSS-Image natively (PR #17095, October 16, 2026) — no plugin, no third-party workflow. The official ripack on Hugging Face contains exactly the files you need, sorted by folder:

• diffusion_models/ — the DiT in bf16 (Base and SFT) and int8_convrot
• text_encoders/ — Qwen3.5 9B in bf16, int8 and w4a8_gptq
• loras/ — color_depth_control and edit_rank_64_bf16
• vae/ — flux2-vae and flux2-vae_small

Each file goes into its matching folder in your ComfyUI installation: that is the whole install, there is nothing else to download. The ripack includes four ready workflows (text-to-image, text-to-image from Base, and two layout-guided), and last month it logged 3.7 million downloads — the most honest signal that the flow works.

The Python setup, if you work from the repository instead of ComfyUI, needs Python 3.10+, PyTorch 2.9+, diffusers ≥ 0.38 and transformers ≥ 5.3, as stated in the MOSS-Image-Base model card.

Real VRAM: the table that counts

The 28 GB of bf16 weights are not a number to take at face value: they are the sum of two very different components. The math:

Piece	Parameters	bf16 weight
DiT	5B	5 × 2 bytes = 10 GB
Qwen3.5 encoder	9B	9 × 2 bytes = 18 GB
Total weights	14B	28 GB

The encoder is 64% of the model. That is why the full bf16 build does not fit a 24GB GPU: even with everything else removed, the encoder alone takes 18GB. The way out is the quantized variants already in the ripack.

Combination (ripack files)	Weights	Real-world VRAM*	Where it fits
DiT bf16 + encoder bf16	~28 GB	~31 GB	RTX 5090 32GB (tight), Mac Studio 512GB
DiT int8 + encoder bf16	~23 GB	~26 GB	RTX 5090 32GB, Mac Studio 64GB
DiT w4a8 + encoder w4a8	~8 GB	~11 GB	RTX 4070 Ti Super 16GB, RTX 3060 12GB (tight)

*Weights + ~3GB of runtime (activations, VAE, sampler workspace) at 1024px with 50 steps. Weights are computed from the actual parameter counts (1 byte/param for int8, ~0.56 for w4a8); runtime is an estimate from typical DiT inference behavior.

Two practical consequences. If you have 24GB, the middle row is your entry point on a 32GB card and will not make it on 24GB: with 24GB, start from the w4a8 row (~11GB), which leaves headroom for higher resolution and extra steps. If you run a Mac with unified memory, the whole model fits in the shared RAM, and the rule is the same: weights + headroom.

And the limits?

• The quantized weights have no official benchmark. The table above is a byte count, not a quality measurement: w4a8 on the encoder is the most aggressive quantization, and rendered text — the model's declared strength — is exactly what suffers most from compression. Check it on your own use case.
• Base vs SFT is not "Base = worse." SFT is refined on curated data and gives cleaner layout and text; Base is the checkpoint you run your LoRAs on. If you do custom adaptation, start from Base.
• The VAE is float32 in the Base distribution: it is small in absolute terms, but it is not quantized alongside the other two.
• Long prompts do not mean high resolution. The 4,000 prompt tokens are context capacity, not pixels: output dimensions still have to be multiples of 16.

See also

• Local image models: from SDXL to Qwen-Image — the full picture of generators that run on your hardware
• ComfyUI 0.40 and comfy_attention — the engine that runs this workflow
• Quantization: get more from the same hardware — how to read the int8 and w4a8 formats in the table above

Sources

• OpenMOSS/MOSS-Image — GitHub repository
• Comfy-Org/MOSS-Image — ComfyUI ripack (Hugging Face)
• OpenMOSS-Team/MOSS-Image-Base — model card (Hugging Face)

In summary

MOSS-Image brings the "5B DiT + Qwen3.5 9B encoder" format to the Apache 2.0 license, and the ComfyUI ripack makes it installable in ten minutes: files in the right folders, four workflows included. The real cost is VRAM: 28GB of bf16 weights, with the encoder alone taking 18GB, and the way under 24GB is the w4a8 pair, down to ~11GB in the real world. If your GPU has 16GB or more, you have a local image workflow that handles layout, text and long prompts — no subscription required.

Article generated with AI