🤖 AI

Brick: Spatial Capability Routing for the Mixture-of-Models (MoM) Paradigm

Brick ist ein multimodaler Router für das Mixture-of-Models-Paradigma, der Abfragen basierend auf sechs Fähigkeitsdimensionen und geschätzter Schwierigkeit dynamisch an Modelle weiterleitet und dabei eine überlegene Genauigkeit sowie signifikante Kosten- und Latenzreduzierungen im Vergleich zu Single-Model-Baselines und bestehenden Routern erreicht.

Ursprüngliche Autoren: Francesco Massa, Marco Cristofanilli

Veröffentlicht 2026-06-12

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Francesco Massa, Marco Cristofanilli

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 führen ein riesiges, exklusives Restaurant. Sie haben drei verschiedene Köche in Ihrer Belegschaft:

Chef Qwen: Ein talentierter, schneller und sehr günstiger lokaler Koch.
Chef DeepSeek: Ein hochqualifizierter Spezialist zum Mittelpreis.
Chef Kimi: Ein weltberühmter, teurer Star-Koch, der ein Vermögen verlangt, aber bei fast allem unglaublich gut ist.

Das Problem:
Jeden Tag kommen tausende Kunden mit unterschiedlichen Wünschen herein. Einige bestellen ein einfaches Käsebrot (einfache Aufgaben). Andere bestellen ein komplexes, 10-gängiges Molekularküche-Menü (schwierige Aufgaben).
In der Vergangenheit nutzten Restaurantmanager „oberflächliches Routing“, um zu entscheiden, wer was kocht. Sie schauten auf die Länge der Bestellung oder auf Schlüsselwörter.

Der Fehler: Eine kurze Bestellung wie „Beweise die Riemannsche Vermutung“ ist eigentlich unglaublich schwer und benötigt den Star-Koch. Eine lange, ausschweifende Bestellung über „wie man Toast macht“ ist eigentlich einfach und könnte vom lokalen Koch erledigt werden. Wenn Sie jede lange oder komplex klingende Bestellung an den teuren Star-Koch schicken, nur weil sie so aussieht als sei sie schwierig, gehen Sie bankrott. Wenn Sie alles dem günstigen Koch schicken, bekommen Sie viel verbrannten Toast und wütende Kunden.

Die Lösung: „Brick“
Das Paper stellt Brick vor, einen smarten „Oberkellner“ (einen Router), der nicht nur auf die Länge der Bestellung schaut. Stattdessen analysiert er die spezifischen Fähigkeiten, die die Bestellung erfordert.

Brick unterteilt jede Anfrage in sechs spezifische „Geschmacksrichtungen“ des Schwierigkeitsgrades:

Programmierung (Coding)
Kreatives Schreiben
Befolgen von Anweisungen
Mathematisches Denken
Planung/Strategie
Allgemeines Weltwissen

Wie Brick funktioniert (Die Analogie):

Die Bestellung kosten: Wenn eine Bestellung eingeht, liest Brick sie und fragt: „Wie viel davon ist Mathematik? Wie viel ist kreatives Schreiben?“ Er erstellt ein „Geschmacksprofil“ für die Anfrage.
Die Fähigkeiten der Köche prüfen: Brick besitzt eine geheime Bewertungsliste (eine „Skill-Matrix“) für jeden Koch. Er weiß zum Beispiel, dass Chef Kimi fantastisch in Mathematik ist, aber manchmal weigert, Fragen zu obskurer Geschichte zu beantworten (indem er lieber „Ich weiß es nicht“ sagt, statt zu raten). Er weiß auch, dass Chef DeepSeek überraschend gut in Geschichte ist, sogar besser als der Star-Koch in manchen Fällen.
Der „Qualität vs. Kosten“-Regler: Brick hat einen speziellen Drehknopf, den der Restaurantbesitzer drehen kann.
- Auf „Maximale Qualität“ gestellt: Brick ignoriert den Preis und schickt die Bestellung an den Koch, der am wahrscheinlichsten alles perfekt erledigt, selbst wenn dieser teuer ist.
- Auf „Maximale Ersparnis“ gestellt: Brick versucht, den günstigsten Koch möglich einzusetzen, selbst wenn ein winziges Risiko für einen Fehler besteht.
- Auf „Neutral“ gestellt: Brick findet den Mittelweg und setzt für die meisten Dinge den mittelpreislichen Koch ein und ruft den Star-Koch nur dann, wenn es absolut notwendig ist.

Die Ergebnisse:
Das Paper testete dieses System mit 5.504 verschiedenen „Bestellungen“ (Anfragen). Hier ist, was sie herausfanden:

Den besten Einzelkoch schlagen: Selbst wenn Brick auf „Maximale Qualität“ eingestellt war, erledigte er mehr Bestellungen korrekt, als wenn man alles an den Star-Koch (Kimi) geschickt hätte. Warum? Weil der Star-Koch manchmal Fragen verweigert, die die günstigeren Köche tatsächlich lösen können. Brick weiß, wann er den „Ich weiß es nicht“-Einstellung des Star-Kochs umgehen muss.
Geld sparen: Bei der Einstellung „Neutral“ sparte Brick dem Restaurant etwa das 4,7-fache Geld im Vergleich dazu, immer den Star-Koch zu nutzen, während er nur minimal an Genauigkeit verlor (weniger als 1 %).
Geschwindigkeit: Da Brick oft einfache oder mittlere Aufgaben an die schnelleren, günstigeren Köfe schickte, bekamen die Kunden ihr Essen im Durchschnitt fast doppelt so schnell im Vergleich zum Warten auf den Star-Koch.
Die Konkurrenz schlagen: Andere Systeme versuchten, die Schwierigkeit anhand von Wortanzahl oder Domainnamen zu erraten. Sie scheiterten. Brick übertraf alle anderen getesteten Routing-Methoden, indem er die tatsächlichen benötigten Fähigkeiten betrachtete.

Die „Oracle“-Obergrenze:
Die Forscher berechneten auch das „Perfekte-Welt-Szenario“ (genannt „Oracle“). Wenn ein magischer Kellner jede einzelne Bestellung sehen und sofort wissen könnte, welcher der drei Köche sie genau lösen würde, könnten sie 83,25 % der Bestellungen korrekt bearbeiten.
Brick erreichte 76,98 %. Das bedeutet, Brick hat den Großteil der möglichen Einsparungen und Qualitätsverbesserungen erfasst, aber es gibt noch eine kleine Lücke (etwa 6 %) an „Spielraum“, den das System noch nicht voll ausgeschöpft hat.

Warum das für „Agents“ (Roboter) wichtig ist:
Das Paper stellt fest, dass dies entscheidend für KI-„Agents“ (Software, die eine Serie von Aufgaben erledigt) ist. Wenn ein Agent 10 Schritte braucht, um ein Problem zu lösen, und dabei ein „träges“ Routing-System nutzt, das zuerst den günstigsten Koch prüft, dann den nächstgünstigeren, dann den teuersten (ein „Kaskaden-Modell“), verschwendet er bei jedem einzelnen Schritt Zeit und Geld. Brick ist ein „One-Shot“-Entscheider: Er wählt sofort den richtigen Koch aus. Das hält den Roboter schnell und die Rechnung niedrig.

Zusammenfassend:
Brick ist ein intelligenter Disponent, der verhindert, dass wir blind für jeden Job das teuerste KI-Modell bezahlen. Er analysiert, was eine Aufgabe tatsächlich benötigt, gleicht dies mit den spezifischen Stärken verschiedener Modelle ab und lässt uns die Balance zwischen Geld sparen und der bestmöglichen Antwort steuern.

Technisches Resümee: Brick – Räumliche Kapazitätssteuerung für das Mixture-of-Models (MoM)-Paradigma

1. Problemstellung

Das Paper adressiert die Herausforderung, Abfragen effizient über einen heterogenen Pool von Large Language Models (LLMs) während der Inferenz zu routen. Die zentrale Schwierigkeit liegt in der empirischen Definition von „Schwierigkeit“: Die Komplexität einer Abfrage wird nicht durch Oberflächenmerkmale wie die Token-Anzahl oder Domänen-Labels bestimmt, sondern durch die spezifischen Kapazitätsanforderungen der Aufgabe im Verhältnis zu den Stärken und Schwächen eines Modells.

Bestehende Routing-Strategien verlassen sich auf oberflächliches Routing (domänenbasiert oder basierend auf Länge/Keywords), welches versagt, die Varianz innerhalb einer Domäne zu erfassen. Beispielsweise kann eine kurze Abfrage ein ungelöstes Problem anvisieren, das ein Frontier-Modell erfordert, während ein langer Boilerplate-Prompt eine triviale Aufgabe umschließen kann, die auch ein kleines Open-Weight-Modell bewältigen könnte. Dies führt zu zwei Ineffizienzen:

Kosteneffizienz: Das Versenden einfacher Abfragen an teure Frontier-Modelle (z. B. Kimi 2.6) verschwendet Budget, da lokale Open-Weight-Modelle (z. B. Qwen 3.5-9B) oft ausreichen.
Latenz- und Genauigkeits-Trade-offs: Cascade-Routing (das Testen von Modellen vom günstigsten zum teuersten) verursacht signifikante Overheads in agentischen Workflows, bei denen eine einzige Nutzeranfrage mehrere LLM-Aufrufe auslöst, was die Kosten für abgebrochene „billige“ Versuche kumuliert.

Das Ziel ist es, jede Abfrage an das günstigste Modell zu leiten, das sie korrekt beantwortet, um Kosten, Latenz und Genauigkeit ohne Rückgriff auf Oberflächenheuristiken auszubalancieren.

2. Methodik: Der Brick-Router

Die Autoren schlagen Brick vor, einen multimodalen Router, der innerhalb des Mixture-of-Models (MoM)-Paradigmas operiert. Im Gegensatz zu Mixture of Experts (MoE), das Sub-Netzwerke innerhalb eines einzelnen Modells aktiviert, leitet MoM ganze Abfragen an verschiedene, unabhängige vortrainierte Modelle weiter.

2.1 Das MoM-Paradigma

Brick nutzt einen Pool aus drei heterogenen Modellen:

Qwen3.5-9B: Ein State-of-the-Art Open-Weight-Modell (<10B Parameter).
DeepSeek-V4-Flash: Ein State-of-the-Art Open-Weight-Modell (<500B Parameter).
Kimi2.6: Ein Frontier Open-Source-Konkurrent.

Der Pool deckt unterschiedliche Preispunkte ab (von ca. ~$0,001 bis ~$0,03 pro Aufruf) sowie unterschiedliche Kapazitätsprofile, was es dem Router ermöglicht, Kapazitäts-Komplementarität auszunutzen (z. B. kann ein Modell eine Abfrage lösen, die ein anderes ablehnt).

2.2 Der sechsdimensionale Kapazitätsraum

Brick rahmt das Routing als geometrische Entscheidung in einem sechsdimensionalen Kapazitätsraum ein. Die Dimensionen sind:

Coding
Creative Synthesis
Instruction Following
Math Reasoning
Planning/Agentic
World Knowledge

Die Pipeline:

Kapazitätsschätzung: Ein feingetunter ModernBERT-Klassifikator bildet die Abfrage auf einen Wahrscheinlichkeitsvektor $p(x)$ über die sechs Dimensionen ab.
Komplexitätsschätzung: Ein separater Klassifikator schätzt einen Schwierigkeitsgrad $\tau_q$ (gemischt aus „easy/medium/hard“-Ankern).
Skill-Matrix-Kalibrierung: Eine offline-kalibrierte Skill-Matrix $S$ speichert die empirischen Erfolgsraten ( $s_{m,c}$ ) jedes Modells $m$ für jede Kapazität $c$ , abgeleitet aus einem gelabelten Datensatz.
Geometrisches Routing-Verfahren:
- Anforderung: Der Anforderungsvektor $r_{q,c}$ der Abfrage wird aus $p(x)$ und dem Schwierigkeits-Logit $z_q$ abgeleitet.
- Kapazität: Der Kapazitätsvektor $v_{m,c}$ des Modells wird aus $p(x)$ und dem Modell-Skill-Logit $\text{logit}(s_{m,c})$ abgeleitet.
- Residuen: Der Router berechnet asymmetrische Residuen: Unterkapazität ( $u$ , Modell zu schwach) und Überkapazität ( $o$ , Modell zu leistungsstark).
- Scoring: Ein Gesamtwert $J_m$ wird als gewichteter euklidischer Abstand der Residuen plus einer Kostenstrafe berechnet:
  $J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$
  Wobei $a_m$ die normalisierten Kosten sind, $\lambda$ die Überkapazität bestraft und $\beta$ den Trade-off zwischen Kosten und Qualität steuert.
Entscheidung: Das Modell mit dem minimalen $J_m$ wird ausgewählt.

2.3 Der Präferenzregler ( $r$ )

Brick führt einen kontinuierlichen Präferenzregler $r \in [-1, 1]$ ein, der es Betreibern ermöglicht, zwischen einem „Max-Quality“- und einem „Max-Saving“-Profil zu wechseln. Dieser Regler moduliert die vier Routing-Skalare ( $\mu, b, \beta, \lambda$ ) über ein kalibriertes Potenzgesetz, wodurch der Trade-off zwischen Kosten und Qualität zu einem Parameter zur Laufzeit wird, statt zu einer Codeänderung.

3. Zentrale Beiträge

MoM-Formulierung: Das Paper rahmt das Routing ganzer Modelle über heterogene Pools als MoM-Paradigma ein und zeigt, dass dies 24 % des erreichbaren Spielraums zwischen dem besten Einzelmodell und einem theoretischen Drei-Modell-Oracle zurückgewinnt.
Ablehnung von oberflächlichem Routing: Es zeigt empirisch, dass domänenbasierte sowie Längen-/Keyword-basierte Routings die Varianz der Schwierigkeit innerhalb einer Domäne nicht erfassen können und sogar einem einfachen „Always-Kimi“-Baseline-Ansatz unterlegen sind.
Brick-Router: Ein kalibrierter MoM-Router mit einer expliziten Kapazitätsvektor-Repräsentation und einem nutzerseitigen Präferenzregler.
Agentische Effizienz: Das Paper argumentiert, dass reines Single-Step-Routing (wie Brick) strukturell einem Cascade-Routing überlegen ist, da es die Kosten der abgelehnten Cascade-Stufen bei jedem Schritt eines Agenten-Trajektorien-Prozesses vermeidet.

4. Experimentelle Ergebnisse

Evaluierung auf Datensatz A (5.504 Abfragen über sechs Kapazitätsdimensionen):

Genauigkeit vs. Kosten:
- Max-Quality Profil ( $r=+1$ ): Brick erreicht 76,98 % Genauigkeit, übertrifft damit das beste Einzelmodell (Kimi 2.6 mit 75,02 %) und alle externen Router (RouteLLM, FrugalGPT, Cascade Routing). Dies geschieht bei 28 % geringeren Kosten ($0,022 vs. $0,031 pro Aufruf).
- Neutrales Profil ( $r=0$ ): Erreicht 74,11 % Genauigkeit bei einem 4,71-mal niedrigeren Kostenfaktor im Vergleich zu Always-Kimi, mit nur 0,91 Prozentpunkten Genauigkeitsverlust. Es übertrifft Cascade-Routing um +0,71 pp bei vergleichbaren Kosten.
- Low-Profil ( $r=-0,5$ ): Erreicht 71,62 % Genauigkeit und schlägt FrugalGPT (69,42 %) um +2,20 pp bei vergleichbaren Kosten.
- Min-Cost Profil ( $r=-1$ ): Erreicht die Genauigkeit des günstigsten Modells (Qwen) mit 63,17 %, aber bei 22,15-mal geringeren Kosten als Always-Kimi.
Latenz:
- Die mediane End-to-End-Latenz für Brick (Max-Profil) sinkt von 51,2 s (Always-Kimi) auf 22,8 s. Dies liegt daran, dass Brick selbst im Max-Quality-Setting ~31 % der Abfragen an das schnellere DeepSeek-V4-Flash routet.
Oracle-Grenze:
- Das theoretische Maximum (Drei-Modell-Oracle) liegt bei 83,25 %. Brick deckt einen signifikanten Teil der Lücke zwischen dem besten Einzelmodell und diesem Oracle ab, wobei ein Rest von 6,27 pp durch die aktuellen Kapazitätsmerkmale noch ungenutzt bleibt.

5. Bedeutung und Behauptungen

Das Paper behaupten, dass Brick die Lebensfähigkeit des MoM-Paradigmas als erstklassiges Deployment-Muster demonstriert. Die Bedeutung liegt in:

Empirischer Validierung: Der Beweis, dass das Routing basierend auf einem kalibrierten Kapazitätsraum oberflächliches Routing und Einzelmodell-Baselines übertrifft.
Operative Flexibilität: Bereitstellung eines kontinuierlichen Reglers für Betreiber, um den Trade-off zwischen Kosten und Qualität zu steuern, ohne das Modell neu trainieren oder den Code ändern zu müssen.
Agentische Skalierbarkeit: Die Feststellung, dass reines Routing das einzige Design ist, das effizient zu agentischen Workloads skaliert, da es die linearen Kosten- und Latenzstrafen vermeidet, die inhärent bei Cascade-Routing sind.
Komplementarität: Hervorhebung, dass Modell-Pools komplementäre Fehler-Sets bieten (z. B. Umgang mit „ehrlichen Verweigerungen“ vs. Halluzinationen), die ein kapazitätsbewusster Router nutzen kann, um die allgemeine Systemzuverlässigkeit zu verbessern.

Die Autoren bleiben bescheiden und räumen ein, dass die verbleibende Lücke zum Oracle (6,27 pp) Informationen darstellt, die der aktuelle Router noch nicht extrahiert; zukünftige Arbeiten sollten sich auf Bayesianisches Smoothing für spärliche Pools und domänenbedingte Komplexitätsschätzung konzentrieren.