Pourquoi les LLM restent non déterministes même à une température nulle

En septembre 2025, des chercheurs de Thinking Machines ont démontré que les grands modèles de langage (LLM) ne parviennent pas à produire des sorties identiques, même lorsqu'ils sont configurés pour un maximum de déterminisme. En envoyant la même requête mille fois avec une température réglée sur zéro, ils ont obtenu quatre-vingts complétions différentes. Cette découverte souligne un défi architectural critique pour les développeurs qui construisent des systèmes d'IA en production : les modèles génératifs sont intrinsèquement probabilistes, et non déterministes.

Ce qui s'est passé

L'expérience portait sur une simple requête demandant des informations sur Richard Feynman. L'équipe a utilisé un modèle ouvert avec une température nulle, un paramètre théoriquement conçu pour toujours sélectionner le token suivant le plus probable. Malgré cette contrainte, les sorties ont divergé après les 102 premiers tokens. Alors que 992 réponses indiquaient que Feynman était né au Queens, New York, huit autres citaient New York City. Cette variation est apparue malgré des entrées et des graines (seeds) identiques, prouvant que les paramètres de configuration standard ne garantissent pas la reproductibilité.

Ce comportement ne se limite pas aux benchmarks académiques. Dans les environnements de production, les développeurs rencontrent souvent des situations où une démo fonctionne parfaitement, mais où la même entrée produit des résultats différents lors de présentations clients ou d'utilisations en direct. Le problème devient critique lorsque les agents IA prennent des décisions impliquant de l'argent, le contrôle d'accès ou la conformité. Contrairement aux logiciels traditionnels, où un bug produit la même erreur à chaque fois, un LLM peut donner une réponse correcte lors d'une exécution et incorrecte lors de la suivante, rendant le débogage et l'audit considérablement plus difficiles.

La cause profonde réside dans le fonctionnement des serveurs d'inférence. Les fournisseurs regroupent les requêtes en lots (batches) pour optimiser l'utilisation des GPU. Les recherches indiquent que les kernels GPU courants ne sont pas invariants par lot, ce qui signifie que les résultats mathématiques peuvent varier légèrement selon le nombre de requêtes concurrentes. Lorsque deux tokens potentiels ont des probabilités presque identiques, ces infimes différences numériques poussent le modèle à choisir des chemins différents, entraînant une génération de texte divergente. De plus, les mises à jour côté fournisseur des piles de service ou des versions de modèles peuvent modifier le comportement sans préavis, compromettant davantage la reproductibilité.

Comment cela fonctionne

Les systèmes déterministes, tels que les moteurs de règles ou les classificateurs entraînés avec des poids figés, fonctionnent comme des fonctions pures. Ils mappent des entrées spécifiques vers des sorties spécifiques sans échantillonnage à partir d'une distribution. Si vous les exécutez deux fois avec les mêmes données, vous obtenez exactement le même résultat, octet par octet. Cela permet les tests unitaires, la comparaison de versions et des pistes d'audit claires. En revanche, les LLM ne renvoient pas directement des réponses. Ils calculent une distribution de probabilité pour chaque token suivant possible, puis effectuent un échantillonnage à partir de cette distribution.

Même lorsque la température est réglée sur zéro, le processus d'échantillonnage reste vulnérable aux facteurs externes. Le paramètre seed proposé par de nombreux fournisseurs est décrit comme « best-effort » (au mieux). Il ne peut pas tenir compte des changements dans l'état matériel sous-jacent, des tailles de batch ou des mises à jour silencieuses des modèles. De plus, les agents dépendent souvent d'outils externes comme les moteurs de recherche ou les bases de données. Comme ces sources évoluent avec le temps, le contexte fourni au modèle dérive, garantissant qu'aucune deux exécutions ne soient véritablement identiques. Comme noté dans une étude de 2024, la précision sur les tâches de benchmark peut varier jusqu'à quinze pour cent entre les exécutions sous des paramètres déterministes, avec des écarts atteignant soixante-dix pour cent dans les cas extrêmes.

Détails clés

• Thinking Machines a observé 80 complétions différentes à partir de 1 000 requêtes identiques à température nulle.
• La divergence survient généralement lorsque les tokens candidats ont des probabilités quasi égales, influencée par le batching côté serveur.
• Des kernels invariants par lot peuvent imposer le déterminisme, mais risquent d'augmenter la latence d'inférence de 26 à 55 secondes.
• Les alias de modèles des fournisseurs peuvent pointer vers des versions mises à jour, provoquant des changements de comportement silencieux en production.
• Les classificateurs ML traditionnels offrent des sorties entièrement reproductibles entre les releases, contrairement aux modèles génératifs.
• La non-déterminisme se concentre sur les cas limites où le modèle est réellement incertain.

Pourquoi c'est important

Pour les ingénieurs logiciels et les fondateurs techniques, traiter les LLM comme des composants déterministes conduit à des architectures fragiles. Lorsqu'un système d'IA contrôle des transactions financières, des permissions utilisateur ou la conformité réglementaire, la variabilité est un risque. Une plainte client concernant un remboursement refusé ne peut être résolue en relançant la requête, car le modèle pourrait fournir une justification ou un résultat différent. Ce manque de reproductibilité complique les tests de régression et rend difficile l'explication des décisions aux auditeurs ou aux équipes juridiques.

Comprendre la distinction entre l'IA déterministe et probabiliste permet aux équipes d'allouer les tâches de manière appropriée. Les modèles génératifs excellent dans l'interprétation de données non structurées et la rédaction de textes, mais ils ne devraient pas être seuls responsables des décisions finales. En reconnaissant que la non-déterminisme est une caractéristique de la technologie plutôt qu'un bug, les développeurs peuvent concevoir des systèmes qui isolent la logique critique dans des couches déterministes. Cette approche garantit que le produit reste testable, explicable et fiable, même lorsque le modèle de langage sous-jacent se comporte de manière imprévisible.

Ce que vous pouvez faire

• Implémentez des règles strictes dans le code pour les limites, les permissions et les calculs arithmétiques, plutôt que de compter sur les instructions de prompt.
• Utilisez des classificateurs calibrés pour les décisions à haut volume lorsque des données historiques étiquetées sont disponibles.
• Contraintes les sorties des LLM à des schémas JSON stricts avec des valeurs énumérées pour réduire la variation.
• Définissez des échelles d'évaluation explicites dans les prompts avec des exemples concrets pour ancrer les jugements du modèle.
• Exécutez plusieurs fois les requêtes critiques et utilisez le vote ou la moyenne pour estimer les niveaux de confiance.
• Journalisez toutes les entrées, versions de modèles et sorties pour permettre l'audit sans régénérer les réponses.