Robust Batch-Level Query Routing for Large Language Models under Cost and Capacity Constraints

Este artigo propõe um framework de roteamento robusto e consciente de recursos em nível de lote para modelos de linguagem grandes (LLMs), que otimiza a alocação de instâncias e controla custos e capacidades sob restrições adversárias, superando significativamente os métodos de roteamento por consulta individual em benchmarks multi-tarefa.

O essencial

Imagine que você é o gerente de um restaurante muito popular que tem vários chefs à disposição. Alguns chefs são lendários (modelos de IA grandes e caros), mas cobram muito pelo prato e demoram um pouco. Outros são rápidos e baratos, mas só sabem fazer pratos simples.

O seu objetivo é servir o melhor prato possível para cada cliente, sem quebrar o caixa do restaurante e sem deixar a cozinha lotada a ponto de os chefs pararem de trabalhar.

Aqui está o que os autores deste artigo descobriram e propuseram, explicado de forma simples:

1. O Problema: O Caos do "Peça por Peça"

Antes, a maioria dos restaurantes (sistemas de IA) fazia o seguinte: quando um cliente chegava, o garçom olhava o pedido e decidia imediatamente qual chef faria aquele prato.

• O erro: Se 10 clientes pedirem pratos complexos ao mesmo tempo, o garçom pode mandar todos para o "Chef Lendário". Resultado? A cozinha explode, a conta fica altíssima e os clientes esperam horas.
• A analogia: É como se você tivesse um orçamento de $100 para o dia todo. Se você gastar $50 no primeiro cliente, sobra pouco para os outros. O sistema antigo não olhava para o "grupo" de pedidos, apenas para um de cada vez.

2. A Solução: O "Gerente de Grupo" (Roteamento em Lote)

Os autores propuseram uma nova ideia: em vez de decidir um por um, vamos olhar para o grupo inteiro de pedidos que chegou de uma vez (o "lote" ou batch).

Imagine que você tem uma caixa de ferramentas e um grupo de 100 tarefas.

• A abordagem antiga: Escolher a melhor ferramenta para cada tarefa individualmente, sem olhar para o saldo da sua conta bancária.
• A nova abordagem (Inteligente): Você olha para as 100 tarefas juntas.
  • "Ok, essas 80 tarefas são fáceis, vamos mandar para os ajudantes rápidos e baratos."
  • "Essas 20 são difíceis, vamos mandar para o Chef Lendário."
  • O Truque: O sistema resolve um "quebra-cabeça matemático" (chamado Programação Linear Inteira) para garantir que, no final, você não gastou mais do que o orçamento e que nenhum chef ficou sobrecarregado.

Resultado: Em situações onde os pedidos chegam de forma desorganizada (ou até mal-intencionada, como no teste "adversário"), essa nova forma de gerenciar o grupo economizou até 24% de recursos e melhorou a qualidade da resposta.

3. O "Seguro" contra Erros (Otimização Robusta)

Às vezes, o garçom acha que sabe qual é o melhor chef, mas pode estar enganado. O sistema antigo confiava cegamente nessa previsão.

• A nova ideia: O sistema agora é "cauteloso". Ele pergunta: "E se a previsão estiver errada? E se o Chef Lendário estiver cansado hoje?"
• A analogia: É como dirigir com um guarda-chuva mesmo quando o céu está meio nublado. O sistema assume o "pior cenário possível" dentro de uma margem de erro e toma a decisão que funciona bem mesmo se as coisas derem errado.
• Benefício: Isso aumentou a precisão em até 14% em alguns casos, porque evita que o sistema mande um pedido difícil para um chef que, na verdade, não consegue fazer bem naquele momento.

4. A Decisão de Longo Prazo (Alocação de Recursos)

Antes de o restaurante abrir, você precisa decidir quantos chefs contratar e quantas cozinhas (GPUs) instalar.

• O jeito antigo: Contratar o mesmo número de ajudantes para todos os tipos de cozinha, ou apenas focar nos grandes chefs.
• O jeito novo: O sistema simula o dia todo antes de começar. Ele calcula: "Para atender bem os pedidos de segunda a sexta, precisamos de 3 cozinhas pequenas e 1 grande, e não o contrário."
• Resultado: Isso melhorou o desempenho em até 3%, garantindo que os recursos (como placas de vídeo/GPUs) não fiquem parados ou sobrecarregados.

Resumo da Ópera

Este trabalho é como transformar um gerente de restaurante que reage freneticamente a cada cliente em um maestro experiente.

1. Ele olha para a orquestra inteira (o lote de pedidos), não para um músico de cada vez.
2. Ele usa um plano de contingência (robustez) para garantir que a música não pare se um instrumento falhar.
3. Ele planeja o palco (alocação de GPUs) antes do show começar para garantir que tudo corra bem.

O resultado? Um sistema de Inteligência Artificial que é mais barato, mais rápido, não trava quando muita gente pede ao mesmo tempo e entrega respostas melhores, mesmo quando as previsões não são 100% perfeitas.

Resumo técnico

Resumo Técnico: Roteamento Robusto em Lote para Grandes Modelos de Linguagem (LLMs)

1. O Problema

O artigo aborda os desafios de rotear consultas (queries) para Grandes Modelos de Linguagem (LLMs) em sistemas de produção, onde as consultas chegam em lotes dinâmicos e estão sujeitas a restrições rigorosas de custo monetário e capacidade de hardware (GPUs).

Os métodos de roteamento existentes operam predominantemente em uma base por consulta (per-query), tentando equilibrar qualidade e custo para cada solicitação individualmente. O artigo identifica três falhas críticas nessa abordagem:

1. Falta de controle de custo em nível de lote: O custo é controlado indiretamente através de um hiperparâmetro de trade-off ($\lambda$), tornando difícil garantir orçamentos estritos por lote.
2. Ignorância de efeitos de lote: Quando múltiplas consultas difíceis chegam juntas (especialmente em cenários adversários), o roteamento por consulta pode sobrecarregar modelos caros ou com capacidade limitada, causando picos de custo ou atrasos.
3. Incerteza nas estimativas de desempenho: As estimativas de qualidade ($l(q, m_j)$) podem ser ruidosas, levando a decisões de roteamento excessivamente otimistas ou pessimistas.

Além disso, a alocação de recursos (ex: número de GPUs para modelos locais) é frequentemente tratada como fixa ou desconectada da estratégia de roteamento online.

2. Metodologia

Os autores propõem um framework de roteamento baseado em Programação Linear Inteira (ILP) que otimiza a atribuição de modelos para um lote inteiro de consultas simultaneamente, em vez de consulta por consulta.

A. Formulação de Roteamento em Lote (Online)
O problema é formulado como um ILP que maximiza a qualidade média de roteamento no lote, sujeito a:

• Restrição de Custo: O custo total do lote não pode exceder um orçamento definido.
• Restrição de Capacidade: O número de consultas roteadas para uma instância de modelo não pode exceder sua capacidade de concorrência ($l_j \times I_j$).
• Atribuição: Cada consulta deve ser atribuída a exatamente um modelo.

B. Roteamento Robusto (Robust Optimization)
Para lidar com a incerteza nas estimativas de desempenho ($a_{i,j}$), o framework introduz uma variante robusta. Em vez de usar um ponto estimado, o método utiliza o limite inferior de um intervalo de previsão (obtido via bootstrap resampling ou conformal prediction).

• A função objetivo passa a maximizar o desempenho no pior caso dentro da incerteza estimada.
• Isso evita que o roteador confie excessivamente em modelos cujas estimativas de desempenho têm alta variância.

C. Alocação Offline de Instâncias de Modelo
Antes da inferência, o sistema resolve um problema de otimização offline para determinar o número ideal de instâncias ($I_j$) de cada modelo a ser implantado (especialmente relevante para modelos de código aberto hospedados localmente).

• O objetivo é equilibrar a qualidade e a capacidade total do sistema, simulando o desempenho de inferência em lotes de calibração, respeitando o orçamento total de GPUs.

D. Estimadores de Desempenho
O framework é agnóstico ao modelo de estimativa, mas os autores testam e comparam:

• MIRT (Multidimensional Item Response Theory).
• k-NN (K-Nearest Neighbors).
• XGBoost (proposto como um estimador eficiente e escalável para dados tabulares).
• Variantes robustas (usando o limite inferior do intervalo de previsão) para XGBoost e k-NN.

3. Contribuições Principais

1. Identificação de Falhas: Demonstra empiricamente que o roteamento por consulta falha em controlar custos em nível de lote e é vulnerável a aglomerações adversárias de consultas.
2. Framework de Otimização em Lote: Introduz uma formulação baseada em ILP que maximiza a qualidade média do lote enquanto respeita estritamente orçamentos de custo e limites de hardware (GPUs).
3. Abordagem Robusta: Desenvolve uma variante de otimização robusta que garante desempenho estável mesmo sob erros de estimativa, priorizando modelos com menor variância preditiva.
4. Otimização Conjunta de Alocação: Propõe um método para otimizar offline a alocação de recursos computacionais (GPUs) entre modelos, fechando a lacuna entre o planejamento de implantação e o roteamento online.
5. Validação Empírica: Demonstra que os ILPs podem ser resolvidos eficientemente (em milissegundos) usando solvers comerciais (SCIP), viabilizando a implantação em tempo real.

4. Resultados Experimentais

Os experimentos foram realizados em dois benchmarks multi-tarefa de LLMs (Dataset 1 e Dataset 2).

• Robustez: A incorporação de robustez melhorou a precisão de roteamento em 1% a 14% em comparação com métodos não robustos, dependendo do estimador utilizado. O roteamento robusto tende a selecionar modelos com menor incerteza preditiva.
• Roteamento em Lote vs. Por Consulta:
  • Sob agrupamento aleatório, o roteamento em lote superou o método por consulta em até 4%.
  • Sob agrupamento adversário (consultas difíceis agrupadas), a melhoria foi de até 24%, demonstrando a capacidade do método de evitar picos de custo e subutilização de recursos.
• Otimização de Alocação de Instâncias: A alocação de GPUs baseada em dados (otimizada offline) gerou ganhos adicionais de até 3% em comparação com alocações fixas e uniformes.
• Eficiência de Recursos: O método de otimização completa (com robustez) superou o estado da arte (MIRT) e modelos individuais de alto desempenho. Por exemplo, para igualar o desempenho do modelo DeepSeek_Chat, o roteador otimizado exigiu apenas 177 GPUs e um orçamento baixo, contra 800 GPUs necessários para rodar o modelo isoladamente.
• Desempenho do Solver: O solver SCIP resolveu problemas de roteamento para lotes de tamanho 400 em menos de 0,4 segundos, confirmando a viabilidade de tempo real.

5. Significado e Impacto

Este trabalho representa um avanço significativo na operação de sistemas de LLMs em escala industrial. Ao mudar o paradigma de "otimização por consulta" para "otimização em lote com restrições", o artigo oferece:

• Previsibilidade Financeira: Garante que os custos de inferência não ultrapassem orçamentos definidos, mesmo em cenários de tráfego imprevisível.
• Eficiência de Hardware: Permite o uso mais inteligente de GPUs locais e APIs na nuvem, maximizando a qualidade da resposta dentro das limitações físicas e financeiras.
• Resiliência: A abordagem robusta protege o sistema contra falhas catastróficas de qualidade quando as estimativas de desempenho são imprecisas.

Em suma, o paper fornece uma estrutura prática e matematicamente fundamentada para gerenciar o trade-off entre custo, latência, capacidade e qualidade em sistemas de inferência de LLMs modernos, sendo diretamente aplicável a cenários de produção onde a estabilidade e a eficiência de custos são críticas.