RouteWeaver lernt Ausführungsmodus und Worker-Wahl in einer einzigen Policy

Eine Policy wählt zuerst den Modus, dann die Worker-Modelle

RouteWeaver fasst Single-Round-, Multi-Round- und agentisches Routing in einer LLM-Policy zusammen. Sie lernt gemeinsam, welcher Ausführungsmodus zum Zug kommt und welche Worker-Modelle innerhalb dieses Modus gewählt werden.

Laut den Autoren legen bestehende Router das Ausführungsparadigma vorab fest. Sie passen an, welche Modelle sie aufrufen, nicht aber, wie diese Aufrufe organisiert sind. RouteWeaver macht das Paradigma selbst zur Routing-Entscheidung. Die Autoren führen darauf eine höhere Genauigkeit über verschiedene Reasoning-Aufgaben zurück.

Gegenüber den im Material belegten Ansätzen liegt der Unterschied in der gemeinsamen Policy. RouteLLM ist ein Framework für Single-Round-Routing zwischen einem starken und einem schwachen Modell. Router-R1 trainiert per Reinforcement Learning einen Multi-Round-Router, der „think“- und „route“-Aktionen verschränkt. LLMRouter/xRouteBench formuliert Routing als sequentiellen Entscheidungsprozess. Als Rahmenwerk deckt es mehrere Modi ab, darunter Single-Round, Multi-Round und personalisiertes Routing.

COMET-GRPO und progressive Exploration: So wird der Router trainiert

Für das Training entwickelten die Autoren COMET-GRPO (COordinated Mode-Execution Training). Das Verfahren zerlegt den Vorteil auf Trajektorienebene in getrennte Signale für die Modusauswahl und die Ausführung innerhalb des Modus. So lässt sich der Erfolg gezielter der jeweiligen Entscheidungsebene zuordnen.

Ergänzt wird dies durch progressive Exploration. Das Training verschiebt sich schrittweise von extern vorgegebenen Modi hin zu autonomer Modusauswahl. Zuerst lernt der Router, jeden Modus auszuführen. Danach lernt er, wann er welchen einsetzt.

Laut Modellkarte basiert das veröffentlichte Modell auf Qwen3-4B-Instruct-2507, alle Parameter sind feinabgestimmt. Trainiert wurde mit reiner Task-Belohnung (α = 0). Das Modell ist kein Chat-Modell. Es schreibt Routing-Aktionen, die eine Agentenschleife gegen einen Worker-Pool ausführt. Die Worker sind eingefroren. Angesprochen werden sie nur über anonyme, positionsgebundene IDs (worker_1 bis worker_6) mit Fähigkeitsbeschreibungen. Der Router sieht weder Modellnamen noch Preise. Die IDs bedeuten nur das, was der Prompt festlegt. Deshalb muss das Modell mit derselben Pool-Definition betrieben werden.

61,4 Prozent Genauigkeit, aber das Paper fehlt und die Baseline bleibt unbenannt

Die Evaluation umfasst Mathematik, Coding, Wissen, logisches Schließen und Faktenabruf. Die Autoren berichten eine durchschnittliche Genauigkeit von 61,4 Prozent und eine relative Verbesserung von 11,03 Prozent gegenüber der stärksten Baseline. Welche Baseline das ist, geht aus dem Material nicht hervor. Der Abstract bricht an dieser Stelle ab. Ein Vergleich mit dem besten Einzelmodell ist ebenfalls nicht belegt.

Auf Hugging Face sind Code, Projektseite, Datensatz und kostenbewusste Varianten wie RouteWeaver-4B-cost verlinkt. Dort ist das Paper als „coming soon“ geführt. Die Einordnung stützt sich daher allein auf Abstract und Modellkarte.

Prüfbar wird das erst mit dem Volltext samt Baselines und Ablationen. Nötig sind außerdem Vergleiche gegen Router-R1 und die Router aus LLMRouter sowie eine unabhängige Reproduktion mit dem veröffentlichten Code. Zwei weitere Treffer namens RouteWeaver, ein Windows-Proxy-Gateway und ein Reddit-Post, lassen sich nicht nachweislich dieser Arbeit zuordnen.