TokenRouter acelera o roteamento de LLMs por token em 2–64 vezes frente ao serviço convencional

Usar uma única LLM para todas as tarefas é um meio-termo. Para calcular harmônicos ou analisar uma especificação, é preciso um modelo seguro com fórmulas e tabelas; para bate-papo, um modelo generalista basta. Em produção, isso já é resolvido há tempos com roteamento: no nível da sessão ou da requisição, o sistema escolhe qual modelo chamar. Os pesquisadores acreditam que o ganho seria mais evidente se o roteamento fosse feito não por requisição, mas por token. O problema é que os servidores de inferência convencionais não foram projetados para isso. A equipe do TokenRouter propôs um sistema que corrige essa limitação.

Por que rotear tokens

Imagine que um modelo pequeno está escrevendo a resposta. Enquanto tudo é trivial, ele se vira sozinho e custa pouco. Num trecho difícil, falta confiança a ele, e um modelo grande entra em ação. Assim, é possível deslocar a fronteira entre custo e qualidade: paga-se pelo modelo grande apenas onde ele é necessário.

O artigo traz como exemplo o roteador R-Stitch. Depois de cada passo de decodificação, ele calcula a entropia da distribuição do próximo token. Se a entropia fica acima de um limiar (nos experimentos, τ = 0,03), o token é considerado incerto, é descartado e o modelo grande o regenera. Os demais tokens permanecem com o modelo pequeno.

No papel, é elegante. Na prática, a requisição fica saltando entre modelos e o servidor começa a patinar.

Onde os servidores convencionais falham

Os autores apontam três problemas.

• Dessincronização de passos. Os modelos levam tempos diferentes para calcular um passo. Em um batch síncrono, todos esperam o mais lento, e os mais rápidos ficam ociosos.
• Atraso de admissão no batch. A requisição chega ao modelo de destino quando ele está ocupado com o batch anterior e precisa esperar o próximo. Surgem buracos no agendamento, e os batches se fragmentam em lotes pequenos.
• Complexidade de implementação. Os engines prontos não têm uma interface para decidir "para onde ir agora" a cada passo. É preciso reescrever muito código e conciliá-lo com o continuous batching e o cache de prefixos.

Há ainda um problema à parte: num servidor convencional, o token que volta de outro modelo é tratado como uma nova requisição. Isso gera custo extra com a correspondência de prefixos e a atualização do KV-cache.

Como o TokenRouter funciona

O princípio dos autores: programar sob a ótica da requisição e executar sob a ótica do modelo. Para o cliente, o sistema parece um servidor comum com uma única LLM. Por dentro, cada modelo roda em um subservidor próprio, com seu agendador e um pool privado de KV-cache. Os subservidores trabalham de forma assíncrona e trocam requisições peer entre si.

O desenvolvedor escreve o algoritmo por meio de três funções:

• route(result) é chamada após cada passo e, com base nos logits, nos estados ocultos e nos tokens amostrados, decide se a requisição fica local ou é passada a outro modelo;
• send(req) monta a mensagem para outro modelo: ID da requisição, sufixo com os tokens que ele ainda não viu, status e campos específicos do algoritmo;
• receive(peer_req) transforma a mensagem em uma requisição local. Por padrão, ela apenas aceita todos os tokens recebidos, e raramente é preciso sobrescrevê-la.

Contra o atraso de admissão, há um agendador com batching adiado: ele espera até que o buffer reúna B requisições e só então dispara o passo. O limiar B é definido de forma analítica: os autores modelam o roteamento como uma cadeia de Markov, levando em conta a concorrência, a probabilidade de roteamento e o tempo de passo de cada modelo. Um B muito pequeno fragmenta os batches; um B muito grande mantém as requisições na fila.

O que os experimentos mostraram

Foram testados cinco algoritmos: CITER, R2R, R-Stitch, Co-LLM e ME. Quatro deles operam com o par Qwen3-0.6B e Qwen3-32B; o ME usa três modelos (0.6B, 8B, 32B). O hardware é um servidor com 8×A100-80G. Foram três cargas: raciocínio curto (AIME2024, saída de até 2048 tokens), raciocínio longo (saída de até 8192) e tarefas de agente em trajetórias do SWE-Smith.

O resultado: throughput de 2,01 a 64,15 vezes maior e latência end-to-end de 2,03 a 63,64 vezes menor em relação ao serviço padrão. Quando a saída cresceu de 2048 para 8192 tokens, o TokenRouter não perdeu desempenho, enquanto o serviço padrão perdeu de 58,1% a 85,2% do throughput.

O que fazer com isso

Se você monta uma cascata com um modelo pequeno e um grande, a principal conclusão é esta: o problema muitas vezes não está no algoritmo de roteamento em si, mas em como o engine o atende. Uma implementação ingênua pode consumir quase todo o ganho.

Há também limitações. Os resultados foram obtidos com a família Qwen3 e com algoritmos específicos. A qualidade das respostas não é o foco aqui: o artigo trata da velocidade de serviço, não de qual roteador é melhor. O limiar B depende da probabilidade de roteamento e da velocidade dos modelos, então, na sua combinação de modelos, é preciso recalculá-lo. Para equipes com inferência própria, vale olhar o código aberto.