Agentes de IA: latência derruba o modelo mais forte

Agentes sob o relógio: latência derruba o modelo mais forte

O arXiv (16/10) traz "The World Won't Wait: Evaluating and Teaching Agents Under a Live Clock" (2610.20665).

Contexto: agentes de LLM já resolvem tarefas interativas complexas, mas raciocinar e chamar ferramenta leva tempo. Num ambiente que muda continuamente, uma ação que seria correta pode simplesmente chegar tarde demais — e a maioria dos benchmarks avalia o agente com o mundo parado, esperando a resposta.

O que mudou: os autores apresentam o RealtimeBench, com 180 tarefas em seis tipos de jogo, para avaliar agentes enquanto o jogo segue rodando durante a inferência. Nas avaliações pareadas, o GPT-6.1-sol supera o Jev — o modelo mais rápido — quando os jogos estão pausados, mas fica atrás quando eles continuam rodando. O trabalho propõe o TORSI (Two-Timescale Offline Recursive Self-Improvement).

Por que importa: é a demonstração de que, em sistema ao vivo, latência vale tanto quanto acerto. Para quem roda agente em produção — e queima token com isso —, o modelo mais forte pode perder a janela de ação para um modelo mais rápido.

Feedback de correção apaga a evidência do bug (Verus/Rust)

O arXiv (16/10) publica "When Correctness Feedback Erases Evidence: Phase-Separated Completeness Auditing in Verus" (2610.20676).

Contexto: auditoria de completude de especificação existe para achar um tipo perigoso de programa: o que satisfaz o contrato escrito, mas viola o comportamento pretendido. A pista de que o contrato está errado fica justamente no descompasso entre o que o código faz e o que devia fazer.

O que mudou: o estudo mostra que o feedback de correção suprime justamente a evidência que essa auditoria procura. Em 12 tarefas Verus/Rust, com quatro famílias de modelo e orçamento de chamadas igualado, a descoberta independente sem feedback mais que dobra o rendimento de witness certificado frente ao loop de feedback corretivo do IntentShield: 59,0% contra 27,1%. Um controle iterativo com formato pareado indica que a maior parte dessa diferença está no conteúdo do feedback.

Por que importa: é um alerta para quem corrige código na conversa com o assistente. O loop de "corrigir até passar" pode estar apagando a pista de que o contrato em si está errado — o código passa no teste, mas faz a coisa errada.

llama.cpp b11678 limita buffer pinned CUDA a 4 GB

O release b11678 do llama.cpp (16/10) traz uma mudança única: "Limit max CUDA pinned host buffer size to 4 GB" (PR #30449), com o site llama.app como referência.

Contexto: o llama.cpp é o motor por trás de boa parte de quem roda modelo localmente, e o buffer pinned host é memória do host fixada para transferência rápida para a GPU.

O que mudou: a partir deste release, o tamanho máximo desse buffer CUDA fica limitado a 4 GB.

Por que importa: teto de buffer mexe no uso de memória do host e em como a carga de um modelo grande é dividida entre host e device. É o tipo de mudança de infraestrutura que quem faz inferência local acompanha de perto — e que, em máquina com CUDA, pode alterar o comportamento de sessões longas.

Benchmark saturado: a transcrição vira o novo dado

O arXiv (16/10) publica "Evaluating Model Capabilities After Benchmark Saturation" (2610.20667).

Contexto: benchmarks estão saturando. Quando vários modelos se aproximam de score perfeito, o benchmark perde o poder de diferenciá-los — e, com isso, a utilidade para informar casos de segurança e políticas de fronteira.

O que mudou: o trabalho lembra que os itens de benchmark produzem mais informação do que o score que costumamos extrair deles: a transcrição completa de como cada modelo resolveu a tarefa. A investigação é se essas transcrições servem para avaliar capacidades mesmo depois de o score saturar.

Por que importa: para quem acompanha modelo pelo placar de benchmark, a nota pode estar escondendo a saturação. A saída proposta é olhar o processo, não só o veredito — o mesmo recado da seção do Verus.

Status do TOKEN CLUB

Placar (16/10)

• 🥇 Kogu — 3.940.488.420 tokens
• 🥈 Xepa — 3.035.251.037
• 🥉 JOAO_AMORIM — 2.694.799.519
• 4º Tetz — 302.210.242

Placar congelado desde 03/10 (sábado). Kogu mantém 905.237.383 tokens de folga sobre Xepa, e Xepa segue 340.451.518 à frente de JOAO_AMORIM — a briga real continua sendo o 2º/3º lugar. Do 3º para o 4º, o abismo de sempre: 2.392.589.277 tokens, com Tetz 8,9x atrás do JOAO_AMORIM. O clube tem 38 jogadores e só 4 pontuam.

Índice

• Hoje (16/10): SEM DADO — nenhuma máquina reportou ainda (o número é parcial e só sobe).
• Base: 5.666.075,5 tokens/dia (média de 14 dias).
• 01/10: 715.408.605 tokens (~126x a base).
• 02/10: 201.585.277 tokens (~36x a base).
• Pico dos últimos 90 dias: 28/08, com 1.287.167.152 tokens.

A arrancada de 916.993.882 tokens em dois dias (01+02/10) segue sem explicação nas notícias — e, desde 03/10, o índice está mudo. Ressalva honesta: a amostra é de 38 jogadores, e um deles virando a noite move o índice inteiro. Placar parado e índice em silêncio mantêm a pauta aberta: ou houve uma maratona não contada, ou o mundo da IA viu algo que ainda não apareceu no feed.