Equipe do ARC-AGI-3 acelerou seu agente de 500 para 3.400 tokens por segundo

Na competição ARC-AGI-3, um participante ficou em sexto lugar e extraiu uma lição útil muito além dos agentes que jogam. Quando o orçamento computacional é limitado a nove horas, não é necessariamente o prompt mais engenhoso que vence. Às vezes, o fator decisivo é quantas tentativas completas o agente consegue realizar e quanta qualidade é sacrificada para alcançar essa velocidade.

O autor começou com cerca de dez trajetórias de jogo em paralelo e uma velocidade próxima de 500 tokens por segundo. Após um mês de trabalho, o servidor entregava cerca de 3.400 tokens por segundo e atendia simultaneamente 110 trajetórias em uma GPU com 96 GB de memória. No entanto, apenas acelerar o sistema não garantia um resultado melhor: algumas otimizações prejudicavam discretamente as respostas do modelo e, após várias horas de jogo, surgia um platô.

Por que os prompts quase não ajudaram

No início, o participante testou o conjunto habitual de ideias: dois agentes com um juiz, diferentes formas de representar o tabuleiro, um "fotógrafo" dedicado às mecânicas do jogo, um modelo programático do mundo, um enxame de conselheiros e um agente com um novo olhar. Quase todas as variantes produziram resultados dentro da margem de ruído ou pioraram o desempenho.

O agente básico já conseguia receber uma imagem e uma representação ASCII do tabuleiro, executar Python para análise e escolher uma ação. Os papéis adicionais aumentavam o consumo de tokens, mas não eliminavam a principal limitação: o agente precisava de mais tentativas independentes para concluir 110 jogos. Nas condições da competição, mais uma camada elegante de raciocínio era menos útil do que algumas trajetórias adicionais concluídas.

Esse é um bom teste para qualquer sistema agêntico. Se um novo esquema parece mais inteligente, mas não aumenta a proporção de tarefas concluídas com sucesso em um conjunto repetível, ele ainda não é uma melhoria, mas uma hipótese cara.

Como acomodar 110 trajetórias em uma única placa

A maior parte da memória da GPU era ocupada pelos pesos do modelo e seus 512 especialistas. Por isso, o estado das trajetórias de jogo foi transferido para a RAM, o cache KV foi comprimido para um formato de 4 bits e o número de especialistas disponíveis foi inicialmente reduzido para 400. Isso permitiu aumentar drasticamente o paralelismo.

O processamento em lote das mensagens recebidas trouxe outro ganho. Quando vários jogos devolvem novas observações ao modelo ao mesmo tempo, é mais eficiente processá-las em conjunto: a leitura do contexto de entrada é bem paralelizável, enquanto a geração da resposta continua avançando token por token. Um escalonador agrupava várias solicitações para esse processamento, reduzindo o número de execuções dispendiosas.

Também houve acelerações menores: ajuste fino do modelo de rascunho para o contexto do agente, eliminação do recálculo desnecessário do estado após o corte do contexto e transferência de determinadas operações do Triton para CUDA. Cada medida acrescentou apenas alguns pontos percentuais, mas, juntas, multiplicaram várias vezes a taxa de processamento.

O custo apareceu mais tarde. A versão que operava a 3.400 tokens por segundo às vezes obtinha menos pontos do que a mais lenta. O conjunto reduzido de especialistas e outras aproximações raramente alteravam o próximo token, mas pequenas divergências se acumulavam ao longo de uma trajetória de jogo extensa.

A velocidade é necessária até o ponto de saturação

A descoberta mais prática foi a troca de modo a quente. Durante as primeiras seis horas, o agente operava rapidamente com 400 especialistas e iniciava o máximo possível de trajetórias. Quando os jogos simples terminavam e restavam cerca de 70 difíceis, o sistema ativava todos os 512 especialistas e passava a uma geração de maior qualidade. Esse modo elevou o resultado de aproximadamente 50 para 54 pontos.

Depois de certo ponto, mais tokens quase não ajudavam. O agente concluía rapidamente os níveis simples e depois ficava preso nos difíceis: a diferença entre 600.000 e 900.000 tokens por jogo era pequena. Esse é o limite prático de ampliar as tentativas sem melhorar o próprio solucionador.

A conclusão para os desenvolvedores é simples: não meçam apenas tokens por segundo. São necessários pelo menos três gráficos: taxa de processamento, qualidade da solução e resultado em função do tempo. Primeiro, otimizem o número de tentativas úteis; depois, encontrem o ponto de saturação e recuperem a qualidade no trecho final. E sempre testem cada aceleração em trajetórias longas: um erro microscópico, imperceptível em uma única resposta, pode comprometer toda a tarefa.