Simplified Flux.1 Merge

Model merging is the fast, lazy way to make a new checkpoint: instead of training anything, you take two models and average their weights. Minutes, not days, and no training data. That's the whole pitch of Simplified Flux.1 Merge (class SimplifiedFlux1Merge) from the vekitan55/SimpleFlux1Merger pack - it puts that operation inside your ComfyUI graph for Flux, behind nine sliders.

The name is honest, and so is the README, which cheerfully admits the code was generated by ChatGPT. It's a small, hobby-grade pack with barely any community footprint, but for the one job it does - blending two Flux checkpoints mid-workflow - it works, and it's genuinely easier than the alternatives for a beginner.

Why you'd reach for it

Two classic reasons. You've got a Flux realism fine-tune and a style fine-tune, and you want a taste of both. Or you want to pull the effect of a fine-tune into the base model without loading a LoRA at all. Merging mid-graph like this is one of the things ComfyUI was built for; the node just makes it Flux-aware, since Flux's transformer weights are named double_blocks.* and single_blocks.*, which the generic SD-style merge nodes don't know about.

How it works

Flux's transformer stacks 19 double_blocks and 38 single_blocks. Each of the nine sliders (group_00_01 through group_16_18) controls a pair of double blocks - the last one takes the leftover three - and the same weight applies to the two matching single blocks. Every slider runs from -1 to 2, where 1.0 (the default) means "keep model A", and moving toward 0 blends model B in.

Then there's merge_mode, and this is where the author's SuperMerger inspiration shows. Three modes:

• standard - linear interpolation: A * w + B * (1-w). The classic blend.
• add_difference - A + w * (B - A). Adds only the change B introduces over A. Lighter touch.
• train_difference - A + w * (B - C). Treats the difference between B and C as an effect to apply to A - conceptually close to what a LoRA does, and why a third model slot exists.

The inputs that matter are exactly three: model_a, model_b, and model_c, all MODEL sockets, plus interpolate_groups (a boolean). Gotcha: all three models are required inputs - ComfyUI won't queue if model_c is unplugged, even for a plain two-way merge. Just wire model_c to whatever's handy; it's only ever read in train_difference mode. interpolate_groups, when on, smooths the weight gradient between adjacent groups instead of jumping in steps - handy if you're sweeping from one blend to another.

One subtle thing the code does: top-level layers like img_in, txt_in, and final_layer aren't controlled by any slider - they're pinned at weight 1.0, meaning they always come from model A. So whichever model's overall "voice" you want to keep, put it in model_a.

Output and what it feeds

The single output is a model socket - a merged MODEL you wire straight into your sampler. Note it's a live merge: nothing is written to disk. The result exists only in the graph, so if you want it as a file you'll need to pipe it through ComfyUI's Save Diffusion Model node before it's gone.

Installing it

ComfyUI Manager is the easy path - search for SimpleFlux1Merger (or "Simple Flux.1 Merger"). Or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/vekitan55/SimpleFlux1Merger

Then restart ComfyUI. Two things worth knowing: there's no requirements.txt and no model downloads - this pack needs only PyTorch and ComfyUI itself, plus the Flux checkpoints you feed it. And the README's own install section has a placeholder clone URL (yourname/comfyui-simplified-flux1.git) - ignore that, use the repo above.

Where people get burned

Memory is the real tax. The node copies all three models into system RAM, casts everything to bf16 on your GPU, and assembles the merged result there too - you're transiently holding roughly four times a single bf16 model in VRAM. Flux.1 dev at bf16 is ~24 GB per copy, so on a 24 GB card a dev-scale merge will likely OOM. Quantized checkpoints are your friend here. It also silently keeps model A's weights for any key that doesn't match between models - so a mismatched architecture won't error, it'll just quietly fall back. Fine-tunes of the same base are safe; completely different architectures are a coin flip that "worked" but probably isn't what you want.

Once merged, it still wants the usual Flux treatment when you sample: Euler with a Simple/Normal scheduler and guidance around 3.5 for dev. A merge changes the weights, not the sampler rules.