{"course":{"slug":"open-models","title":"The Open Model Ecosystem","url":"https://addaly.com/learn/open-models","level":"intermediate","track":"deep"},"lesson":{"slug":"merging-models","title":"Merging models, and what it really does","url":"https://addaly.com/learn/open-models/merging-models","position":59,"of":71,"minutes":8,"answer":"Merging averages fine-tuning deltas from a shared base.","keyIdea":"Merging averages fine-tuning deltas from a shared base, which works because those deltas stay in a connected low-loss region. And it is most reliable when merging your own runs and least trustworthy when a merge was selected on the benchmark it is reported against."},"body":{"format":"markdown","text":"## Averaging weights, and why it is not absurd\n\nYou can take two fine-tunes of the same base model and average their weights. The result often works, and sometimes performs better than either parent.\n\nThat sounds like it should produce nonsense, and the reason it does not is worth knowing: fine-tunes of a shared base stay in a connected low-loss region of the weight space. They have not travelled far from the base or from each other, so points between them are also reasonable models. Merge two models with *different* bases and you do get nonsense, immediately.\n\nThe hard requirements: identical architecture, identical tokenizer, same shapes. In practice, a shared base model.\n\n## The methods\n\n**Linear averaging** and **SLERP** interpolate directly between two sets of weights, SLERP along a spherical path rather than a straight line. Simple and effective for two models.\n\n**Task arithmetic** is the idea that clarifies the rest. Define a task vector as the difference between a fine-tune and its base: the change tuning made. Task vectors can be added to combine capabilities, or subtracted to remove one. This gives a vocabulary for what merging is: you are doing arithmetic on the deltas, not on the models.\n\n**TIES** merges many models by trimming small changes, resolving sign conflicts by a weighted vote, and averaging only the parameters that agree. It handles interference between task vectors, which plain averaging does not.\n\n**DARE** randomly drops most of the delta and rescales what remains, on the observation that fine-tuning deltas are highly redundant. Often combined with TIES.\n\n`mergekit` implements all of these from a short configuration:\n\n```yaml\nmodels:\n  - model: ./my-support-tune\n    parameters: {weight: 0.5, density: 0.6}\n  - model: ./my-multilingual-tune\n    parameters: {weight: 0.5, density: 0.6}\nmerge_method: ties\nbase_model: Qwen/Qwen3-8B\ndtype: bfloat16\n```\n\nMerging is cheap. It runs on a CPU with enough RAM, takes minutes, and needs no training data.\n\n## The use that reliably works\n\n**Merging your own runs.** Train the same configuration with three seeds, or take several checkpoints from one run, and average them. This is the model-soup idea and it is the most dependable form of merging: it reduces variance, usually gains a little, and costs nothing but disk.\n\n**Combining your own domain adapters**, where each was trained on a distinct capability you want together. Test the combination on both tasks; interference is common and TIES exists because of it.\n\n## The use that should make you cautious\n\nPublic leaderboards have been full of merges of merges, tuned by trying combinations until the score went up. That process optimises the benchmark directly, and the resulting models frequently underperform their headline numbers on anything else.\n\nThere are three further problems with a deep merge chain, and they are the reasons the vetting lesson treated them as a red flag:\n\n- **Licence.** The merged model carries the obligations of every parent. A single non-commercial ancestor makes the whole thing non-commercial.\n- **Provenance.** Nobody can say what data influenced the result, so no claim about the model's behaviour is supportable.\n- **Evaluation.** Merges are frequently selected on the benchmark they are then reported against, which is the definition of overfitting.\n\n## How to merge responsibly\n\n1. Merge models whose parents you know and whose licences you have checked.\n2. Evaluate on a held-out set the merge selection did not use.\n3. Include the regression set from the previous lesson; merges shift refusal behaviour and language coverage in ways nobody intends.\n4. Record the recipe (the exact configuration, the parent revisions, the method) so the result is reproducible.\n5. Prefer merging your own runs over merging strangers' models.\n\n> Merging is a useful tool with an unusually low cost and an unusually high rate of being used badly. The discipline that separates the two is entirely in step 2."},"check":{"question":"A team merges two Apache 2.0 fine-tunes with a third model that turns out to be a Llama derivative. What is the licence position of the result?","options":[{"text":"Apache 2.0, since two of the three parents are permissive and majority terms apply.","correct":false,"tempting":"Licences do not combine by vote; every parent's obligations attach to a derivative that contains its weights."},{"text":"Unlicensed, since a merge of differently licensed models cannot be distributed at all.","correct":false,"tempting":"Overstates the position: the merge can generally be distributed under the most restrictive parent's terms, not under none."},{"text":"The merge inherits every parent's obligations, so Meta's community licence terms, including the naming requirement, apply to the whole result.","correct":true},{"text":"No licence applies because merging produces new weights that are not derived from any single parent.","correct":false,"tempting":"Averaging weights is derivation in the most literal sense; the parents' parameters are arithmetically present in the result."}]},"prev":{"slug":"catastrophic-forgetting","title":"Measuring what you broke","url":"https://addaly.com/learn/open-models/catastrophic-forgetting"},"next":{"slug":"continued-pretraining","title":"When the model does not have your language at all","url":"https://addaly.com/learn/open-models/continued-pretraining"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Merging models, and what it really does', in The Open Model Ecosystem. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/open-models/merging-models (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Merging models, and what it really does","courseTitle":"The Open Model Ecosystem","module":{"index":6,"slug":"adapting-a-model","title":"Adapting a model to your work"},"answer":null,"keyIdea":"Merging averages fine-tuning deltas from a shared base, which works because those deltas stay in a connected low-loss region. And it is most reliable when merging your own runs and least trustworthy when a merge was selected on the benchmark it is reported against.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"averaging-weights-and-why-it-is-not-absurd","runs":[{"text":"Averaging weights, and why it is not absurd"}]},{"t":"p","runs":[{"text":"You can take two fine-tunes of the same base model and average their weights. The result often works, and sometimes performs better than either parent."}]},{"t":"p","runs":[{"text":"That sounds like it should produce nonsense, and the reason it does not is worth knowing: fine-tunes of a shared base stay in a connected low-loss region of the weight space. They have not travelled far from the base or from each other, so points between them are also reasonable models. Merge two models with "},{"text":"different","i":true},{"text":" bases and you do get nonsense, immediately."}]},{"t":"p","runs":[{"text":"The hard requirements: identical architecture, identical tokenizer, same shapes. In practice, a shared base model."}]},{"t":"h2","id":"the-methods","runs":[{"text":"The methods"}]},{"t":"p","runs":[{"text":"Linear averaging","b":true},{"text":" and "},{"text":"SLERP","b":true},{"text":" interpolate directly between two sets of weights, SLERP along a spherical path rather than a straight line. Simple and effective for two models."}]},{"t":"p","runs":[{"text":"Task arithmetic","b":true},{"text":" is the idea that clarifies the rest. Define a task vector as the difference between a fine-tune and its base: the change tuning made. Task vectors can be added to combine capabilities, or subtracted to remove one. This gives a vocabulary for what merging is: you are doing arithmetic on the deltas, not on the models."}]},{"t":"p","runs":[{"text":"TIES","b":true},{"text":" merges many models by trimming small changes, resolving sign conflicts by a weighted vote, and averaging only the parameters that agree. It handles interference between task vectors, which plain averaging does not."}]},{"t":"p","runs":[{"text":"DARE","b":true},{"text":" randomly drops most of the delta and rescales what remains, on the observation that fine-tuning deltas are highly redundant. Often combined with TIES."}]},{"t":"p","runs":[{"text":"mergekit","code":true},{"text":" implements all of these from a short configuration:"}]},{"t":"code","lang":"yaml","label":"YAML","text":"models:\n  - model: ./my-support-tune\n    parameters: {weight: 0.5, density: 0.6}\n  - model: ./my-multilingual-tune\n    parameters: {weight: 0.5, density: 0.6}\nmerge_method: ties\nbase_model: Qwen/Qwen3-8B\ndtype: bfloat16"},{"t":"p","runs":[{"text":"Merging is cheap. It runs on a CPU with enough RAM, takes minutes, and needs no training data."}]},{"t":"h2","id":"the-use-that-reliably-works","runs":[{"text":"The use that reliably works"}]},{"t":"p","runs":[{"text":"Merging your own runs.","b":true},{"text":" Train the same configuration with three seeds, or take several checkpoints from one run, and average them. This is the model-soup idea and it is the most dependable form of merging: it reduces variance, usually gains a little, and costs nothing but disk."}]},{"t":"p","runs":[{"text":"Combining your own domain adapters","b":true},{"text":", where each was trained on a distinct capability you want together. Test the combination on both tasks; interference is common and TIES exists because of it."}]},{"t":"h2","id":"the-use-that-should-make-you-cautious","runs":[{"text":"The use that should make you cautious"}]},{"t":"p","runs":[{"text":"Public leaderboards have been full of merges of merges, tuned by trying combinations until the score went up. That process optimises the benchmark directly, and the resulting models frequently underperform their headline numbers on anything else."}]},{"t":"p","runs":[{"text":"There are three further problems with a deep merge chain, and they are the reasons the vetting lesson treated them as a red flag:"}]},{"t":"ul","items":[[{"text":"Licence.","b":true},{"text":" The merged model carries the obligations of every parent. A single non-commercial ancestor makes the whole thing non-commercial."}],[{"text":"Provenance.","b":true},{"text":" Nobody can say what data influenced the result, so no claim about the model’s behaviour is supportable."}],[{"text":"Evaluation.","b":true},{"text":" Merges are frequently selected on the benchmark they are then reported against, which is the definition of overfitting."}]]},{"t":"h2","id":"how-to-merge-responsibly","runs":[{"text":"How to merge responsibly"}]},{"t":"ol","start":1,"items":[[{"text":"Merge models whose parents you know and whose licences you have checked."}],[{"text":"Evaluate on a held-out set the merge selection did not use."}],[{"text":"Include the regression set from the previous lesson; merges shift refusal behaviour and language coverage in ways nobody intends."}],[{"text":"Record the recipe (the exact configuration, the parent revisions, the method) so the result is reproducible."}],[{"text":"Prefer merging your own runs over merging strangers’ models."}]]},{"t":"quote","runs":[{"text":"Merging is a useful tool with an unusually low cost and an unusually high rate of being used badly. The discipline that separates the two is entirely in step 2."}]}],"check":{"question":[{"text":"A team merges two Apache 2.0 fine-tunes with a third model that turns out to be a Llama derivative. What is the licence position of the result?"}],"options":[{"text":[{"text":"Apache 2.0, since two of the three parents are permissive and majority terms apply."}],"correct":false,"tempting":[{"text":"Licences do not combine by vote; every parent’s obligations attach to a derivative that contains its weights."}]},{"text":[{"text":"Unlicensed, since a merge of differently licensed models cannot be distributed at all."}],"correct":false,"tempting":[{"text":"Overstates the position: the merge can generally be distributed under the most restrictive parent’s terms, not under none."}]},{"text":[{"text":"The merge inherits every parent’s obligations, so Meta’s community licence terms, including the naming requirement, apply to the whole result."}],"correct":true,"tempting":null},{"text":[{"text":"No licence applies because merging produces new weights that are not derived from any single parent."}],"correct":false,"tempting":[{"text":"Averaging weights is derivation in the most literal sense; the parents’ parameters are arithmetically present in the result."}]}],"order":[0,1,3,2],"why":null},"prev":{"slug":"catastrophic-forgetting","title":"Measuring what you broke","minutes":8},"next":{"slug":"continued-pretraining","title":"When the model does not have your language at all","minutes":8}}}