Como superar a não determinismo na inferência de LLMs

• Na inferência de LLMs (grandes modelos de linguagem), ocorre o problema de não determinismo (nondeterminism), em que resultados diferentes podem surgir mesmo com a mesma entrada e as mesmas condições
• Até agora, concorrência (concurrency) e a não associatividade (non-associativity) das operações de ponto flutuante (floating-point) vinham sendo consideradas as principais causas do não determinismo
• Na prática, a verdadeira causa determinante vem da mudança na ordem de cálculo dentro do kernel (código de operação) conforme a variação do tamanho do batch (batch size)
• Se todas as operações dentro do kernel forem implementadas com invariância a batch (batch invariance), é possível garantir reprodutibilidade (reproducibility) completa
• Com operações paralelas por dados, split reduction e estratégia de split de tamanho fixo, é possível criar kernels invariantes a batch para operações principais como RMSNorm, matmul e attention

---

Introdução e visão geral do problema

• A reprodutibilidade (reproducibility), elemento central do progresso científico, não tem sido bem preservada na inferência de LLMs (grandes modelos de linguagem)
• Mesmo fazendo a mesma pergunta ao ChatGPT várias vezes, é comum que sejam geradas respostas diferentes
• Isso acontece porque o processo de sampling de resultados em LLMs é uma escolha probabilística baseada em uma distribuição de probabilidade
• Porém, mesmo com a temperature ajustada para 0, na prática a API de LLM não é necessariamente determinística (ou seja, não retorna sempre o mesmo resultado para a mesma entrada)
• O problema de não determinismo também existe ao rodar em bibliotecas open source de inferência, como vLLM e SGLang, e em hardware próprio

Hipóteses anteriores e limitações

• Hipótese amplamente conhecida: o não determinismo ocorre por causa de concorrência + não associatividade de ponto flutuante
  • Em operações de ponto flutuante na GPU, o resultado pode variar sutilmente conforme a ordem das operações e a ordem de término das threads
• Porém, na prática, mesmo repetindo a mesma multiplicação de matrizes sobre os mesmos dados e da mesma forma, sempre se obtém exatamente o mesmo resultado (bw=bitwise equal)
• Para identificar a causa real, é necessária uma análise mais profunda

Análise aprofundada das causas do não determinismo na inferência de LLMs

A essência da não associatividade de ponto flutuante

• Operações de ponto flutuante obedecem à relação (a+b)+c ≠ a+(b+c)
• Ao operar valores com magnitudes diferentes (exponent), há perda de precisão, perda de informação e o resultado muda conforme a ordem das operações
• Como a ordem das operações pode mudar, se várias somas forem executadas aleatoriamente, surgem resultados variados (confirmado também experimentalmente)

Mudança na ordem das operações do kernel e concorrência

• Em geral, problemas de concorrência em operações como atomic add são apontados como causa principal do não determinismo
• Porém, a maioria dos kernels usados na inferência de LLMs (especialmente no forward pass) funciona mesmo sem atomic add
• Com estratégia de paralelização adequada e split (reduction), é possível garantir a mesma ordem de operações

A causa central de fato: ausência de "invariância a batch (batch invariance)"

• Cada kernel individualmente sempre retorna o mesmo resultado se a entrada for a mesma (run-to-run deterministic)
• Porém, como as requisições simultâneas de vários usuários (batch size) mudam de forma não determinística, na prática o resultado não é estável para cada requisição
• Conforme o tamanho do batch, a ordem de dividir ou combinar operações internamente muda, causando não determinismo
• Ou seja, a causa central era o fato de que a carga do servidor e o paralelismo (tamanho do batch) eram não determinísticos

Projeto de kernels invariantes a batch e casos das operações principais

RMSNorm

• Aplicação de estratégia data-parallel: cada elemento do batch é processado de forma independente por um único core
• Quando o tamanho do batch é grande, mantém-se paralelismo suficiente; assim, a estratégia de paralelização permanece constante e a invariância a batch é preservada
• Quando o tamanho do batch é muito pequeno, usam-se estratégias alternativas como split reduction, mas nesse caso parte da invariância a batch é sacrificada

Multiplicação de matrizes (matmul)

• Usa-se estratégia data-parallel com paralelização por tile
• Para otimizar o uso de Tensor Cores, é preciso dividir em tiles 2D, e em batches muito pequenos são necessárias estratégias especiais como split-K
• Ao usar a estratégia split-K, a invariância a batch pode ser quebrada
• Mesmo com alguma perda de desempenho, é possível garantir uma ordem de operações constante e reproduzível ao forçar a mesma configuração de kernel

Attention

• Em FlashAttention2 e afins, a paralelização na direção de query e a redução simultânea de Key/Value garantem a invariância a batch
• Se a ordem de reduction mudar conforme o tamanho do batch ou a divisão da sequência (chunked prefill, prefix caching etc.), a invariância é quebrada
• Em estratégias de split-reduction como split-KV (FlashDecoding), é possível manter a mesma ordem de operações fixando o tamanho do split (fixed split-size)
• Internamente, não se deve tratar separadamente o cache de key/value e os novos tokens; é preciso manter um layout consistente de keys/values em todas as operações

Implementação

• Foi disponibilizada uma demo de inferência determinística com aplicação de kernels batch-invariant usando vLLM e torch.Library
• Os kernels de substituição para essas operações podem ser vistos no repositório GitHub (thinking-machines-lab/batch-invariant-ops)

Experimentos e desempenho

Experimento de medição de não determinismo

• Com o modelo Qwen/Qwen3-235B-A22B-Instruct-2507, em condição de temperature 0, foi feita a geração 1000 vezes com o mesmo prompt (“Tell me about Richard Feynman”)
• Foram geradas 80 finalizações diferentes (mesmo prompt, mas com não determinismo)
• Até os 102 primeiros tokens, o resultado era igual; a primeira divergência ocorreu no token 103 (“Queens, New York” vs “New York City”)
• Ao usar kernels invariantes a batch, os 1000 resultados foram idênticos, garantindo reprodutibilidade completa

Avaliação de desempenho

• Com 1 GPU rodando Qwen-3-8B, foram feitas 1000 requisições de sequências com comprimento entre 90 e 110
  • vLLM padrão: 26 segundos
  • vLLM determinístico não otimizado: 55 segundos
  • Com kernel de attention melhorado: 42 segundos
• Embora ainda faltem otimizações, o desempenho permanece em um nível prático de uso

Valor para On-policy RL

• Antes, por pequenas diferenças numéricas entre training e inference, on-policy RL não podia ser implementado com precisão
• Com inferência determinística, torna-se possível fazer sampling e training bitwise identical, permitindo uma implementação real de on-policy RL
• Foi confirmada correspondência completa dos resultados em métricas principais como KL-divergence e reward

Conclusão

• Em sistemas de inferência de LLMs, é fácil ignorar o não determinismo e os erros numéricos, mas ao identificar e corrigir a causa raiz (falta de invariância a batch), é possível obter reprodutibilidade e determinismo completos
• Este estudo mostra um caminho para resolver o problema de não determinismo na inferência de LLMs e ajuda desenvolvedores a garantir reprodutibilidade total em seus próprios sistemas

Informações de citação

• Ao citar este estudo, use as informações abaixo

He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

ou

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}