Stratégies pour la reproductibilité de l’inférence des LLM

Synthèse

Chez Zokforce, nous avons constaté que le processus d’inférence des grands modèles de langage (LLM) est intrinsèquement non déterministe : un modèle peut produire des sorties différentes même à partir de prompts identiques. Si l’aléatoire délibéré est utile aux tâches créatives, une forme plus profonde et systémique de non-déterminisme afflige les systèmes en production.

Des travaux récents, menés notamment par Thinking Machines Lab, montrent que l’hypothèse classique « concurrence + virgule flottante » est incomplète. La cause profonde est l’absence d’« invariance au lot » (batch invariance) – une charge serveur imprévisible oblige les moteurs d’inférence à modifier dynamiquement la taille des lots, ce qui change les stratégies d’exécution internes des noyaux et entraîne des différences de sortie au niveau du bit.

La distinction essentielle : stochasticité ou non-déterminisme

Pour comprendre le non-déterminisme des LLM, il faut distinguer deux formes d’aléatoire :

Pourquoi la reproductibilité compte pour les entreprises

Analyse approfondie : les sources du non-déterminisme

Non-déterminisme des LLMDes sorties différentes pour des prompts identiques

Impact élevéProblème de l’invariance au lotLa taille dynamique des lots modifie l’exécution des noyaux

Impact moyenNon-associativité de la virgule flottanteLe vecteur de la variation, pas sa cause profonde

ContrôlableStochasticité intrinsèqueÉchantillonnage aléatoire : temperature, top_p et seed

Trois sources principales contribuent au comportement non déterministe des systèmes d’inférence de LLM

1. Le problème de l’invariance au lot

Les services de LLM en production maximisent l’utilisation des GPU en regroupant plusieurs requêtes d’utilisateurs en lots. Le problème central : un changement de taille de lot impose des stratégies de noyau internes entièrement différentes.

# Example: Same operation, different batch contexts
# Batch size = 4 users
result_1 = process_batch([user1, user2, user3, user4])

# Batch size = 1 user (different kernel strategy)
result_2 = process_batch([user1])

# Result: Different outputs for user1 due to kernel optimization differences

Lorsque les lots sont trop petits pour exploiter tous les cœurs du GPU, les ingénieurs passent à des stratégies de « réduction fractionnée » (split-reduction), où plusieurs cœurs collaborent à un même calcul, ce qui modifie l’ordre des opérations et rompt l’invariance au lot.

2. La non-associativité de la virgule flottante

Bien qu’elle soit souvent citée comme la cause principale, l’arithmétique en virgule flottante n’est que le vecteur par lequel la variation se manifeste. Les recherches montrent que des opérations individuelles comme torch.mm(A, B) sont déterministes lorsqu’on les exécute à répétition avec des entrées identiques.

3. La stochasticité intrinsèque des LLM

Les LLM génèrent du texte en prédisant des distributions de probabilité pour les tokens suivants. Trois grandes stratégies de décodage contrôlent cette génération :

Cadre de solution multicouche

Couche 1Noyaux et frameworks

• Noyaux invariants au lot
• Algorithmes déterministes
• Contrôles des frameworks

Couche 2API et application

• Paramètres seed
• Temperature = 0
• Sortie structurée

Couche 3Ingénierie de prompts

• Prompts déterministes
• Exemples few-shot
• Prompting négatif

Couche 4MLOps et flux de travail

• Gestion des versions
• Couches de cache
• Documentation de l’environnement

Quatre couches intégrées qui agissent ensemble pour atteindre une reproductibilité de niveau entreprise

Couche 1 : socle des noyaux et des frameworks

Principales stratégies de mise en œuvre :

• RMSNorm : ordre de réduction fixe, quelle que soit la taille du lot
• Multiplication matricielle : configuration de noyau fixe, indépendante de la forme du lot
• Mécanismes d’attention : réduction fractionnée avec une taille de fraction fixe

Contrôles de déterminisme propres à chaque framework :

Référence technique pour mettre en œuvre des contrôles déterministes dans différents frameworks

Couche 2 : contrôles au niveau de l’API et de l’application

Couche 3 : l’excellence en ingénierie de prompts

Des prompts conçus pour le déterminisme restreignent efficacement l’espace de sortie du modèle :

# Example: Deterministic Prompt Structure
prompt = f"""
Task: Extract key information from the following contract.
Output Format: JSON with fields: party1, party2, date, amount
Requirements: 
- Use exact text from document
- Return "N/A" if information not found
- No additional commentary

Contract: {contract_text}

JSON Response:
"""

Couche 4 : MLOps et gestion des flux de travail

Arbitrages entre performance et reproductibilité

Reproductibilité ↑

1 2 3 4

Performance →

1

Par défaut (non déterministe)

2

Noyaux invariants au lot

3

Mode déterministe du framework

4

Échantillonnage contrôlé

Différentes approches positionnées selon leur impact sur la performance et la reproductibilité obtenue

Quantifier les coûts

Atteindre le déterminisme implique des compromis de performance mesurables :

Guide de mise en œuvre en entreprise

Phase 1 : évaluation et fondations (mois 1-2)

Phase 2 : mise en œuvre et tests (mois 3-6)

# Example: PyTorch Deterministic Configuration
import torch
import os
import random
import numpy as np

def setup_deterministic_environment():
    # Set all random seeds
    torch.manual_seed(42)
    torch.cuda.manual_seed(42)
    torch.cuda.manual_seed_all(42)
    np.random.seed(42)
    random.seed(42)
    
    # Enable deterministic algorithms
    torch.use_deterministic_algorithms(True)
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False
    
    # CUDA environment variables
    os.environ['CUBLAS_WORKSPACE_CONFIG'] = ':16:8'
    os.environ['PYTHONHASHSEED'] = str(42)

Phase 3 : déploiement en production (mois 6-9)

Études de cas concrètes

Étude de cas 1 : traitement documentaire dans les services financiers

Étude de cas 2 : plateforme de recherche en santé

Perspectives et solutions émergentes

Technologies émergentes

• Noyaux invariants au lot avancés : surcoût de performance réduit, déterminisme préservé
• Approches hybrides : bascule dynamique entre modes déterministe et non déterministe
• Accélération matérielle : puces spécialisées, optimisées pour l’inférence d’IA déterministe
• Normalisation des protocoles : normes sectorielles pour un déploiement d’IA reproductible

Références et lectures complémentaires

1. Sitation.com. « Output from AI LLMs is Non-Deterministic. What that means and why you should care. » Lien
2. AIMultiple Research. « Reproducible AI: Why it Matters & How to Improve it. » Lien
3. StartupHub.ai. « The Real Reason for LLM Inference Nondeterminism. » Lien
4. Thinking Machines Lab. « Defeating Nondeterminism in LLM Inference. » Publication Medium.
5. Microsoft Azure. « How to generate reproducible output with Azure OpenAI. » Lien
6. Documentation PyTorch. « Reproducibility Guidelines. » Lien
7. Hugging Face. « Reproducible pipelines documentation. » Lien
8. NVIDIA GTC 2024. « Restoring the Scientific Method to HPC: High Performance Reproducible Parallel Reductions. »