Comment vaincre le non-déterminisme dans l’inférence des LLM

• En inférence de LLM (grands modèles de langage), un problème de non-déterminisme (nondeterminism) apparaît : même avec une entrée et des conditions identiques, les résultats peuvent différer
• Jusqu’ici, la concurrence (concurrency) et la non-associativité des opérations en virgule flottante (floating-point) étaient considérées comme les principales causes du non-déterminisme
• En réalité, la cause déterminante est le changement de taille de batch (batch size), qui modifie l’ordre des calculs à l’intérieur des kernels (code de calcul)
• Si toutes les opérations d’un kernel sont implémentées de façon à garantir l’invariance au batch (batch invariance), il devient possible d’assurer une reproductibilité (reproducibility) complète
• Grâce à des techniques comme les opérations parallèles sur les données, le split reduction et les stratégies de split à taille fixe, il est possible de construire des kernels invariants au batch pour les principales opérations (RMSNorm, matmul, attention)

---

Introduction et vue d’ensemble du problème

• La reproductibilité (reproducibility), élément central du progrès scientifique, est mal assurée dans l’inférence des LLM (grands modèles de langage)
• En posant plusieurs fois la même question à ChatGPT, on obtient souvent des réponses différentes
• Cela vient du fait que, dans les LLM, le processus de sampling repose sur une sélection probabiliste fondée sur une distribution de probabilités
• Cependant, même en réglant le temperature à 0, une API de LLM n’est pas nécessairement déterministe en pratique (autrement dit, la même entrée ne produit pas toujours exactement le même résultat)
• Le problème de non-déterminisme existe aussi avec des bibliothèques d’inférence open source (vLLM, SGLang, etc.) et sur du matériel exploité en propre

Hypothèses classiques et leurs limites

• Hypothèse largement admise : le non-déterminisme vient de la concurrence + la non-associativité des flottants
  • Sur GPU, les opérations en virgule flottante peuvent produire des résultats légèrement différents selon l’ordre des opérations et l’ordre de terminaison des threads
• Mais en pratique, répéter exactement la même multiplication de matrices sur les mêmes données produit toujours un résultat identique (bw=bitwise equal)
• Il faut donc une analyse plus approfondie pour identifier la vraie cause

Analyse approfondie des causes du non-déterminisme en inférence LLM

Nature de la non-associativité des flottants

• Les opérations en virgule flottante vérifient la relation (a+b)+c ≠ a+(b+c)
• Lors d’opérations entre des valeurs de tailles différentes (exponent), il peut y avoir perte de précision et perte d’information, ce qui fait que le résultat varie selon l’ordre des calculs
• Comme l’ordre des opérations peut changer, exécuter plusieurs additions dans des ordres aléatoires conduit à des résultats variés (confirmés expérimentalement)

Variation de l’ordre des calculs dans les kernels et concurrence

• En général, on désigne souvent les problèmes de concurrence, comme l’addition atomique (atomic add), comme principale cause du non-déterminisme
• Mais la plupart des kernels utilisés en inférence LLM (en particulier lors du forward pass) fonctionnent sans addition atomique
• Avec une stratégie de parallélisation appropriée, un split (reduction), etc., il est possible de garantir le même ordre d’opérations

La cause centrale en pratique : l’absence d’« invariance au batch (batch invariance) »

• Chaque kernel pris individuellement renvoie toujours le même résultat à entrée identique (run-to-run deterministic)
• Mais comme les requêtes simultanées de plusieurs utilisateurs (batch size) varient de manière non déterministe, le résultat n’est pas stable en pratique pour chaque requête
• Selon la taille du batch, l’ordre interne de découpage ou de fusion des calculs change, ce qui introduit du non-déterminisme
• Autrement dit, la vraie cause est le fait que la charge serveur et le niveau de parallélisme (taille du batch) étaient non déterministes

Conception de kernels invariants au batch et cas des opérations clés

RMSNorm

• Application d’une stratégie de parallélisation orientée données (data-parallel) : chaque élément du batch est traité indépendamment par un cœur
• Si la taille du batch est grande, le parallélisme reste suffisant, donc la stratégie parallèle reste constante et l’invariance au batch est assurée
• Quand la taille du batch est très petite, on utilise des stratégies alternatives comme le split reduction, mais cela peut alors sacrifier une partie de l’invariance au batch

Multiplication de matrices (matmul)

• Utilisation d’une stratégie de parallélisation par tile pour exploiter le parallélisme des données
• Pour optimiser l’usage des Tensor Cores, il faut découper en tiles 2D, et pour des batches très petits, des stratégies spéciales comme split-K sont nécessaires
• L’usage de split-K peut rompre l’invariance au batch
• Même si cela coûte une partie des performances, il est possible de forcer une configuration de kernel identique afin de garantir un ordre d’exécution constant (reproducible)

Attention

• Avec FlashAttention2, etc., l’invariance au batch peut être assurée grâce à une parallélisation dans la direction des requêtes (query) et à une stratégie de reduction simultanée sur Key/Value
• Si l’ordre de reduction change selon la taille du batch ou le découpage de séquence (chunked prefill, prefix caching, etc.), l’invariance est rompue
• Dans les stratégies de split-reduction comme split-KV (FlashDecoding), il faut fixer la taille de split (fixed split-size) pour conserver le même ordre de calcul
• En interne, il faut aussi éviter de traiter séparément le cache key/value et les nouveaux tokens, et conserver une disposition cohérente des clés/valeurs dans toutes les opérations

Implémentation

• Une démo d’inférence déterministe appliquant des kernels invariants au batch est fournie à l’aide de vLLM et de torch.Library
• Les kernels de remplacement pour les opérations concernées sont disponibles dans le dépôt GitHub (thinking-machines-lab/batch-invariant-ops)

Expériences et performances

Expérience de mesure du non-déterminisme

• Avec le modèle Qwen/Qwen3-235B-A22B-Instruct-2507, génération 1000 fois du même prompt (« Tell me about Richard Feynman ») avec temperature 0
• 80 complétions différentes sont générées (preuve de non-déterminisme malgré un prompt identique)
• Les 102 premiers tokens sont identiques ; la première bifurcation apparaît au 103e token (« Queens, New York » vs « New York City »)
• Avec les kernels invariants au batch, les 1000 exécutions produisent exactement le même résultat, assurant une reproductibilité complète

Évaluation des performances

• Sur 1 GPU, exécution de Qwen-3-8B avec 1000 requêtes de séquences de longueur 90 à 110
  • vLLM standard : 26 secondes
  • vLLM déterministe non optimisé : 55 secondes
  • avec kernel d’attention amélioré : 42 secondes
• L’optimisation reste incomplète, mais le niveau de performance reste exploitable en pratique

Intérêt pour le RL on-policy

• Jusqu’ici, de légères différences numériques entre entraînement et inférence empêchaient une mise en œuvre exacte du RL on-policy
• Avec une inférence déterministe, il devient possible de rendre l’échantillonnage et l’entraînement bitwise identical, ce qui permet une véritable implémentation du RL on-policy
• Les métriques clés comme la KL-divergence et la reward montrent des résultats parfaitement identiques

Conclusion

• Dans les systèmes d’inférence LLM, il est facile de négliger le non-déterminisme et les erreurs numériques, mais en identifiant et en corrigeant leur cause fondamentale (l’absence d’invariance au batch), on peut obtenir une reproductibilité et un déterminisme complets
• Cette étude met en lumière une méthode pour résoudre le problème du non-déterminisme en inférence LLM et aide les développeurs à garantir une reproductibilité totale dans leurs propres systèmes

Informations de citation

• Pour citer cette étude, utilisez les informations suivantes

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}
}