Nougan Qwen 2.1 RefMod Bake 🧬

Qwen-Image's Edit line quietly became the default open instruction-editing stack, and the KB's summary of why is one word: Apache 2.0. Kontext's anti-circumvention clause turned every NSFW fine-tune into a licence violation; Qwen carries none of that. So people moved, and the family grew a 2.1 that takes reference images natively.

Nougan Qwen 2.1 RefMod Bake 🧬 freezes your reference set into a file so you're not re-encoding the same four portraits before every generation. It's the least surprising node in the pack to use - and the most interesting one to understand, because Qwen 2.1 does reference conditioning differently from everyone else.

Why a Qwen refmod stores an image as well as a latent

Flux 3's refmod is one tensor: a latent, attached to a dedicated image_cond stream. Qwen 2.1 isn't that. Its text encoder looks at every reference image, then drops the vision tokens from its output, and the DiT splices each reference latent into the prompt sequence at the exact position (image_slots) where those tokens used to be.

Read that again, because it decides the file format: the slots are produced by the text encoder, so a baked reference has to carry both the VAE latent and the image the encoder saw. Hence two tensors per reference:

lat_i : float32 [1, 64, H/16, W/16]   raw vae.encode() output
img_i : uint8   [1, H, W, 3]          the exact resized image the text encoder sees

Baking still pays off - the VAE pass is gone, and you get a named library - but the vision tower still runs on the stored image every generation. That's not a shortcut the node forgot; it's the architecture.

Files are marked with a nougan_qwen21 metadata key, so H3 bundles, Krea 2 refmods and MOSS refmods are ignored by the Qwen nodes, and vice versa.

Inputs

images - every frame in the batch becomes one reference, cap 16 (same cap as the stock 2.1 encode node). A four-portrait batch = four references, one file.

vae - the Qwen Image 2.1 VAE (64-channel latents, 16× spatial downscale). Not interchangeable with the FLUX.2 or Flux 3 VAEs.

name - filename and dropdown label. subfolder defaults to qwen21, overwrite defaults to off.

resolution (default 1024, step 32) - references are resized to about resolution² pixels in multiples of 32; 0 keeps each image's own size. That 32 isn't arbitrary: the latent grid plus patch size needs it.

image_2…image_4 - optional extra inputs.

Output: path (STRING). Output node, so it runs on queue.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Winnougan/Nougan_Nodes
# restart ComfyUI

Or ComfyUI Manager → "Nougan". No pip dependencies, no patches to install - unlike the Krea 2 and MOSS branches of this family, Qwen 2.1 handles reference latents natively, so the matching Encode node is a straight replacement for the stock text-encode node. Restart, then Ctrl+F5 so the refmod library UI loads.

Workflow:

Load Image batch ──► Nougan Qwen 2.1 RefMod Bake ──► models/refmods/qwen21/<name>.safetensors
VAELoader (Qwen 2.1) ┘

Where people get burned

Baking 16 frames of a clip. You meant one character; you now have sixteen references competing for prompt slots. Pass the batch you actually want as references.

The wrong VAE, again. 64-channel latents from a 16-channel VAE don't fail loudly at bake time. They fail as mush.

Expecting speed. The bake saves the VAE encode; every run still runs the vision tower over img_i for each reference. If generation feels slower than plain text-to-image, that's inherent to how 2.1 consumes references, not a bug in the node.

Assuming 16 refs = better. Each reference occupies prompt slots. Two or three well-chosen portraits beat a dozen near-duplicates in every architecture I've tried, and this one is no exception.

Mixing Qwen 2.1 nodes with Qwen-Image-Edit 2509/2511 workflows. This pair targets the 2.1 encode path specifically. Older edit graphs have their own encode nodes; swapping in a 2.1 encode node won't magically upgrade them.