🤖 machine learning

FusionFactory: Fusing LLM Capabilities with Multi-LLM Log Data

Das Paper stellt FusionFactory vor, ein systematisches Framework und das dazugehörige LLMFusionBench-Benchmark, welches Multi-LLM-Logdaten nutzt, um komplementäre Fähigkeiten auf Abfrage-, Denk- und Modellebene zu fusionieren, wobei es über verschiedene Aufgaben hinweg konsistent einzelne Modelle übertrifft und gleichzeitig reale Serving-Beschränkungen berücksichtigt.

Ursprüngliche Autoren: Tao Feng, Haozhen Zhang, Zijie Lei, Pengrui Han, Mostofa Patwary, Mohammad Shoeybi, Bryan Catanzaro, Jiaxuan You

Veröffentlicht 2026-07-02

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Tao Feng, Haozhen Zhang, Zijie Lei, Pengrui Han, Mostofa Patwary, Mohammad Shoeybi, Bryan Catanzaro, Jiaxuan You

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie besitzen eine riesige Bibliothek mit Gesprächen zwischen Menschen und vielen verschiedenen KI-Assistenten. Einige KIs sind großartig in Mathe, andere sind Zauberer beim Programmieren und manche sind Enzyklopädien für allgemeine Fakten. Normalerweise müssen Sie sich, wenn Sie eine Frage stellen, für nur eine einzige KI entscheiden. Aber was wäre, wenn Sie all diese vergangenen Gespräche betrachten und die besten Teile jeder einzelnen KI zu einem superintelligenten System kombinieren könnten?

Genau darum geht es in dieser Arbeit, FusionFactory. Die Autoren haben ein riesiges Toolkit entwickelt, um herauszufinden, wie man diese verschiedenen KI-Gehirne unter Verwendung ihrer „Log-Daten“ (den Aufzeichnungen dessen, was sie gesagt haben und wie gut sie abgeschnitten haben) am besten mischt und kombiniert.

Hier ist die einfache Aufschlüsselung ihrer Entdeckung:

1. Das Problem: Zu viele Auswahlmöglichkeiten, eine Frage

Stellen Sie sich die Welt der KI wie ein Restaurant mit 20 verschiedenen Köchen vor.

Koch A macht die beste Pizza.
Koch B macht die beste Suppe.
Koch C ist ein Meister in der Dessertküche.

Wenn Sie ein Menü bestellen, müssen Sie sich normalerweise für nur einen Koch entscheiden, der Ihr gesamtes Abendessen zubereitet. Aber die Autoren haben bemerkt, dass Unternehmen in der realen Welt oft alle Köche dasselbe Gericht kochen lassen und aufzeichnen, wer was gemacht hat. Sie fragten sich: „Können wir diese Aufzeichnungen nutzen, um einen ‚Super-Koch‘ zu erschaffen, der gleichzeitig die perfekte Pizza, Suppe und das perfekte Dessert zuberehen kann?“

2. Die Lösung: FusionFactory (Die drei Wege des Mischens)

Die Autoren entwickelten ein Framework namens FusionFactory, das drei verschiedene Wege versucht, diese Köche zu kombinieren, je nachdem, wann man sie mischt.

Ebene 1: Der „Schlaue Kellner“ (Query-Level Fusion / Abfrage-Ebene)

Wie es funktioniert: Noch bevor Sie überhaupt bestellen, schaut ein schlauer Kellner auf Ihre Anfrage. Wenn Sie ein Matheproblem stellen, schickt der Kellner es sofort an den Mathe-Koch. Wenn Sie einen Witz verlangen, schickt er ihn an den Comedy-Koch.
Die Analogie: Es ist wie ein Verkehrspolizist, der Autos auf die schnellste Spur leitet.
Das Ergebnis: Dies ist die günstigste und schnellste Methode. Es verändert die Köche nicht; es wählt nur den richtigen für die Aufgabe aus. Es spart Geld, weil man keine Zeit damit verschwendet, den falschen Koch etwas fragen zu lassen.

Ebene 2: Das „Rezeptbuch“ (Thought-Level Fusion / Gedanken-Ebene)

Wie es funktioniert: Anstatt nur einen Koch auszuwählen, schaut diese Methode auf die besten Rezepte, die die Köche in der Vergangenheit verwendet haben. Wenn 10 Köche ein schwieriges Matheproblem gelöst haben, liest das System deren Schritte, fasst das „perfekte Denkmuster für dieses Problem“ zusammen und gibt diese Zusammenfassung dem Koch, den man gerade benutzt.
Die Analogie: Stellen Sie sich vor, Sie kochen gerade, und bevor Sie anfangen, reicht Ihnen jemand einen Klebezettel mit der Aufschrift: „Hier ist der Geheimtrick, den die besten Köche für genau dieses spezifische Problem genutzt haben.“ Dann kochen Sie Ihr Gericht unter Verwendung dieses Tricks.
Das Ergebnis: Dies war der Gewinner. Es lieferte den größten Leistungsschub. Es ist, als würde man dem Koch ein Spickzettel mit den besten Denkmustern geben, ohne ihn neu trainieren zu müssen.

Ebene 3: Der „Lehrlings-Koch“ (Model-Level Fusion / Modell-Ebene)

Wie es funktioniert: Das ist die Schwerstarbeit. Das System nimmt alle besten Antworten der 20 Köche und zwingt einen spezifischen Koch dazu, sie zu studieren, bis er die Lektionen auswendig kennt. Es ist wie ein langes, teures Trainingslager.
Die Analogie: Sie nehmen einen Junior-Koch und lassen ihn die besten Gerichte aller Meister auswendig lernen, damit er selbst zu einem Meister wird.
Das Ergebnis: Dies war am wenigsten effektiv. Der „Junior-Koch“ (das Modell) wurde verwirrt, als er versuchte, zu viele verschiedene Stile gleichzeitig zu lernen, und performte tatsächlich schlechter, als wenn man einfach nur den richtigen Koch ausgewählt oder ihm einen Spickzettel gegeben hätte.

3. Die große Entdeckung: „Einheitsgröße passt niemandem“

Die Arbeit testete dies bei 14 verschiedenen Aufgabentypen (wie Mathe, Programmieren, Lesen und Trivia) mit 20 verschiedenen KI-Modellen.

Das „Rezeptbuch“ (Gedanken-Ebene) ist der MVP: Für die meisten Aufgaben war es besser, der KI eine Zusammenfassung darüber zu geben, wie sie denken soll (das „Rezeptbuch“), als alles andere. Es war flexibel und leistungsstark.
Der „Schlaue Kellner“ ist der Budget-König: Wenn Sie um die Kosten besorgt sind, ist es ein großartiges Angebot, einfach einen intelligenten Router zu nutzen, der den richtigen KI auswählt. Es ist fast so gut wie die beste einzelne KI, kostet aber nur einen Bruchteil des Preises.
Das „Trainingslager“ (Modell-Ebene) ist knifflig: Zu versuchen, das gesamte Wissen in ein einziges KI-Modell zu verschmelzen, scheiterte oft. Es ist schwer, ein einzelnes Gehirn darauf zu trainieren, in allem gut zu sein, wenn die „Lektionen“ von 20 verschiedenen Persönlichkeiten kommen.

4. Warum das wichtig ist

Die Autoren argumentieren, dass wir keine neuen, komplexen KI-Modelle erfinden müssen, um bessere Ergebnisse zu erzielen. Wir besitzen bereits eine Goldgrube an Daten: die Protokolle dessen, was verschiedene KIs in der Vergangenheit gesagt haben.

Wenn Sie Geld haben, aber Geschwindigkeit brauchen: Nutzen Sie den Schlauen Kellner (Query-Level).
Wenn Sie die absolut besten Antworten wollen: Nutzen Sie das Rezeptbuch (Thought-Level).
Wenn Sie eine einzige, permanente KI bauen wollen: Seien Sie vorsichtig, denn das Trainingslager (Model-Level) ist möglicherweise noch nicht die Mühe wert.

Kurz gesagt, die Arbeit besagt: Wählen Sie nicht nur eine KI aus. Schauen Sie sich die Aufzeichnungen darüber an, wie sie alle denken, und nutzen Sie diese Aufzeichnungen, um Ihre aktuelle KI zu leiten. Es ist, als würde man der KI eine Bibliothek an Weisheit zum Lesen geben, bevor sie antwortet, anstatt zu versuchen, sie zu zwingen, die ganze Bibliothek auswendig zu lernen.

Technisches Resümee: FusionFactory: Verschmelzung von LLM-Kapazitäten mit Multi-LLM-Logdaten

Problemstellung

Die rasche Diversifizierung von Large Language Models (LLMs) hat zu einer Landschaft geführt, in der verschiedene Modelle unterschiedliche Aufgaben exzellent bewältigen (z. B. Codegenerierung vs. faktische Informationsabfrage). Infolgedessen setzen Praktiker zunehmend mehrere LLMs in Workflows ein, wodurch wertvolle Multi-LLM-Logdaten entstehen. Diese Daten bestehen aus strukturierten Serving-Datensätzen, die aus abgestimmten Query-Response-Paaren mehrerer Modelle sowie Metadaten wie Modellidentität, Antwortmodus (direkt vs. reasoning-augmentiert), Inferenzkosten und Qualitätsfeedback bestehen.

Trotz der Verfügbarkeit dieser Daten adressieren bestehende Methoden zur Integration mehrerer LLMs typischerweise nur isoliert eine einzige Stufe der Pipeline:

Query-Ebene: Routing-Methoden wählen das beste Modell für eine spezifische Query aus, führen aber über die Selektion hinaus keine Kapazitätsverschmelzung durch.
Thought-Ebene: Prompting-Strategien aggregieren Schlussfolgerungen (Reasoning), lassen jedoch oft eine systematische Evaluierung gegenüber anderen Fusionsstufen vermissen.
Modell-Ebene: Destillation und Model Merging übertragen Wissen auf ein einzelnes Modell, ignorieren jedoch oft die spezifischen Einschränkungen des API-basierten Servings oder die Nuancen von Logdaten.

Es besteht eine kritische Lücke im Verständnis darüber, wie dieselben strukturierten Multi-LLM-Logdaten über verschiedene Interventionspunkte (Routing, Prompting und Training) hinweg genutzt werden können, um variierende Nutzerbedürfnisse zu erfüllen – insbesondere in Szenarien, in denen Modellgewichte nicht zugänglich sind (API-basiertes Serving).

Methodik

Die Autoren schlagen FusionFactory vor, ein systematisches Framework zur Verschmelzung von LLM-Kapazitäten, unterstützt durch LLMFusionBench, einen groß angelegten Benchmark zur Evaluierung von Fusionsstrategien über drei verschiedene Stufen hinweg.

1. Konstruktion von LLMFusionBench

Um einen stufenübergreifenden Vergleich zu ermöglichen, haben die Autoren einen Benchmark konstruiert, der Folgendes umfasst:

Umfang: 14 Aufgaben in 6 Domänen (Mathematik, Code, Commonsense Reasoning, Weltwissen, Leseverständnis, Popular Knowledge).
Daten: Antworten von 20 Open-Source-LLMs, die von 8B bis 671B Parametern reichen, insgesamt 103M Token.
Struktur: Im Gegensatz zu Standarddatensätzen ist jeder Eintrag ein strukturierter Log-Tupel $(q, t, m, s, r, c, y, j)$ , der die Query, die Aufgabe, die Modellidentität, den Antwortmodus, die generierte Antwort, die Inferenzkosten, die aufgabenspezifische Leistung und einen LLM-Judge-Score erfasst.
Duale Modi: Für jede Query generieren die Modelle sowohl direkte Antworten als auch reasoning-augmentierte (Chain-of-Thought) Antworten, um vielfältige Reasoning-Muster zu erfassen.

2. Das FusionFactory-Framework

FusionFactory operiert auf drei Ebenen, die den frühen, mittleren und späten Fusionsstadien in der LLM-Pipeline entsprechen:

A. Query-Level Fusion (Frühe Fusion)

Ziel: Auswahl des optimalen LLMs und Antwortmodus für eine spezifische Query vor der Generierung.
Mechanismus: Ein Router lernt eine Policy $f_\phi$ , um $(query, task)$ auf eine Aktion $a = (model, mode)$ abzubilden.
Zielsetzung: Maximierung einer Belohnungsfunktion, die Leistung ( $P$ ), Kosten ( $C$ ) und LLM-Judge-Qualität ( $J$ ) ausbalanciert:
$Reward = \alpha \cdot P - \beta \cdot C + \gamma \cdot J$
Implementierung: Evaluierung mittels verschiedener Routing-Algorithmen (KNN, SVM, MLP, BERT, GraphRouter) unter verschiedenen Reward-Gewichtungsszenarien (Performance First, Balance, Cost First, LLM Judge).

B. Thought-Level Fusion (Mittlere Fusion)

Ziel: Verbesserung der Generierung durch Injektion wiederverwendbarer Reasoning-Muster, ohne die Modellgewichte zu verändern.
Mechanismus:
1. Template-Extraktion: Ein LLM-Summarizer destilliert abstrakte „Thought Templates“ aus den Top- $k$ Antworten historischer Queries (gerankt nach Leistung oder Judge-Score).
2. Retrieval: Für eine neue Query werden ähnliche historische Queries via Embedding-Ähnlichkeit abgerufen.
3. Prompting: Die entsprechenden Thought Templates werden als Few-Shot-Demonstrationen verwendet, um das Ziel-LLM zu leiten.
Strategie: Evaluierung mittels Performance-basierter, LLM-Judge-basierter und hybrider Selektionsstrategien für die Top- $k$ Antworten.

C. Model-Level Fusion (Späte Fusion)

Ziel: Konsolidierung komplementärer Fähigkeiten in ein einziges Basismodell mittels Supervised Fine-Tuning (SFT).
Mechanismus: Hochwertige Antworten aus den Multi-LLM-Logs (selektiert durch Leistung oder Judge-Score) dienen als Trainingsdaten für ein Basismodell.
Strategie: Vergleich von Top- $K$ SFT (unter Verwendung selektierter Multi-LLM-Antworten) gegenüber Top- $K$ Label-only SFT (unter Verwendung nur der Ground Truths), um den Nutzen von Multi-LLM-Wissen zu isolieren.

Zentrale Ergebnisse

Die Experimente wurden auf dem vollständigen Testset von LLMFusionBench durchgeführt, wobei die drei Fusionsstufen gegen das beste einzelne LLM und Zero-Shot-Baselines verglichen wurden.

Thought-Level Fusion erzielt die beste Leistung:
- Die Thought-Level Fusion (insbesondere die Hybrid-Strategie mit Full-Scale-Modellen) erreichte die höchste durchschnittliche Leistung (0,615) und übertraf damit das beste einzelne LLM (0,600) sowie andere Fusions-Baselines wie LLM-Blender (0,603) und die angepasste FuseLLM (0,557).
- Die Gewinne waren in reasoning-intensiven Aufgaben (Mathe und Code) am ausgeprägtesten, wo der Retrieval diverser Reasoning-Traces einen signifikanten Wert lieferte.
- Die Leistungssteigerungen waren selbst bei Kontrolle für Near-Duplicate-Retrieval robust, was darauf hindeutet, dass der Nutzen aus wiederverwendbaren Reasoning-Mustern und nicht aus einfachem Daten-Overlap resultiert.
Query-Level Fusion bietet die beste Kosteneffizienz:
- Die Query-Level Fusion (via GraphRouter) bot einen vorteilhaften Trade-off zwischen Leistung und Kosten.
- Unter kostenbewusstem Routing erreichte sie eine Leistung vergleichbar mit dem besten einzelnen LLM, jedoch bei etwa 10-mal geringeren Inferenzkosten (0,0184 vs. 0,1850 in normierten Einheiten).
- Dies bestätigt ihren Nutzen für das API-basierte Serving, bei dem die Minimierung des Token-Verbrauchs entscheidend ist.
Model-Level Fusion zeigt begrenzte Generalisierung:
- Die Model-Level Fusion (SFT) lieferte nur moderate Gewinne und schnitt in einigen Domänen (Code und Weltwissen) schlechter ab als Zero-Shot-Baselines.
- Die Autoren führen dies auf Overfitting auf die spezifischen Antwortstile der geloggten Daten sowie auf die Schwierigkeit zurück, heterogene Aufgabenverhaltensweisen in einen einzigen Parametersatz zu abstrahieren.
- Bemerkenswert ist, dass Multi-LLM SFT die Label-only SFT übertraf, was bestätigt, dass Multi-LLM-Logs wertvolles Wissen jenseits der Ground Truths enthalten, der Konsolidierungsprozess jedoch Generalisierungsprobleme einführt.
Domänenspezifische Variationen:
- Die Fusion brachte nur marginale Verbesserungen in den Domänen Weltwissen und Mathematik, die stark auf strikte faktische Genauigkeit und logische Konsistenz angewiesen sind, was darauf hindeutet, dass diese Bereiche weniger für die aktuellen Fusionsheuristiken geeignet sind.
- Reasoning-lastige Aufgaben (Mathe, Code) profitierten am meisten von der Thought-Level Fusion, während wissensintensive Aufgaben gemischte Ergebnisse zeigten.

Bedeutung und Behauptungen

Das Paper behauptet, dass FusionFactory und LLMFusionBench eine vereinheitlichte, stufenbewusste Perspektive auf die LLM-Fusion bieten, die zuvor gefehlt hat.

Über API-Kompatibilität hinaus: Während frühere Arbeiten sich auf das reine API-basierte Routing konzentrierten, zeigt diese Arbeit, dass dieselben strukturierten Multi-LLM-Logdaten systematisch über Routing-, Prompting- und Trainingsstufen hinweg evaluiert werden können.
Entscheidungsrahmen: Die „Fusionsstufen-Matrix“ verdeutlicht, dass es keine einzelne optimale Fusionsstrategie gibt; die Wahl hängt von den Deployment-Beschränkungen (z. B. Kosten vs. Genauigkeit) und den Aufgabenanforderungen (z. B. Reasoning vs. Recall) ab.
- Nutzen Sie Query-Level für kostenintensive, High-Throughput-Szenarien.
- Nutzen Sie Thought-Level zur Maximierung der Reasoning-Kapazitäten ohne Modell-Retraining.
- Nutzen Sie Model-Level nur, wenn ein einzelnes deploybares Modell zwingend erforderlich ist und Offline-Training machbar ist, wobei die Grenzen der Generalisierung zu beachten sind.
Praktische Grundlage: Die Arbeit validiert Multi-LLM-Logdaten als praktische, skalierbare Supervision-Quelle zur Verschmelzung diverser LLM-Kapazitäten und bietet einen Blueprint für zukünftige Systeme, die in heterogenen, realen Serving-Umgebungen operieren müssen.

Die Autoren kommen zu dem Schluss, dass die Thought-Level Fusion derzeit die stärksten Leistungssteigerungen bietet, der systematische Vergleich durch ihr Framework jedoch essenziell ist, um die Trade-offs zwischen Flexibilität, Kosten und Generalisierung in Multi-LLM-Systemen zu verstehen.