Le principe
Même à température nulle — quand on lui demande la réponse la plus probable et rien d'autre — un LLM servi derrière une API ne rend pas toujours la même sortie pour la même entrée. Ce n'est pas un réglage oublié : c'est une propriété de la façon dont il est servi, et elle se cadre plutôt qu'elle ne se corrige.
L'explication courante — arrondis flottants plus exécution concurrente sur GPU — est incomplète. La cause première est l'absence d'invariance au batch : la sortie d'une requête dépend du nombre de requêtes servies en même temps qu'elle. Les auteurs l'ont prouvé en réécrivant les noyaux de calcul : mille exécutions, mille sorties identiques. Le non-déterminisme se maîtrise donc quand on contrôle la pile d'inférence — mais derrière une API tierce, vous ne la contrôlez pas. thinkingmachines.ai
La règle
Pour chaque tâche, avant d'y mettre une IA, une seule question :
Le résultat doit-il être reproductible et auditable ?
Les deux cas
- Oui → déterministe. Calculs, règles métier, conformité, montants, décisions traçables. Ça se câble en dur — code, automatisation. L'IA prépare, elle ne tranche jamais seule.
- Non → non-déterministe assumé. Rédaction, exploration, synthèse, jugement sous incertitude. La variabilité devient un atout — à condition de la contenir.
Placer un LLM sur une tâche déterministe est l'erreur d'architecture la plus coûteuse que je rencontre.
Contenir le non-déterminisme (quand on le garde)
- Sortie contrainte — imposer un schéma ou un format de réponse strict.
- Garde-fous déterministes — validation, bornes, vérifications autour de l'appel.
- Évaluation systématique — une IA-juge qui note les sorties sur une grille, pour détecter la dérive avant la production, pas en production.
À retenir
La bonne question n'est pas « quel modèle ? » mais « cette tâche doit-elle être reproductible ? ». C'est cette ligne de partage — pas la puissance du modèle — qui sépare un POC qui impressionne d'un système qui tient.