SDXL : trop de stochasticité tue la stochasticité

Introduction

Depuis plusieurs mises à jour récentes Intel (pilotes GPU, AIPG, ComfyUI, backends oneAPI/WGPU), l’écosystème SDXL traverse une rupture technique et fonctionnelle majeure. Ce n’est pas seulement une régression de reproductibilité : c’est une altération simultanée du déterminisme et de la qualité visuelle, qui transforme des heures de travail créatif en résultats totalement aléatoires pour un même seed. Cet article rassemble, de façon factuelle et détaillée, les mécanismes techniques en cause, leurs effets concrets sur SDXL et les LoRAs, et la logique commerciale qui sous‑tend ces choix.

Le déterminisme brisé et ce que cela signifie

Déterminisme par seed signifie qu’un même seed, un même modèle et des mêmes paramètres produisent la même image. Historiquement, SDXL offrait cette garantie pratique : relancer l’interface ou redémarrer la machine ne changeait pas sensiblement le rendu pour un même seed. Aujourd’hui, sur certaines configurations (notamment Intel Arc avec oneAPI/WGPU et wrappers imposés), cette garantie n’existe plus. Le même seed peut donner des images radicalement différentes d’un lancement à l’autre. Ce n’est pas du simple « bruit » : la composition, les visages, l’application d’une LoRA et la cohérence stylistique peuvent diverger. La perte de déterminisme rend impossible la reproduction fidèle d’un style obtenu après des heures d’entraînement et d’itération.

Mécanismes techniques responsables

Recompilation dynamique des kernels Les backends modernes peuvent compiler ou recompiler des kernels selon l’environnement, l’ordre de chargement ou des heuristiques. Des kernels différents exécutent mathématiquement les mêmes opérations mais avec des micro‑variations d’arrondi et d’ordre d’évaluation. En faible précision, ces micro‑variations sont amplifiées par les étapes successives de la diffusion et deviennent visibles.

Conversions et mélanges de précision Les pipelines mélangent FP16, BF16 et FP32 pour gagner en performance. Chaque conversion FP16↔FP32 ou BF16↔FP32 introduit arrondis et pertes. L’ordre et la granularité de ces conversions (par exemple attention upcastée en FP32 puis retombée en FP16) changent selon le kernel et le backend, ce qui modifie le résultat final. Sur certaines architectures, les implémentations matérielles de ces conversions sont moins déterministes.

Ordre de chargement et application des LoRAs Le chargement des modules et des LoRAs (mmap, caches, timing) peut varier. SDXL et les LoRAs sont sensibles à l’ordre d’application : un changement d’ordre ou une différence de dtype lors du chargement peut altérer la façon dont une LoRA module les poids, produisant des styles différents pour le même seed.

Wrappers et whitelists de flags Des wrappers de lancement filtrent, réécrivent ou bloquent les flags. Plutôt que d’exposer le contrôle fin, ils imposent des heuristiques (activer WGPU, forcer BF16, interdire la désactivation de certains backends). L’utilisateur perd la maîtrise du pipeline et se retrouve soumis à des choix opaques qui favorisent la performance au détriment du déterminisme.

Optimisations pilotes agressives et modifications irréversibles Les mises à jour de pilotes peuvent introduire de nouveaux chemins d’exécution et transformations internes qui améliorent les benchmarks mais modifient l’ordre d’évaluation et les arrondis. Certaines modifications touchent des fichiers ou caches difficiles à rollback, rendant la régression difficilement réversible pour des configurations « full Intel ».

Comment le manque de déterminisme dégrade la qualité SDXL

Amplification des micro‑erreurs De petites différences numériques se propagent et s’amplifient dans le processus itératif de diffusion. Un arrondi différent dans une couche d’attention peut, après plusieurs étapes, produire un visage mal proportionné ou une texture floue.

Application instable des LoRAs Les LoRAs modifient finement des couches. Si leur application dépend du dtype, de l’ordre de chargement ou d’un kernel recompilé, le style n’est plus appliqué de façon stable. Le même entraînement de LoRA peut donner des rendus divergents, rendant l’itération stylistique impossible.

Perte de détails et cohérence Les conversions et saturations en faible précision effacent les micro‑contrastes et les détails fins. Les couleurs et l’éclairage deviennent moins fiables quand les chemins d’exécution changent, ce qui altère la cohérence d’une série d’images censées partager un même style.

Effets visibles sur les éléments critiques Les visages, les textures fines, la netteté des contours et la cohérence des ombres sont les premiers éléments à souffrir. Ces dégradations ne sont pas marginales : elles transforment la qualité perçue et la fiabilité d’un rendu professionnel.

Conséquences pratiques et dimension commerciale

Perte de valeur du travail itératif Des heures, parfois des centaines d’heures, sont investies pour entraîner une LoRA, peaufiner un prompt, calibrer un pipeline. Si l’application de la LoRA ou l’effet d’un prompt varie d’un run à l’autre, toute l’itération devient aléatoire : on ne peut plus comparer, mesurer, corriger.

Risque professionnel Pour des usages commerciaux, l’imprévisibilité et la baisse de qualité rendent SDXL moins utilisable. Les livrables deviennent instables, les délais s’allongent, la confiance dans l’outil s’effrite.

Fragmentation et inégalité d’accès Les utilisateurs qui peuvent contrôler leur stack (rollback de drivers, exécution standalone) trouvent des contournements ; d’autres, sur configurations verrouillées, subissent la régression. L’écosystème se fragmente entre ceux qui peuvent maintenir la qualité et ceux qui ne le peuvent pas.

Logique commerciale sous‑jacente Les décisions techniques ne sont pas neutres. Optimiser pour la latence et le throughput produit des chiffres marketing attractifs. Verrouiller les flags et imposer des heuristiques centralise le contrôle et facilite la standardisation et la vente de services. Quand la stabilité devient un service, la pression commerciale pour pousser les utilisateurs vers des offres propriétaires ou payantes augmente. Ce n’est pas une conspiration, c’est une logique « business is business » : métriques visibles et contrôle centralisé favorisent la monétisation, parfois au prix de la pérennité fonctionnelle pour les workflows avancés.

Conclusion factuelle

Le problème est désormais global : les recompilations de kernels, les mélanges de précision imposés, les variations d’ordre de chargement et les wrappers qui limitent le contrôle utilisateur ont brisé la garantie essentielle de SDXL — un même seed donne la même image. Cette rupture du déterminisme s’accompagne d’une baisse visible de qualité, surtout sur les visages, les détails fins et l’application des LoRAs.

Pour celles et ceux qui ont passé des heures à entraîner des LoRAs, à ajuster des prompts et à construire un style cohérent, l’impact est lourd : les styles deviennent impossibles à reproduire, les workflows perdent leur sens, et la confiance dans l’outil s’effondre. Ce n’est pas une simple régression technique : c’est le résultat d’une logique produit qui privilégie les métriques de performance et le contrôle des backends, au détriment de la stabilité et de la valeur créative. SDXL, autrefois fiable et maîtrisable, se retrouve fragilisé par des choix qui érodent sa qualité et sa reproductibilité.