Meu Agente de IA Construiu uma Ferramenta de Benchmark para Meus Agentes de IA

Meu agente de programação Hermes escreveu uma ferramenta de benchmark. Ela testa a velocidade, a inteligência e a aptidão para agente dos meus modelos locais — os mesmos modelos sobre os quais outros agentes de IA rodam — e gera JSON e uma tabela no terminal. A ferramenta tem 1.660 linhas de Python e se chama bench-llm — um agente de IA construiu uma ferramenta de benchmark para agentes de IA.

Com o que você fica

Um único comando contra um modelo gera este formato de saída no seu terminal (execução de exemplo):

$ bench-llm gemma-4-31b-it

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     ~/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

Ele também grava um payload JSON completo em ~/benchmarks/ com todas as medições brutas, cada resposta de teste e um resumo estruturado — para você poder realimentar os resultados no seu agente e perguntar "quais dos meus modelos deveriam cuidar do trabalho pesado com JSON?".

O que ele testa

Três dimensões, cada uma escolhida porque importa para uma pilha de agentes sempre ligada.

⚡ Velocidade

Três tamanhos de prompt — curto (~50 caracteres, "explique o que é uma variável"), médio (~200 caracteres, "explique recursão") e longo (~800 caracteres, "compare três paradigmas de programação") — com três execuções de aquecimento seguidas das medições reais.

O que é medido:

• TTFT (Time To First Token) — quanto tempo até o modelo começar a digitar. Crítico para a UX de chat; qualquer coisa acima de 500ms parece lento.
• Throughput (tokens/seg) — a rapidez com que ele gera depois de começar. Importa para blocos de código longos e relatórios.
• T/s de prefill — a rapidez com que ele processa o prompt de entrada antes de gerar. Um custo oculto, mas real.

Ele também roda uma verificação de plausibilidade contra limites de hardware conhecidos. Se o seu modelo de 30 GB afirma 200 T/s em uma 7900 XTX, o bench-llm sinaliza — esse número provavelmente está contaminado por decodificação especulativa ou cache pré-aquecido.

🧠 Capacidade

Cinco testes que são triviais para um modelo competente e um delator definitivo para um que está sofrendo:

• Geração de código — Escreva median_of_list(numbers) com casos de borda (lista vazia, comprimento par, comprimento ímpar, não mutar a entrada). A função é executada dentro do bench-llm contra seis casos de teste — não é correspondência de padrões contra o texto da resposta, é código realmente rodando.
• Quebra-cabeça lógico — Um quebra-cabeça de posse de quatro animais de estimação (Alice/peixe, Bob/pássaro, Carol/gato, Dan/cachorro). Uma regex extrai as atribuições da resposta e verifica as quatro.
• Conformidade com JSON — "Retorne um objeto JSON com exatamente estas chaves." Testa se o modelo consegue produzir JSON válido e conforme ao esquema sob demanda — o mínimo absoluto para chamada de ferramentas.
• Seguir instruções — Escreva os números de 1 a 10, marque os pares com *, some-os. Testa adesão precisa a formato: a resposta é trivial, o formato é o ponto principal.
• Sumarização — Um parágrafo denso sobre computação quântica baseada em hélio. Verifica se seis fatos técnicos importantes sobreviveram à compressão. A maioria dos modelos perde pelo menos um.

🤖 Aptidão para agente

É aqui que o bench-llm faz algo que não vi em outras ferramentas de benchmark. Ele envia ao modelo uma tarefa de agente real — buscar linhas ERROR no syslog, agrupar por serviço, produzir um relatório JSON — e avalia a resposta como um supervisor de agentes avaliaria:

• Reconhecimento de tarefas — O modelo entende o que foi pedido? Ele consegue esboçar uma abordagem e identificar bloqueios? (Um modelo que sai alucinando entradas de syslog falha aqui.)
• Adesão a formato — A saída corresponde ao esquema JSON solicitado? Verifica o array services, o inteiro total_errors e a string scan_period.
• Concisão — Qual é a proporção saída/entrada? Modelos que respondem a um prompt de 1.300 caracteres com 20.000 caracteres de divagação são sinalizados como VERBOSE. Um agente que não consegue ser conciso queima sua janela de contexto a cada turno.

Os três testes de aptidão para agente compartilham o mesmo prompt — eles avaliam aspectos diferentes da mesma resposta. Isso mantém o benchmark rápido enquanto mede as qualidades que importam quando um modelo roda sem supervisão.

Como foi construído

O Hermes — o agente de programação da minha máquina — escreveu tudo. Eu dei uma especificação aproximada: "Preciso de uma ferramenta que avalie modelos locais no LM Studio, teste velocidade e inteligência, e gere JSON e uma tabela." Ele foi, voltou com um script funcional, e iteramos.

O processo foi:

1. Primeira versão: apenas testes de velocidade — conectar à API compatível com OpenAI do LM Studio, fazer streaming de tokens, medir TTFT e T/s.
2. Segunda versão: testes de capacidade — codificação (com execução real), quebra-cabeças lógicos, conformidade com esquema JSON, seguir instruções, sumarização.
3. Terceira versão: aptidão para agente — a tarefa de syslog, avaliação da resposta como se o modelo fosse um agente da minha pilha.
4. Passadas de polimento: resolução de arquivos GGUF (encontrar o arquivo real do modelo no disco, reportar tamanho e quantização), validação de plausibilidade de velocidade, a tabela-resumo, o modo --quick, o --list para descoberta de modelos e o comando de pré-verificação --check.

Todas as quatro iterações aconteceram em uma única tarde. O script final tem 1.660 linhas. Cada linha foi escrita pelo Hermes — eu revisei, testei em modelos reais, apontei problemas ("esse número de throughput não pode estar certo para um modelo de 123B"), e ele corrigiu. O validador de plausibilidade nasceu exatamente desse tipo de ciclo de feedback.

Decisões de design que ficaram

• Streaming, não polling. O bench-llm usa streaming compatível com OpenAI para obter o timing por token. Uma abordagem de polling borraria a medição de TTFT e perderia a granularidade no nível do token.
• Execução real de código no teste de codificação. Ele não pergunta "isso parece uma função de mediana?" — ele faz exec() do código em um namespace novo e roda seis casos de teste; saída que parece confiante mas não roda, falha.
• Extração de respostas com regex para os testes de lógica/JSON. Benchmarks que exigem formato preciso falham duramente com modelos que acrescentam "Claro! Aqui está sua resposta:" antes da saída real. Os verificadores do bench-llm extraem o payload de qualquer invólucro que o modelo coloque ao redor — testando o conteúdo do modelo, não sua verbosidade.
• Limpeza de VRAM entre benchmarks. Ele executa pkill -f llama-server e espera o LM Studio mostrar zero modelos carregados antes de cada execução. Sem isso, o cache KV de um modelo anterior pode contaminar a medição de TTFT do benchmark seguinte.
• Resolução de arquivos GGUF. Ele mapeia os IDs de modelo do LM Studio de volta aos arquivos GGUF reais no disco usando correspondência difusa por nome do publicador e arquitetura. Isso dá o tamanho do modelo, a quantização e se o arquivo sequer existe — respondendo "este modelo está realmente pronto para benchmark?" antes de desperdiçar uma execução.

Configuração

Três passos:

# 1. Install the two dependencies (requests talks to LM Studio's model-metadata
#    endpoint — without it every model shows as "not found")
pip install openai requests

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

# 3. Run it
./bench-llm --list                         # see what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

Sem arquivos de configuração, sem chaves de API (o LM Studio aceita qualquer string), sem banco de dados. Os resultados caem em ~/benchmarks/.

Opcional, mas útil: copie o bench-llm para o seu PATH para poder rodá-lo de qualquer lugar.

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

Resultados reais: modelos base na minha máquina e no meu notebook

Os números abaixo vêm das suítes sucessoras (mesmo método de velocidade, conjunto de testes mais amplo) e cobrem apenas modelos base — sem fine-tunes da comunidade. "Máquina" é um box GPU headless, 2× RTX 5090 + 2× RTX 3090; "APU" é a GPU integrada deste notebook. Velocidade só é comparável dentro de um mesmo dispositivo. A ressalva das próprias suítes se aplica: as transcrições abrangem algumas revisões, então leia pequenas diferenças como ruído.

Velocidade + aptidão para agente (suíte bench, relatório de 2026-08-18 — Code / Tools / Instruct / Reason são taxas de aprovação):

Nível difícil (Gauntlet, 2026-08-19 — taxa de aprovação sobre os casos só-difíceis; "—" = categoria não executada para aquele modelo):

O que eu tiro disso: o MoE Gemma 4 26B (4B ativos) é o cavalo de batalha diário da máquina — 229 T/s, TTFT de 110ms, chamadas de ferramenta perfeitas — e sua coluna fraca é seguir instruções, que é exatamente no que um loop de agente não supervisionado se apoia. O Nemotron de 4B é a surpresa: em uma APU de notebook ele segue instruções melhor do que o 26B na máquina, só que cinco vezes mais devagar (18.5 T/s na APU vs 229 na máquina). No nível difícil, o Qwen3.8 27B base chega a 74% em codificação, as linhas de 1.5B e 256M mostram como é "pequeno demais para trabalho de agente", e a linha do V4-Flash na nuvem é o teto que os modelos locais perseguem — a $0.088 por toda a execução difícil.

O que o torna diferente

Existem muitos benchmarks de LLM. A maioria são conjuntos de quebra-cabeças acadêmicos (MMLU) ou trivia otimizada para leaderboards. O bench-llm faz três coisas que importam para alguém que realmente executa modelos locais:

1. Testa qualidades de agente, não qualidades de chatbot. Adesão a formato, reconhecimento de tarefas e concisão são o que faz ou quebra um modelo em um loop de agente não supervisionado. Um modelo ótimo em conversa, mas incapaz de seguir um esquema JSON, é inútil em um fluxo de trabalho de chamada de ferramentas.
2. Valida as próprias medições. O verificador de plausibilidade detecta números que não podem estar certos — contaminação por decodificação especulativa, caches pré-aquecidos, bugs de medição. Se uma ferramenta de benchmark não consegue te dizer quando a própria saída é lixo, você não pode confiar em nada dela.
3. É um único script. Sem Docker, sem banco de dados, sem dependências de driver de GPU, sem download de dataset de 50 GB. Um arquivo Python, um pip install, e funciona contra o que você tiver carregado no LM Studio agora.

Armadilhas

• O LM Studio precisa estar rodando primeiro. O bench-llm não inicia o LM Studio para você — ele se conecta a localhost:1234. Se não houver nada escutando, ele falha com um erro claro.
• A limpeza de VRAM é agressiva. Ele executa pkill llama-server entre os benchmarks para limpar o cache KV. Se você tem outros processos llama-server que quer manter vivos, não rode o bench-llm — ou modifique o passo de limpeza.
• A sumarização é o teste mais difícil. Quase todo modelo que testei perde pelo menos um fato importante. Se um modelo marca 4/5 com a sumarização como única falha, esse é um resultado forte — não leia como deficiência.
• Modelos de raciocínio têm TTFT mais lento. Modelos pensantes gastam tempo em uma fase de raciocínio antes de produzir saída. O bench-llm mede o TTFT a partir do primeiro token de qualquer tipo — incluindo tokens de raciocínio. Isso faz os modelos de raciocínio parecerem mais lentos do que parecem na prática, porque os tokens de pensamento fluem durante o que de outra forma seria tempo morto. A saída JSON separa o TTFT em ttft_reasoning_s e ttft_content_s para você ver a divisão.
• O teste de codificação faz exec() da saída do modelo. Ele roda em um namespace novo com funções de teste puras — não é um sandbox real, então execute como um usuário que não tem nada a perder — mas se a ideia de rodar código gerado por LLM te incomoda, pule os testes de capacidade com --speed-only.
• Muitos modelos demoram. Um benchmark completo em um modelo leva de 2 a 5 minutos dependendo da velocidade; algumas dúzias é uma noite inteira. Use --quick para comparações e guarde a suíte completa para seus principais candidatos.

Download

O bench-llm é um único script Python mais um README. Sem etapa de build, sem assistente de instalação — descompacte e rode.

O zip inclui:

• bench-llm — o script de benchmark de 1.660 linhas
• README.md — instruções condensadas de configuração e uso

Os dois arquivos foram escritos pelo Hermes, meu agente de programação. Licença MIT — use, modifique, envie no seu próprio toolchain. Dependências: openai e requests.

Relacionados: Quanto Meus Agentes de IA Realmente Custam (por que a velocidade local importa), Reasonix e DeepSeek Harness (os agentes de programação que esses modelos sustentam), e a stack local de agentes em que rodam.

Downloads

• Baixar bench-llm (zip) 18 KB

Gratuito para uso pessoal. Se isso te economizar uma tarde, o botão do café está logo ali.