TokenRouter accélère jusqu'à 64 fois le routage token par token entre modèles

L'équipe du laboratoire thu-nics (Tsinghua) a publié TokenRouter, un système qui permet à un grand et à un petit modèle de langage de se partager une même génération : pour chaque token suivant, le système décide quel modèle l'écrit. Le chiffre phare « jusqu'à 64 fois » correspond au rapport entre le débit de TokenRouter (tokens par seconde sur l'ensemble des requêtes parallèles) et celui des implémentations officielles des algorithmes de routage existants. Ce gain ne vient pas d'une nouvelle mathématique du choix de modèle, mais de l'ingénierie : les auteurs ont supprimé les surcoûts qui, dans les implémentations brutes, absorbent presque tout le temps.

Le routage de requêtes est un sujet mûr, pas le routage de tokens

L'auteur du post d'origine, sur @gonzo_ML, rappelle que l'on sait depuis longtemps aiguiller les requêtes vers différents modèles. Son entreprise, Intento, le fait depuis près de dix ans. L'évaluation d'OpenRouter et l'accord avec Stripe l'ont donc surpris : d'après Menlo Ventures, le géant du paiement rachète ce service d'agrégation de modèles.

Un tel routeur examine la requête dans son ensemble. Une question simple part vers un modèle bon marché, une question complexe vers un modèle coûteux. Parmi les exemples : des services commerciaux et le projet open source RouteLLM.

TokenRouter opère à un autre niveau. Au sein d'une même réponse, la difficulté n'est pas uniforme. La plupart des tokens sont triviaux : terminaisons de mots, mots de liaison, code standard. Seules certaines bifurcations du raisonnement exigent un modèle puissant. Le critère de difficulté est l'entropie : moins le petit modèle est sûr du token suivant, plus l'entropie est élevée. Quand elle est élevée, le token est confié au grand modèle. Dans les autres cas, c'est le petit qui écrit.

En théorie, cela réduit le coût de l'inférence : le modèle lourd ne travaille que là où l'on ne peut pas s'en passer. En pratique, le schéma se heurte à l'infrastructure qui l'entoure.

Où se perdent les tokens par seconde

À chaque étape, une implémentation naïve appelle tantôt un modèle, tantôt l'autre, recalcule le contexte et fait circuler les données entre processus. Toutes ces opérations sont coûteuses. L'auteur du post y voit l'aspect le plus intéressant du travail : sans optimisation, la machinerie annexe coûte très cher.

TokenRouter est construit sur SGLang, un moteur open source pour exécuter des LLM, et se compose de plusieurs briques :

• Une API de trois fonctions. L'algorithme de routage se décrit via une petite interface, ce qui permet de brancher différents routeurs sans réécrire le runtime.
• Des sous-serveurs asynchrones. Chaque modèle a son propre sous-serveur, et ils fonctionnent en parallèle sans s'attendre les uns les autres.
• La conservation du KV-cache entre les appels. Le KV-cache stocke les états intermédiaires déjà calculés du contexte. Sans cette conservation, il faudrait recalculer le contexte à chaque changement de modèle.
• Un ordonnanceur de batching différé fondé sur des chaînes de Markov. Un GPU traite plus efficacement un lot de requêtes que des requêtes isolées. L'ordonnanceur modélise le flux d'appels vers chaque sous-serveur et décide s'il vaut la peine d'attendre un peu que le lot se constitue.

Pour R2R, l'un des routeurs existants au niveau du token, les auteurs ont mesuré séparément la contribution des CUDA graphs. Cette technologie de NVIDIA enregistre une seule fois une chaîne d'opérations GPU, puis l'exécute d'un bloc, sans perdre de temps sur des appels individuels. Sur l'accélération totale de 2,76x, les CUDA graphs ont apporté 1,71x.

Les chiffres sur les mathématiques olympiques et le code agentique

Le système a été testé sur cinq algorithmes de routage. Les tâches sont de deux types : du raisonnement sur AIME2024 (problèmes de l'olympiade américaine de mathématiques) et des scénarios agentiques sur SWE-Smith (un ensemble de tâches de correction de code pour agents logiciels).

Avec 4 requêtes parallèles :

• TokenRouter : 76,6–290,3 tokens/s selon l'algorithme.
• Baseline token par token sur SGLang : 4,5–63,1 tokens/s.
• Implémentations officielles : 0,7–78,3 tokens/s.
• Gain : de 2,01x à 64,15x.

Sur le seul routeur R2R :

• 8 requêtes : 134,9 → 372,5 tokens/s (2,76x).
• 16 requêtes : TokenRouter devance R2R de 3,61x à parallélisme identique.
• Face à R2R avec une seule requête, le gain est de 18,58x, tandis que la vitesse par utilisateur augmente de 1,13x.

Cette dernière paire de chiffres montre l'intérêt pratique : on peut charger le système avec de nombreux utilisateurs sans perdre en vitesse pour chacun d'eux.

Ce que cela change en pratique, et où est le piège

Les auteurs montrent que le routage token par token peut se cacher derrière un point d'accès unique compatible OpenAI. Pour le client, c'est une API ordinaire ; en interne, deux modèles se partagent la génération. Sur le rapport vitesse/précision, ce schéma peut surpasser des routeurs au niveau des requêtes comme RouteLLM. Pour les entreprises qui paient l'inférence, c'est un nouveau levier : le prix du token baisse à proportion des tokens « faciles », et la qualité est préservée sur les bifurcations complexes.

Deux limites méritent l'attention d'un ingénieur avant tout déploiement :

• Chaque sous-serveur doit stocker le KV-cache de toute la séquence. La mémoire des GPU est consommée presque deux fois plus : le cache existe à la fois pour le petit et pour le grand modèle.
• Le solveur markovien de l'ordonnanceur n'a été validé que jusqu'à 4 requêtes parallèles. Son comportement sur des centaines de sessions en production reste inconnu à ce stade. Les chiffres pour 8 et 16 requêtes ont été obtenus sur R2R.

Le code lui-même est publié en accès libre (thu-nics/TokenRouter). Les équipes qui exploitent leurs propres modèles peuvent tester l'approche sur leurs charges de travail. La leçon principale de ce travail est pratique : l'idée du routage de tokens est connue depuis longtemps, mais sans une ingénierie système rigoureuse, son gain se perd dans l'infrastructure environnante.