Model Scale Qwen Image 2.1
38 Dials for Surgery on a Diffusion Model
- model
- MODEL
Most merging nodes average two models together and hope. This one does the opposite: it takes a single Qwen-Image 2.1 diffusion model and multiplies individual internal layers by a number you pick. Scale 1.0 leaves a layer exactly as shipped, 0.0 erases it, 2.0 turns it up. Nothing is written to disk, which makes it the cheapest way to find out what a layer in a modern DiT is actually doing.
Why you'd reach for it
Merging - weighted averaging of existing checkpoints, no training, no dataset - is the community's oldest trick, and it's why CivitAI's model list is so crowded. This node is the surgical version. Instead of blending two checkpoints and accepting whatever came out, you can pull proj_out. down to 0.9 and watch the output soften, or zero time_text_embed. and see how much structure the timestep conditioning is carrying. Same impulse as the block-weight merges people used on SDXL, one layer at a time.
There's precedent in this pack: its VAE scaling nodes produced a community-made Z-Image "clear" VAE - same layer-nudging idea, visible color effect. Nobody writes threads about the model-scale nodes. This is a one-person utility pack.
How it works
The whole mechanism is longest-prefix weight matching. Each prefix you can name in the node - img_in., modulation.1., norm_out., time_text_embed., txt_in., transformer_blocks.0. through transformer_blocks.31., proj_out. - is matched against the keys inside ComfyUI's loaded diffusion_model., and the longest matching prefix wins. Keys that match nothing get 1.0, meaning untouched.
For anything you didn't leave at 1.0, it clones the model object and registers a runtime patch that scales that weight. The source does it cleverly: it hands ComfyUI the model's own weight back as the "patch" with strength scale - 1.0, so the patcher computes weight * 1.0 + weight * (scale - 1.0) = weight * scale. The patch is the existing tensor, so there's no second copy of the model in VRAM, and layers left at 1.0 aren't patched at all.
Which is also the limit: it's a patch, not an edit. Bypass the node or restart and you're back to stock weights. For a file on disk, the same pack ships Load Original Model and Model Save with Original, which round-trip an edited MODEL out to safetensors.
The knobs that matter
38 dials plus the model input, and 32 of them are just block numbers. Range 0.0–2.0, step 0.01, default 1.0.
model- your loaded Qwen-Image 2.1 diffusion model. MODEL out goes wherever a model-modifying node would normally sit, on the way to the sampler.transformer_blocks.N.- the per-block dials, where most of the model lives. There's no "all blocks" widget, so changing the stack means setting 32 numbers by hand.proj_out.,img_in.,txt_in.,time_text_embed.- entry, exit and conditioning paths. They move a lot of weight with one number, so start here.
The widget labels carry trailing dots (modulation.1.). They look broken. They're the real key prefixes, and the node maps ComfyUI's dot-to-underscore widget mangling back for you.
Installing it
ComfyUI Manager → search Easygoing (the pack is in the Registry), or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/easygoing0114/ComfyUI-easygoing-nodes.git
Restart, and it appears under advanced/model_merging/model_specific. There's nothing to download and no pip step - the pack has no Python dependencies beyond ComfyUI, no model files, no requirements.txt. It is written against ComfyUI's V3 node API (from comfy_api.latest import io), and on a build old enough to lack it the pack registers zero nodes and prints an explanation to the console. Nothing shows up after a restart? Update ComfyUI.
Where people get burned
Wrong Qwen generation = dials that quietly do nothing. The pack's sibling node, Model Scale Qwen Image, is for the 20B line (base, 2512, the Edit models) and offers 60 blocks; this one offers 32. Feeding a 60-block model to the 32-block node doesn't error - the shared prefixes still match something, so you get partial, mislabelled scaling, and modulation.1. and norm_out. won't match anything at all. Count the blocks the node offers before you trust it: 60 = v1 family, 32 = 2.1. Feed it a different architecture entirely (SDXL, Flux, Z-Image) and nothing matches, nothing scales, and nothing tells you.
Check the keys yourself. The pack's Key Name Inspector (advanced/debug) accepts a MODEL, prints every weight key to the console, and passes the model through unchanged. Compare those prefixes with the node's widgets before you burn an hour on settings.
Upgrading from the 1.x pack. The v2.0 rewrite (Nodes 2.0 + V3 schema) tries to migrate old nodes automatically, and the README admits it doesn't always work. If the node shows up empty or broken, delete it and add a fresh one.
Mixing it with LoRAs. Both this node and LoRA loaders work by patching the same weights. Keep scaling experiments separate from LoRA experiments, or you'll never know which one moved the image.
Below roughly 0.8 on a big prefix you've stopped tuning and started damaging the model. That's fine - it's what the dial is for.
Inputs (39)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| img_in. | FLOAT | 1.000–2 | — |
| modulation.1. | FLOAT | 1.000–2 | — |
| norm_out. | FLOAT | 1.000–2 | — |
| time_text_embed. | FLOAT | 1.000–2 | — |
| txt_in. | FLOAT | 1.000–2 | — |
| transformer_blocks.0. | FLOAT | 1.000–2 | — |
| transformer_blocks.1. | FLOAT | 1.000–2 | — |
| transformer_blocks.2. | FLOAT | 1.000–2 | — |
| transformer_blocks.3. | FLOAT | 1.000–2 | — |
| transformer_blocks.4. | FLOAT | 1.000–2 | — |
| transformer_blocks.5. | FLOAT | 1.000–2 | — |
| transformer_blocks.6. | FLOAT | 1.000–2 | — |
| transformer_blocks.7. | FLOAT | 1.000–2 | — |
| transformer_blocks.8. | FLOAT | 1.000–2 | — |
| transformer_blocks.9. | FLOAT | 1.000–2 | — |
| transformer_blocks.10. | FLOAT | 1.000–2 | — |
| transformer_blocks.11. | FLOAT | 1.000–2 | — |
| transformer_blocks.12. | FLOAT | 1.000–2 | — |
| transformer_blocks.13. | FLOAT | 1.000–2 | — |
| transformer_blocks.14. | FLOAT | 1.000–2 | — |
| transformer_blocks.15. | FLOAT | 1.000–2 | — |
| transformer_blocks.16. | FLOAT | 1.000–2 | — |
| transformer_blocks.17. | FLOAT | 1.000–2 | — |
| transformer_blocks.18. | FLOAT | 1.000–2 | — |
| transformer_blocks.19. | FLOAT | 1.000–2 | — |
| transformer_blocks.20. | FLOAT | 1.000–2 | — |
| transformer_blocks.21. | FLOAT | 1.000–2 | — |
| transformer_blocks.22. | FLOAT | 1.000–2 | — |
| transformer_blocks.23. | FLOAT | 1.000–2 | — |
| transformer_blocks.24. | FLOAT | 1.000–2 | — |
| transformer_blocks.25. | FLOAT | 1.000–2 | — |
| transformer_blocks.26. | FLOAT | 1.000–2 | — |
| transformer_blocks.27. | FLOAT | 1.000–2 | — |
| transformer_blocks.28. | FLOAT | 1.000–2 | — |
| transformer_blocks.29. | FLOAT | 1.000–2 | — |
| transformer_blocks.30. | FLOAT | 1.000–2 | — |
| transformer_blocks.31. | FLOAT | 1.000–2 | — |
| proj_out. | FLOAT | 1.000–2 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |