CONCEPTS — TROIS MESURES · NON-DÉTERMINISME DE L'INFÉRENCE
Résultats de recherche, documentations de moteurs d'inférence et chiffres relevés le 10 août 2026 sur les publications et les pages officielles citées. Cet article est une analyse : aucun test n'a été exécuté pour l'écrire, et le protocole de la dernière section est destiné à être exécuté par le lecteur, sur son propre système.
Posez deux fois exactement la même question. Même modèle, même version, même invite, curseur de créativité à zéro. Vous vous attendez à deux réponses identiques : c'est ce que le réglage semble promettre. Vous obtiendrez parfois deux réponses différentes — pas très différentes, souvent un mot, une virgule, un chiffre en fin de calcul. Assez pour qu'une comparaison automatique déclare un écart, et pour qu'une chaîne de test rougisse sans que rien n'ait changé.
La thèse de cet article est simple, et elle déplace le problème d'un cran : ce non-déterminisme ne vient pas du modèle, il vient de la manière dont on le sert. Plus précisément, du nombre de requêtes qui se trouvent partager le même lot de calcul à l'instant où la vôtre passe. C'est une propriété de votre infrastructure, pas un réglage de votre requête — et cela change entièrement ce qu'il faut faire pour y remédier, ou pour vivre avec.
« Température 0 » ne promet pas ce qu'on lui prête
Un modèle de langage ne produit pas un mot, il produit une distribution de probabilités sur le vocabulaire, à chaque pas. Le décodage est ce qui transforme cette distribution en un token choisi. Mettre la température à zéro revient à supprimer le tirage au sort : on prend systématiquement le token le plus probable. C'est ce que détaille l'article Temperature, top-p : les curseurs qui rendent une IA créative ou déterministe.
Le second réglage auquel on prête cette vertu est la graine aléatoire. La documentation de reproductibilité du moteur d'inférence vLLM est explicite sur son périmètre : le paramètre seed « is used to control the random states for various random number generators ». Il fixe le hasard du tirage. Il ne fixe pas l'arithmétique.
La même page pose deux conditions que l'on oublie régulièrement de citer. La reproductibilité n'est obtenue qu'en désactivant le multiprocessing du moteur, ou en activant un mode dédié dont il sera question plus bas. Et elle ne vaut, dans tous les cas, que « when it runs on the same hardware and the same vLLM version ». Changez de génération de carte, changez de version du serveur : la garantie tombe, sans qu'aucun de vos paramètres n'ait bougé.
La cause la plus citée n'est pas la bonne
L'explication qui circule depuis des années tient en deux mots : arithmétique flottante. L'addition en virgule flottante n'est pas associative — (a+b)+c ne donne pas toujours exactement a+(b+c) — et un processeur graphique répartit une même somme sur des milliers de fils d'exécution dont l'ordre d'arrivée varie. D'où, conclut-on, des résultats qui diffèrent au dernier bit.
Le raisonnement est juste sur les prémisses et faux sur la conclusion. Un travail publié le 10 septembre 2025, « Defeating Nondeterminism in LLM Inference », montre que les noyaux de calcul concernés sont, pris isolément, parfaitement reproductibles d'une exécution à l'autre : relancez deux fois la même multiplication matricielle sur les mêmes données, vous obtenez le même résultat au bit près. La non-associativité existe, mais elle ne suffit pas à produire l'instabilité observée.
Le facteur qui la produit est ailleurs, et le texte le nomme sans détour : « the primary reason nearly all LLM inference endpoints are nondeterministic is that the load (and thus batch-size) nondeterministically varies! ». Autrement dit : votre requête n'est pas calculée seule. Elle est agrégée avec celles des autres utilisateurs dans un lot, et la taille de ce lot dépend de la charge à la milliseconde près. Or les noyaux optimisés changent de stratégie de découpage selon la taille du lot — donc changent l'ordre dans lequel ils additionnent. Le résultat bouge au dernier bit, et parfois cela suffit.
| Propriété | Ce qu'elle dit | Vraie sur un moteur standard ? |
|---|---|---|
| Reproductibilité d'exécution | Le même calcul, relancé sur les mêmes entrées, rend le même résultat | Oui, pour les noyaux concernés |
| Invariance par lot | Le résultat pour votre requête ne dépend pas du nombre de requêtes calculées en même temps | Non — et c'est là qu'est le non-déterminisme |
La conséquence est contre-intuitive : votre réponse dépend de ce que d'autres personnes ont demandé au même instant. Rien dans votre requête ne le laisse voir, rien dans votre code ne peut le corriger.
Ce que l'invariance par lot rend possible
Le correctif est décrit dans le même travail, et il est de nature bien précise : réécrire les noyaux pour que « the reduction order for each element must be fixed regardless of the batch-size of the kernel ». Fixer l'ordre des sommes, quelle que soit la charge. Trois noyaux ont été traités : la normalisation RMSNorm, la multiplication matricielle et l'attention.
La mesure qui accompagne cette réécriture est le chiffre à retenir de l'article. Sur le modèle Qwen/Qwen3-235B-A22B-Instruct-2507, mille complétions ont été demandées à partir de la même invite. Avant intervention : 80 réponses distinctes sur 1 000. Après activation des noyaux invariants : les 1 000 complétions sont identiques.
Le prix de la reproductibilité
Fixer l'ordre des réductions coûte du débit : on renonce à une partie des optimisations qui rendent le service rapide. Le même travail donne les temps mesurés sur sa charge d'essai : 26 secondes pour le moteur par défaut, 55 secondes pour la version déterministe naïve, 42 secondes une fois le noyau d'attention retravaillé. L'ordre de grandeur est là : une reproductibilité stricte se paie en latence, et elle se paie d'autant plus qu'on la veut sur toute la chaîne.
C'est exactement le compromis inverse de celui que décrit D'où vient la latence : batching, streaming, décodage spéculatif. Le regroupement dynamique des requêtes est ce qui rend l'inférence économiquement soutenable : il amortit le coût du chargement des poids sur plusieurs demandes. Le non-déterminisme n'est pas un défaut collatéral de cette optimisation, il en est la contrepartie directe.
Ce que cela casse, concrètement
Tant que l'IA sert à rédiger, l'écart passe inaperçu. Il devient coûteux dès qu'un chiffre issu du modèle sert à décider quelque chose.
| Usage | Ce qui se passe | Le geste correctif |
|---|---|---|
| Évaluation de qualité | Deux campagnes séparées par une nuit donnent des scores différents à modèle constant | Rejouer la campagne N fois et publier un intervalle, jamais un point |
| Test de non-régression | La chaîne rougit sur une comparaison stricte de texte, sans qu'aucune ligne ait changé | Comparer sur une propriété (structure, contrainte respectée), pas sur l'octet |
| Comparaison de modèles | Un écart de deux points sur un classement est plus petit que la variance interne | Ne conclure que sur des écarts supérieurs à votre propre dispersion |
| Reproduction d'incident | La sortie fautive ne se reproduit pas, on classe l'incident « non reproductible » | Journaliser la sortie complète au moment de l'incident, pas seulement l'invite |
| Audit et preuve | Impossible de démontrer qu'une décision passée serait rejouée à l'identique | Conserver la sortie signée et datée, plutôt que promettre de la régénérer |
Le troisième cas mérite qu'on s'y arrête, parce qu'il touche à une pratique très répandue. Choisir entre deux modèles sur deux points d'écart au classement suppose que ces deux points soient significatifs. Ils ne le sont que si votre dispersion d'exécution est plus petite qu'eux — ce que presque personne ne vérifie. C'est un cousin direct du problème décrit dans Benchmarks & contamination : pourquoi les classements de modèles mentent : la précision affichée d'un chiffre n'est pas sa fiabilité.
Le même raisonnement s'applique à vos propres mesures. Une chaîne d'évaluation maison, telle que la décrivent Évaluer une sortie d'IA : les evals et, côté mise en œuvre, Mesurer la qualité d'un assistant IA en production, produit un score. Ce score a une barre d'erreur que le non-déterminisme d'inférence alimente, en plus de l'échantillonnage des cas de test. La barre d'erreur n'apparaît nulle part si l'on ne la mesure pas.
Enfin, la question des tests. Tests à l'ère de l'IA : le test reste une décision pose que l'on ne teste pas une sortie de modèle comme une fonction pure. Le non-déterminisme d'inférence en donne la raison mécanique : une sortie de modèle n'est pas une fonction pure de son entrée, tant qu'elle est calculée sur une infrastructure partagée. Ce n'est pas de la prudence méthodologique, c'est une propriété du système.
Le protocole, à exécuter chez vous
Aucun chiffre de cet article ne décrit votre installation. La seule façon de savoir ce que vaut votre reproductibilité est de la mesurer, et l'opération est courte.
Un mot sur ce que ce protocole ne mesure pas. Compter des réponses textuellement distinctes est un indicateur grossier : deux réponses peuvent différer sur un mot sans importance, ou coïncider par chance alors que les probabilités internes ont bougé. Un préprint de 2026 consacré à cette question montre que l'instabilité reste visible dans les probabilités des tokens même lorsque le texte produit, lui, ne varie pas. Si votre fournisseur vous donne accès à ces probabilités, elles constituent une mesure plus fine — et plus précoce.
Ce que cela change dans la conduite d'un projet
La tentation naturelle, une fois le mécanisme compris, est de chercher à tout rendre déterministe. C'est presque toujours le mauvais arbitrage : vous paierez le débit de toute votre production pour une propriété dont seuls quelques usages ont besoin. La question utile n'est pas « comment supprimer la variabilité », mais « où ai-je promis qu'il n'y en aurait pas ».
Cette promesse se cache à des endroits inattendus. Dans un contrat qui parle de résultat « constant ». Dans une procédure qualité qui prévoit de « rejouer » une décision. Dans une chaîne de traitement où la sortie d'un modèle alimente un identifiant, une clé de cache ou un tri. Chacune suppose une stabilité que l'infrastructure ne garantit pas par défaut, et qu'aucun réglage d'API ne rétablira.
Pour une équipe qui héberge son propre modèle, la conséquence est directe et documentée : la reproductibilité tient au trio version du moteur, version des poids, génération de matériel. Ce trio doit figurer dans les métadonnées de chaque campagne de mesure, au même titre que le nom du modèle. C'est une exigence de plus dans la liste de Servir un modèle IA à toute une équipe, en interne — et l'une des rares qui ne coûte rien à mettre en place, tant qu'on y pense avant.
Reste le fond du sujet, qui dépasse largement l'inférence : le coût de la vérification. Une sortie qu'on ne peut pas rejouer doit être vérifiée au moment où elle est produite, pas plus tard. C'est le déplacement de charge qu'analyse Quand vérifier coûte plus cher que produire, et le non-déterminisme en est l'illustration la plus matérielle qui soit.
Les moteurs d'inférence évolueront, les noyaux invariants se généraliseront peut-être, et le surcoût baissera. Ce qui ne bougera pas, c'est le fait qu'un service partagé arbitre en permanence entre débit et stabilité, et que cet arbitrage se fait sous vos requêtes sans vous demander votre avis. Les mouvements de produits et de moteurs sont suivis dans le radar IA et dans le bulletin Nouveautés.
Une question, un projet IA ?
Vous montez une chaîne d'évaluation ou un test de non-régression sur des sorties de modèle, et les résultats bougent sans raison apparente ? Échangeons sur votre contexte.
Prendre contact →