EditUtils: QwenImage 2.1 Model Config lrzjason

One optional text box, one dictionary

QwenImage21ModelConfig_EditUtils has no required inputs at all. Optionally, you can type something into instruction. It outputs a single model_config dictionary that you wire into the model_config input of EditTextEncode_EditUtils. That's the entire node.

It earns its place because EditUtils is one encode node serving five architectures - Qwen 1.0, Qwen-Image 2.1, Flux2Klein, Boogu, and Krea2's Qwen-based pipeline - and the encode node decides which branch to run by reading this dictionary. No config node, no branch. Specifically, the encoder's first line does a membership test on the dict, so an unconnected model_config port doesn't degrade gracefully; the run dies. On the chain path this node is mandatory, not decorative.

The dictionary it returns is three keys: model_name: "qwen_image21", vae_unit: 32, and llama_template: "". Each one is doing real work.

model_name picks the 2.1 route through the encoder - the same resized tensor going to both the Qwen3-VL vision tower and the VAE, references spliced into the text sequence at the vision slots. vae_unit: 32 is the alignment number: the 2.1 VAE is 64-channel with 16x spatial downscale, so 32 pixels means 16 × 2, which is exactly one vision slot landing on a 2×2 group of latent tokens. Get that wrong and your reference is subtly misaligned with the prompt that describes it.

llama_template: "" is the interesting one, because it's a genuine behavioural change from the Qwen 1.0 nodes in the same pack.

Leave the instruction box empty

With instruction empty, llama_template stays empty, and the QwenImage21 tokenizer builds its own T2I template - inserting the vision blocks before your prompt and framing the job as comprehending the image and the instruction. That's the trained, expected path, and it's why the README says an empty instruction means the built-in template.

Type something into instruction and it becomes the system prompt of a chat template instead, with a {} slot where the vision blocks get spliced in. Useful if you want to impose your own framing on the model's behaviour, and the encoder is careful about it - it strips a template prefix or suffix if you paste one in by accident.

Contrast that with QwenModelConfig_EditUtils, the 1.0 node, which always sets a template: leave its instruction empty and you get the long boilerplate about describing colour, shape, size, texture and objects. Same-looking widget, different meaning. If you're coming from a Qwen-Edit 2509 workflow and reflexively want to fill that box, don't.

Where it fits in the graph

It's a leaf node. It takes nothing from the graph and feeds EditTextEncode_EditUtils:

QwenImage21ModelConfig_EditUtils ──► EditTextEncode_EditUtils (model_config)
QwenImage21ConfigPreparer_EditUtils ──► (configs) ──► EditTextEncode_EditUtils (configs)
CLIPLoader (qwen_image) ──► (clip)
VAELoader (qwen_image_2.1_vae) ──► (vae)

Worth saying out loud: the pack's simple one-piece encoder, QwenImage21EditTextEncode_EditUtils, builds this exact config internally and has no model_config port. If you're on that node and wondering why your Model Config node changes nothing, that's why - nothing can be wired to it. This node exists for the config-chain path where you want multiple references, per-image sizing, or ROPE placement.

Install

ComfyUI Manager, search ComfyUI-EditUtils, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/ComfyUI-EditUtils

Restart ComfyUI. The pack has no dependencies of its own - no requirements.txt, nothing pip-installed beyond what ComfyUI already has - but the 2.1 path needs a ComfyUI build with upstream qwen_image21 support. On an older build the model won't load, which is a load-time failure that will look nothing like a node problem. The example workflow's files are qwen_image_2.1_int8_convrot.safetensors (UNETLoader), qwen3vl_8b_fp8_scaled.safetensors (CLIPLoader, type qwen_image), qwen_image_2.1_vae_bf16.safetensors (VAELoader).

Gotchas

The failure that costs the most time is the silent one: a config dictionary from a different model node - say the generic ModelConfig_EditUtils with model_choice set to qwen - will wire up perfectly and produce a plausible, wrong-looking result, because the encoder is now treating your 2.1 model with 1.0 assumptions, an 8-pixel VAE unit and a Picture n: prompt prefix. If your references look blurry, misaligned, or vaguely ignored, check which config node is actually feeding the encoder before you touch a single sampler setting.

And if you do set a custom instruction, keep it short and directive. It's a system prompt for a language model, not a place for a paragraph of aesthetic notes, and it applies to every reference in the chain.