🧪 Benchmark de LLMs: como escolhi o modelo certo pro meu SaaS (e por que o Claude perdeu)

E aí, dev que já precisou escolher entre um modelo de IA caro, um intermediário e um open-source gratuito? Ou pior: já colocou um modelo em produção e descobriu, depois, que ele custava 40 vezes mais do que o previsto — ou que simplesmente não completava as chamadas?

Pois é. Escolher modelo de IA para um produto SaaS é fácil quando você olha só para a qualidade da resposta. Difícil é equilibrar qualidade, custo, latência e confiabilidade operacional ao mesmo tempo.

Este post nasceu de um micro-capstone da minha Pós-Graduação em Engenharia de IA. O desafio era montar um benchmark aplicado, com chamadas reais, para recomendar um modelo de linguagem a uma startup SaaS. Como eu não podia usar dados reais de uma empresa, criei a InsightFlow, uma empresa fictícia que serve de estudo de caso para exemplificar o processo de seleção de modelo. Tudo o que você vai ler aqui — dataset, script, logs e resultados — é real e reproduzível. A empresa é fictícia; o benchmark é de verdade.

Neste post, vou te contar o que o experimento revelou, por que o modelo "premium" não ganhou, e o que aprendi sobre limites de tier gratuito que nenhuma documentação te conta. Bora?

O contexto: a InsightFlow (empresa fictícia)

A InsightFlow é uma startup B2B SaaS fictícia, criada como caso de uso do meu trabalho de pós-graduação. Ela representa uma empresa que recebe milhares de comentários de NPS, tickets de suporte, avaliações de produto e formulários de satisfação. A empresa queria adicionar um módulo de IA para classificar sentimento, identificar temas, gerar resumos executivos e recomendar ações.

O ponto importante aqui é que o case é fictício, mas o problema é real: qualquer SaaS B2B que trabalhe com análise de feedback textual enfrenta exatamente as mesmas decisões — qualidade, custo, latência e confiabilidade operacional. Por isso o benchmark funciona como exercício aplicado: você pode trocar "InsightFlow" pelo nome do seu produto e o experimento continua válido.

A tarefa padronizada foi:

"Analise o feedback abaixo e produza: 1. Sentimento (Positivo, Negativo ou Neutro); 2. Categoria principal; 3. Resumo executivo em até 3 linhas; 4. Recomendação de ação."

O experimento: 3 modelos, 20 feedbacks, 180 chamadas

Usei 20 feedbacks estratificados (5 de cada origem), com casos deliberadamente ambíguos — mistos, vagos e contraditórios — para testar se os modelos realmente interpretavam contexto ou só reagiam a palavras-chave. Cada feedback foi executado 3 vezes por modelo, totalizando 180 chamadas.

Para garantir comparação justa:

• Mesmo prompt de sistema e de usuário para todos;
• Mesma temperatura (0,2) e mesmo max_tokens (500);
• Streaming habilitado para medir TTFT;
• temperature omitido no Claude Sonnet 5, que rejeita o parâmetro;
• Script próprio em Python (benchmark_insightflow.py), disponível no repositório, que registra latência, tokens, JSON válido e erros em CSV.

Os modelos originais do plano eram GPT-4o, Claude Sonnet e Llama 3.3 70B. Mas a realidade de contas e catálogos me obrigou a substituir dois deles:

O que o experimento revelou

O resumo bruto do script ao final das 180 chamadas foi este:

modelo n lat_med p95 ttft_med json_ok erros ----------------------------------------------------------------- gpt-4o-mini 60 2.26 2.96 1.64 100% 0 claude-sonnet 60 2.03 5.18 2.78 33% 38 modelo-gratuito 60 5.17 9.08 3.96 85% 7 

A tabela consolidada, com notas de 1 a 5 e média ponderada (Qualidade 25%, Consistência 15%, Formato 15%, Latência 10%, Custo 20%, Risco 15%):

A conclusão é clara: o modelo com a melhor qualidade não foi o vencedor. O Claude Sonnet acertou 100% dos 8 feedbacks que conseguiu processar — incluindo um caso ambíguo que o GPT-4o-mini errou. Mas ele não completou o benchmark: 38 das 60 chamadas falharam por falta de crédito (402) e limite de novas contas (20 RPM no OpenRouter). Em produção, um modelo que falha 66% das chamadas não é viável, por melhor que seja a resposta.

As três lições que eu não esperava

1. Qualidade sem completude não vale nada

O Claude foi mais preciso. Mas a taxa de JSON válido foi de 33%, contra 100% do GPT-4o-mini. Em um produto SaaS, uma resposta excelente que não chega é pior do que uma resposta boa que chega sempre. Confiabilidade operacional é parte da qualidade.

2. O tier gratuito tem teto — e ele chega rápido

O Nemotron 550B entregou 94% de acerto com custo zero. Parecia imbatível. Até o limite de 50 requisições por dia do OpenRouter bloquear as últimas chamadas. Para um protótipo, é ótimo. Para 50 mil requisições por mês, o tier gratuito simplesmente não existe. Custo zero no papel pode significar inviabilidade na prática.

3. O custo real é muito diferente do custo estimado

O GPT-4o-mini consumiu, em média, ~167 tokens de entrada e ~95 de saída por requisição. O Claude consumiu ~265 e ~250. Com os preços reais, isso deu:

Quarenta vezes de diferença. O benchmark original do papel estimava GPT-4o e Claude praticamente empatados. Com dados reais de tokens, a economia muda completamente a análise de margem.

A recomendação (e o que eu faria no seu lugar)

Adotei o GPT-4o-mini como modelo principal. Ele foi o único com 100% de JSON válido, zero erros operacionais, 93,3% de acerto de sentimento, latência mediana de 2,26 s e custo 40 vezes menor que o Claude.

O Claude Sonnet 5 fica como modelo secundário para casos complexos, ativado apenas quando o GPT-4o-mini errar a classificação ou quando o feedback exigir um resumo mais elaborado. Antes disso, é preciso estabilizar saldo no OpenRouter, aumentar max_tokens para 800 e implementar retry com backoff para 429.

O Nemotron vai para piloto controlado de baixo volume. Só faz sentido se a InsightFlow comprar créditos suficientes para sustentar o volume.

Dica quente: não escolha modelo só pela nota de qualidade. Rode o benchmark com o seu dataset, meça tokens reais e taxa de completude, e trate falhas operacionais como parte da nota de risco. Um modelo que falha 1 em cada 3 chamadas não é um modelo de produção.

Conclusão

O experimento da InsightFlow — lembra, a empresa é fictícia, mas o benchmark é real — mostrou que a escolha de modelo é uma decisão de negócio, não só de tecnologia. O melhor modelo no papel pode perder para um modelo "menor" que entrega consistência e custo previsível. E o modelo gratuito pode ser imbatível no protótipo e inviável na produção.

A lição que fica é simples: benchmark sem dados reais é opinião. Rode as chamadas, registre os logs, meça o custo por requisição com os seus tokens e trate as falhas operacionais como parte do resultado. Foi assim que o GPT-4o-mini ganhou — não por ser o mais "inteligente", mas por ser o único que completou o trabalho.

Este post é a versão pública do meu micro-capstone da pós-graduação. Se você também está fazendo um trabalho acadêmico com LLMs, o script, o dataset e os logs estão no repositório do projeto — fica à vontade para adaptar.

Já precisou escolher modelo de IA para produção? Como você pesou qualidade contra custo e confiabilidade? Conta aí nos comentários!

# InteligenciaArtificial # LLM # Benchmark # Java # SpringAI # SaaS # EngenhariaDeSoftware

Referências

• Micro-capstone: Seleção de Modelo para Produto SaaS com IA — Pós-Graduação em Engenharia de IA. Benchmark com 3 modelos, 20 feedbacks e 180 chamadas.
• InsightFlow: empresa fictícia criada como estudo de caso para o experimento.
• Script benchmark_insightflow.py e logs resultados_brutos.csv / logIA.txt — execução real via OpenRouter em 02/11/2026.
• OpenRouter: Free Models Router e limites de tier gratuito.
• Documentação da OpenAI e da Anthropic sobre preços e modelos.

Quer mais? No próximo post, vou mostrar como estruturar um pipeline de avaliação contínua para monitorar a qualidade do modelo em produção — com métricas de consistência e detecção de deriva. Até lá!