Quanto cada modelo custa de verdade: benchmark com juiz cego e números

Escolher modelo de LLM costuma ser vibe: testa dois ou três, olha a resposta, escolhe o que “parece melhor”. Isso funciona até o dia em que o modelo mais caro perde pro mais barato numa tarefa específica, e ninguém percebe porque ninguém mediu. Decidi medir. O motivo prático: minha wiki pessoal (a mesma do post anterior) precisava escolher um modelo pra escrever páginas a partir de código e documentos, e “parece melhor” não é critério que sobrevive a uma auditoria de custo.

O processo inteiro cabe num desenho:

As seções abaixo percorrem cada caixa desse fluxo, na ordem.

A fixture: a mesma entrada pra todo mundo

Nada de comparar modelo em tarefas diferentes. Montei uma fixture congelada: um conjunto de entradas fixo, que não muda entre um teste e outro. No caso, as mesmas 4 fontes pra todos os modelos, sempre: dois projetos meus que eu sabia de antemão que dependiam um do outro (uma lib e o serviço que a usa; isso serve de gabarito, porque se a página gerada não linkar os dois, o modelo errou algo verificável) e duas páginas de documentação técnica.

Um juiz (outro modelo, claude-sonnet-4.6, sem saber qual texto veio de qual concorrente) lê cada página gerada e dá nota de 0 a 25 em quatro critérios, somando 0 a 100: fidelidade ao conteúdo, cross-linking (os links entre páginas relacionadas), aderência ao formato e qualidade da síntese. Custo real vem do consumo de API reportado por cada chamada, sem tabela de preço; inclui os casos em que o modelo gastou mais tokens (a unidade de cobrança das APIs, pedaços de palavra) tentando de novo depois de um erro.

Uma ressalva honesta: o juiz cego foi validado contra um fato de domínio conhecido (a dependência entre os dois projetos), sem calibração estatística contra avaliadores humanos. É rigor suficiente pra comparar modelos entre si. Não prova que o juiz nunca erra, e o achado mais interessante deste post mostra isso.

Rodada 1: 7 modelos, mesma fixture

Testei deepseek-v4-flash, deepseek-v4-pro, gemini-2.5-flash-lite, gpt-4.1-nano, qwen-plus, qwen3.7-plus e minimax-m3 contra a fixture, duas vezes. Uma vez com um padrão de frontmatter mais enxuto, outra com um mais estruturado (frontmatter é o bloco de metadados no topo de cada página gerada: título, tags, links):

O painel mostra o que interessa lado a lado: nota do juiz, custo em dólar e a métrica que decide de verdade, o score por dólar. gpt-4.1-nano custou quase nada (US$ 0,0045) mas errou o cross-linking sistematicamente (nota 22 de 100 em páginas de repositório). Barato não serve se o resultado não presta. No outro extremo, minimax-m3 teve a melhor nota bruta (91) mas custou 14× mais que o vencedor real e demorou 10 minutos contra 4 segundos.

O padrão mais estruturado de frontmatter (segundo teste) piorou a nota de quase todo mundo. Os modelos mais leves perderam de 10 a 20 pontos tentando preencher campos demais:

Lição direta: mais estrutura pedida no prompt nem sempre é “mais profissional”. Pra modelo pequeno, é mais chance de errar formatação em vez de conteúdo. Fiquei com o padrão enxuto.

Vencedor da rodada 1: deepseek-v4-flash. A nota dele (80 de 100) veio atrás de outros, mas o score por dólar foi o melhor da mesa e nenhum erro sistemático apareceu. Custo total pra rodar os 7 modelos duas vezes, com juiz incluso: menos de US$ 0,50.

Rodada 2: modelos novos, e o viés que eu não esperava

Meses depois, com modelos mais novos disponíveis (claude-sonnet-5, gemini-2.5-pro, gpt-5.1, entre outros), repeti o mesmo teste na mesma fixture. claude-sonnet-5 tirou a maior nota: 93 de 100, à frente de todo mundo.

Só que o juiz também era um modelo Claude (claude-sonnet-4.6). E isso é um problema conhecido de LLM-como-juiz: modelo tende a dar nota mais alta pra texto escrito por um “parente” da mesma família, mesmo sem saber qual foi. Descontei o resultado por causa disso: não dava pra confiar numa nota que pode estar inflada pelo próprio mecanismo de avaliação. O modelo realmente competitivo, sem esse viés, era gemini-3.5-flash, empatado tecnicamente na faixa de 89-91.

Essa é a parte que não aparece em benchmark de propaganda: o número mais alto não ganhou. Ganhou o número que eu conseguia justificar.

Nem toda falha é do modelo

Um achado separado, que quase me fez trocar de modelo à toa: um lote de páginas vinha saindo com nota baixa de forma consistente, e a primeira suspeita foi “esse modelo não dá conta”. Investigando, o problema era outro: páginas ficavam órfãs (fora do índice) por um bug de pipeline, não por limitação do modelo. Corrigido o bug (auto_index_orphans, uma correção mecânica, sem trocar nada de IA), a taxa de sucesso do mesmo modelo foi de 7 em 10 pra 10 em 10.

Separe essas duas coisas antes de qualquer benchmark: um modelo ruim erra a resposta; um pipeline com bug erra em quem recebe a resposta.

O que ficou em produção

A decisão final foi uma combinação, porque as duas perguntas (“quanto custa no grosso” e “o que fazer com os que falham”) têm respostas diferentes:

• Barato no volume: gemini-2.5-flash-lite processa a maioria das páginas da minha wiki pessoal a um custo por página que fica na casa de centavos de dólar por repositório.
• Forte nos casos difíceis: quando o modelo barato falha ou o resultado sai abaixo do esperado, reprocesso só esse pedaço com gemini-3.5-flash. Mais caro, mas usado numa fração pequena do volume total.
• Upgrade completo, sob demanda: se algum dia eu quiser resincronizar tudo com o modelo mais forte disponível, sei quanto custa por página, porque medi em vez de estimar.

Num piloto real (produção, já fora da fixture sintética): 20 repositórios meus processados com o modelo forte, zero falhas, custo real de US$ 0,21 por repositório. Cerca de 3× a estimativa inicial, porque em tarefa de síntese o texto de saída domina o custo, bem mais que o de entrada. Bom saber antes de orçar um lote maior.

O ponto

Benchmark serve pra ter um número que sobrevive à pergunta “por que esse e não aquele”. Sem isso, toda decisão de modelo é opinião vestida de dado. Com isso, até quando o juiz erra (como no viés de auto-preferência), você sabe que errou, e por quê.