Merging modeli: SLERP, TIES, DARE i kiedy to ma sens

Większość dyskusji o dostosowywaniu LLM obraca się wokół fine-tuningu: zebrać dane, uruchomić trening, czekać godziny lub dni, oceniać. Istnieje jednak cała kategoria technik, która ten cykl całkowicie omija: model merging, czyli łączenie wag kilku wytrenowanych modeli bezpośrednio w przestrzeni parametrycznej — bez ani jednej iteracji treningowej. Żadnego treningu na GPU, żadnego gradient descent. Tylko arytmetyka na wagach.

Brzmi jak skrót, który nie może działać. W praktyce jednak działa zaskakująco dobrze — jeśli wiecie, kiedy i jak go stosować. Ten artykuł wyjaśnia trzy główne metody (SLERP, TIES, DARE), czym merging różni się od destylacji i ensemblingu, oraz jakie są realistyczne korzyści i ograniczenia dla firm rozważających bardziej zaawansowaną pracę z modelami open-weight.

Czym jest model merging — i czym nie jest

Zanim przejdziemy do metod, ważne rozróżnienie:

Model merging łączy wagi dwóch lub więcej modeli o wspólnej architekturze i tokenizerze bezpośrednio w przestrzeni parametrycznej. Wynikiem jest jeden model z wagami stanowiącymi pewną kombinację modeli źródłowych. Nie wymaga żadnych danych treningowych, żadnego GPU podczas samego mergingu (tylko RAM do wczytania wag) ani gradientu.

Destylacja to coś innego: większy model-nauczyciel (teacher) generuje syntetyczne odpowiedzi, na których trenowany jest mniejszy model-uczeń (student). Destylacja wymaga treningu — merging nie. Oba podejścia mogą się uzupełniać, ale nie są wymienne. Jeśli interesuje was destylacja, poświęcony jej jest osobny artykuł Destylacja modelu.

Ensemble to również odrębne podejście: kilka modeli działa w czasie inferencji równolegle, a ich wyniki są łączone przez głosowanie lub uśrednianie agregacji. Ensemble jest droższy w inferencji (uruchamiacie więcej modeli), merging produkuje jeden model ze zwykłym obciążeniem inferencji.

Merging stoi więc we własnej kategorii: łączy możliwości bez kosztów treningowych, ale kosztem nieprzewidywalności wyniku.

Dlaczego merging w ogóle działa?

Intuicja stojąca za mergingiem wynika z obserwacji, że modele o tej samej architekturze trenowane z tego samego (lub podobnego) modelu bazowego mają wagi w podobnej przestrzeni. Fine-tuning na domenie A przesuwa wagi w określonym kierunku; fine-tuning na domenie B — w innym. Liniowa kombinacja tych przesunięć w zasadzie uchwyci obie możliwości — jeśli nie znoszą się nawzajem.

To „jeśli" jest sednem problemu, któremu poświęcone są bardziej zaawansowane metody, takie jak TIES i DARE.

Trzy główne metody

SLERP — sferyczna interpolacja

SLERP (Spherical Linear Interpolation) to najprostsza i najstarsza metoda. Pierwotnie stosowana do interpolacji rotacji w grafice 3D; w kontekście modeli aplikowana do wektorów parametrycznych.

Zamiast liniowego uśredniania ((wagi_A + wagi_B) / 2) SLERP interpoluje po łuku geodezyjnym na hipersferycznej powierzchni przestrzeni parametrycznej. Wynik lepiej zachowuje różnice w kierunkach wag niż bezpośrednia średnia liniowa.

W praktyce: - Działa wyłącznie na dwóch modelach — nie na trzech i więcej. - Jeden parametr t (0.0 = czysty model A, 1.0 = czysty model B, 0.5 = środek) kontroluje „bliskość" wyniku. - Wynik jest wrażliwy na wybór t — optymalna wartość różni się w zależności od pary modeli. - Nadaje się do delikatnego „złagodzenia" różnicy między dwoma fine-tunami (np. jeden model jest lepszy stylistycznie, drugi merytorycznie).

TIES — obsługa interferencji

TIES (Trim, Elect Sign, Disjoint Merge) rozwiązuje problem, który SLERP ignoruje: gdy naiwnie połączycie kilka fine-tunów, ich zmiany w przestrzeni parametrycznej mogą sobie wzajemnie przeczyć — niektóre parametry są przesunięte dodatnio w modelu A i ujemnie w modelu B, przez co przy uśrednianiu znoszą się i całościowa zdolność zostaje utracona.

TIES rozwiązuje to w trzech krokach:

1. 1.Trim — przycinanie małych zmian: zachowywane są tylko największe delty parametrów (odchylenia od modelu bazowego). Małe zmiany są przeważnie szumem.
2. 2.Elect Sign — wybór kierunku: dla każdego parametru głosowaniem ustalany jest dominujący kierunek zmiany w modelach. Modele głosujące w mniejszościowym kierunku są przy danym parametrze ignorowane.
3. 3.Disjoint Merge — scalenie: każdy parametr wnosi wkład tylko z tych modeli, które przeżyły poprzednie kroki.

TIES działa na trzech i więcej modelach, co czyni go odpowiednim do budowania modeli „poliglotycznych" z kilku domenowych fine-tunów. Za cenę wyższej złożoności konfiguracji.

DARE — redukcja redundancji

DARE (Drop And REscale) podchodzi do problemu inaczej: przed scaleniem losowo „odrzuca" (ustawia na zero) duży odsetek delta parametrów każdego modelu — typowo 80–90 % z nich — i odpowiednio przeskalowuje pozostałe. Intuicja: większość delta parametrów jest redundantna lub zakłócająca; zachowanie tylko małej części z przeskalowaniem daje porównywalny lub lepszy wynik.

DARE w praktyce łączy się z TIES (DARE+TIES): DARE redukuje szum w każdym modelu źródłowym, zanim TIES zastosuje swoją logikę redukcji interferencji. Ta kombinacja jest w mergekit dostępna jako jedna z predefiniowanych strategii.

Task Arithmetic i inne warianty

mergekit i społeczność badawcza implementują również inne metody:

• Task Arithmetic: sumowanie „wektorów zadań" (delta od modelu bazowego) z ważeniem — prosty fundament, z którego wyrastają TIES i DARE.
• Passthrough: niektóre warstwy pobierane są bezpośrednio z jednego modelu, inne z drugiego — subiektywna, ale niekiedy zaskakująco skuteczna metoda przy modelach z różnie silnymi częściami.

mergekit — narzędzie, które to wszystko spina

Do praktycznego użytku `mergekit` jest de facto standardem. Konfiguruje się przez pliki YAML, co ułatwia reprodukowalność i wersjonowanie przepisów. Przykład minimalnej konfiguracji dla 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 poradzi sobie z większością mergingów na CPU z wystarczającą ilością RAM (dla modeli 7B w BF16 rzędu 30–40 GB RAM, bez VRAM). Sam merging trwa kilka minut.

Stosunkowo nowa funkcja tokensurgeon umożliwia przeszczep wag między różnymi tokenizerami — co otwiera możliwość mergowania modeli z różnych rodzin (np. Qwen i Llama), choć ze znacznie niższą przewidywalnością wyniku i koniecznością gruntownej ewaluacji.

Dla tych, którzy nie chcą ręcznego dostrajania parametrów: istnieje również ewolucyjny merging (Mergenetic i podobne narzędzia), gdzie optymalny przepis wyszukiwany jest automatycznie przez algorytmy ewolucyjne — merging działa dziesiątki iteracji z różnymi kombinacjami parametrów, każda iteracja jest oceniana na małym zestawie benchmarkowym. Ta metoda jest wolniejsza (godziny zamiast minut), ale zmniejsza zależność od eksperckiej intuicji.

Kiedy merging ma sens

W praktyce merging jest uzasadniony w kilku konkretnych sytuacjach:

Łączenie możliwości z kilku fine-tunów. Macie model fine-tunowany na komunikacji z klientami i inny na dokumentacji technicznej. Chcecie jeden model, który radzi sobie z oboma. Zamiast kolejnego treningu na mieszanych danych wypróbujcie merge — jeśli możliwości nie są ze sobą w konflikcie, wynik może być porównywalny.

Przyspieszona eksploracja na wczesnym etapie. Zanim zainwestujecie godziny treningu w każdą kombinację hiperparametrów i mieszanek danych, merging pozwoli wam szybko zbadać przestrzeń możliwości. Kilka mergów z istniejących checkpointów kosztuje mniej niż kilka przebiegów treningowych.

Alternatywa przy braku zasobów treningowych. Jeśli nie macie mocy obliczeniowej GPU na kolejny trening, ale dysponujecie kilkoma częściowo wyspecjalizowanymi modelami, merging jest uzasadnioną alternatywą.

Delikatne dostrajanie stylu. SLERP z wartością t bliższą jednej stronie da wam model, który „trochę bardziej" uwzględnia cechy jednego z fine-tunów — co może być wszystkim, czego potrzebujecie do osiągnięcia pożądanego tonu.

Kiedy merging nie ma sensu

Równie ważne jest wiedzieć, kiedy nie próbować mergingu:

Wyraźnie różne rozkłady treningowe. Im bardziej różnią się rozkłady danych i cele modeli źródłowych, tym większe prawdopodobieństwo interferencji. Merge modelu trenowanego na umowach prawnych z modelem trenowanym na twórczości poetyckiej prawdopodobnie nie ma sensu — oba fine-tuny ciągną wagi w różnych kierunkach.

Różne architektury lub tokenizery (bez tokensurgeon). Merging zakłada identyczną architekturę i ten sam tokenizer — w przeciwnym razie technicznie nie istnieje spójna przestrzeń parametryczna, w której można by interpolować.

Gdy potrzebujecie przewidywalnej poprawy. Merging jest eksperymentalny. Nie zawsze działa. Wynik zawsze należy ocenić na własnych konkretnych benchmarkach — bez ewaluacji nie macie pewności, czy nie pogorszyliście modelu. Jeśli wasz projekt wymaga gwarancji, sięgnijcie po standardowy fine-tuning, którego wynik jest replikowalny i kontrolowalny. Problematyce pomiaru jakości zmian po fine-tuningu poświęcony jest artykuł Jak zmierzyć, czy fine-tuning pomógł.

Środowiska regulowane. W kontekście medycyny, prawa lub finansów merging na modelu produkcyjnym jest bardziej ryzykowny niż fine-tuning — ze względu na słabszą audytowalność. Nie możecie wskazać, na jakich danych był trenowany wynikowy model. W sektorach regulowanych zalecamy merging wyłącznie jako narzędzie do wewnętrznych eksperymentów, nie jako ścieżkę do modelu produkcyjnego.

Ryzyka i ograniczenia

Degradacja na długim ogonie. Merging jest zazwyczaj oceniany na popularnych benchmarkach. W przypadkach brzegowych specyficznych dla waszej domeny wynikowy model może zawodzić w sposób, którego proste benchmarki nie uchwycą.

Rozrzut jakości. Ta sama metoda z różnymi parami modeli daje dramatycznie różne wyniki. Przepis, który zadziałał dla jednej pary fine-tunów, może nie zadziałać dla innej.

Niekontrolowany wynik z perspektywy bezpieczeństwa. Modele po mergingu mogą przejąć nieodpowiednie zachowania z jednego ze źródłowych modeli, jeśli nie był wystarczająco wyrównany (aligned). Ma to szczególne znaczenie przy mergowaniu modeli od różnych trenerów.

Merging SLERP/TIES nie jest „zawsze bezpieczny" — w tym sensie, że wynikowy model może nie zachować wszystkich pożądanych właściwości modeli źródłowych. Wynik zawsze należy ocenić. Jeśli chcecie uniknąć najczęstszych pułapek przy eksperymentowaniu z fine-tuningiem w ogóle, przeczytajcie 7 powodów, dla których fine-tuning zawodzi w praktyce.

Merging vs. fine-tuning: kiedy co

Prosty schemat decyzyjny:

• Macie co najmniej dwa istniejące fine-tuny ze wspólnego modelu bazowego i chcecie zbadać ich kombinację? → Najpierw wypróbujcie merge.
• Potrzebujecie modelu z konkretną wiedzą domenową, której żaden z waszych fine-tunów nie posiada? → Fine-tuning na nowych danych.
• Potrzebujecie gwarancji jakości i audytowalności w środowisku regulowanym? → Fine-tuning z udokumentowanymi danymi.
• Chcecie szybkiej eksploracji przed inwestycją w trening? → Merge to uzasadniona wstępna sonda.
• Pracujecie z architekturą MoE (Llama 4, Qwen3 MoE)? → Merging jest znacznie bardziej skomplikowany, wsparcie narzędzi jest mniej dojrzałe — zweryfikujcie przed inwestycją.

Merging nie jest zamiennikiem fine-tuningu. To uzupełniające narzędzie w toolboxie zaawansowanego inżyniera ML — wartościowe dokładnie tam, gdzie trening byłby niepotrzebnie drogi w przypadku pytań eksploracyjnych. Relacja między fine-tuningiem a mergingiem jest podobna do tej między lokalnymi LLM a chmurą: oba mają swoje miejsce — zależy od kontekstu.

Praktyczny przewodnik dla pierwszej próby

Jeśli chcecie wypróbować merging:

1. 1.Zacznijcie od dwóch fine-tunów ze wspólnego modelu bazowego, gdzie oba mają udokumentowaną jakość na waszych benchmarkach.
2. 2.Zainstalujcie mergekit, napiszcie konfigurację YAML dla SLERP z t=0.5.
3. 3.Uruchomcie merging (działa na CPU, zajmuje dziesiątki GB RAM, bez GPU).
4. 4.Oceńcie wynik na tych samych benchmarkach co modele źródłowe — bez ewaluacji nie wiecie nic.
5. 5.Jeśli wynik jest obiecujący, eksperymentujcie z różnymi wartościami t lub przejdźcie na TIES dla większej liczby modeli.
6. 6.Tylko jeśli ewaluacja potwierdza jakość → stosujcie w produkcji.

Najczęstsze pytania

Czy merging zastępuje fine-tuning?

Nie. Merging zakłada, że macie co najmniej jeden dobrej jakości fine-tun — pracuje na istniejących wynikach treningu, nie zastąpi go. Jeśli żaden fine-tun nie istnieje, merging nie ma na czym pracować.

Ile RAM potrzebuję do mergingu modeli 7B?

Dla modeli 7B w BF16 rzędu 30–40 GB RAM na CPU. Sam VRAM nie jest potrzebny — merging przebiega na CPU w kilka minut. Dla modeli 13B liczcie mniej więcej dwukrotność.

Czym DARE różni się od losowego usuwania wag (pruning)?

Pruning trwale usuwa parametry w celu zmniejszenia modelu. DARE usuwa delta parametry (odchylenia od modelu bazowego) przed mergingiem w celu redukcji szumu interferencyjnego — wynikowy model ma tę samą liczbę parametrów co modele źródłowe. To fundamentalnie różne motywacje.

Czy merging działa dla modeli MoE (Llama 4, Qwen3 MoE)?

Technicznie częściowo — mergekit dodaje wsparcie, jednak architektury MoE są znacznie bardziej skomplikowane: oprócz wag ekspertów trzeba obsługiwać parametry routera. Wyniki są mniej przewidywalne niż w przypadku modeli gęstych (dense), a wsparcie narzędzi jest nadal rozwijane. Zalecamy najpierw sprawdzić aktualny stan dokumentacji mergekit dla konkretnej architektury.

Czy mergingiem można rozwiązać problem katastroficznego zapominania?

Częściowo — jeśli macie checkpoint sprzed zapominania i po fine-tuningu, merge między nimi może złagodzić regresję ogólnych możliwości. To uzasadniona technika, ale nie niezawodny zamiennik dla danych replay ani podejść regularyzacyjnych podczas samego fine-tuningu.

*Jeśli rozważacie pracę z własnymi fine-tunowanymi modelami i nie wiecie, od czego zacząć — czy to wybór metody, przygotowanie danych, czy merging — chętnie przyjrzymy się razem konkretnemu przypadkowi. W MP Industrial Solutions przeszliśmy przez ten proces z wieloma klientami z produkcji i inżynierii i wiemy, gdzie są realne pułapki.*