SevenTnewS

NVIDIA

Nvidia et Hugging Face s'associent pour rendre l'entraînement distribué de diffusion banal

NeMo Automodel de Nvidia s'intègre désormais directement à Diffusers de Hugging Face, permettant un entraînement distribué de qualité production pour des modèles comme FLUX, Wan 2.1 et HunyuanVideo. La bibliothèque sous licence Apache 2.0 gère le parallélisme comme une bascule de configuration et permet aux points de contrôle affinés de se charger directement dans les pipelines d'inférence.

Emmanuel Fabrice Omgbwa Yasse Assisté par IA

2026-07-19 · 5 min de lecture

Nvidia et Hugging Face s'associent pour rendre l'entraînement distribué de diffusion banal
Sources : Fine-tune video…

Les modèles de diffusion ne cessent de grossir, et leur entraînement devient de plus en plus complexe. FLUX.1-dev pèse 12 milliards de paramètres. La variante à 14 milliards de paramètres de Wan 2.1 nécessite un parallélisme tensoriel juste pour tenir sur un H100. HunyuanVideo 1.5 fonctionne à 13 milliards. Passer à l'échelle l'inférence pour ces modèles est relativement bien compris. Passer à l'échelle l'entraînement ne l'est pas, surtout si vous voulez passer d'une expérience LoRA sur un seul GPU à un ajustement complet sur un cluster sans réécrire votre script d'entraînement.

C'est cette lacune que Nvidia et Hugging Face ciblent avec une nouvelle intégration entre NeMo Automodel et la bibliothèque Diffusers, désormais documentée dans le guide d'entraînement Diffusers et publiée sous licence Apache 2.0. L'affirmation est simple : vous pointez vers n'importe quel modèle compatible Diffusers sur le Hub, et le même flux de travail piloté par YAML gère le partitionnement FSDP2, le parallélisme tensoriel, le parallélisme de contexte, la mise en cache latente et le bucketage multi-résolution. Aucune étape de conversion. Aucun format d'entraînement séparé. Le point de contrôle sort au format Diffusers et se charge directement dans un pipeline de diffusion pour l'inférence.

Pour les équipes qui ont assemblé des scripts d'entraînement personnalisés autour de chaque nouvelle version de modèle, cet empaquetage compte plus qu'un simple chiffre de performance.

Ce qui change réellement

Les gains pratiques se décomposent en trois parties. Premièrement, aucune conversion de point de contrôle. Un point de contrôle NeMo affiné est un point de contrôle Diffusers, la même structure de dossiers, les mêmes classes de modèle. Les outils en aval (quantification, compilation, échantillonneurs personnalisés, fusion LoRA) continuent de fonctionner sans étape d'adaptation. Deuxièmement, un support rapide pour les nouveaux modèles. Lorsqu'une nouvelle architecture de diffusion arrive dans Diffusers, son activation dans NeMo Automodel nécessite un gestionnaire de prétraitement des données et un adaptateur de modèle plutôt qu'un script d'entraînement personnalisé complet. Le reste de la pile de recettes, parallélisme, bucketage, points de contrôle, génération, reste inchangé.

Schéma : NeMo Automodel + Diffusers Training Workflow
L'intégration NeMo Automodel avec Diffusers élimine la conversion de points de contrôle en permettant aux utilisateurs de lancer un entraînement distribué à partir de n'importe quel modèle compatible Diffusers et d'obtenir directement un point de contrôle au format Diffusers pour les outils en aval et l'inférence, comme décrit dans l'article.

Troisièmement, l'ajustement complet et le style LoRA PEFT sont tous deux gérés par la même structure de recette. La configuration YAML sélectionne celui à exécuter ; le chemin de code est partagé. Cela signifie qu'un praticien peut commencer avec LoRA sur un seul nœud pour valider la qualité des données, puis passer à un ajustement complet sur huit GPU (ou quatre-vingts) en modifiant quelques champs de configuration et une déclaration de parallélisme, sans échanger de scripts d'entraînement.

La couche de référence

Les benchmarks publiés sur 8x H100 80GB donnent une idée de l'endroit où se situe la bibliothèque. L'ajustement complet de FLUX.1-dev à une résolution de 512x512 fonctionne à 35,5 images par seconde avec une taille de lot globale de 32 et une allocation GPU maximale de 63,9 GiB. LoRA au rang 64 avec DDP pousse cela à 53,7 images par seconde, consommant 67,4 GiB. Pour le texte-à-vidéo, l'ajustement complet 14B de Wan 2.1 sur des clips de 49 images à 512x512 fonctionne à environ 2,1 clips par seconde avec la vérification d'activation activée, culminant à 33,4 GiB par GPU. La variante 1.3B tient facilement, 6,1 GiB de pointe, sans vérification d'activation nécessaire.

Ces chiffres sont des moyennes en régime permanent avec les écritures de points de contrôle désactivées et les lots complets imposés. Les exécutions réelles avec des points de contrôle périodiques seront légèrement plus lentes, mais l'écart entre LoRA sur un seul GPU et l'ajustement complet distribué est suffisamment étroit pour que le principal goulot d'étranglement pour la plupart des équipes soit la préparation des données et l'évaluation, et non le débit d'entraînement.

Un guide concret

La documentation comprend un ajustement complet de bout en bout de FLUX.1-dev sur l'ensemble de données de 78 images de tarot Rider-Waite. Le flux de travail est : pré-encoder l'ensemble de données en latents VAE mis en cache et en embeddings de texte, puis lancer l'entraînement en utilisant le YAML FLUX existant avec des remplacements en ligne de commande pour les chemins de l'ensemble de données et les paramètres d'exécution. Après 200 étapes d'optimiseur, le point de contrôle produit des résultats qui mélangent le contenu de l'invite de l'astronaute avec les palettes vintage et les contours d'encre appris des cartes de tarot, une adaptation de domaine contrôlée plutôt qu'une prise de contrôle du modèle de base.

Le jeton de déclenchement trtcrd fonctionne comme un commutateur de style. Avec lui, les générations passent à des champs de couleur unie crème, rouge et noir. Sans lui, la même graine et la même invite produisent un résultat photographique. Ce genre de contrôle fin est exactement ce à quoi devrait ressembler un ajustement de domaine, et le fait qu'il ait fallu un seul fichier de configuration et aucune modification du modèle source est le point essentiel.

L'élément manquant

NeMo Automodel ne prend actuellement en charge que les modèles de flux matching. Cela laisse de côté les modèles de diffusion à temps discret encore largement utilisés dans la communauté, par exemple les architectures de classe Stable Diffusion 3 et SDXL. La bibliothèque est également livrée avec l'orchestration multi-nœuds SLURM mais pas encore avec le support Kubernetes, ce qui limite son attrait pour les équipes travaillant sur des plates-formes cloud gérées.

L'API de recette Pythonic prévue, qui permettrait aux utilisateurs de composer les mêmes composants à partir de Python typé plutôt que de YAML, est toujours répertoriée comme une version future. Pour les équipes qui ont besoin d'intégrer l'entraînement dans des cadres de gestion d'expériences existants, ce chemin programmatique comptera plus que le démarrage rapide YAML.

Rien de tout cela ne diminue ce qui est réellement là. L'intégration Diffusers-NeMo résout un problème spécifique, l'entraînement distribué de diffusion de qualité production sans l'échafaudage habituel, et le résout proprement. Les chiffres de performance sont solides, le flux de travail est reproductible et l'artefact fonctionne avec les outils existants. Pour les laboratoires qui exécutent des scripts ad hoc sur des clusters, il s'agit probablement de la voie de moindre résistance vers une configuration qui passe à l'échelle.

L'essentiel de la tech en 3 minutes chaque matin

Un email, chaque jour ouvré, avec ce qui compte vraiment en IA et en tech.