MOSS-Image in ComfyUI: Setup, Weights, and Layout Workflows

MOSS-Image is a 5-billion-parameter text-to-image model from OpenMOSS, released on October 16, 2026, under Apache 2.0. It is a single-stream diffusion transformer that turns a scene caption into a finished image, and its distinguishing feature is layout control: you can specify where objects and text go using a JSON structure or bounding boxes, rather than hoping the prompt lands correctly.

This guide covers getting it running in ComfyUI — which files you need, where they go, which nodes to use, and how to build a working workflow.

Before you start, note that “moss” also means the plant. Several results for this term are image libraries of actual moss. If you are looking for photographs of moss, this is not the page.

What you need before installing

Requirement	Detail
ComfyUI	A working installation. Any recent version with custom node support.
MOSS-Image checkpoint	Two variants exist: SFT (base) and Turbo (LoRA, fewer steps).
Text encoders	Shipped as separate files; both are required.
VRAM	5B parameters. ComfyUI will offload to system RAM if VRAM is short, at a large speed cost.
Disk space	Checkpoint plus encoders. Budget several gigabytes.

The Turbo variant is the one to start with if you want fast iteration. The SFT variant produces higher fidelity but needs more steps and more time per image.

Where the weights come from

Two distributions exist, and choosing between them saves time:

Official (OpenMOSS). The original repository on HuggingFace and ModelScope holds the raw checkpoints. This is the source of truth — newest, unmodified.

Comfy-Org repackaged. Comfy-Org publishes a ComfyUI-ready repack of the same weights, with the files arranged in the folder structure ComfyUI expects. This is faster to install because you skip manual file placement.

If you are comfortable placing files manually, use the official weights. If you want the shortest path to a working setup, use the Comfy-Org repack.

Installation steps

Step 1 — Install the model files.

Place the checkpoint in your ComfyUI models folder:

ComfyUI/models/
├── diffusion_models/     ← MOSS-Image checkpoint here
├── text_encoders/        ← text encoder files here
└── vae/                  ← VAE, if distributed separately

The Comfy-Org repack documents the exact destination for each file. Follow its layout rather than guessing — misplacing a text encoder produces an error that does not clearly say which file is missing.

Step 2 — Install the nodes.

Install the official MOSS-Image node pack from the ComfyUI manager (search “MOSS-Image”), or clone the comfyui/moss-image directory from the official repository into ComfyUI/custom_nodes/.

Restart ComfyUI after installing nodes. A node pack that has not been picked up on restart is the most common cause of “the node does not exist” errors.

Step 3 — Load a workflow and verify.

Start from a minimal text-to-image workflow before attempting layout control. Load the checkpoint, connect the text encoder, write a short prompt, generate at a modest resolution, and confirm you get an image.

Do not start with the JSON layout workflow. When something breaks in a complex graph, you cannot tell whether the problem is installation or prompt structure.

Step 4 — Resolutions and step counts.

MOSS-Image works best at standard diffusion resolutions (1024×1024 and its aspect variants). The SFT variant benefits from 20-30 steps; the Turbo LoRA produces usable output in roughly 4-8. Pushing beyond these counts adds time without visible improvement.

Layout control: the reason to use this model

This is where MOSS-Image differs from a generic text-to-image model. Instead of describing composition in prose and accepting what you get, you specify placement.

Bounding boxes are the simpler form: you define rectangular regions and assign content to each. This works well for product shots, poster layouts, and anything where an element must sit at a specific position.

JSON layout prompts are the fuller form: a structured description of the scene with positions, which the model uses as a spatial blueprint. This suits complex multi-element compositions — a room with several objects, a scene with foreground and background elements that must not merge.

Practically, plan the layout before writing the prompt. If you write a descriptive prompt first and then try to force positions onto it, the two will fight. Decide the arrangement, then describe what goes in each region.

Downloading a working workflow

A ready-to-import workflow JSON removes most of the setup friction. Load it, point the nodes at your installed files, and generate.

The workflow needs to match your installed variant — SFT and Turbo use different sampler settings, and a Turbo workflow run against SFT weights produces noise rather than an image.

Understanding the architecture, because it explains the setup

MOSS-Image is a single-stream DiT — a diffusion transformer rather than a UNet. This matters practically for two reasons.

File layout differs from SDXL workflows. A single-stream model does not split work between separate text and image streams the way SD 1.5 or SDXL architectures do. In ComfyUI terms, you cannot assume an SDXL workflow will transfer: the node graph expects the model’s own loader, and pairing it with an SDXL checkpoint loader produces errors that do not explain themselves.

Text encoding is external. The text encoders ship as separate files. That is why installation is a multi-file operation rather than a single checkpoint drop. Missing or mismatched encoders are the most common reason a fresh install produces garbage output rather than an error.

The 5B parameter count is modest by current standards, which is the point — a smaller transformer at 1024 resolution is fast enough for iteration on a single consumer GPU. The trade-off shows up in fine detail and in text rendering, where larger models still have an edge.

Layout control in practice: a worked example

The JSON layout structure is the reason to choose this model over a generic text-to-image checkpoint, and it is easier to understand with a concrete case.

Say you want a product photo: a ceramic mug centered on a wooden table, with a window in the upper left and a plant in the lower right.

A prose prompt describes this and hopes for the best. A layout prompt specifies it:

{
  "canvas": { "width": 1024, "height": 1024 },
  "elements": [
    { "label": "ceramic mug", "box": [380, 400, 640, 700], "weight": 1.0 },
    { "label": "window light", "box": [0, 0, 320, 360], "weight": 0.7 },
    { "label": "potted plant", "box": [700, 680, 980, 980], "weight": 0.6 }
  ]
}

Boxes are [x1, y1, x2, y2] in pixels. The weight field controls how strongly the model honours each region — lower values let the model improvise within the box.

Three things to know before writing your own:

Overlapping boxes blend. If the mug box overlaps the plant box, the model will merge the concepts rather than layering them. Keep primary subjects in non-overlapping regions.

Boxes are hints, not masks. The model respects placement approximately. It is guidance for composition, not compositing. Expect small deviations and do not fight them with tighter boxes.

Order affects emphasis. Elements listed earlier in the array tend to assert themselves more strongly. Put the primary subject first.

For bounding-box-only control — simpler than full JSON — the node accepts box inputs directly, which is the faster route when you only need one or two elements positioned.

Performance tuning

The two knobs that matter, and what they actually do:

Resolution dominates generation time and VRAM use quadratically. 1024×1024 is the design point; 768 is the practical fallback on limited hardware. Going above 1024 on a consumer card is usually not worth the wait, since the model was trained around that resolution and higher values mostly add compute.

Step count matters more for SFT than Turbo. SFT converges around 20-30 steps; below 20, structure is incomplete. Turbo targets 4-8 — the LoRA is trained for aggressive few-step sampling, so running it at 30 steps wastes time without improving output.

One non-obvious setting: the sampler and scheduler pairing. Turbo LoRAs generally expect specific schedulers, and using an SFT-tuned pairing with Turbo weights produces washed-out results that look like a prompt problem when they are a configuration problem. Start from the default workflow the node pack ships, and change one thing at a time.

Common problems and fixes

Node does not appear after install. Restart ComfyUI. If it still does not appear, check the console for an import error — a missing dependency in the node pack is the usual cause.

“Model not found” errors. The checkpoint is in the wrong folder, or the filename differs from what the node expects. Check the exact path, including case.

Output is noise or heavily distorted. Usually a variant mismatch: Turbo workflow with SFT weights, or vice versa. Also check the step count.

Text rendering looks wrong. Layout control positions text regions, but the model’s text rendering has limits at small sizes. Increase the region size or the overall resolution.

Very slow generation. VRAM offload. Reduce resolution first; if that does not help, the model is exceeding your card’s capacity and will run at RAM speed.

Related

• MOSS-Image model details and license — parameters, variants, license terms
• ComfyUI workflow basics — if you are new to ComfyUI nodes

---