TokenRouter acelera el enrutamiento de LLM por token de 2 a 64 veces frente al serving convencional

Una sola LLM para todas las tareas es un compromiso. Para calcular armónicos o analizar una especificación hace falta un modelo seguro con fórmulas y tablas, mientras que para charlar basta uno generalista. En producción este problema se resuelve desde hace tiempo con enrutamiento: a nivel de sesión o de consulta, el sistema elige a qué modelo llamar. Los investigadores consideran que la ganancia sería mayor si se enrutaran no las consultas, sino los tokens individuales. El problema es que los servidores de inferencia convencionales no están diseñados para ello. El equipo de TokenRouter ha propuesto un sistema que lo corrige.

Por qué enrutar tokens

Imagine que un modelo pequeño escribe la respuesta. Mientras todo es trivial, se las arregla solo y cuesta casi nada. Ante un pasaje difícil le falta seguridad y entra en juego un modelo grande. Así se puede desplazar la frontera entre coste y calidad: se paga por el modelo grande solo donde hace falta.

El artículo cita como ejemplo el router R-Stitch. Después de cada paso de decodificación, calcula la entropía de la distribución del siguiente token. Si la entropía supera un umbral (en los experimentos, τ = 0,03), el token se considera incierto, se descarta y el modelo grande lo regenera. El resto de los tokens se quedan con el modelo pequeño.

Sobre el papel resulta elegante. En la práctica, la consulta salta constantemente de un modelo a otro y el servidor empieza a patinar.

Dónde fallan los servidores convencionales

Los autores señalan tres problemas.

• Desincronización de pasos. Cada modelo tarda un tiempo distinto en calcular un paso. En un batch síncrono todos esperan al más lento, y los rápidos se quedan ociosos.
• Retraso de admisión al batch. La consulta llega al modelo de destino cuando este está ocupado con el batch anterior, y espera al siguiente. Aparecen huecos en la planificación y los batches se fragmentan en otros más pequeños.
• Complejidad de implementación. Los motores existentes no tienen una interfaz para decidir «adónde ir después» en cada paso. Hay que reescribir mucho código y coordinarlo con el continuous batching y la caché de prefijos.

Hay otro inconveniente: en un servidor convencional, el token que vuelve de otro modelo se trata como una consulta nueva. Esto genera costes adicionales por la comparación de prefijos y la actualización de la KV-cache.

Cómo funciona TokenRouter

El principio de los autores: se programa desde el punto de vista de la consulta y se ejecuta desde el punto de vista del modelo. Para el cliente, el sistema parece un servidor normal con una sola LLM. Por dentro, cada modelo tiene su propio subservidor, con su planificador y su pool privado de KV-cache. Los subservidores trabajan de forma asíncrona e intercambian peer requests.

El desarrollador escribe el algoritmo con tres funciones:

• route(result) se llama después de cada paso y, a partir de los logits, los estados ocultos y los tokens muestreados, decide si la consulta se queda en local o se pasa a otro modelo;
• send(req) construye el mensaje para el otro modelo: ID de la consulta, sufijo de tokens que ese modelo aún no ha visto, estado y campos específicos del algoritmo;
• receive(peer_req) convierte el mensaje en una consulta local. Por defecto, simplemente acepta todos los tokens recibidos y rara vez hace falta redefinirla.

Para el retraso de admisión hay un planificador con delayed batching: espera a que se acumulen B consultas en el búfer y solo entonces lanza el paso. El umbral B se calcula de forma analítica: los autores modelan el enrutamiento con una cadena de Markov que tiene en cuenta la concurrencia, la probabilidad de enrutamiento y el tiempo de paso de cada modelo. Un B demasiado pequeño fragmenta los batches; uno demasiado grande mantiene las consultas en cola.

Qué muestran los experimentos

Se probaron cinco algoritmos: CITER, R2R, R-Stitch, Co-LLM y ME. Cuatro funcionan con la pareja Qwen3-0.6B y Qwen3-32B; ME, con tres modelos (0.6B, 8B y 32B). El hardware es un servidor con 8×A100-80G. Hay tres cargas de trabajo: razonamiento corto (AIME2024, salida de hasta 2048 tokens), razonamiento largo (salida de hasta 8192) y tareas de agentes sobre trayectorias de SWE-Smith.

Resultado: el rendimiento es de 2,01 a 64,15 veces mayor y la latencia end-to-end es de 2,03 a 63,64 veces menor respecto al serving estándar. Cuando la salida pasa de 2048 a 8192 tokens, TokenRouter no se resiente, mientras que el serving estándar pierde entre el 58,1 y el 85,2% del rendimiento.

Qué hacer con esto

Si está construyendo una cascada de un modelo pequeño y uno grande, la conclusión principal es esta: el problema a menudo no está en el algoritmo de enrutamiento, sino en cómo lo sirve el motor. Una implementación ingenua puede comerse casi toda la ganancia.

También hay limitaciones. Los resultados se obtuvieron con la familia Qwen3 y con algoritmos concretos. La calidad de las respuestas no es aquí el objeto principal: el artículo trata de la velocidad de servicio, no de qué router es mejor. El umbral B depende de la probabilidad de enrutamiento y de la velocidad de los modelos, así que con su propia combinación habrá que calcularlo de nuevo. Para los equipos con inferencia propia, es una buena razón para echar un vistazo al código abierto.