Ming-Image-0.1-Design-ComfyUI

Ming-Image 0.1 Design — ComfyUI workflow

Drag ming_image_0.1_design.json onto the ComfyUI canvas. The graph is one Ming Image 0.1 Design node, a Save Image for the RGB preview, and Join Image with Alpha plus a second Save Image for the RGBA file.

This is not an inclusionAI release. The weights are MIT licensed. Copyright in the model remains with inclusionAI. The original card is inclusionAI/Ming-Image-0.1-Design.

The graph needs the custom node pack ComfyUI-Ming-Image (node type MingImageDesign) in custom_nodes. SaveImage and JoinImageWithAlpha are built into ComfyUI.

Where the weights go

The node reads ComfyUI's models directory (folder_paths.models_dir) and appends ming-image/<checkpoint folder>. From the ComfyUI root that is:

On the DGX Spark this workflow was saved from, that models directory is /home/okita/comfyui/models, mounted in the ComfyUI container at /opt/ComfyUI/models.

--local-dir must be the checkpoint folder itself. An extra nested directory will not load.

hf download alexokita/Ming-Image-0.1-Design-FP8 \
  --local-dir <ComfyUI>/models/ming-image/Ming-Image-0.1-Design-FP8

hf download alexokita/Ming-Image-0.1-Design-INT8 \
  --local-dir <ComfyUI>/models/ming-image/Ming-Image-0.1-Design-INT8

hf download alexokita/Ming-Image-0.1-Design-INT4 \
  --local-dir <ComfyUI>/models/ming-image/Ming-Image-0.1-Design-INT4

hf download inclusionAI/Ming-Image-0.1-Design \
  --local-dir <ComfyUI>/models/ming-image/Ming-Image-0.1-Design

Only the bf16 release is fetched automatically, and only when weights is bf16 and that folder is empty. fp8, int8, and int4 have to be downloaded first. A quantized folder has to contain quantization_config.json.

The saved graph uses fp8, 1024, 12 steps, and CFG 1.0. Those sampling numbers are the ones on the original model card. 2048 is the other resolution the node offers.

DGX Spark

This file was saved on a DGX Spark (NVIDIA GB10, one unified memory pool). ComfyUI on that machine reports about 124 GB total.

Two widget values in the graph were chosen for that machine:

• weights is fp8. The original bf16 checkpoint is about 53 GB. The FP8 and INT8 copies are about 25 GB, and INT4 is about 14 GB, because the large linear layers are absmax weight-only. Embeddings, norms, the VAE, and the tokenizer stay bf16.
• memory is sequential. The node puts the prompt encoder on the GPU, writes the conditioning, moves that stage off, then loads the diffusion transformer and VAE. all on GPU keeps both stages resident.

The ComfyUI process on this Spark is started by the DGX-Spark-ComfyUI container with:

--disable-dynamic-vram --reserve-vram 72 --disable-pinned-memory --disable-mmap
--force-fp16 --use-sage-attention --bf16-unet --bf16-vae --bf16-text-enc --dont-upcast-attention

Those flags are container configuration. They are not stored in the workflow JSON. --disable-mmap, --disable-pinned-memory, --disable-dynamic-vram, and --reserve-vram 72 change how that process uses the Spark's unified memory. The Ming node loads its own PyTorch modules, so --force-fp16, the bf16 UNet/VAE/text-encoder switches, and sage attention do not change this node's matmul or attention.

The same JSON loads on another machine. Keep memory on sequential when the prompt encoder and the diffusion model do not fit in memory together.

One loader fix showed up on this stack (Transformers 5.2, PyTorch 2.13, SDPA). The connector config says dtype: float32, so Transformers built the unquantized layers in fp32 and SDPA rejected a bf16 attention mask. The loader builds the connector in bf16, which is the dtype of those weights.