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;
-
temperatureomitido 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:
| Papel no benchmark | ID realmente executado | Motivo da substituição |
|---|---|---|
| Premium | openai/gpt-4o-mini |
Conta OpenAI sem crédito para o GPT-4o |
| Intermediário | anthropic/claude-sonnet-5 |
ID atual; série 5.x rejeita temperature
|
| Open-source | nvidia/nemotron-3-ultra-550b-a55b:free |
O Llama gratuito saiu do catálogo do OpenRouter |
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%):
| Critério | GPT-4o-mini | Claude Sonnet | Nemotron 550B |
|---|---|---|---|
| Qualidade | 4,3 | 4,7 | 4,2 |
| Consistência | 4,8 | 5,0 | 5,0 |
| Formato | 5,0 | 3,0 | 4,0 |
| Latência | 5,0 | 4,0 | 3,0 |
| Custo | 5,0 | 3,0 | 5,0 |
| Risco | 5,0 | 2,0 | 3,0 |
| Média ponderada | 4,80 | 3,68 | 4,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:
| Modelo | Custo por requisição | 50 mil req./mês |
|---|---|---|
| GPT-4o-mini | ~US$ 0,00008 | ~US$ 4,10 |
| Claude Sonnet | ~US$ 0,0033 | ~US$ 165,00 |
| Nemotron (free) | US$ 0,00 | inviável no tier gratuito |
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.pye logsresultados_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á!
Top comments (0)