Random_Model_Merge

If the nine GodnessMerger_* nodes are the modular, build-it-yourself version of SP-Nodes' merge system, Random_Model_Merge is the all-in-one version - the README's "model merging based on controlled randomization" screenshot in a single node. Two checkpoints in, a merged one out, with the randomization knobs built straight into the node instead of spread across half a dozen separate ratio-generator nodes.

How it's put together

You get model1, model2, a global strength, a min/max range, and a seed. Then, separately, three of the U-Net's smaller, structurally distinct sub-modules each get their own explicit override: time_embed, label_emb, and out - each with a default/random/custom enum plus a matching _custom value field. My read on why exactly these three and not, say, middle_block or output_blocks: those three are genuinely tiny, self-contained pieces of the U-Net (a small MLP for the timestep, an embedding for SDXL's extra conditioning vector, and the final output convolution), where an author would plausibly want fine, deliberate control - versus the big encoder/decoder stacks, which presumably ride on the blanket strength/min/max recipe instead. That's inference from the node's shape, not something the README confirms outright, but it's a sensible design and it's consistent with how the modular GodnessMerger_* nodes are named after those exact same sub-modules.

Each of the three overrides works the same way: default presumably leaves that block following model1 (or the global recipe) untouched, random draws a ratio between min and max seeded by seed, and custom uses the matching _custom field instead.

The outputs, and why VALUES matters

You get a merged MODEL and a VALUES string. That string is the whole point of running this in random mode at all: a random draw isn't visible to you until after the merge happens, so if you land on a combination that actually looks good, VALUES is your only record of what ratios were used for each block. Save it. Feed it into GodnessMerger_RAW_Apply later and you can reproduce that exact recipe - against the same two models, or a different pair entirely - without depending on the seed landing the same way twice (seeds are only reproducible if every upstream input to the random draw stays identical, and swapping either source checkpoint can change that).

The fields worth touching

• seed - pins every random draw in this node. Change nothing else and you'll get the same merge back.
• strength - the overall blend intensity for the parts of the network not covered by the three per-block overrides.
• min / max - the range any random overrides draw from.
• time_embed / label_emb / out - each default, random, or custom, with a matching _custom field for the custom case.

Installing SP-Nodes

Through Manager: search "SP-Nodes," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Restart once cloned. Nothing here needs a separate model download - it merges checkpoints you've already loaded, using plain tensor math.

Common issues

Architecture mismatch is the big one: model1 and model2 have to be the same family (both SD1.5, both SDXL). Cross-architecture merges aren't something a ratio can paper over - expect an error or a broken model, not a warning. The pack's author also ships a separate Windows tool, Comfizen, for building simplified UIs over ComfyUI workflows, which tells you a bit about the target audience here: someone iterating on a lot of merge attempts and wanting a quick way to lock in and reuse a result, which is exactly what the VALUES output is for. Use it - running random mode without saving VALUES when you get something you like means you can't get back to it.