Guide de l’inférence IA
Pourquoi l’inférence est non déterministe
Le mythe de la question « identique »
Les sorties d’un LLM peuvent varier même lorsque deux requêtes semblent identiques. L’échantillonnage introduit délibérément de la variation ; les changements de service, le contexte masqué, les résultats d’outils et certains noyaux parallèles peuvent en ajouter. Une reproductibilité au bit près exige la maîtrise de l’entrée complète, de la configuration de décodage, de la version du modèle et du runtime, ainsi que de l’environnement d’exécution.
À retenir : les variations proviennent de quatre domaines principaux : génération et échantillonnage, contexte et entrée, système et architecture, matériel et implémentation. Comprendre ces facteurs est essentiel pour bâtir des systèmes IA fiables.
Catégorie 1 : paramètres délibérés de génération et d’échantillonnage
Le « coup de dés » : l’échantillonnage peut accroître la diversité des sorties
1. Température
Rééchelonne les logits des jetons avant l’échantillonnage, ce qui modifie la concentration de la distribution de probabilité.
2. La graine
Les ordinateurs utilisent une « graine » (nombre de départ) pour produire des suites pseudo-aléatoires.
3. Top-P (échantillonnage par noyau)
Le modèle échantillonne dans le plus petit ensemble de jetons dont la probabilité cumulée atteint le seuil (par exemple 0,9). L’ensemble de candidats est recalculé à chaque étape de génération.
4. Top-K
Le modèle échantillonne parmi les K jetons les plus probables (par exemple les 50 premiers).
5. Autres stratégies d’échantillonnage
Des échantillonneurs comme Mirostat ou le typical sampling appliquent d’autres règles pour choisir les jetons candidats.
Catégorie 2 : réglages de requête qui façonnent la sortie
Modifier ces réglages change le contrat de sortie ; ce n’est pas une preuve de non-déterminisme
6. Pénalités de répétition, de fréquence et de présence
Ces réglages abaissent le score des jetons déjà apparus et peuvent décourager la répétition. Changer une pénalité change la distribution des candidats, même à graine fixe.
7. Conditions d’arrêt (max tokens)
Limite stricte sur la longueur de la réponse. Une exécution avec max_tokens=50 diffère d’une exécution avec max_tokens=500.
8. Conditions d’arrêt (séquences d’arrêt)
Le modèle s’arrête s’il génère une chaîne configurée (par exemple "\nHuman:"). Avec un échantillonnage stochastique, différents chemins peuvent rencontrer une séquence d’arrêt à des endroits différents.
Catégorie 3 : variables de contexte et d’entrée
La « mémoire » : l’entrée du modèle contient souvent plus que le dernier message de l’utilisateur
9. Historique de conversation (la fenêtre de contexte)
Raison la plus fréquente d’un non-déterminisme perçu. Le modèle voit toute la conversation précédente, pas seulement la dernière question.
Un seul jeton modifié crée une entrée différente et peut changer la sortie
10. Limite de la fenêtre de contexte (le point d’« oubli »)
Les modèles ont des fenêtres de contexte finies dont la taille varie selon le modèle. Les longues conversations peuvent être tronquées, résumées ou rejetées par l’application ; ce qui se trouve hors du contexte soumis est inaccessible au modèle.
11. Prompt système
Instruction prioritaire fournie par l’application ou l’API. Elle peut être visible du développeur mais masquée pour l’utilisateur final, et sa modification peut altérer le style et le comportement des réponses.
12. Recherche documentaire et outils externes
Source majeure de variation d’entrée d’une requête à l’autre. Dans un flux ancré sur une recherche, l’application peut :
- Suspendre la génération
- Appeler un outil externe (par exemple l’API Google Search)
- Recevoir de nouvelles données dynamiques (résultats de recherche)
- Injecter ces données dans le contexte
Les résultats d’outils peuvent changer d’une requête à l’autre, ce qui change l’entrée du modèle et peut changer la réponse
Catégorie 4 : variables de système et d’architecture
L’« orchestre » : le « modèle » est souvent un système complexe composé de plusieurs modèles
13. Mises à jour et versions du modèle
Le modèle que vous utilisez aujourd’hui peut être une version nouvelle, réentraînée ou mise à jour par rapport à hier. Un modèle v1.2 répondra différemment d’un modèle v1.3.
14. Tests A/B et déploiements canari
Un fournisseur ou votre propre passerelle peut répartir le trafic entre plusieurs versions pendant un déploiement. Sans épinglage de version, deux requêtes peuvent atteindre des déploiements différents et produire des réponses différentes.
15. Décodage spéculatif
Un modèle brouillon propose des jetons que le modèle cible vérifie. Les implémentations exactes visent à préserver la distribution cible, mais des différences de runtime, de batching, d’approximation ou de configuration peuvent tout de même affecter la reproductibilité.
16. Architecture à mélange d’experts (MoE)
Un routeur sélectionne un sous-ensemble d’experts pour chaque jeton. La fonction de routage peut être déterministe à entrée fixe, tandis que les limites de capacité, le batching et les détails d’implémentation peuvent créer une variation au niveau du déploiement.
Catégorie 5 : matériel et implémentation bas niveau
La « physique » : la source de variation la plus profonde et la plus difficile à maîtriser
Attention : certains choix d’exécution peuvent varier même lorsque la température vaut 0 et que la graine est fixée.
17. Noyaux parallèles et ordre de réduction en virgule flottante
Des opérations fixes dans un ordre fixe peuvent être reproductibles. La variation peut apparaître lorsque des noyaux parallèles ou des réductions s’exécutent dans un ordre différent et que les écarts d’arrondi se propagent :
- Parallélisme : les GPU effectuent des milliards de calculs en parallèle
- Arithmétique en virgule flottante : le calcul décimal machine n’est pas parfaitement associatif
- Conséquence : de petits écarts de score peuvent changer le jeton retenu lorsque les candidats sont très proches
Exemple : (a+b)+c ≠ a+(b+c) à cause des arrondis → 0,81234567 contre 0,81234568 → un autre mot est choisi
18. Configuration de quantification
Un modèle quantifié utilise des représentations de précision inférieure à celles d’une autre version et peut donc produire des scores ou des sorties différents. Un couple modèle quantifié et runtime figé n’est pas non déterministe en soi ; consignez la quantification et le runtime exacts comme partie intégrante de la version du modèle.
19. Batching
Votre requête est traitée dans un « lot » avec celles d’autres utilisateurs. La façon dont ces requêtes sont regroupées et complétées peut changer l’ordre exact des calculs GPU et déclencher les effets de virgule flottante.
20. Dropout au moment de l’inférence
Le dropout est normalement désactivé en inférence. Des techniques de recherche comme le dropout de Monte-Carlo le laissent délibérément actif ; un runtime de production configuré ainsi sera stochastique tant que son état aléatoire n’est pas contrôlé.
Points clés pour les développeurs
Approcher le déterminisme
- Fixer la température à 0 (décodage glouton)
- Utiliser une valeur de graine fixe
- Contrôler exactement tout le contexte d’entrée
- Utiliser la même version de modèle
- Accepter que des variations au niveau matériel restent possibles
Assumer le non-déterminisme
- Concevoir des systèmes qui absorbent la variation
- Utiliser des métriques d’évaluation qui tiennent compte de l’équivalence sémantique
- Réserver les nouvelles tentatives, en nombre borné, aux opérations sûres ou idempotentes
- Viser la constance de la qualité plutôt que des sorties identiques