Por que dois modelos de IA dão respostas diferentes para o mesmo prompt (e qual deles está certo)?

Fala aí, beleza? Tu roda o mesmo pedido em dois modelos e volta com duas respostas que se contradizem, as duas escritas com aquela confiança de quem nunca erra

E aí bate a pergunta óbvia: qual dos dois está certo?

Antes de escolher lado, se liga numa coisa: receber respostas diferentes para o mesmo prompt não é bug, é comportamento esperado de como a inferência roda na GPU, e acontece até com temperature 0

Esse post não tem torcida por marca

O que ele entrega é critério: por que a divergência acontece, o que dá pra travar, o que não dá pra travar, e como decidir qual saída aceitar sem chutar no olho

Sintoma 1: o mesmo modelo, o mesmo prompt e saídas diferentes

O sintoma:

Tu manda a mesma requisição duas vezes, com temperature 0, esperando saída idêntica

Vem texto diferente

Não é impressão sua. A documentação oficial do Claude avisa isso na cara limpa: "Even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls"

E vale tanto pro serviço de inferência da própria Anthropic quanto pra inferência via provedores de nuvem terceiros

O mesmo aviso aparece na referência do endpoint de criação de mensagens da API, na nota sobre temperature: nem com 0.0 os resultados são totalmente determinísticos

Na OpenAI a conversa é parecida. O parâmetro seed é descrito como esforço de melhor tentativa, "our system will make a best effort to sample deterministically"

Melhor tentativa não é garantia, né? O determinismo não é prometido, e ainda é comum ver variação com o mesmo seed e o mesmo system_fingerprint

A causa:

Aqui entra a parte que quase ninguém explica direito

Repara que nada disso é sorteio de amostragem: com temperature 0 a escolha probabilística do token já saiu de cena, e a variação continua aparecendo

Se tu já mexeu com ponto flutuante em qualquer linguagem, tu sabe que somar os mesmos números em ordem diferente pode dar resultado diferente na última casa. Aritmética de ponto flutuante não é associativa

Agora junta isso com o jeito que a inferência roda no servidor: as requisições são agrupadas em lotes, e o tamanho do lote depende da carga do momento

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Se os kernels de GPU não são invariantes ao tamanho do lote, o caminho de soma muda quando o batch muda

E se o caminho de soma muda, o resultado final da SUA requisição muda, mesmo que o seu prompt seja byte a byte igual ao de antes

Ou seja: é problema numérico e de infraestrutura, não é o modelo "jogando dado"

O artigo de referência sobre isso é Defeating Nondeterminism in LLM Inference, de Horace He e colegas, publicado no blog do Thinking Machines Lab em 10 de setembro de 2025

Eles apontam três operações que quebram a consistência numérica quando o batch varia: normalização, multiplicação de matrizes e atenção

E mediram o estrago: com o Qwen/Qwen3-235B-Instruct, mil completions a temperature 0 produziram 80 saídas distintas, com a primeira divergência aparecendo já no token 103

Mil chamadas idênticas, 80 respostas diferentes 😀

Se tu já se pegou olhando pra duas saídas do mesmo modelo sem entender o que mudou, esse mesmo mecanismo explica as respostas diferentes no mesmo modelo que aparecem no dia a dia

A solução:

A correção proposta é trocar os kernels de redução por versões batch-invariant, ou seja, kernels que dão o mesmo resultado independente do tamanho do lote

Com eles ativados, as mesmas mil chamadas voltaram bitwise idênticas: 1.000 de 1.000

O código está publicado no repositório batch_invariant_ops, do próprio Thinking Machines Lab, que usa torch.Library pra substituir kernels existentes do PyTorch e traz exemplo de inferência determinística no vLLM

Se tu serve modelo por conta própria, dá pra ligar isso hoje

No vLLM, a batch invariance é ativada por variável de ambiente:

export VLLM_BATCH_INVARIANT=1

Requisito: GPU NVIDIA com compute capability 8.0 ou superior. A documentação registra impacto de desempenho frente ao modo padrão

No SGLang, o determinismo entra por flag na subida do servidor:

--enable-deterministic-inference --attention-backend fa3

O --attention-backend aceita fa3, flashinfer ou triton, e só esses três backends de atenção são suportados nesse modo

Tome cuidado com o preço: no SGLang, a inferência determinística custa de 25% a 45% de lentidão, com média de 34,35% nos backends FlashInfer e FlashAttention 3. A própria recomendação é usar isso principalmente pra depuração e reprodutibilidade

Como prevenir:

Se tu está na API fechada, fixa o que dá pra fixar: manda seed e observa o system_fingerprint na resposta

Que campo é esse? O system_fingerprint é uma string que representa a configuração de backend usada, e serve justamente pra tu detectar quando a infraestrutura mudou por baixo

Mas repete comigo: nada disso é garantia

É redução de ruído, não é contrato

Sintoma 2: dois modelos diferentes discordam no mesmo pedido

O sintoma:

Modelo A afirma uma coisa

Modelo B afirma outra

Os dois com tom de professor seguro, sem nenhuma pista de dúvida no texto

A causa:

Aqui a coisa é estrutural, não é só ruído numérico

Cada modelo tem treino próprio, tokenização própria, estratégia de decodificação própria e infraestrutura de inferência própria

Ou seja: o não determinismo do sintoma 1 já existe DENTRO de cada um dos dois

Quando tu compara sistemas diferentes, tu não está só somando esse ruído, tu está comparando duas máquinas que aprenderam e decidem de jeitos diferentes

E tem uma leitura que ajuda muito aqui, tirada do trabalho de self-consistency de Wang et al.: quando muitos caminhos de raciocínio convergem na mesma resposta, ela tem probabilidade muito maior de estar correta, e a discordância ampla sinaliza incerteza

Sacou a virada de chave? A divergência não é só um problema pra resolver

Ela é informação sobre a tarefa

Se dois sistemas independentes discordam, provavelmente o pedido tem ambiguidade, ou o problema está acima do que uma passada única consegue resolver com confiança

A solução:

Parar de tratar divergência como empate a ser desempatado no olho

A sensação de "essa resposta parece melhor escrita" não é evidência de nada. Modelo bem calibrado no texto e modelo certo no conteúdo são coisas separadas

Como prevenir:

Duas coisas antes de rodar qualquer comparação:

• reduzir a ambiguidade do prompt, porque pedido vago produz divergência que não diz nada sobre os modelos
• definir ANTES qual evidência decide o caso

Se tu não sabe o que aceitaria como prova, tu não está comparando, tu está torcendo

Como decidir qual saída aceitar, passo a passo

1. Repita a chamada no mesmo modelo antes de comparar modelos. Roda o mesmo prompt 3 ou 5 vezes no modelo A, depois no modelo B, e olha a variação interna de cada um. O erro comum deste passo: comparar duas amostras únicas e concluir que "o modelo A é melhor nisso", quando na real tu pegou uma amostra boa de um lado e uma ruim do outro. Lembra das 80 saídas distintas em mil chamadas

2. Fixe o que dá pra fixar. Na API fechada, manda seed e registra o system_fingerprint de cada resposta junto com o resultado. Se tu serve o modelo, sobe o ambiente determinístico:

export VLLM_BATCH_INVARIANT=1

Ou, no SGLang, --enable-deterministic-inference junto de --attention-backend fa3, flashinfer ou triton, lembrando do requisito de compute capability 8.0 ou superior. O erro comum deste passo: ligar modo determinístico em produção e comer de 25% a 45% de lentidão sem precisar. Isso é ferramenta de depuração e reprodutibilidade, não configuração padrão

3. Amostre vários caminhos e fique com a resposta majoritária. É o self-consistency de Wang et al.: em vez de aceitar uma saída, tu gera várias e vota. No artigo original, a votação por maioria levou a acurácia no GSM8K de 56,5% com um único chain of thought pra 74,4% com 40 amostras. O erro comum deste passo: sair votando em tudo. Em modelos atuais o ganho encolheu bastante, e a recomendação é reservar amostragem múltipla pra problemas que comprovadamente passam do limite de confiabilidade de uma passada única do modelo

4. Valide contra fonte externa executável. Teste que roda, código que executa, documento que dá pra abrir e conferir. O erro comum deste passo: validar a saída do modelo A perguntando pro modelo B se está certo. Isso não é validação, é segunda opinião de alguém que erra pelos mesmos motivos

5. Se for usar LLM como juiz, meça o juiz antes. Sim, colocar um modelo pra escolher a melhor das duas respostas é uma opção, e às vezes é a única que escala. Só que o viés de posição está documentado em larga escala: o estudo "Judging the Judges" olhou 15 LLMs juízes em MTBench e DevBench, 22 tarefas, cerca de 40 modelos geradores de solução e mais de 150.000 instâncias de avaliação, e mostrou que esse viés não é aleatório, ele é fortemente afetado pela diferença de qualidade entre as soluções comparadas. Já o "Reliability without Validity" mostrou que o ranking de juízes se desloca em até 14 posições entre benchmarks, ou seja, juiz bom num teste não é juiz bom em todos. Pra medir isso na tua casa, a RAND publicou o Judge Reliability Harness, com código em github.com/RANDCorporation/judge-reliability-harness, que gera testes de precisão com respostas de rótulo invertido, invariância a formatação e paráfrase, suscetibilidade a viés de verbosidade, estabilidade estocástica sob amostragem repetida e calibração em escala ordinal. O erro comum deste passo: assumir que um juiz consistente é um juiz sem viés. Não é a mesma coisa, e já já eu mostro o número disso

Métodos de desempate: o que cada um resolve e quanto custa

Um detalhe do estudo "Reliability without Validity" que merece atenção: foram 21 juízes de 9 provedores em MT-Bench, JudgeBench e RewardBench, 118 execuções e cerca de 541.000 julgamentos

E dois juízes usados em produção apresentaram confiabilidade teste-reteste acima de 0,95 convivendo com viés de posição acima de 0,10

Ou seja: repetível pra caramba, e enviesado do mesmo jeito toda vez 😛

O viés de verbosidade, esse sim, ficou pequeno sob uma única rubrica pareada, abaixo de 0,011

Quando a divergência importa (e quando você pode ignorar)

Nem todo caso merece o preço do determinismo. Separa assim:

• Código, refatoração e migração: aqui a divergência se resolve rápido e barato. O teste roda, a aplicação sobe ou não sobe, o build passa ou não passa. Não precisa de juiz nenhum, precisa de terminal
• Análise de dados, números e cálculo: é onde amostragem múltipla ganha sentido, porque o erro não grita na tela. Se o problema realmente passa do que uma passada única entrega com confiança, vale gastar tokens e votar
• Texto criativo, título, copy, brainstorm: aqui variação é feature, não defeito. Rodar duas vezes e receber duas versões diferentes é exatamente o que tu quer. Travar determinismo nesse cenário é pagar lentidão pra perder opção
• Auditoria, benchmark e comparação de ferramentas: esse é o caso que MAIS exige ambiente congelado. Se tu vai publicar "a ferramenta X é melhor que a Y", tu precisa saber que a diferença medida não é ruído de batch. É aqui que os 25% a 45% de lentidão do modo determinístico se pagam

Regra prática: quanto mais a decisão depende do resultado ser reproduzível por outra pessoa, mais vale congelar o ambiente

O que aconteceu quando rodei dois setups no mesmo projeto

Eu vivi esse problema na prática num comparativo de frameworks pro Claude Code

A audiência ficava perguntando qual é melhor, sem consenso nenhum, então resolvi fazer o mesmo projeto duas vezes: um com Superpowers e outro com GSD

Montei duas pastas separadas no VS Code, uma pra cada framework, com um terminal e uma sessão de Claude Code em cada

O prompt foi idêntico nos dois lados: e-commerce com home em grid de produtos, página de produto, carrinho lateral em drawer, checkout com formulário e cartão fake, página de confirmação, autenticação simples, página de pedidos, painel admin, filtro por categoria, busca, responsividade e dark mode

Mesmo modelo nos dois lados durante o planejamento, justamente pra não contaminar a comparação

E aí começou o que esse post inteiro descreve: as saídas divergiram cedo, e não foi por qualidade, foi por caminho

A fase inicial é bem parecida nos dois, ambos fazem rodadas de perguntas antes de gerar qualquer artefato

Mas as PERGUNTAS divergiram

O GSD levantou controle de estoque, ciclo de vida do pedido e exigência de login, coisas que o outro lado não trouxe

O Superpowers puxou estratégia de testes (nenhum, manual, unitário básico, unitário mais smoke), tema que o GSD não trouxe do mesmo jeito

Quando testei, ficou claro que essas perguntas diferentes já mandam os dois projetos pra lugares diferentes antes de existir uma linha de código

Por isso alinhei respostas propositalmente dos dois lados, pra manter a comparação justa

No fim, os dois geraram estrutura de documentação equivalente: o Superpowers criou o spec e o GSD criou a pasta de specs com o planejamento em markdown

E a lição do comparativo é exatamente a do passo 4 lá em cima: o que desempatou não foi qual documento estava mais bonito, foi rodar e ver funcionando

Impressão de qualidade de texto engana. Aplicação que sobe, não

Outra coisa que vale dizer, porque foi a dúvida mais repetida da audiência: os dois podem coexistir no mesmo fluxo de trabalho, e essa história de usar dois sistemas ao mesmo tempo não é o problema que parece ser

Eu não coroei um vencedor absoluto no vídeo de propósito

A ideia era dar material pra pessoa formar a própria opinião e usar cada um onde ele é melhor

No vídeo abaixo eu mostro o teste inteiro, do setup até o resultado:

Veredito: o certo é o que passa no teste, não o que soa melhor

Nenhum modelo tem autoridade por padrão

E nenhum juiz automático é uniformemente confiável: depois de avaliar quatro juízes em benchmarks de segurança, persuasão, uso indevido e tarefas agênticas, a RAND mostrou que a consistência quebra com mudanças simples de formatação, paráfrase e variação de verbosidade

Soma isso com o dado dos juízes de produção com teste-reteste acima de 0,95 e viés de posição acima de 0,10 e a conclusão é meio dura: dá pra ter um avaliador estável e errado ao mesmo tempo

Então o veredito não pode ser "o modelo X é o certo"

O veredito é um critério de aceite definido ANTES de tu escrever o prompt, com prioridade pra evidência executável

Se a tarefa produz código, o teste decide

Se produz número, a conta confere ou não confere

Se produz afirmação sobre o mundo, a fonte externa decide

E se não dá pra verificar nada disso, o honesto é assumir que tu está diante de incerteza, não de uma disputa com vencedor

Conclusão

Recapitulando o que importa: divergência é comportamento esperado, não defeito, e a causa vai desde os kernels de GPU até a diferença estrutural entre dois sistemas distintos

O desempate não sai de impressão nem de segunda opinião de outro modelo, sai de evidência executável combinada com critério definido antes

E se for chamar um LLM pra julgar, mede o juiz primeiro: consistente não quer dizer sem viés

Modo determinístico, por sua vez, é ferramenta de depuração e auditoria, com preço de desempenho medido, não configuração padrão

O próximo passo prático é bem simples: escreve o teste de aceite ANTES de comparar modelos

Depois repete a chamada no mesmo modelo umas 3 a 5 vezes antes de acusar diferença entre modelos diferentes

E só liga reprodutibilidade forçada quando ela valer o custo de desempenho

Faça o teste e me conta o que apareceu, tenho quase certeza que tu vai se assustar com a variação dentro de UM modelo só…

Até o próximo post! 🙂