SuperMerger: merging Stable Diffusion checkpoints inside the web UI without saving them

The core idea is that a merge never becomes a file

SuperMerger is a model merge extension for AUTOMATIC1111's stable-diffusion-webui, and the single sentence that defines the project is in the overview: it allows merged models to be loaded as models for image generation without saving them.

That is a bigger change to the workflow than it sounds. The normal way to explore model combinations is to merge two checkpoints into a new file on disk, then point the web UI at that file, then generate. Each ratio change costs a write, a load and a wait. SuperMerger keeps the merged result resident, so the loop becomes: change the ratio, generate, look, change the ratio again.

The README credits this with two effects. It says the extension can prevent the use of HDD and SSD, since a merge that never lands on disk does not consume storage, and it says the extension significantly improves the efficiency of model merging by eliminating the need for saving and loading the model and by generating continuously while changing ratios.

There is a subtlety the documentation is careful about, and it is worth knowing before you start. The model display on the top left of the web UI does not change when a merge happens, but the merged model is indeed loaded. It stays loaded until you select a different model from the model selection in that same top left area. So the UI will not tell you which model you are actually generating with, and that is the first thing to get used to.

The audience is someone already working inside the web UI who treats model merging as an exploration activity rather than a build step. If you merge once and ship the result, this extension is the wrong shape for you.

Four merge modes, and the formulas are the whole API

The merge modes are simple arithmetic, and the documentation writes them out as formulas, which is the most useful thing in the README.

Weight sum, written in the documentation as $(1-\alpha) A + \alpha B$, is the normal merge, where alpha is used, and if block-by-block weights are enabled the MBW base is used as alpha instead. Add difference, written as $A + \alpha (B-C)$, takes A plus alpha times the difference between B and C, and again uses the MBW base as alpha when that is enabled.

Triple sum, $(1-\alpha - \beta) A + \alpha B + \beta C$, merges three models at once with alpha and beta, and the author is candid that he added it because there were three model selection windows and is not sure if it works effectively. That is worth knowing before you build anything on it.

The fourth mode, sum twice, written as $(1-\beta)((1-\alpha)A+\alpha B)+\beta C$, applies the weight sum twice, weighted by beta. So a two-model merge can be a starting point for the first half and a third model can be blended on top of that result in the second half.

The basic usage flow follows from this. You select models A, B and optionally C, choose a merge mode and an alpha (and beta), and then press Merge or Merge and Gen. In the Merge and Gen case, the generation uses the prompt and other settings already specified in txt2img, so you keep generating with the settings you were already using. The Gen button only generates images, and the Stop button interrupts the merging process, which is the escape hatch for a merge that is taking too long.

Ten calculation methods, and one of them is a different operation entirely

The calculation method, called calcmode, is set separately from the merge mode, and the documentation keeps a table mapping the two. The mapping is not arbitrary: each calcmode is valid for particular merge modes, and normal applies to all of them.

The two cosine variants, cosineA and cosineB, calculate to minimize loss during merging, using model A or model B as the reference, and both belong to the weight sum mode. trainDifference, described as training the difference as if it were being finetuned relative to model A, is for add difference. smoothAdd adds a difference that mixes the benefits of median and Gaussian filters, also for add difference, and smoothAdd MT is the multi-threaded version of the same, added for speed.

Then there are the two that are not really blends. extract merges the common and uncommon parts between models B and C, which is how the tool isolates what is different between two models. The tensor methods exchange the tensors themselves at a given ratio rather than summing them, with tensor2 doing the exchange along the second dimension when the tensor has a large number of dimensions. Both belong to weight sum. And self simply multiplies the weight by alpha.

The performance work in this area has a compatibility cost, and the documentation is honest about it. In several modes the functions used for calculations were changed, resulting in faster merge computation speeds. The calculation results should be the same, but if you cannot get the same result, there is a use old calc method option. The affected methods are named: weight sum in its normal, cosineA and cosineB variants, and sum twice in its normal variant.

That fallback option is the difference between a speed optimisation and a silent behaviour change, and it exists because someone asked for it. A contributor named wkpark is credited with proposing the method.

Block-by-block weights and the merge history are what make it a search tool

Two features turn the extension from a convenience into something you can search over.

The first is use MBW, block-by-block merging. The README section explains that block-by-block merging is enabled and asks you to set the weights in the Merge interface. The practical effect is that alpha is no longer a single number for the whole model but a set of per-block weights, which is how you isolate one region of the network, for example the text encoder, without disturbing the rest.

The second is the merge log. The documentation describes reading settings from the merge log, with the log updated on each merge and a sequential ID starting from 1 assigned to each entry. A value of -1 corresponds to the settings from the last merge and -2 to the one before it. The log itself is saved as mergehistory.csv in the extension directory, and there is a History tab where you can browse and search it, with the note that you can search by separating terms with a half-width space.

So the workflow this enables is: merge with a given configuration, look at the result, and if you liked it, go back and find the exact alpha, mode and MBW settings that produced it. Without the log you would be relying on memory of a slider position, which is not a reproducible method.

There is also a cache, and it is worth understanding what it does. If the web UI's model cache function is enabled, SuperMerger will create a model cache to speed up continuous merging, and during this process the model is cached separately from the web UI's own cache. There is a Clear Cache button to delete it after use. The documentation is explicit that the cache is created in RAM, not VRAM, which is a useful distinction when you are watching memory usage on a large merge.

LoRA merging, extraction and the LoRA tab

The second half of the extension is a set of LoRA tools, listed in the index as Merge LoRAs, Merge to Checkpoint, Extract from Checkpoints and Extract from two LoRAs.

The LoRA workflow has a naming convention that the project changed recently. The recent update notes from February 2024 record that the model name for MakeLoRA has changed, following the Dreambooth convention, with the names changed to Tuned and Original. The Japanese note explains the same change. So if you have scripts or notes that refer to the old names, they will not match the interface any more.

The extraction tools are the interesting half. Extracting from two LoRAs and extracting from checkpoints are the operations that let you take a piece out of a model, and they are what the calcmode table describes when it says extract merges the common and uncommon parts between models B and C.

A November 2023 update added an Include/Exclude feature and a new calcmode for extract, credited to a contributor named subaqua. Another change in the same period extended the LoRA extract script to support SDXL and 2.x, and added support for LoRA merging into a checkpoint in SD 2.x.

The index also lists tabs for Calcomode, Elemental Merge, and Other Tabs, and the repository holds separate documents for the calculation methods in calcmode_en.md and the elemental merge feature in elemental_en.md, each with a Japanese counterpart. The elemental merge documentation is a separate file rather than part of the README, which is a sign the feature set has grown past what the main document covers.

64GB of RAM is the floor for an XL merge, and the author says so loudly

The README devotes an attention block to a hardware requirement, and the tone of it is worth quoting in spirit because it is unusually candid for a project README.

A minimum of 64GB of CPU memory is required for the XL model merge. Even with 64GB of memory, depending on the software you are using in conjunction, there is a risk of system instability. The instruction is to work in a state where it is acceptable for the system to crash, and the author mentions encountering a blue screen for the first time in a while.

That is the whole operational warning, and it is significant. The merges happen on CPU, and an SDXL checkpoint merged in memory means two or three full models resident in system RAM simultaneously, plus the intermediate tensors. The use cuda option added in November 2023 is the answer for people with GPU memory to spare, and the documentation says that with enough GPU memory the merge speed can be 50x faster.

The second known issue is about interaction with other extensions. If you have other extensions installed simultaneously, such as sd-webui-prompt-all-in-one, enabling the option to automatically open the browser upon launch can cause instability. The likely cause is Gradio, so the documentation says it might be difficult to fix, and advises disabling that option.

The project publishes a changelog file in the repository, and the README notes that all updates can be found there. The most recent entry listed in the README itself is the February 2024 bug fix, while the last push to the repository was on 2026-09-13, so the changelog is the authoritative record of what has changed since then.

Where SuperMerger is the wrong tool

The first wrong-tool case is a pipeline that needs the merged checkpoint as a file. The whole design is built on not saving, so if your workflow ends with a checkpoint on disk that a downstream training run or an inference server consumes, you are using a tool whose central feature is the opposite of what you need. You would be merging, saving, and loading, which is what the extension was built to avoid.

The second case is a machine that does not have 64GB of RAM and no spare GPU memory. The XL merge is out of reach, and the failure mode is a system crash rather than a clean error, which is a poor property for a machine you also use for other work.

The third case is someone who wants a single deterministic merge. The tool is built for exploration, and the calculation method changes in a later version produced different intermediate results for some modes, with a compatibility flag as the escape hatch. If you need one reproducible artefact, the in-memory approach adds a variable without adding value.

There is a licensing point that matters if you plan to distribute anything built on it. The project is AGPL-3.0, which is the copyleft licence, and it carries a network use obligation. For a personal experimentation tool that is irrelevant. For a company that modifies the extension and serves the modified version to users over a network, the source availability obligation is real, and it is a different conversation from the permissive licences common in the Stable Diffusion extension ecosystem.

Finally, the platform assumption. The extension targets AUTOMATIC1111's stable-diffusion-webui specifically, and the fork situation around that project has been unsettled for a while, so a tool that plugs into its extension interface is tied to that host's internals.

Editorial conclusion

SuperMerger suits someone exploring model combinations interactively, since the point of loading a merged model without saving it is that you can change the ratio and generate again immediately, and the block-by-block and LoRA tooling makes systematic comparison practical. It does not suit a workflow that needs reproducible merged checkpoints on disk, and the XL merge path has a hard floor of 64GB of CPU memory with an explicit warning about system instability. Before adopting, read the calculation method notes in calcmode_en.md, check whether the use old calc method option is needed to reproduce older results, and note that the repository has no GitHub releases and its changelog lives in changelog.md rather than in release notes.

Frequently asked questions

Official sources

1. hako-mikan/sd-webui-supermerger on GitHub
2. Issues
3. License: AGPL-3.0
4. README