Technische Samenvatting: Brick - Ruimtelijke Capaciteitsroutering voor het Mixture-of-Models (MoM) Paradigma

1. Probleemstelling

Het artikel behandelt de uitdaging om queries efficiënt te routeren over een heterogene pool van Large Language Models (LLM's) tijdens de inferentie. De kern van de moeilijkheid ligt in het empirisch definiëren van "moeilijkheidsgraad": de complexiteit van een query wordt niet bepaald door oppervlakkige kenmerken zoals het aantal tokens of domeinlabels, maar door de specifieke capaciteitsvereisten van de taak in relatie tot de sterktes en zwaktes van een model.

Bestaande routeringsstrategieën vertrouwen op oppervlakkige routering (domein-gebaseerd of op basis van lengte/trefwoorden), wat faalt in het vastleggen van intra-domein variantie. Een korte query kan bijvoorbeeld een onopgelost probleem targeten dat een frontier-model vereist, terwijl een lange boilerplate prompt een triviale taak kan bevatten die oplosbaar is door een klein open-weight model. Dit leidt tot twee inefficiënties:

1. Kosteninefficiëntie: Het versturen van eenvoudige queries naar dure frontier-modellen (bijv. Kimi 2.6) verspilt budget, aangezien lokale open-weight modellen (bijv. Qwen 3.5-9B) vaak volstaan.
2. Latency- en nauwkeurigheidstrade-offs: Cascade-routering (het aftasten van modellen van goedkoop naar duur) brengt aanzienlijke overhead met zich mee in agentic workflows, waarbij een enkele gebruikersaanvraag meerdere LLM-aanroepen triggert, wat de kosten van afgewezen "goedkope" pogingen cumulatief verhoogt.

Het doel is om elke query te sturen naar het goedkoopste model dat het correct zal beantwoorden, waarbij een balans wordt gezocht tussen kosten, latentie en nauwkeurigheid zonder te vertrouwen op oppervlakkige heuristieken.

2. Methodologie: De Brick Router

De auteurs stellen Brick voor, een multimodale router die opereert binnen het Mixture-of-Models (MoM) paradigma. In tegen tegenstelling tot Mixture of Experts (MoE), dat sub-netwerken binnen één enkel model activeert, stuurt MoM volledige queries door naar verschillende, onafhankelijke, vooraf getrainde modellen.

2.1 Het MoM Paradigma

Brick maakt gebruik van een pool van drie heterogene modellen:

• Qwen3.5-9B: Een state-of-the-art open-weight model (<10B parameters).
• DeepSeek-V4-Flash: Een state-of-the-art open-weight model (<500B parameters).
• Kimi2.6: Een frontier open-source concurrent.

De pool beslaat verschillende prijssegmenten (variërend van ~$0.001 tot ~$0.03 per aanroep) en capaciteitsprofielen, waardoor de router de capaciteitscomplementariteit kan benutten (bijv. een model dat een query weigert die een ander model wel oplost).

2.2 De Zesdimensionale Capaciteitsruimte

Brick kadert routering als een geometrische beslissing in een zesdimensionale capaciteitsruimte. De dimensies zijn:

1. Coding (Coderen)
2. Creative Synthesis (Creatieve Synthese)
3. Instruction Following (Instructieopvolging)
4. Math Reasoning (Wiskundig Redeneren)
5. Planning/Agentic (Planning/Agentic)
6. World Knowledge (Wereldkennis)

De Pipeline:

1. Capaciteitschatting: Een gefinetuned ModernBERT classifier brengt de query in kaart naar een waarschijnlijkheidsvector $p(x)$ over de zes dimensies.
2. Complexiteitschatting: Een aparte classifier schat een moeilijkheidsscore $\tau_q$ in (een blend van "easy/medium/hard" ankers).
3. Skill Matrix Kalibratie: Een offline gekalibreerde skill matrix $S$ slaat de empirische succespercentages ($s_{m,c}$) van elk model $m$ op elke capaciteit $c$ op, afgeleid van een gelabelde dataset.
4. Geometrische Routeringswiskunde:
   • Vereiste: De vereistenvector van de query $r_{q,c}$ wordt afgeleid van $p(x)$ en de difficulty logit $z_q$.
   • Capaciteit: De capaciteitsvector van het model $v_{m,c}$ wordt afgeleid van $p(x)$ en de model skill logit $\text{logit}(s_{m,c})$.
   • Residualen: De router berekent asymmetrische residualen: ondercapaciteit ($u$, model te zwak) en overcapaciteit ($o$, model te krachtig).
   • Scoring: Een totale score $J_m$ wordt berekend als een gewogen Euclidische afstand van residualen plus een kostenstraf:
     $$J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$$
     Waarbij $a_m$ de genormaliseerde kosten zijn, $\lambda$ overcapaciteit bestraft, en $\beta$ de kosten-kwaliteit trade-off regelt.
5. Besluitvorming: Het model met de minimale $J_m$ wordt geselecteerd.

2.3 De Preference Knob ($r$)

Brick introduceert een continue preferentieknop $r \in [-1, 1]$ die operators in staat stelt te schuiven tussen een "max-kwaliteit" en een "max-besparing" profiel. Deze knop moduleert de vier routeringsscalars ($\mu, b, \beta, \lambda$) via een gekalibreerde machtswet, waardoor de kosten-kwaliteit trade-off een parameter tijdens de implementatie wordt in plaats van een wijziging in de code.

3. Belangrijkste Bijdragen

1. MoM Formulering: Het artikel frameert het routeren van volledige modellen over heterogene pools als het MoM-paradigma, en toont aan dat dit 24% van de haalbare headroom herstelt tussen het beste enkele model en een theoretische drie-modellen oracle.
2. Verwerping van Oppervlakkige Routering: Het toont empirisch aan dat domein-gebaseerde en lengte/trefwoord-gebaseerde routering falen in het vastleggen van intra-domein moeilijkheid, en zelfs onderpresteren ten opzichte van een simpele "always-Kimi" baseline.
3. Brick Router: Een gekalibreerde MoM-router met een expliciete capaciteitsvector-representatie en een gebruikersvriendelijke preferentieknop.
4. Agentic Efficiëntie: Het artikel beargumenteert dat pure single-step routering (zoals Brick) structureel superieur is aan cascade-routering voor agentic workloads, omdat het de cumulatieve kosten van afgewezen cascade-stadia bij elke stap van een agent-traject vermijdt.

4. Experimentele Resultaten

Geëvalueerd op Dataset A (5.504 queries over zes capaciteitsdimensies):

• Nauwkeurigheid vs. Kosten:

  • Max-Quality Profiel ($r=+1$): Brick bereikt 76,98% nauwkeurigheid, waarmee het het beste enkele model (Kimi 2.6 met 75,02%) en alle externe routers (RouteLLM, FrugalGPT, Cascade Routing) verslaat. Dit doet het met 28% lagere kosten ($0,022 vs $0,031 per aanroep).
  • Neutraal Profiel ($r=0$): Bereikt 74,11% nauwkeurigheid bij 4,71× lagere kosten dan always-Kimi, met slechts een verlies van 0,91 procentpunt aan nauwkeurigheid. Het presteert beter dan Cascade Routing met +0,71 pp bij vergelijkbare kosten.
  • Low Profiel ($r=-0,5$): Bereikt 71,62% nauwkeurigheid, waarmee het FrugalGPT (69,42%) verslaat met +2,20 pp bij vergelijkbare kosten.
  • Min-Cost Profiel ($r=-1$): Matcht het goedkoopste model (Qwen) met 63,17% nauwkeurigheid, maar tegen 22,15× lagere kosten dan always-Kimi.

• Latentie:

  • De mediane end-to-end latentie voor Brick (Max profiel) daalt van 51,2s (always-Kimi) naar 22,8s. Dit komt doordat Brick ~31% van de queries naar het snellere DeepSeek-V4-Flash model stuurt, zelfs in de max-kwaliteit instelling.

• Oracle Bound:

  • De theoretische bovengrens (Three-Model Oracle) is 83,25%. Brick vangt een aanzienlijk deel van de kloof tussen het beste enkele model en deze oracle op, hoewel een residu van 6,27 pp nog niet door de huidige capaciteitskenmerken wordt geëxtraheerd.

5. Betekenis en Claims

Het artikel claimt dat Brick de levensvatbaarheid van het MoM-paradigma demonstreert als een eersteklas implementatiepatroon. De betekenis ligt in:

• Empirische Validatie: Het bewijs dat routering gebaseerd op een gekalibreerde capaciteitsruimte beter presteert dan heuristische routering en single-model baselines.
• Operationele Flexibiliteit: Het bieden van een continue knop voor operators om de kosten-kwaliteit trade-off af te stemmen zonder hertraining of wijzigingen in de code.
• Agentic Schaalbaarheid: Het vaststellen dat pure routering de enige vorm is die efficiënt schaalt naar agentic workloads, waarbij de lineaire kosten- en latentiepenaliteiten van cascade-routering worden vermeden.
• Complementariteit: Het benadrukken dat modelpools complementaire foutensets bieden (bijv. het afhandelen van "eerlijke weigeringen" versus hallucinaties), waar een capaciteitsbewuste router van kan profiteren om de algehele systeembetrouwbaarheid te verbeteren.

De auteurs blijven bescheiden en erkennen dat de resterende kloof tot de oracle (6,27 pp) informatie vertegenwoordigt die de huidige router nog niet extraheert, en dat toekomstig werk zich moet richten op Bayesian smoothing voor sparse pools en domein-geconditioneerde complexiteitschatting.