Model merging: SLERP, TIES, DARE en wanneer het zinvol is

De meeste discussies over het aanpassen van LLM's draaien om fine-tuning: data verzamelen, training starten, uren of dagen wachten, evalueren. Er bestaat echter een hele categorie technieken die deze cyclus volledig omzeilt: model merging, oftewel het samenvoegen van de gewichten van meerdere getrainde modellen rechtstreeks in de parameterruimte — zonder ook maar één trainingsiteratie. Geen GPU-training, geen gradient descent. Alleen rekenkunde op gewichten.

Het klinkt als een shortcut die niet kan werken. In de praktijk werkt het verrassend goed — als u weet wanneer en hoe u het toepast. Dit artikel legt de drie belangrijkste methoden uit (SLERP, TIES, DARE), beschrijft hoe merging verschilt van distillatie en ensembling, en bespreekt realistisch wat de voordelen en beperkingen zijn voor bedrijven die serieuzer met open-weight modellen willen werken.

Wat model merging is — en wat het niet is

Voordat we ingaan op de methoden, een belangrijke afbakening:

Model merging combineert de gewichten van twee of meer modellen met een gedeelde architectuur en tokenizer rechtstreeks in de parameterruimte. Het resultaat is één model met gewichten die op een bepaalde manier een combinatie zijn van de bronmodellen. Het vereist geen trainingsdata, geen GPU tijdens het mergen zelf (alleen RAM om de gewichten te laden), en geen gradient.

Distillatie is iets anders: een groter teacher-model genereert synthetische antwoorden waarop een kleiner student-model wordt getraind. Distillatie vereist training — merging niet. Beide aanpakken kunnen elkaar aanvullen, maar zijn niet uitwisselbaar. Als distillatie u interesseert, behandelt een apart artikel Modeldistillatie dit onderwerp.

Ensembling is ook een andere aanpak: meerdere modellen draaien tegelijkertijd tijdens inferentie en hun uitvoer wordt gecombineerd via voting of gemiddeld aggregeren. Ensembling is duurder bij inferentie (u draait meerdere modellen), terwijl merging één model produceert met een normale inferentiebelasting.

Merging staat dus in een geheel eigen categorie: het combineert capaciteiten zonder trainingskosten, maar ten koste van onvoorspelbaarheid van het resultaat.

Waarom merging überhaupt werkt

De intuïtie achter merging komt voort uit de observatie dat modellen met dezelfde architectuur, getraind vanuit hetzelfde (of een vergelijkbaar) basismodel, gewichten hebben in een vergelijkbare ruimte. Fine-tuning op domein A verschuift de gewichten in een bepaalde richting; fine-tuning op domein B in een andere richting. Een lineaire combinatie van die verschuivingen legt in principe beide capaciteiten vast — als ze elkaar niet neutraliseren.

Dat "als" is de kern van het probleem waar geavanceerdere methoden zoals TIES en DARE zich op richten.

De drie belangrijkste methoden

SLERP — sferische interpolatie

SLERP (Spherical Linear Interpolation) is de eenvoudigste en oudste methode. Oorspronkelijk gebruikt voor het interpoleren van rotaties in 3D-graphics; in de context van modellen wordt het toegepast op parametervectoren.

In plaats van lineair te middelen ((gewichten_A + gewichten_B) / 2) interpoleert SLERP langs een geodetische boog op het hypersferische oppervlak van de parameterruimte. Het resultaat behoudt de richtverschillen van gewichten beter dan een simpel lineair gemiddelde.

In de praktijk: - Werkt uitsluitend op twee modellen — niet op drie of meer. - Eén parameter t (0.0 = puur model A, 1.0 = puur model B, 0.5 = midden) bepaalt de "nabijheid" van het resultaat. - Het resultaat is gevoelig voor de keuze van t — de optimale waarde verschilt per modelpaar. - Geschikt voor het subtiel "verzachten" van het verschil tussen twee fine-tunes (bijv. het ene model is beter in stijl, het andere in feiten).

TIES — interferentiebehandeling

TIES (Trim, Elect Sign, Disjoint Merge) lost een probleem op dat SLERP negeert: wanneer u meerdere fine-tunes naïef combineert, kunnen hun wijzigingen in de parameterruimte elkaar tegenwerken — sommige parameters worden positief verschoven bij model A en negatief bij model B, waardoor ze bij middeling naar nul gaan en de betreffende capaciteit verloren gaat.

TIES lost dit op in drie stappen:

1. 1.Trim — het wegsnijden van kleine wijzigingen: alleen de grootste deltaparameters (afwijkingen van het basismodel) worden behouden. Kleine wijzigingen zijn meestal ruis.
2. 2.Elect Sign — richtingskeuze: voor elke parameter wordt via stemming de dominante wijzigingsrichting bepaald over alle modellen. Modellen die in de minderheidsrichting stemmen, worden bij die parameter genegeerd.
3. 3.Disjoint Merge — samenvoegen: elke parameter wordt alleen bijgedragen door de modellen die de voorgaande stappen hebben overleefd.

TIES werkt op drie of meer modellen, wat het geschikt maakt voor het bouwen van "polyglot"-modellen uit meerdere domeinspecifieke fine-tunes. Ten koste van hogere configuratiecomplexiteit.

DARE — redundantiereductie

DARE (Drop And REscale) benadert het probleem anders: vóór het samenvoegen "gooit" het willekeurig een groot deel van de deltaparameters van elk model weg (instellen op nul) — doorgaans 80–90% — en schaalt de overige proportioneel op. De intuïtie: de meeste deltaparameters zijn redundant of verstorend; alleen een klein deel bewaren met herschaling geeft een vergelijkbaar of beter resultaat.

DARE wordt in de praktijk gecombineerd met TIES (DARE+TIES): DARE reduceert ruis in elk bronmodel voordat TIES zijn interferentiereductielogica toepast. Deze combinatie is in mergekit beschikbaar als een van de vooraf gedefinieerde strategieën.

Task Arithmetic en andere varianten

mergekit en de onderzoeksgemeenschap implementeren ook andere methoden:

• Task Arithmetic: het optellen van "task vectors" (delta ten opzichte van het basismodel) met weging — een eenvoudige basis waaruit TIES en DARE voortkomen.
• Passthrough: sommige lagen worden rechtstreeks van het ene model genomen, andere van het tweede — een niet-objectieve maar soms verrassend effectieve methode bij modellen met wisselend sterke onderdelen.

mergekit — de tool die het bijeenbrengt

Voor praktisch gebruik is `mergekit` de de facto standaard. Het wordt geconfigureerd via YAML-bestanden, wat reproduceerbaarheid en versiebeheer van recepten vergemakkelijkt. Een voorbeeld van een minimale configuratie voor SLERP:

merge_method: slerp
base_model: meta-llama/Llama-3-8B
models:
  - model: ./my-finetune-A
  - model: ./my-finetune-B
parameters:
  t: 0.5
dtype: bfloat16

mergekit verwerkt de meeste merges op CPU met voldoende RAM (voor 7B-modellen in BF16 ruwweg 30–40 GB RAM, geen VRAM). Het mergen zelf duurt slechts minuten.

De relatief nieuwe functie tokensurgeon maakt cross-tokenizer transplantatie van gewichten mogelijk — waarmee het samenvoegen van modellen uit verschillende families (bijv. Qwen en Llama) mogelijk wordt, al met aanzienlijk minder voorspelbaar resultaat en de noodzaak van grondige evaluatie.

Voor wie handmatig afstemmen van parameters wil vermijden: er bestaat ook evolutionair merging (Mergenetic en vergelijkbare tools), waarbij het optimale recept automatisch wordt gevonden via evolutionaire algoritmen — het mergen wordt tientallen iteraties uitgevoerd met verschillende parametercombinaties, waarbij elke iteratie wordt geëvalueerd op een kleine benchmarkset. Deze methode is langzamer (uren in plaats van minuten), maar vermindert de afhankelijkheid van expertintuïtie.

Wanneer merging zinvol is

In de praktijk is merging gerechtvaardigd in een aantal concrete situaties:

Combineren van capaciteiten uit meerdere fine-tunes. U hebt een model dat is fine-getuned op klantcommunicatie en een ander op technische documentatie. U wilt één model dat beide beheerst. In plaats van opnieuw te trainen op gemengde data, probeert u eerst een merge — als de capaciteiten niet conflicteren, kan het resultaat vergelijkbaar zijn.

Versnelde verkenning in een vroeg stadium. Voordat u uren training investeert in elke combinatie van hyperparameters en datamixen, kunt u met merging snel de ruimte van mogelijkheden verkennen. Enkele merges van bestaande checkpoints kosten minder dan meerdere trainingsruns.

Noodoplossing bij beperkte trainingsresources. Als u geen GPU-capaciteit hebt voor verdere training, maar wel meerdere gedeeltelijk gespecialiseerde modellen, is merging een legitiem alternatief.

Subtiele stijlafstemming. SLERP met een waarde van t dichter bij één kant geeft u een model dat "iets meer" rekening houdt met de eigenschappen van één van de fine-tunes — wat precies alles kan zijn wat u nodig hebt om de gewenste toon te bereiken.

Wanneer merging geen zin heeft

Even belangrijk is te weten wanneer u merging beter niet probeert:

Sterk verschillende trainingsdistributies. Hoe meer de datadistributies en doelstellingen van de bronmodellen uiteenlopen, hoe groter de kans op interferentie. Een merge van een model getraind op juridische contracten met een model getraind op poëzie zal waarschijnlijk nergens op slaan — beide fine-tunes trekken de gewichten in verschillende richtingen.

Verschillende architecturen of tokenizers (zonder tokensurgeon). Merging veronderstelt een identieke architectuur en dezelfde tokenizer — anders bestaat er technisch gezien geen consistente parameterruimte om in te interpoleren.

Wanneer u voorspelbare verbetering nodig hebt. Merging is experimenteel. Het werkt niet altijd. Het resultaat moet altijd worden geëvalueerd op uw specifieke benchmarks — zonder evaluatie weet u niet of u het model er niet op achteruit hebt laten gaan. Als uw project garanties vereist, gebruik dan standaard fine-tuning, waarvan het resultaat reproduceerbaar en controleerbaar is. Het meten van de kwaliteit van fine-tuningwijzigingen komt aan bod in het artikel Hoe meet u of fine-tuning heeft geholpen.

Gereguleerde omgevingen. In de context van geneeskunde, recht of financiën is merging op een productiemodel risicovoller dan fine-tuning — vanwege de beperkte auditbaarheid. U kunt niet aantonen op welke data het resulterende model is getraind. Voor gereguleerde sectoren raden wij merging aan alleen als tool voor interne experimenten, niet als weg naar een productiemodel.

Risico's en beperkingen

Degradatie op de lange staart. Merging wordt doorgaans beoordeeld op populaire benchmarks. Op randgevallen die specifiek zijn voor uw domein kan het resulterende model op manieren falen die eenvoudige benchmarks niet opvangen.

Kwaliteitsvariatie. Dezelfde methode met verschillende modelparen produceert dramatisch verschillende resultaten. Een recept dat werkte voor één paar fine-tunes, hoeft niet te werken voor een ander.

Ongecontroleerd resultaat vanuit veiligheidsperspectief. Samengevoegde modellen kunnen ongewenst gedrag overnemen van een van de bronmodellen als dat niet voldoende was uitgelijnd (aligned). Dit is in het bijzonder belangrijk bij het samenvoegen van modellen van verschillende trainers.

SLERP/TIES-merging is niet "altijd veilig" — in die zin dat het resulterende model niet alle gewenste eigenschappen van de bronnen hoeft te bewaren. Het resultaat moet altijd worden geëvalueerd. Als u de meest voorkomende valkuilen bij experimenteren met fine-tuning in het algemeen wilt vermijden, lees dan 7 redenen waarom fine-tuning in de praktijk mislukt.

Merging versus fine-tuning: wat en wanneer

Een eenvoudig beslissingsraamwerk:

• Hebt u ten minste twee bestaande fine-tunes van hetzelfde basismodel en wilt u de combinatie verkennen? → Probeer eerst een merge.
• Hebt u een model nodig met specifieke domeinkennis die geen van uw fine-tunes heeft? → Fine-tuning op nieuwe data.
• Hebt u kwaliteitsgaranties en auditbaarheid nodig in een gereguleerde omgeving? → Fine-tuning met gedocumenteerde data.
• Wilt u snel verkennen voordat u in training investeert? → Merge is een legitieme eerste peiling.
• Werkt u met een MoE-architectuur (Llama 4, Qwen3 MoE)? → Merging is veel gecompliceerder, de toolondersteuning is minder volwassen — verifieer dit voordat u investeert.

Merging is geen vervanging voor fine-tuning. Het is een aanvullende tool in de gereedschapskist van een gevorderde ML-engineer — waardevol precies daar waar training onnodig duur zou zijn voor exploratieve vragen. De relatie tussen fine-tuning en merging lijkt op die tussen lokale LLM's en de cloud: beide hebben hun plek, het hangt af van de context.

Praktische aanpak voor een eerste poging

Als u merging wilt proberen:

1. 1.Begin met twee fine-tunes van hetzelfde basismodel, waarbij beide gedocumenteerde kwaliteit hebben op uw benchmarks.
2. 2.Installeer mergekit, schrijf een YAML-configuratie voor SLERP met t=0.5.
3. 3.Voer de merge uit (draait op CPU, vraagt tientallen GB RAM, geen GPU).
4. 4.Evalueer het resultaat op dezelfde benchmarks als de bronmodellen — zonder evaluatie weet u niets.
5. 5.Als het resultaat veelbelovend is, experimenteer met verschillende waarden van t of ga over op TIES voor meer modellen.
6. 6.Alleen als evaluatie de kwaliteit bevestigt → gebruik in productie.

Veelgestelde vragen

Is merging een vervanging voor fine-tuning?

Nee. Merging veronderstelt dat u ten minste één goed getrainde fine-tune hebt — het werkt bovenop bestaande trainingsresultaten en vervangt die niet. Als er geen fine-tune bestaat, heeft merging niets om mee te werken.

Hoeveel RAM heb ik nodig voor het mergen van 7B-modellen?

Voor 7B-modellen in BF16 ruwweg 30–40 GB RAM op CPU. VRAM zelf is niet nodig — het mergen verloopt op CPU in enkele minuten. Voor 13B-modellen rekent u ruwweg het dubbele.

Hoe verschilt DARE van willekeurig verwijderen van gewichten (pruning)?

Pruning verwijdert parameters permanent met als doel het model kleiner te maken. DARE verwijdert deltaparameters (afwijkingen van het basismodel) vóór het mergen om interferentieruis te verminderen — het resulterende model heeft hetzelfde aantal parameters als de bronmodellen. Het zijn fundamenteel verschillende motivaties.

Werkt merging voor MoE-modellen (Llama 4, Qwen3 MoE)?

Technisch gezien gedeeltelijk — mergekit voegt ondersteuning toe, maar MoE-architecturen zijn aanzienlijk gecompliceerder: naast de expertgewichten moeten ook de routerparameters worden behandeld. De resultaten zijn minder voorspelbaar dan bij dense modellen en de toolondersteuning is nog in ontwikkeling. Wij raden aan eerst de actuele mergekit-documentatie te raadplegen voor de specifieke architectuur.

Kan ik met merging het probleem van catastrofisch vergeten oplossen?

Gedeeltelijk — als u een checkpoint hebt van vóór het vergeten en na het fine-tunen, kan een merge tussen beide de regressie van algemene capaciteiten verzachten. Dit is een legitieme techniek, maar geen betrouwbare vervanging voor replay-data of regularisatiebenaderingen tijdens het fine-tunen zelf.

*Overweegt u met uw eigen fine-getunte modellen aan de slag te gaan en weet u niet waar u moet beginnen — of het nu gaat om de keuze van de methode, de voorbereiding van data of merging — dan kijken wij graag met u mee naar uw concrete situatie. Bij MP Industrial Solutions hebben wij dit proces doorlopen met meerdere klanten uit de maakindustrie en engineering, en weten wij waar de echte valkuilen liggen.*