Resumo Técnico: INFRAMIND

1. Declaração do Problema: Cegueira de Infraestrutura

Os atuais sistemas de orquestração de modelos de linguagem de grande escala (LLM) multi-agente sofrem de um modo de falha crítico denominado cegueira de infraestrutura. Embora métodos existentes (ex: MoA, GPTSwarm, MasRouter) tenham avançado no aprendizado de topologias e seleção de modelos adaptáveis à tarefa com base em características estáticas de consulta, eles operam sem observar o estado de execução da infraestrutura de serviço.

Em clusters de GPU compartilhados que servem múltiplos modelos (ex: via vLLM ou SGLang), essa cegueira leva a uma subutilização sistemática de recursos e explosões de latência:

• Desequilíbrio de Filas: Modelos "preferidos" acumulam filas profundas de requisições enquanto alternativas igualmente capazes permanecem ociosas.
• Atrasos Compostos: Em pipelines multi-agente, um gargalo em qualquer etapa atrasa todos os agentes subsequentes, fazendo com que a latência se acumule.
• Decisões Estáticas: As decisões de roteamento são tomadas com base em regimes de informação de tempo de treinamento que estão desconectados das condições de execução (profundidade de fila, pressão de KV-cache e latências).
• Raciocínio Inflexível: Os sistemas falham em adaptar a profundidade do raciocínio (ex: alternar de "DeepThink" para "Flash") com base na capacidade disponível, deixando recursos ociosos não aproveitados ou sobrecarregando os congestionados.

O desafio central é que os sinais de infraestrutura são dinâmicos e ruidosos, mas devem impulsionar três decisões acopladas: planejamento (topologia/papéis), roteamento por etapa (seleção de modelo/estratégia) e escalonamento (priorização de fila).

2. Metodologia: Framework INFRAMIND

Os autores propõem o INFRAMIND, o primeiro orquestrador multi-agente orientado à infraestrutura de ponta a ponta. Ele integra métricas de sistema em tempo real em cada camada da pilha de orquestração, formulada como um Processo de Decisão de Markov com Restrições Hierárquicas (CMDP) e resolvido via Aprendizado por Reforço (RL).

Componentes Principais

1. Planejador Consciente da Infraestrutura (Infra-Aware Planner):

   • Função: Determina a estrutura de raciocínio (topologia, contagem de agentes, papéis) no momento da chegada da consulta ($t=0$).
   • Mecanismo: Diferente do trabalho anterior que depende apenas de embeddings de consulta, o planejador condiciona suas decisões em um resumo da carga atual do sistema ($z_0$) e do orçamento restante.
   • Implementação: Utiliza um controlador em cascata onde a Modulação Linear por Características (FiLM) injeta vetores de estado do sistema (orçamento, profundidade de fila, latência E2E, KV cache) no embedding da consulta. Isso enviesa o planejador para grafos mais simples sob congestionamento e topologias mais ricas quando há capacidade disponível.

2. Executor Consciente da Infraestrutura (Infra-Aware Executor):

   • Função: Seleciona o modelo específico e a estratégia de raciocínio (Flash, Conciso, DeepThink) para cada etapa do agente.
   • Mecanismo: Opera em uma arquitetura de via dupla:
     • Via Semântica: Processa a consulta e os embeddings de papel (o que a tarefa precisa).
     • Via de Recursos: Processa o orçamento restante e as métricas de sistema ao vivo (o que o sistema pode entregar).
   • Decisão: Mescla esses sinais para selecionar conjuntamente um modelo e uma estratégia. Por exemplo, se a fila de um modelo grande estiver saturada, o executor pode redirecionar para um modelo menor ocioso e compensar usando uma estratégia "DeepThink", aproveitando o tempo economizado ao pular a fila para manter a precisão.

3. Escalonador de Prioridade Consciente do Orçamento (Budget-Aware Priority Scheduler):

   • Função: Gerencia a ordenação de requisições dentro da fila local de cada modelo.
   • Mecanismo: Implementa uma política de Prazo Mais Próximo (Earliest-Deadline-First - EDF). Cada consulta recebe um prazo baseado em seu tempo de chegada e orçamento de tempo. Cada chamada de agente herda este prazo.
   • Impacto: Evita que requisições de orçamento apertado sejam bloqueadas por outras mais relaxadas (bloqueio de cabeça de linha), garantindo que consultas urgentes sejam atendidas primeiro.

Abordagem de Treinamento

Os três componentes são treinados conjuntamente como uma única política de RL hierárquica sob uma restrição de orçamento compartilhada.

• Objetivo: Maximizar a qualidade (taxa de resolução) sujeita a um orçamento de latência.
• Otimização: Utiliza um multiplicador de Lagrange ($\lambda$) para descobrir automaticamente o equilíbrio entre qualidade e latência. O executor utiliza PPO (Otimização de Política Próxima) para trajetórias por etapa, enquanto o planejador utiliza REINFORCE para retornos de episódio.
• Adaptação: O sistema é treinado através de vários níveis de orçamento e taxas de chegada de Poisson, permitendo que aprenda a se adaptar a diferentes regimes de congestionamento.

3. Principais Contribuições

1. Identificação da Cegueira de Infraestrutura: O artigo quantifica empiricamente como ignorar o estado de execução da infraestrutura leva a desequilíbrios de fila, latência evitável e subutilização de recursos em sistemas multi-agente.
2. Orquestração de Ponta a Ponta Consciente da Infraestrutura: Introdução do INFRAMIND, que unifica planejamento, execução e escalonamento em uma única política de RL que condiciona em telemetria em tempo real (profundidade de fila, KV cache, latência).
3. Ganhos de Desempenho: Demonstrou melhorias significativas em precisão, latência e conformidade com o Objetivo de Nível de Serviço (SLO) em diversos benchmarks e condições de carga.

4. Resultados Experimentais

O sistema foi avaliado em cinco benchmarks (MBPP, HumanEval, GSM-Hard, MATH, MMLU-Pro) usando um pool heterogêneo de cinco modelos (3B a 32B parâmetros) servidos em GPUs compartilhadas.

• Baixa Carga ($\mu=10$ req/min): O INFRAMIND alcançou até +7,6 pontos percentuais (pp) de precisão superior ao baseline mais forte (MasRouter) enquanto reduzia a latência em até 7×. Por exemplo, no MATH, atingiu 82,0% de precisão contra 74,4% do MoA.
• Alta Carga ($\mu=100$ req/min): É aqui que o valor do sistema é mais pronunciado.
  • Conformidade de SLO: O INFRAMIND manteve até 99,9% de conformidade de SLO (consultas completando dentro do orçamento de 300s) no HumanEval.
  • Colapso dos Baselines: Todos os baselines caíram abaixo de 50% de conformidade de SLO sob alta carga. MoA e GPTSwarm caíram abaixo de 12% na maioria dos benchmarks, com latências excedendo 1.000 segundos.
  • Latência: O INFRAMIND manteve latências abaixo de 300s em todos os benchmarks, enquanto os baselines migraram para zonas de "congestionamento severo".
• Pools Blackbox/Híbridos: A abordagem foi estendida para pools apenas de API e híbridos (misturando modelos whitebox e de API) usando proxies do lado do cliente para sinais de congestionamento. O INFRAMIND manteve um desempenho robusto onde os baselines colapsaram, provando que a consciência de infraestrutura não requer acesso privilegiado ao servidor, apenas um sinal correlacionado com a responsividade.

5. Significância e Alegações

O artigo afirma que o INFRAMIND aborda uma lacuna fundamental nos sistemas multi-agente de LLM: a desconexão entre a inteligência de nível de tarefa e a realidade da infraestrutura. Ao tornar a consciência de infraestrutura um cidadão de primeira classe nas camadas de planejamento, execução e escalonamento, o sistema equilibra automaticamente qualidade versus latência sem regras codificadas manualmente.

Os autores sustentam que esta abordagem é crítica para fluxos de trabalho multi-agente de produção rodando em clusters de GPU compartilhados (ex: suítes internas empresariais ou implantações de escala web), onde a contenção de fila e a pressão de cache são os principais drivers de latência de cauda. O framework é apresentado como uma solução geral que pode ser implantada em diferentes backends de serviço (vLLM, SGLang ou provedores de API) para melhorar significativamente a conformidade de SLO e a utilização de recursos.