Meu Agente de IA Criou uma Ferramenta de Benchmarking para os Meus Agentes de IA

Em 11 de agosto de 2026, pedi ao meu agente de programação uma ferramenta que fizesse o benchmarking dos modelos locais no meu stack de agentes. Ele retornou com o bench-llm: 1.660 linhas de código Python que medem a velocidade de execução no LM Studio, executam o código gerado pelo modelo e verificam se este consegue realizar uma pequena tarefa de agente. Em duas semanas, todos os modelos que eu considerava importantes obtiveram nota 5/5 nesse teste; por isso, reconstruí a ferramenta como CrucibleForge: agora possui 251 casos de teste, sendo 158 deles considerados difíceis. O código está disponível como software livre no GitHub. Esta página descreve ambas as ferramentas. Use o bench-llm para obter um primeiro resultado do modelo em apenas cinco minutos; use o CrucibleForge quando precisar classificar modelos que já tenham passado nos testes mais fáceis.

O que você obtém no final

Um único comando executado contra um modelo gera o seguinte resultado (exemplo de execução, resumido):

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

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

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

O arquivo JSON contém todos os tempos de processamento brutos, todas as respostas do modelo e um resumo. Você pode repassá-lo ao seu agente e perguntar: “Qual dos meus modelos deve lidar com o processamento em massa de dados no formato JSON?”

O que os testes do bench-llm avaliam

Velocidade

O sistema envia três comprimentos de prompt (cerca de 50, 200 e 800 caracteres), realiza rodadas de aquecimento e, em seguida, mede três aspectos. O TTFT (tempo até o primeiro token) indica quanto tempo você espera para que o texto apareça; valores acima de 500 ms são considerados lentos em um chat. O Throughput (tokens/segundo) mostra a velocidade com que o modelo começa a gerar texto após o início do processo. Já o Prefill T/s mede a rapidez com que o modelo lê o seu prompt.

Também é feita uma verificação de plausibilidade em relação aos limites de hardware conhecidos. Se um modelo de 30 GB afirmar alcançar 200 T/s numa placa 7900 XTX, o bench-llm sinaliza esse valor como suspeito, pois é provável que a decodificação especulativa ou um cache já aquecido tenham distorcido os resultados.

Habilidade

• Geração de código: escreva median_of_list(numbers) garantindo que todos os casos extremos sejam tratados. O bench-llm executa a função com base em seis casos de teste, em vez de apenas analisar o texto.
• Quebra-cabeça lógico: um enigma envolvendo quatro pessoas e seus animais de estimação. O verificador extrai todas as quatro atribuições do texto de resposta.
• Conformidade com JSON: retorne um objeto contendo chaves exatas. Esse é o mínimo exigido para que um modelo possa ser usado em chamadas de ferramentas.
• Seguimento de instruções: liste os números de 1 a 10, marque os pares e some-os. A matemática é simples; o importante é o formato da resposta.
• Resumo de texto: condense um parágrafo complexo mantendo seis informações específicas. A maioria dos modelos acaba omitindo pelo menos uma delas.

Aptidão para atuação como agente

O modelo recebe uma tarefa realista de agente: procurar no syslog por linhas contendo “ERROR”, agrupá-las por serviço e retornar um relatório em JSON. Três verificações avaliam essa única resposta:

• Acknowledgment da tarefa: o modelo descreve uma abordagem e aponta o que não consegue fazer? Um modelo que inventa linhas de syslog é reprovado.
• Conformidade com formato: há um array services, um inteiro total_errors e uma string scan_period na resposta?
• Concisão: relação entre o tamanho da saída e do input. Uma resposta com 20.000 caracteres para um prompt de 1.300 caracteres é classificada como “VERBOSE”, pois um agente que fala demais consome rapidamente a janela de contexto a cada interação.

Como foi construído

Minha instrução para o agente de codificação foi uma única frase: “Preciso de uma ferramenta que faça benchmark de modelos locais no LM Studio, testando sua velocidade e capacidades, e gerando saídas em formato JSON e tabelas.” Ele criou a ferramenta em quatro etapas, numa única tarde: testes de velocidade utilizando a API de streaming compatível com OpenAI do LM Studio; depois, testes de capacidades do modelo; em seguida, implementação das funcionalidades solicitadas; e por fim, ajustes finais (como localizar o arquivo GGUF no disco, realizar a verificação de plausibilidade, além dos parâmetros --quick, --list e --check). O agente escreveu cada linha de código. Minha parte foi executar a ferramenta em modelos reais e fornecer feedback. A verificação de plausibilidade existe porque eu informei ao agente que um determinado valor de throughput era impossível para um modelo de 123 bilhões de parâmetros.

Escolhas de design que valem a pena copiar para suas próprias ferramentas:

• Use streaming, não polling. A medição do tempo por token é a única forma de obter um TTFT preciso.
• Execute o código. Código que parece correto, mas não roda, deve ser considerado um fracasso, não um sucesso.
• Extraia a resposta antes de validá-la. Os verificadores removem os textos introdutórios como “Claro! Aqui está sua resposta:”. Dessa forma, o teste avalia apenas o conteúdo, e não o preâmbulo.
• Inicie cada execução com uma GPU vazia. Caso contrário, o cache do modelo anterior distorce os resultados do TTFT. O modo como o bench-llm faz isso é o primeiro “problema” a ser observado abaixo.

Configuração

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

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

Não há arquivos de configuração nem banco de dados. O LM Studio aceita qualquer string como chave de API. Os resultados são salvos em ~/benchmarks/. Copie o script para uma pasta que esteja no seu PATH se quiser executá-lo de qualquer lugar.

Armadilhas

• O script encerra o llama-server. Para iniciar uma nova execução, ele executa pkill -f llama-server e aguarda até que o LM Studio informe que não há modelos carregados. Qualquer outro processo llama-server na máquina também é encerrado. Não execute este script em uma máquina que hospede outros serviços, ou remova essa etapa.
• O teste de codificação executa a saída do modelo usando exec(). Ele utiliza um namespace novo, que não é uma “sandbox”. Execute-o como um usuário sem nada a perder, ou pule os testes de capacidade com --speed-only.
• Os modelos de raciocínio parecem lentos. O TTFT conta o primeiro token gerado, incluindo os tokens de pensamento. O JSON separa esse valor em ttft_reasoning_s e ttft_content_s.
• Uma nota 4/5, com apenas o teste de resumo falhando, é um resultado excelente. Quase todos os modelos deixam de incluir pelo menos um fato na resposta.
• Uma execução completa leva de 2 a 5 minutos por modelo. Use --quick para comparar vários modelos, e execute o conjunto completo apenas nos finalistas.
• O LM Studio deve já estar em execução. O bench-llm se conecta ao localhost:1234, mas não inicia nada por conta própria.

Resultados: modelos base no meu rig e no mini PC

Esses números vêm do conjunto de testes intermediário que sucedeu o bench-llm (mesmo método de medição de velocidade, mais testes; relatório de 18/08/2026). “Rig” é um servidor GPU sem monitor, equipado com 2× RTX 5090 e 2× RTX 3090. “APU” refere-se à GPU integrada do mini PC (quando ainda rodava um servidor de modelos locais). Compare as velocidades apenas dentro de cada dispositivo. Code, Tools, Instruct e Reason representam as taxas de sucesso nos testes.

O modelo Gemma 4 26B do tipo “mixture-of-experts” (com 4B de parâmetros ativos) é o principal modelo utilizado no rig: gera 229 T/s, demora 110 ms para produzir o primeiro token e possui uma taxa de sucesso perfeita na execução de tarefas de ferramentas. Sua fraqueza está no seguimento de instruções, algo essencial para um loop de agente não supervisionado. O modelo Nemotron 3 Nano 4B, no mini PC, segue melhor as instruções (94% contra 50%). Porém, é cerca de doze vezes mais lento (18,5 vs 229 T/s) e roda em um dispositivo diferente. Escolha o modelo com base na coluna que reflete melhor suas necessidades de trabalho, e não apenas no número de velocidade mais alto.

O que o substituiu: CrucibleForge

O bench-llm “morreu de sucesso”. Cinco testes de avaliação resultam em um bom detector de falhas, mas em uma classificação pobre: quando todos os modelos obtêm pontuação máxima, a ferramenta não tem mais nada a dizer. O CrucibleForge é a reescrita do sistema. Ele conta com cerca de 9.400 linhas de código Python; sua regra fundamental é que uma pergunta difícil deve ser fácil de avaliar.

• 158 casos difíceis. Problemas matemáticos com respostas inteiras, quebra-cabeças lógicos de solução única e desafios de programação cujos testes exigem complexidade adequada (um algoritmo de contagem de inversões O(n²) acaba por expirar). Há também situações envolvendo uso indevido de ferramentas, injeção de prompts, recuperação de contexto em textos longos (12k–24k tokens) e instruções com múltiplas restrições.
• O código é avaliado por meio da sua execução num ambiente bwrap sem rede, com sistema em modo somente leitura e limite de 15 segundos. Para ser aprovado, o programa deve exibir uma string específica no stdout; assim, não é possível falsificar sucesso ao encerrar com código zero. Sem bwrap (o que ocorre sempre no macOS e Windows), a execução do código do modelo só é permitida se você usar o parâmetro --allow-unsandboxed.
• As respostas em prosa têm uma resposta de referência. O modelo avaliador conhece a resposta correta e decide apenas se a resposta fornecida tem o mesmo significado. Qualquer modelo capaz de seguir instruções consegue realizar essa tarefa; assim, o avaliador deixa de ser o ponto fraco do sistema.
• Qualquer endpoint compatível com OpenAI. LM Studio, Ollama, llama.cpp, vLLM, DeepSeek, OpenRouter e outros. Os modelos hospedados processam os casos simultaneamente e informam o custo em tokens. As chaves de API são obtidas exclusivamente por meio de variáveis de ambiente.
• O sistema recupera respostas que os modelos racionais perdem. Um modelo que utiliza todo o seu orçamento de tokens para “pensar” acaba retornando uma resposta vazia. O CrucibleForge detecta isso, repete o teste sem ativar o modo de raciocínio e conta quantas vezes isso ocorre. O comando recover reexecuta apenas esses casos de uma execução anterior.
• O sistema compartilha GPUs de forma justa. No meu equipamento StudioForge, cada execução “aluga” as placas de vídeo necessárias e devolve-as após o término. O bench-llm utilizava o comando pkill para resolver o mesmo problema, mas matando todos os modelos em execução.
• Há uma interface web disponível em 127.0.0.1:8777 que permite selecionar modelos e categorias, visualizar o log e abrir qualquer caso com falha: prompt, resposta, raciocínio do modelo e nota do avaliador. É necessário um token para que a interface aceite conexões fora do loopback.

Experimente

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

O perfil standard contém 56 casos selecionados de forma a serem processados em menos de uma hora por um modelo de 27 bilhões de parâmetros, com taxa de geração de aproximadamente 70 tokens/segundo, incluindo a avaliação. Trata-se de uma execução que vale a pena repetir. O perfil também está dividido em duas partes: coding não requer avaliação por modelo; já chat contém os casos que precisam de avaliação. Os demais comandos disponíveis são run, judge, recover, report, pairwise, models, import-openclaw e cases.

O comando em que mais confio é o que verifica as próprias questões. Ele executa todas as soluções de referência na sandbox, recalcula todas as respostas matemáticas por métodos exaustivos e reconstrói todos os “montes de texto” usados nos testes de contexto longo. Esta é a saída obtida em 16/09/2026:

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

O conjunto de testes (335 testes) realiza a mesma verificação; assim, uma questão mal formulada não pode passar despercebida para todos os modelos, mesmo nos níveis mais difíceis.

Como é um relatório

O comando report gera um arquivo Markdown e um JSON. Cada modelo recebe uma linha de resumo e uma linha por categoria, contendo as contagens brutas. A seguir, a linha referente ao DeepSeek V4 Pro:

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

Cada falha é listada com seu motivo. Todas as sete falhas de programação do modelo são semelhantes à primeira linha abaixo; a segunda linha corresponde a um dos dois casos em que o modelo não soube utilizar corretamente as ferramentas disponíveis:

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

Essa é a parte útil do relatório. O modelo não escreveu código ruim; ele “pensou” até esgotar o limite de 32.768 tokens e acabou não gerando nada. Um orçamento maior ou um esforço de raciocínio menor alterariam esse resultado. A simples taxa de aprovação não revelaria isso.

Resultados de nível difícil

Estes são os resultados dos testes completos: todos os 251 casos, ou quase todos. A porcentagem “Hard %” representa a taxa de acerto nos casos considerados difíceis (143 de um total de 154; os outros quatro foram avaliados separadamente). As colunas “Code”, “Math” e “Tools” indicam as taxas de acerto em todos os casos pertencentes a essas categorias. Excluí as linhas referentes aos testes com apenas 56 casos, pois eles cobrem apenas 38 casos difíceis e não são comparáveis. Também omiti as pontuações relativas a role-play e conteúdo adulto presentes no relatório completo, pois não são relevantes para o trabalho com agentes de IA.

Os nomes em letras minúsculas referem-se a versões modificadas ou ajustadas pela comunidade, listadas conforme seus rótulos oficiais. As linhas sem marcação foram processadas novamente em 16/09/2026 a partir dos arquivos de execução salvos. Os testes abrangem diversas revisões do conjunto de casos; portanto, pequenas variações nas porcentagens podem ser consideradas ruído. ¹ Dados extraídos do relatório de 25/08/2026. Testes posteriores com apenas 56 casos substituíram os resultados completos desses modelos. Uma versão anterior desta página indicava que o V4 Flash alcançou 272/308 pontos: na verdade, dois testes completos foram contabilizados sob um único rótulo; o valor de $0,331 acima corresponde a apenas um desses testes. ² O MiniMax M3 é um modelo hospedado pela MiniMax. Um caso não foi pontuado, e o custo informado é estimativo: uso um plano com taxa fixa, e o valor considera a taxa padrão definida no meu arquivo de registro ($0,255/$1,02 por milhão de tokens de entrada/saída). Segundo os preços oficiais da MiniMax ($0,60/$2,40), o custo seria cerca de 2,4× maior; com a promoção atual de desconto, seria aproximadamente 1,2×. ³ Esses modelos executaram testes em 140 dos 154 casos difíceis; os demais exigiam mais contexto do que eles conseguiam processar.

Minhas conclusões:

• O modelo hospedado líder custa cerca de um dólar por execução. O V4 Pro acertou 143 dos 154 casos difíceis, por apenas $1,10. É um preço baixo o suficiente para permitir novas execuções sempre que os resultados locais parecerem muito bons.
• Um modelo de 27 bilhões de parâmetros rodando localmente também se sai bem. O Qwen3.8 27B acertou 135 casos, ficando apenas dois pontos atrás do V4 Flash e sendo 1,7× mais rápido na geração de respostas.
• A velocidade não é indicador de capacidade. O MiniMax M3 é o modelo hospedado mais rápido, gerando 212 tokens por segundo, mas atingiu apenas 85% de acerto; sua pontuação em matemática foi a mais baixa (77%). O joyfox-35b-rp gera 319 tokens/s e alcança 75% de acerto.
• Modificar um modelo pode prejudicar seu desempenho em programação. O Qwen3.8 27B após modificações atingiu apenas 62% de acerto em tarefas de programação, contra 85% na versão original.
• A capacidade de processar contextos longos por si só não garante bom desempenho. Mesmo com a capacidade de lidar com contextos extensos, os modelos de 1,5 bilhão, 7 bilhões e 256 milhões de parâmetros ainda obtiveram taxas de acerto razoáveis (83%, 80% e 56%) em programação e matemática.

Download

O arquivo para download é o bench-llm, a versão original já descontinuada, e não o CrucibleForge (que está disponível no GitHub). O pacote ZIP contém dois arquivos: bench-llm, um script com 1.660 linhas, e README.md, que traz instruções resumidas de configuração. Não há necessidade de compilar ou instalar nada além desses dois arquivos: basta descompactar e executar. O agente de IA criou ambos os arquivos, que são licenciados sob a licença MIT. As dependências necessárias são openai e requests. Leia as observações importantes antes de executar o programa em uma máquina que hospede outros serviços.

Relacionado: StudioForge (o servidor com GPU do qual esses modelos alugam as placas), Quanto realmente custam meus agentes de IA (por que a velocidade local é importante), DeepSeek Harness (um agente de programação apoiado por esses modelos) e a pilha de agentes de IA local na qual eles operam.

Downloads

• Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

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