TokenRouter acelera hasta 64 veces el enrutamiento token a token entre modelos

El equipo del laboratorio thu-nics (Tsinghua) ha publicado TokenRouter, un sistema que permite a un modelo de lenguaje grande y a uno pequeño repartirse una misma generación: cada token siguiente decide quién lo escribe. La cifra del titular, «hasta 64 veces», es la relación entre el rendimiento de TokenRouter (tokens por segundo sumando todas las solicitudes paralelas) y el de las implementaciones oficiales de los algoritmos de enrutamiento existentes. La ganancia no viene de una matemática nueva para elegir el modelo, sino de la ingeniería: los autores eliminaron la sobrecarga que, en las implementaciones en bruto, se come casi todo el tiempo.

El enrutamiento de solicitudes es un tema maduro; el de tokens, no

El autor del post original en @gonzo_ML señala que dirigir solicitudes a distintos modelos se hace desde hace tiempo. Su empresa, Intento, lo hace desde hace casi diez años. Por eso le sorprendieron la valoración de OpenRouter y el acuerdo con Stripe: según Menlo Ventures, el gigante de los pagos compra el servicio agregador de modelos.

Ese tipo de router analiza la solicitud completa. Una pregunta sencilla va a un modelo barato; una compleja, a uno caro. Ejemplos: servicios comerciales y el RouteLLM de código abierto.

TokenRouter trabaja en otro nivel. Dentro de una misma respuesta, la dificultad no es uniforme. La mayoría de los tokens son triviales: terminaciones de palabras, conectores, código de plantilla. Solo en algunas bifurcaciones del razonamiento hace falta el modelo fuerte. El criterio de dificultad es la entropía: cuanto menos seguro está el modelo pequeño sobre el siguiente token, mayor es la entropía. Cuando es alta, el token pasa al modelo grande. En los demás casos escribe el pequeño.

En teoría, esto reduce el coste de la inferencia: el modelo pesado trabaja solo donde no se puede prescindir de él. En la práctica, el esquema choca con la maquinaria que lo rodea.

Dónde se pierden los tokens por segundo

La implementación ingenua llama en cada paso a un modelo o al otro, recalcula el contexto y mueve datos entre procesos. Todas estas operaciones son costosas. El autor del post lo considera lo más interesante del trabajo: la maquinaria auxiliar, sin optimizar, sale muy cara.

TokenRouter está construido sobre SGLang, un motor de código abierto para ejecutar LLM, y consta de varias piezas:

• API de tres funciones. El algoritmo de enrutamiento se describe mediante una interfaz pequeña, de modo que distintos routers se conectan sin reescribir el runtime.
• Subservidores asíncronos. Cada modelo tiene su propio subservidor, y todos trabajan en paralelo sin esperarse entre sí.
• Conservación de la KV-cache entre llamadas. La KV-cache guarda los estados intermedios del contexto ya calculados. Si no se conservara, cada cambio de modelo obligaría a recalcular el contexto desde cero.
• Planificador de batching diferido basado en cadenas de Markov. La GPU procesa un lote de solicitudes con más eficiencia que una por una. El planificador modela el flujo de peticiones a cada subservidor y decide si conviene esperar un poco a que se complete el lote.

Para R2R, uno de los routers a nivel de token existentes, se midió por separado la aportación de los CUDA graphs. Es una tecnología de NVIDIA: la cadena de operaciones de la GPU se registra una vez y se lanza entera, sin gastar tiempo en llamadas individuales. De la aceleración total de 2,76x, 1,71x correspondió a los CUDA graphs.

Cifras en matemáticas de olimpiada y código agéntico

El sistema se probó con cinco algoritmos de enrutamiento. Las tareas son de dos tipos: razonamiento en AIME2024 (problemas de la olimpiada matemática estadounidense) y escenarios agénticos en SWE-Smith (un conjunto de tareas de edición de código para agentes de software).

Con 4 solicitudes paralelas:

• TokenRouter: 76,6–290,3 tokens/s, según el algoritmo.
• Baseline token a token sobre SGLang: 4,5–63,1 tokens/s.
• Implementaciones oficiales: 0,7–78,3 tokens/s.
• Mejora: de 2,01x a 64,15x.

Solo en el router R2R:

• 8 solicitudes: 134,9 → 372,5 tokens/s (2,76x).
• 16 solicitudes: TokenRouter supera a R2R en 3,61x con el mismo paralelismo.
• Frente a R2R con una sola solicitud, la ganancia es de 18,58x, y la velocidad por usuario aumenta 1,13x.

Este último par de cifras muestra el sentido práctico: se puede cargar el sistema con muchos usuarios sin perder velocidad para cada uno de ellos.

Qué aporta en la práctica y dónde está el inconveniente

Los autores muestran que el enrutamiento por token puede ocultarse tras un único endpoint compatible con OpenAI. Para el cliente es una API normal, mientras que por dentro dos modelos se reparten la generación. En la relación entre velocidad y precisión, este esquema puede superar a los routers a nivel de solicitud como RouteLLM. Para las empresas que pagan por la inferencia, es una nueva palanca: el precio del token baja en la proporción de tokens «fáciles», y la calidad se mantiene en las bifurcaciones difíciles.

Hay dos limitaciones que un ingeniero debería tener en cuenta antes de implantarlo:

• Cada subservidor tiene que guardar la KV-cache de toda la secuencia. La memoria de las GPU se consume casi el doble: la caché existe tanto para el modelo pequeño como para el grande.
• El solver markoviano del planificador solo se ha probado hasta con 4 solicitudes paralelas. Cómo se comportará con cientos de sesiones en producción es, por ahora, desconocido. Las cifras para 8 y 16 solicitudes se obtuvieron con R2R.

El código está publicado en abierto (thu-nics/TokenRouter). Los equipos que sirven sus propios modelos pueden probar el enfoque con sus cargas de trabajo. La lección principal del trabajo es práctica: la idea del enrutamiento por token se conoce desde hace tiempo, pero sin una ingeniería de sistemas cuidadosa su ganancia se pierde en la maquinaria circundante.