TokenRouter: Serving-System für Token-Level-LLM-Routing offiziell veröffentlicht

NeurIPS-Annahme und Open-Source-Veröffentlichung für TokenRouter

Das Forschungsteam um Tianyu Fu hat sein Serving-System TokenRouter offiziell veröffentlicht. Das Paper wurde bei NeurIPS 2026 angenommen und ist auf arXiv unter der ID arXiv:2610.12242 abrufbar. Der Quellcode steht als Open Source auf GitHub bereit und lässt sich per pip installieren; die Konfiguration erfolgt über eine einzelne YAML-Datei. Nach Angaben der Autoren erreicht TokenRouter über verschiedene Routing-Algorithmen, Workloads und Modellpaare hinweg eine 2,01- bis 64,15-fach höhere Decoding-Durchsatzrate als bestehende Systeme. Das System ist darauf ausgelegt, Token-Level-Routing für große Sprachmodelle effizient zu bedienen. Die offizielle Veröffentlichung umfasst neben dem Paper auch eine Projektseite mit interaktiven Erklärungen und Ergebnissen. Die Autoren des Papers sind Tianyu Fu, Tengxuan Liu, Ruoxi Wang, Yixin Dong, Yi Ge, Yichen You und Yu Wang. Der Code ist unter einer Open-Source-Lizenz verfügbar, Details zur Lizenz werden im Repository genannt. Die Installation erfolgt über conda und pip, Beispielkonfigurationen liegen im Verzeichnis config/ vor. Ein Server lässt sich mit einem Befehl wie python -m tokenrouter.launch_server --config_path config/r2r/Qwen3-0.6B_Qwen3-32B.yaml starten. Für den Betrieb auf mehreren Knoten sind Peer-Endpoints in der Konfiguration vorgesehen. Die gemessenen Durchsatzsteigerungen beziehen sich auf den Decoding-Durchsatz und wurden laut Abstract über diverse Routing-Algorithmen, Workloads und Modellpaare hinweg ermittelt.

Technische Architektur: Request-centric Programming und Delayed-Batching Scheduler

TokenRouter folgt dem Prinzip „request-centric programming, model-centric execution“. Entwickler beschreiben die Routing-Logik aus Sicht einer einzelnen Anfrage über drei Interfaces: route(), send() und receive(). Die route()-Methode entscheidet nach jedem Vorwärtsschritt, welches Modell die nächsten Token verarbeiten soll; sie kann den aktuellen Modellnamen zurückgeben, um lokal weiter zu dekodieren, oder ein anderes Modell benennen. send() und receive() steuern die Übergabe von Anfragen zwischen Modellen. Die Laufzeit startet für jedes LLM einen eigenen Subserver und verteilt Anfragen asynchron. Dadurch kann ein schnelles Modell weiter dekodieren, während ein langsameres Peer-Modell geroutete Token verarbeitet. Jeder Subserver verwendet einen sogenannten delayed-batching scheduler. Dieser verzögert die Batch-Bildung gezielt, um unregelmäßig eintreffende Token zu sammeln und gemeinsam zu verarbeiten. Die optimalen Hyperparameter dieses Schedulers werden aus einem mathematischen Durchsatzmodell des Gesamtsystems abgeleitet. Das Modell beschreibt den erwarteten Durchsatz des Subservers in Abhängigkeit von der Verzögerungszeit und der Batch-Größe; die Hyperparameter werden so gewählt, dass der Durchsatz maximiert wird. Eine ausstehende Anfrage behält ihren Serving-Zustand und ihren KV-Slot; zurückkehrende Token werden angehängt, ohne Prefix-Matching oder KV-Allokation zu wiederholen. Die Programmierschnittstelle erlaubt es, Routing-Entscheidungen auf Basis von Logits oder Entropie zu treffen, wie ein Beispiel für R-Stitch zeigt: Dort wird nach jedem Schritt die Entropie der nächsten Token-Verteilung berechnet und bei Überschreiten eines Schwellenwerts an das Peer-Modell delegiert.

Namensverwechslung mit kommerzieller Plattform tokenrouter.io

Der Name TokenRouter wird auch von einer kommerziellen Plattform verwendet, die nichts mit dem Forschungssystem zu tun hat. tokenrouter.io ist ein API-Gateway, das zwischen Anwendungen und LLM-Anbietern sitzt. Es bietet Auto-Routing, Kostenkontrolle, Firewall-Regeln und ein Flat-Fee-Modell. Die Plattform unterstützt Provider wie OpenAI, Anthropic, Google, Mistral, DeepSeek und Meta und stellt eine OpenAI-kompatible API bereit. Nach eigenen Angaben wählt sie für jede Anfrage den optimalen Provider und das passende Modell basierend auf Kosten, Latenz oder Qualität aus. Zusätzlich existiert ein weiteres Projekt namens TokenRouter auf lablab.ai. Dabei handelt es sich um einen containerisierten KI-Agenten, der Aufgaben aus einer JSON-Datei liest, in acht Kategorien klassifiziert und an das jeweils günstigste Fireworks-Modell routet, das eine Genauigkeitsschwelle überschreitet. Die Klassifikation erfolgt lokal über regex- und strukturbasierte Regeln ohne verbrauchte Tokens. Alle drei Projekte – das Forschungssystem, die kommerzielle Plattform und der lablab.ai-Agent – sind unabhängig voneinander. Es gibt keine Hinweise auf eine Verbindung zwischen ihnen. Die Namensgleichheit ist zufällig und führt zu Verwechslungen, insbesondere weil beide im Kontext von LLM-Routing auftreten.

Vom früheren Bericht zur offiziellen Veröffentlichung

Bereits zuvor war TokenRouter als neues Serving-System für Token-Level-Routing über mehrere LLMs bekannt. Der frühere Bericht stützte sich auf vorläufige Informationen, da die offiziellen Quellen – die arXiv-Veröffentlichung, die NeurIPS-Annahme und der Open-Source-Code – zu diesem Zeitpunkt noch nicht öffentlich zugänglich waren. Neu ist nun die offizielle Veröffentlichung: Das Paper liegt auf arXiv vor, die Annahme bei NeurIPS 2026 ist bestätigt, und der Quellcode ist auf GitHub verfügbar. Damit sind erstmals die konkreten technischen Details öffentlich dokumentiert – das Prinzip des request-centric programming, die modellzentrierte Ausführung mit Subservern und der delayed-batching scheduler mit mathematisch abgeleiteten Hyperparametern. Auch die gemessenen Durchsatzsteigerungen von 2,01- bis 64,15-fach gegenüber bestehenden Systemen sind jetzt offiziell belegt. Die Veröffentlichung ermöglicht es Entwicklern, das System zu installieren, zu testen und die Ergebnisse nachzuvollziehen.