Modell-Merging: SLERP, TIES, DARE — und wann es sich lohnt

Die meisten Diskussionen über die Anpassung von LLMs drehen sich um Fine-tuning: Daten sammeln, Training starten, Stunden oder Tage warten, evaluieren. Es gibt jedoch eine ganze Kategorie von Techniken, die diesen Zyklus vollständig umgeht: Model Merging, also das Zusammenführen der Gewichte mehrerer trainierter Modelle direkt im Parameterraum — ohne eine einzige Trainingsiteration. Kein GPU-Training, kein Gradient Descent. Nur Arithmetik auf Gewichten.

Das klingt nach einer Abkürzung, die nicht funktionieren kann. In der Praxis funktioniert sie überraschend gut — wenn man weiß, wann und wie man sie einsetzt. Dieser Artikel erklärt die drei wichtigsten Methoden (SLERP, TIES, DARE), wo sich Merging von Destillation und Ensembling unterscheidet und was die realistischen Vorteile und Grenzen für Unternehmen sind, die mit Open-Weight-Modellen fortgeschrittener arbeiten wollen.

Was Model Merging ist — und was nicht

Bevor wir zu den Methoden kommen, eine wichtige Abgrenzung:

Model Merging kombiniert die Gewichte von zwei oder mehr Modellen mit gemeinsamer Architektur und Tokenizer direkt im Parameterraum. Das Ergebnis ist ein einziges Modell, dessen Gewichte eine Art Kombination der Quellmodelle darstellen. Es sind keine Trainingsdaten erforderlich, kein GPU während des eigentlichen Mergings (nur RAM zum Laden der Gewichte), kein Gradient.

Destillation ist etwas anderes: Ein größeres Teacher-Modell generiert synthetische Antworten, auf denen ein kleineres Student-Modell trainiert wird. Destillation erfordert Training — Merging nicht. Beide Ansätze können sich ergänzen, sind aber nicht austauschbar. Für einen eigenen Artikel zur Destillation lesen Sie Modelldestillation.

Ensemble ist ebenfalls ein anderer Ansatz: Mehrere Modelle laufen zur Inferenzzeit parallel, ihre Ausgaben werden durch Abstimmung oder Mittelwertbildung aggregiert. Ensembles sind inferenzteurer (Sie betreiben mehrere Modelle), Merging produziert ein einziges Modell mit normaler Inferenzlast.

Merging steht damit in einer völlig eigenen Kategorie: Es kombiniert Fähigkeiten ohne Trainingskosten — auf Kosten der Vorhersagbarkeit des Ergebnisses.

Warum Merging überhaupt funktioniert

Die Intuition hinter Merging basiert auf der Beobachtung, dass Modelle mit gleicher Architektur, die ausgehend vom selben (oder ähnlichen) Base-Modell trainiert wurden, Gewichte in einem ähnlichen Raum haben. Fine-tuning auf Domäne A verschiebt die Gewichte in eine bestimmte Richtung; Fine-tuning auf Domäne B in eine andere. Eine lineare Kombination dieser Verschiebungen erfasst im Prinzip beide Fähigkeiten — sofern sie sich nicht gegenseitig aufheben.

Dieses „sofern" ist der Kern des Problems, dem fortgeschrittenere Methoden wie TIES und DARE begegnen.

Die drei wichtigsten Methoden

SLERP — sphärische Interpolation

SLERP (Spherical Linear Interpolation) ist die einfachste und älteste Methode. Ursprünglich für die Interpolation von Rotationen in der 3D-Grafik entwickelt, wird sie im Modellkontext auf Parametervektoren angewendet.

Statt linearer Mittelwertbildung ((Gewichte_A + Gewichte_B) / 2) interpoliert SLERP entlang des geodätischen Bogens auf der hypersphärischen Oberfläche des Parameterraums. Das Ergebnis bewahrt Unterschiede in den Gewichtsrichtungen besser als der direkte lineare Durchschnitt.

In der Praxis: - Funktioniert ausschließlich mit zwei Modellen — nicht mit drei oder mehr. - Ein einziger Parameter t (0.0 = reines Modell A, 1.0 = reines Modell B, 0.5 = Mitte) steuert die „Nähe" des Ergebnisses. - Das Ergebnis ist empfindlich gegenüber der Wahl von t — der optimale Wert variiert je nach Modellpaar. - Geeignet für die feingradige „Weichzeichnung" des Unterschieds zwischen zwei Fine-tunes (z. B. ein Modell ist stilistisch stärker, das andere faktisch genauer).

TIES — Interferenzbehandlung

TIES (Trim, Elect Sign, Disjoint Merge) löst ein Problem, das SLERP ignoriert: Wenn man mehrere Fine-tunes naiv kombiniert, können ihre Änderungen im Parameterraum einander widersprechen — einige Parameter werden bei Modell A positiv verschoben und bei Modell B negativ, heben sich beim Mitteln auf, und die Gesamtfähigkeit geht verloren.

TIES löst das in drei Schritten:

1. 1.Trim — Abschneiden kleiner Änderungen: Es werden nur die größten Delta-Parameter (Abweichungen vom Base-Modell) beibehalten. Kleine Änderungen sind meist Rauschen.
2. 2.Elect Sign — Richtungswahl: Für jeden Parameter wird per Abstimmung die dominante Änderungsrichtung über alle Modelle hinweg ermittelt. Modelle, die in die Minderheitsrichtung votieren, werden bei diesem Parameter ignoriert.
3. 3.Disjoint Merge — Zusammenführung: Jeder Parameter wird nur von den Modellen beigesteuert, die die vorherigen Schritte überstanden haben.

TIES funktioniert mit drei und mehr Modellen, was es für den Aufbau von „Polyglot"-Modellen aus mehreren domänenspezifischen Fine-tunes geeignet macht — auf Kosten höherer Konfigurationskomplexität.

DARE — Redundanzreduktion

DARE (Drop And REscale) geht das Problem anders an: Vor dem Zusammenführen wird ein großer Anteil der Delta-Parameter jedes Modells zufällig „fallengelassen" (auf null gesetzt) — typischerweise 80–90 % — und die verbleibenden werden entsprechend neu skaliert. Die Intuition: Der Großteil der Delta-Parameter ist redundant oder störend; das Behalten nur eines kleinen Anteils mit Rescaling liefert ein vergleichbares oder besseres Ergebnis.

DARE wird in der Praxis mit TIES kombiniert (DARE+TIES): DARE reduziert das Rauschen in jedem Quellmodell, bevor TIES seine Interferenz-Reduktionslogik anwendet. Diese Kombination ist in mergekit als eine der vordefinierten Strategien verfügbar.

Task Arithmetic und weitere Varianten

mergekit und die Forschungsgemeinschaft implementieren auch weitere Methoden:

• Task Arithmetic: Addition von „Task-Vektoren" (Delta vom Base-Modell) mit Gewichtung — einfache Grundlage, auf der TIES und DARE aufbauen.
• Passthrough: Einige Schichten werden direkt von einem Modell übernommen, andere vom zweiten — eine unorthodoxe, aber manchmal überraschend effektive Methode bei Modellen mit unterschiedlich starken Bereichen.

mergekit — das Werkzeug, das alles zusammenbringt

Für den praktischen Einsatz ist `mergekit` der De-facto-Standard. Die Konfiguration erfolgt über YAML-Dateien, was Reproduzierbarkeit und Versionierung von Rezepten vereinfacht. Beispiel einer minimalen Konfiguration für 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 bewältigt die meisten Merges auf der CPU mit ausreichend RAM (für 7B-Modelle in BF16 ca. 30–40 GB RAM, kein VRAM erforderlich). Der eigentliche Merge läuft in Minuten ab.

Die relativ neue Funktion tokensurgeon ermöglicht Cross-Tokenizer-Gewichtstransplantation — was das Mergen von Modellen unterschiedlicher Familien öffnet (z. B. Qwen und Llama), allerdings mit deutlich geringerer Ergebnisvorhersagbarkeit und dem Bedarf an gründlicher Evaluation.

Für alle, die auf manuelles Parameter-Tuning verzichten wollen: Es gibt auch evolutionäres Merging (Mergenetic und ähnliche Tools), bei dem das optimale Rezept automatisch über evolutionäre Algorithmen gesucht wird — Merging läuft dutzende Iterationen mit verschiedenen Parameterkombinationen, jede Iteration wird auf einem kleinen Benchmark-Set evaluiert. Diese Methode ist langsamer (Stunden statt Minuten), reduziert aber die Abhängigkeit von Experten-Intuition.

Wann Merging sinnvoll ist

In der Praxis hat Merging in einigen konkreten Situationen seine Berechtigung:

Kombination von Fähigkeiten aus mehreren Fine-tunes. Sie haben ein Modell, das auf Kundenkommunikation fine-getuned wurde, und ein anderes auf technischer Dokumentation. Sie wollen ein einziges Modell, das beides beherrscht. Statt eines erneuten Trainings auf gemischten Daten probieren Sie Merging — wenn die Fähigkeiten nicht in Konflikt stehen, kann das Ergebnis vergleichbar sein.

Beschleunigte Exploration in frühen Phasen. Bevor Sie Stunden Training in jede Kombination von Hyperparametern und Datenmixes investieren, ermöglicht Merging eine schnelle Erkundung des Möglichkeitsraums. Einige Merges aus bestehenden Checkpoints kosten weniger als mehrere Trainingsläufe.

Backup bei fehlenden Trainingsressourcen. Wenn Sie keine GPU-Kapazität für weiteres Training haben, aber mehrere teilweise spezialisierte Modelle vorliegen, ist Merging eine legitime Alternative.

Feinjustierung des Stils. SLERP mit einem t-Wert näher an einer Seite liefert ein Modell, das die Eigenschaften eines der Fine-tunes „etwas stärker" berücksichtigt — was manchmal alles ist, was Sie brauchen, um den gewünschten Ton zu erreichen.

Wann Merging keinen Sinn ergibt

Genauso wichtig ist es zu wissen, wann man Merging nicht versuchen sollte:

Stark unterschiedliche Trainingsverteilungen. Je mehr sich die Datenverteilungen und Ziele der Quellmodelle unterscheiden, desto größer ist die Wahrscheinlichkeit von Interferenz. Ein Merge eines auf Rechtsverträgen trainierten Modells mit einem auf Lyrik trainierten wird wahrscheinlich keinen Sinn ergeben — beide Fine-tunes ziehen die Gewichte in verschiedene Richtungen.

Unterschiedliche Architekturen oder Tokenizer (ohne tokensurgeon). Merging setzt identische Architektur und denselben Tokenizer voraus — andernfalls gibt es technisch keinen konsistenten Parameterraum, in dem interpoliert werden könnte.

Wenn Sie vorhersagbare Verbesserungen benötigen. Merging ist experimentell. Es funktioniert nicht immer. Das Ergebnis muss stets auf Ihren konkreten Benchmarks evaluiert werden — ohne Evaluation wissen Sie nicht, ob Sie das Modell nicht verschlechtert haben. Wenn Ihr Projekt Garantien erfordert, greifen Sie auf Standard-Fine-tuning zurück, dessen Ergebnis reproduzierbar und kontrollierbar ist. Die Messung der Qualität von Fine-tuning-Änderungen behandelt der Artikel Wie Sie messen, ob Fine-tuning wirklich geholfen hat.

Regulierte Umgebungen. Im Kontext von Medizin, Recht oder Finanzen ist Merging auf einem Produktionsmodell riskanter als Fine-tuning — wegen der geringeren Auditierbarkeit. Sie können nicht nachweisen, auf welchen Daten das resultierende Modell trainiert wurde. Für regulierte Sektoren empfehlen wir Merging ausschließlich als Werkzeug für interne Experimente, nicht als Weg zu einem Produktionsmodell.

Risiken und Grenzen

Degradation im langen Schwanz. Merging wird typischerweise auf populären Benchmarks bewertet. Bei Edge Cases, die spezifisch für Ihre Domäne sind, kann das resultierende Modell auf eine Weise versagen, die einfache Benchmarks nicht erfassen.

Qualitätsstreuung. Dieselbe Methode mit unterschiedlichen Modellpaaren liefert dramatisch verschiedene Ergebnisse. Ein Rezept, das für ein Fine-tune-Paar funktioniert hat, muss für ein anderes nicht funktionieren.

Unkontrolliertes Ergebnis aus Sicherheitsperspektive. Merged Modelle können unerwünschtes Verhalten von einem der Quellmodelle übernehmen, wenn dieses nicht ausreichend aligned war. Das ist besonders wichtig beim Merging von Modellen verschiedener Trainer.

SLERP/TIES-Merging ist nicht „immer sicher" — in dem Sinne, dass das resultierende Modell nicht alle gewünschten Eigenschaften der Quellen behalten muss. Das Ergebnis muss stets evaluiert werden. Wenn Sie die häufigsten Fallstricke beim Experimentieren mit Fine-tuning allgemein vermeiden wollen, lesen Sie 7 Gründe, warum Fine-Tuning in der Praxis scheitert.

Merging vs. Fine-tuning: wann was

Ein einfacher Entscheidungsrahmen:

• Sie haben mindestens zwei bestehende Fine-tunes vom selben Base-Modell und wollen die Kombination erkunden? → Probieren Sie Merging zuerst.
• Sie brauchen ein Modell mit konkretem Domänenwissen, das keines Ihrer Fine-tunes hat? → Fine-tuning auf neuen Daten.
• Sie brauchen Qualitätsgarantie und Auditierbarkeit in einer regulierten Umgebung? → Fine-tuning mit dokumentierten Daten.
• Sie wollen schnell erkunden, bevor Sie in Training investieren? → Merging ist eine legitime erste Sonde.
• Sie arbeiten mit einer MoE-Architektur (Llama 4, Qwen3 MoE)? → Merging ist deutlich komplizierter, die Tool-Unterstützung weniger ausgereift — prüfen Sie vor der Investition.

Merging ist kein Ersatz für Fine-tuning. Es ist ein ergänzendes Werkzeug im Toolbox eines fortgeschrittenen ML-Ingenieurs — wertvoll genau dort, wo Training für explorative Fragen unnötig teuer wäre. Die Beziehung zwischen Fine-tuning und Merging ähnelt der zwischen lokalen LLM und Cloud: Beides hat seinen Platz, es kommt auf den Kontext an.

Praktisches Vorgehen für den ersten Versuch

Wenn Sie Merging ausprobieren wollen:

1. 1.Beginnen Sie mit zwei Fine-tunes vom selben Base-Modell, bei denen beide eine dokumentierte Qualität auf Ihren Benchmarks haben.
2. 2.Installieren Sie mergekit, schreiben Sie eine YAML-Konfiguration für SLERP mit t=0.5.
3. 3.Führen Sie den Merge aus (läuft auf der CPU, benötigt dutzende GB RAM, kein GPU).
4. 4.Evaluieren Sie das Ergebnis auf denselben Benchmarks wie die Quellmodelle — ohne Evaluation wissen Sie nichts.
5. 5.Wenn das Ergebnis vielversprechend ist, experimentieren Sie mit verschiedenen t-Werten oder wechseln Sie für mehr Modelle zu TIES.
6. 6.Nur wenn die Evaluation die Qualität bestätigt → in Produktion einsetzen.

Häufige Fragen

Ist Merging ein Ersatz für Fine-tuning?

Nein. Merging setzt voraus, dass Sie mindestens ein qualitativ gut trainiertes Fine-tune haben — es arbeitet auf bestehenden Trainingsergebnissen auf, ersetzt sie nicht. Wenn kein Fine-tune existiert, hat Merging nichts, womit es arbeiten könnte.

Wie viel RAM brauche ich für den Merge von 7B-Modellen?

Für 7B-Modelle in BF16 rund 30–40 GB RAM auf der CPU. VRAM ist nicht erforderlich — der Merge läuft auf der CPU in wenigen Minuten durch. Für 13B-Modelle rechnen Sie mit etwa dem Doppelten.

Was unterscheidet DARE von zufälliger Gewichtsentfernung (Pruning)?

Pruning entfernt dauerhaft Parameter mit dem Ziel, das Modell zu verkleinern. DARE entfernt Delta-Parameter (Abweichungen vom Base-Modell) vor dem Merging mit dem Ziel, Interferenzrauschen zu reduzieren — das resultierende Modell hat dieselbe Parameteranzahl wie die Quellmodelle. Es handelt sich um grundlegend unterschiedliche Motivationen.

Funktioniert Merging für MoE-Modelle (Llama 4, Qwen3 MoE)?

Technisch teilweise — mergekit ergänzt die Unterstützung, aber MoE-Architekturen sind deutlich komplizierter: Neben den Expertengewichten müssen auch die Router-Parameter behandelt werden. Die Ergebnisse sind unvorhersehbarer als bei Dense-Modellen, und die Tool-Unterstützung entwickelt sich noch. Wir empfehlen, zunächst den aktuellen Stand der mergekit-Dokumentation für die konkrete Architektur zu prüfen.

Kann ich mit Merging das Problem des katastrophischen Vergessens lösen?

Teilweise — wenn Sie einen Checkpoint vor dem Vergessen und nach dem Fine-tuning haben, kann ein Merge zwischen beiden die Regression allgemeiner Fähigkeiten abmildern. Das ist eine legitime Technik, aber kein zuverlässiger Ersatz für replay-Daten oder Regularisierungsansätze beim Fine-tuning selbst.

*Wenn Sie erwägen, mit eigenen fine-getunten Modellen zu arbeiten, und nicht wissen, wo Sie anfangen sollen — ob bei der Methodenwahl, der Datenvorbereitung oder dem Merging — schauen wir uns gerne Ihren konkreten Fall gemeinsam an. In MP Industrial Solutions haben wir diesen Prozess mit mehreren Kunden aus Produktion und Maschinenbau durchlaufen und wissen, wo die realen Fallstricke liegen.*