Apple testa IA que otimiza a própria inferência: 26,7%

Inferência de LLM ainda é onde a conta estoura e o projeto trava. Você valida um modelo no notebook, coloca em produção com vLLM ou SGLang, e de repente a latência dobra, o throughput despenca e o custo por milhão de tokens vira uma conversa difícil com o financeiro. É exatamente nesse ponto que a Apple decidiu cutucar. O novo RSI-Inference Bench não pergunta se o agente escreve um código bonito, pergunta se ele consegue mexer na máquina que roda a IA e deixar ela mais rápida, mais barata e sem quebrar. E a resposta inicial incomoda, porque nem os melhores agentes chegam perto de resolver o problema sozinhos.

O fato sem rodeio

A Apple ML Research lançou o RSI-Inference Bench, um benchmark criado para avaliar agentes capazes de melhorar a própria infraestrutura de inferência. A ideia central é simples de entender e difícil de executar: colocar um agente para trabalhar como um engenheiro de inferência faria no dia a dia. O escopo cobre tarefas reais extraídas do ecossistema de vLLM e SGLang, os dois stacks mais usados por quem roda modelos abertos em produção hoje. Para construir isso, a Apple afirma ter investido algo na casa de 100 mil dólares em tokens de API e 50 mil horas de GPU, um volume que já diz muito sobre a complexidade de testar esse tipo de tarefa de forma séria.

O benchmark foi organizado em três frentes que espelham o ciclo de vida real de quem opera inferência. A primeira é suporte a modelo no dia zero, aquele momento em que um modelo novo sai e precisa rodar com performance decente imediatamente. A segunda é otimização de inferência, que envolve batching, gerenciamento de KV cache, paralelismo, quantização e ajustes de scheduler. A terceira é correção de bugs, quando uma atualização quebra compatibilidade, gera erro de memória ou derruba o throughput sem motivo aparente. O resultado mais comentado até agora é que o melhor agente atinge apenas 26,7 por cento de pass at 1, ou seja, acerta de primeira pouco mais de uma em cada quatro tarefas. Para um benchmark que se propõe a medir auto melhoria recursiva, esse número baixo é na verdade o sinal mais importante.

Como funciona na visão de quem opera

Na prática, o RSI-Inference funciona como um ambiente verificável para engenharia de sistemas, não como um teste de perguntas e respostas. O agente recebe uma tarefa com código, configuração e objetivo mensurável, como reduzir latência p99, aumentar tokens por segundo por GPU ou fazer um modelo novo rodar sem erro em um backend específico. Ele pode editar código, mudar flags de execução, reescrever kernels ou ajustar o serving, e depois é avaliado com recompensas verificáveis, binárias e contínuas. A recompensa binária indica se passou ou falhou, como um teste de integração. A recompensa contínua mede o quanto melhorou, por exemplo uma redução de 18 por cento na latência ou um aumento de 1,3 vez no throughput. Essa combinação é relevante porque reflete como avaliamos trabalho de infraestrutura no mundo real, onde não basta funcionar, precisa funcionar melhor dentro de um orçamento de custo e latência.

Pensando em arquitetura, o que está em jogo aqui é a camada entre o modelo e o hardware. Quem já operou vLLM sabe que performance depende de dezenas de decisões acopladas. Tamanho de bloco do paged attention, política de preempção, chunked prefill, tensor parallel contra pipeline parallel, escolha de kernel de atenção para cada GPU, e por aí vai. No SGLang a lógica é parecida, com o agravante do gerenciamento de programas e cache de prefixo que pode ajudar muito ou atrapalhar muito dependendo do padrão de tráfego. Um agente precisa entender esses tradeoffs sem apenas chutar hiperparâmetros. Minha inferência técnica, e aqui é leitura plausível e não afirmação oficial, é que a Apple montou containers com GPUs reais, scripts de reprodução e travas para evitar otimizações trapaceiras, como reduzir precisão sem permissão ou cortar casos de teste para inflar throughput.

O custo desse tipo de avaliação também explica por que pouca gente tinha feito isso antes. Cinquenta mil horas de GPU não é um número de marketing, é o preço de medir inferência de verdade. Cada tentativa do agente precisa subir servidor, aquecer modelo, rodar carga sintética, coletar métricas de latência e repetir para reduzir ruído. Se você multiplicar isso por centenas de tarefas e dezenas de tentativas por modelo avaliado, a conta explode rápido. Isso também levanta um ponto operacional importante. Avaliar agentes de infraestrutura custa quase tanto quanto operar a infraestrutura. Então qualquer pipeline de auto otimização vai precisar de um harness barato para iteração rápida e um harness caro para validação final, caso contrário o custo de otimizar supera a economia gerada pela otimização.

O que isso muda na prática

Para quem roda LLM em produção, o recado é duplo. Primeiro, agentes ainda não substituem o engenheiro de inferência, mas já servem como um primeiro par de mãos para tarefas repetitivas. Suporte a dia zero é o exemplo mais claro. Quando sai uma variante nova de modelo com arquitetura levemente diferente, boa parte do trabalho é adaptar tokenizador, corrigir configuração de atenção, ajustarrope scaling e fazer o modelo ao menos carregar e responder. Um agente que resolve 26 por cento disso de primeira já economiza horas de trabalho manual, desde que tenha guardrails. Segundo, otimização profunda continua sendo artesanal. Ganhar 30 por cento de throughput mexendo em scheduler e kernels exige entender o perfil de carga, e os dados sugerem que os agentes atuais ainda se perdem quando o espaço de busca cresce.

• Quem ganha agora: times que operam vLLM e SGLang em escala e já têm pipelines de benchmark próprios, porque podem acoplar agentes para gerar candidatos de configuração e validar com métricas reais.
• Quem perde se ignorar: quem ainda otimiza no achismo, mudando batch size na mão e reiniciando pod para ver se melhora, porque esse fluxo vai ser engolido por automação assistida.
• O que ajustar hoje: versione suas configs de serving como código, com teste de carga repetível, senão nenhum agente vai conseguir ajudar você de forma confiável.

A ação prática mais direta é montar um mini RSI interno, mesmo que simples. Escolha três cargas representativas do seu produto, uma com prompt curto e resposta longa, outra com contexto longo e uma terceira com muitas requisições concorrentes pequenas. Congele essas cargas, defina métricas de latência p50 e p99, throughput e custo por milhão de tokens, e rode o mesmo teste toda vez que mudar modelo, GPU ou versão do servidor de inferência. Com isso você cria a base que falta na maioria das empresas: recompensa verificável. Depois, coloque um agente de coding para propor mudanças apenas nesse ambiente isolado, sem acesso à produção. Mande ele tentar cinco otimizações por semana. Você vai se surpreender com quantas ideias ruins ele gera e com uma ou duas ideias boas que seu time não tinha tempo de testar.

A tensão que importa

O ponto que me deixa pensativo é o seguinte: 26,7 por cento é baixo, mas 50 mil horas de GPU para provar isso é alto. Isso escala? Se avaliar um agente custa tão caro, treinar um agente para ser bom nisso vai custar ordens de magnitude a mais, porque exige loop de tentativa e erro em hardware real. E existe um paradoxo operacional aqui. A promessa da auto melhoria recursiva é que a IA barateie a IA, mas o caminho até lá encarece a IA primeiro. Para a Apple, que tem caixa e interesse estratégico em inferência eficiente nos seus chips e servidores, a conta fecha como pesquisa. Para uma startup que gasta 20 mil dólares por mês em GPUs, tentar replicar esse loop do zero não fecha. O ganho precisa aparecer em semanas, não em papers.

Também fico com a dúvida sobre generalização. Otimizar vLLM para uma A100 com um padrão de tráfego específico não garante nada em uma H100 com outro padrão. Muito do que parece inteligência do agente pode ser apenas overfitting a um harness. E tem o risco clássico de otimização que quebra robustez, como um kernel mais rápido que falha em um caso raro ou uma quantização que derruba qualidade em português mas passa nos testes em inglês. O benchmark tenta mitigar isso com recompensas contínuas e testes, mas na produção real o teste que importa é o usuário reclamando no suporte. Então a pergunta não é só se o agente melhora o número, é se ele melhora o número sem mover o gargalo para outro lugar, como trocar latência menor por uso de memória maior que estoura sob pico.

Conclusão

O RSI-Inference Bench é importante porque tira a discussão sobre agentes do campo das demos e joga para onde dói: custo, latência e estabilidade de quem roda modelo de verdade. Com 26,7 por cento de acerto, ele mostra que estamos longe de agentes que se auto otimizam sozinhos, mas perto o suficiente para usar esses agentes como assistentes dentro de um processo bem medido. A questão que fica para você que opera inferência é simples: se um agente tentasse otimizar seu serving hoje, você teria como provar se ele melhorou ou só mudou o problema de lugar?