TokenRouter acelera o roteamento token a token entre modelos em até 64 vezes

A equipe do laboratório thu-nics (Tsinghua) lançou o TokenRouter, um sistema que permite a um modelo de linguagem grande e a um pequeno dividirem uma mesma geração: a cada próximo token, o sistema decide quem o escreve. O número de destaque, "até 64 vezes", é a razão entre a vazão do TokenRouter (tokens por segundo somando todas as requisições paralelas) e a das implementações oficiais dos algoritmos de roteamento existentes. O ganho não vem de uma nova matemática de escolha de modelo, mas de engenharia: os autores eliminaram o overhead que, nas implementações brutas, consome quase todo o tempo.

Roteamento de requisições é um tema maduro; o de tokens, não

O autor do post original no @gonzo_ML observa que direcionar requisições a modelos diferentes já é prática antiga. A empresa dele, a Intento, faz isso há quase dez anos. Por isso, a avaliação da OpenRouter e o negócio com a Stripe o surpreenderam: segundo a Menlo Ventures, a gigante de pagamentos está comprando o serviço agregador de modelos.

Esse tipo de roteador analisa a requisição inteira. Uma pergunta simples vai para o modelo barato; uma complexa, para o caro. Exemplos: serviços comerciais e o RouteLLM, de código aberto.

O TokenRouter atua em outro nível. Dentro de uma mesma resposta, a dificuldade não é uniforme. A maioria dos tokens é trivial: terminações de palavras, conectivos, código-padrão. Só em alguns pontos de bifurcação do raciocínio é preciso um modelo forte. O critério de dificuldade é a entropia: quanto menos segurança o modelo pequeno tem sobre o próximo token, maior a entropia. Quando ela é alta, o token passa para o modelo grande. Nos demais casos, o pequeno escreve.

Em teoria, isso reduz o custo de inferência: o modelo pesado só trabalha onde não há como dispensá-lo. Na prática, o esquema esbarra no código auxiliar ao redor.

Onde os tokens por segundo se perdem

A implementação ingênua chama ora um modelo, ora outro a cada passo, recalcula o contexto e transfere dados entre processos. Todas essas operações são custosas. O autor do post considera esse o ponto mais interessante do trabalho: a maquinaria auxiliar, sem otimização, sai muito cara.

O TokenRouter é construído sobre o SGLang, um motor de código aberto para executar LLMs, e tem várias partes:

• API de três funções. O algoritmo de roteamento é descrito por meio de uma interface pequena, então roteadores diferentes se conectam sem reescrever o runtime.
• Subservidores assíncronos. Cada modelo tem o seu próprio subservidor, e eles trabalham em paralelo, sem esperar um pelo outro.
• Preservação do KV-cache entre chamadas. O KV-cache guarda os estados intermediários do contexto já calculados. Sem preservá-lo, o contexto teria de ser recalculado do zero a cada troca de modelo.
• Agendador de batching adiado com cadeias de Markov. A GPU processa um lote de requisições com mais eficiência do que uma por vez. O agendador modela o fluxo de chamadas a cada subservidor e decide se vale esperar um pouco até o lote se formar.

Para o R2R, um dos roteadores existentes em nível de token, os autores mediram separadamente a contribuição dos CUDA graphs. Trata-se de uma tecnologia da NVIDIA: a sequência de operações da GPU é gravada uma vez e executada inteira, sem gastar tempo com chamadas individuais. Do ganho total de 2,76x, 1,71x veio dos CUDA graphs.

Números em matemática de olimpíada e código agêntico

O sistema foi testado com cinco algoritmos de roteamento. As tarefas são de dois tipos: raciocínio no AIME2024 (problemas da olimpíada americana de matemática) e cenários agênticos no SWE-Smith (conjunto de tarefas de correção de código para agentes de programação).

Com 4 requisições paralelas:

• TokenRouter: 76,6–290,3 tokens/s, dependendo do algoritmo.
• Baseline token a token no SGLang: 4,5–63,1 tokens/s.
• Implementações oficiais: 0,7–78,3 tokens/s.
• Ganho: de 2,01x a 64,15x.

Especificamente no roteador R2R:

• 8 requisições: 134,9 → 372,5 tokens/s (2,76x).
• 16 requisições: o TokenRouter supera o R2R em 3,61x com o mesmo paralelismo.
• Contra o R2R com uma única requisição, o ganho é de 18,58x, e a velocidade por usuário ainda aumenta 1,13x.

O último par de números mostra o sentido prático. É possível atender muitos usuários ao mesmo tempo sem perder velocidade para cada um deles.

O que isso significa na prática e onde está a pegadinha

Os autores mostram que o roteamento por token pode ficar escondido atrás de um único endpoint compatível com a OpenAI. Para o cliente, é uma API comum; por dentro, dois modelos dividem a geração. Em termos de equilíbrio entre velocidade e precisão, esse esquema pode superar roteadores em nível de requisição, como o RouteLLM. Para empresas que pagam por inferência, é uma nova alavanca: o preço do token cai na proporção de tokens "fáceis", enquanto a qualidade nos pontos de decisão difíceis se mantém.

Há duas limitações que o engenheiro deve considerar antes de adotar a solução:

• Cada subservidor precisa guardar o KV-cache de toda a sequência. A memória das GPUs é consumida quase em dobro: o cache existe tanto para o modelo pequeno quanto para o grande.
• O solver markoviano do agendador só foi validado com até 4 requisições paralelas. Como ele se comporta com centenas de sessões em produção ainda é desconhecido. Os números para 8 e 16 requisições foram obtidos no R2R.

O código está disponível em acesso aberto (thu-nics/TokenRouter). Equipes que operam seus próprios modelos podem testar a abordagem com suas cargas de trabalho. A principal lição do trabalho é aplicada: a ideia de rotear tokens é conhecida há tempos, mas, sem engenharia de sistemas cuidadosa, o ganho se perde no código ao redor.