Aritmética de ponto flutuante explica inferência não determinística

O que se observa

Com temperatura zero, o mesmo modelo e prompt no mesmo endpoint deveriam escolher sempre a palavra de maior pontuação. Na prática, podem surgir respostas diferentes. Um caso de avaliação passa duas vezes e falha na terceira; uma palavra diferente na posição 40 faz o restante divergir. O Thinking Machines Lab testou em escala: em mil requisições idênticas, com temperatura zero, obteve 80 completações diferentes. As mil respostas concordaram até o 102º token e se dividiram no 103º.

Por que semente e flags não resolvem

A semente controla o sorteio aleatório usado acima da temperatura zero; com temperatura zero, não há sorteio para repetir. As flags de determinismo do PyTorch fazem uma operação devolver o mesmo resultado sob as mesmas condições, mas os testes não estavam nas mesmas condições: um passou por servidor ocioso, outro por servidor ocupado. A causa está uma camada abaixo, na aritmética.

A ordem da soma altera o total

Um computador guarda número com dígitos fixos; uma pitada de sal não altera uma balança que já marca 2 kg. Em código, (0.1 + 1e20) - 1e20 devolve 0.0, enquanto 0.1 + (1e20 - 1e20) devolve 0.1: mesmos três números, ordens diferentes, totais diferentes. Oito números que deveriam cancelar exatamente produzem 102 totais distintos entre as 40.320 ordens possíveis. O autor repetiu com 4.096 números, em 255 agrupamentos diferentes, e obteve 17 totais. Um modelo faz somas desse tipo milhares de vezes por palavra.

Como a GPU e o tráfego entram

A GPU corta a coluna de números em pedaços, distribui cada um entre núcleos e soma os totais no fim. O número de pedaços acompanha a carga; dez requisições geram um corte, trinta geram outro. Multiplicação de matrizes, normalização e atenção são somas encadeadas; uma diferença no último decimal se acumula. Na camada final, as duas palavras mais prováveis podem estar mais próximas do que a diferença do agrupamento.

O motor de serving agrupa requisições que chegam no mesmo momento. Mais chamadas simultâneas significam lote maior, corte diferente, ordem diferente e, às vezes, palavra diferente no topo. Num endpoint hospedado, o tamanho do lote não é visível nem configurável e muda a cada minuto. Num servidor próprio, --max-num-seqs limita o máximo, mas o lote ainda depende do que chegou. Uma issue do vLLM, a 9567, documenta o efeito: um Llama 3 quantizado, com temperatura zero e lote definido manualmente, ainda muda a saída conforme o tamanho do lote.

O custo de tornar a inferência reproduzível

vLLM e SGLang oferecem um modo determinístico, desligado por padrão. Ele troca os kernels normais por kernels que cortam a coluna sempre no mesmo número de pedaços, qualquer que seja o lote. Isso é mais lento porque o kernel normal ocupa todos os núcleos; o fixo usa o mesmo corte para lote de dois ou de trinta, deixando o chip ocioso em lotes pequenos. O Thinking Machines Lab concluiu cerca de 38% menos requisições por hora nesse modo; a SGLang mediu de 24% a 55% de acréscimo por requisição, dependendo do código de atenção. Cada número vem de um time em hardware próprio. Nem vLLM nem SGLang cobrem modelos Mixture-of-Experts; o TensorRT-LLM não tem esse modo e só é reproduzível com lote de tamanho 1.

A recomendação é ligar onde reproduzir a execução é o produto - avaliações, aprendizado por reforço, auditorias de segurança e reprodução de bugs - e deixar desligado onde a velocidade é o produto, como chat. Há uma armadilha: o modo é aplicado ao lote inteiro, e todos que compartilham o endpoint pagam a latência se um usuário quer saída reproduzível. Um endpoint próprio não basta: as requisições concorrentes do dono ainda formam lote e mudam o corte; é preciso ligar também os kernels invariantes por lote.

A conclusão é que determinismo nunca foi propriedade do modelo, e sim de estar sozinho na máquina. Uma máquina vazia dava determinismo de graça; uma ocupada não dá, e comprá-lo de volta custa cerca de 38% da velocidade.