diffusion-pipe : un script d'entraînement parallèle par pipeline pour modèles de diffusion

Ce que ce script entraîne et comment il répartit le modèle

Le README présente diffusion-pipe comme un script d'entraînement parallèle par pipeline pour modèles de diffusion. Le code d'entraînement est construit autour du parallélisme par pipeline de DeepSpeed, ce qui permet d'entraîner des modèles plus grands que ce qu'une seule GPU peut contenir. La liste des modèles du README comprend SDXL, Flux, LTX-Video, HunyuanVideo (t2v), Cosmos, Lumina Image 2.0, Wan2.1 (t2v et i2v), Chroma, HiDream, Stable Diffusion 3, Cosmos-Predict2, OmniGen2, Flux Kontext, Wan2.2, Qwen-Image, Qwen-Image-Edit, HunyuanImage-2.1, AuraFlow, Z-Image, HunyuanVideo-1.5, Flux 2 (Dev et Klein), Anima, Ernie-Image, LTX 2.3, Ideogram4 et Krea 2. Le README ne fournit pas de benchmarks d'entraînement ni de comparaisons de performance pour ces modèles ; aucun n'est donc rapporté ici.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 1 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 1 porte sur la sortie et la limite explicitement décrites : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Installation et dépendances laissées à l'utilisateur par le README

Le parcours d'installation du README commence par un clone récursif : git clone --recurse-submodules https://github.com/tdrussell/diffusion-pipe, car le dépôt contient un sous-module ComfyUI. Si le premier clone a été fait sans --recurse-submodules, le README indique d'exécuter git submodule init et git submodule update. L'environnement est créé avec Miniconda et Python 3.12, puis PyTorch est installé en premier car il est volontairement absent de requirements.txt : différentes GPU peuvent nécessiter différentes versions de PyTorch ou de CUDA. Le README indique, à la date du 26 octobre 2025, que PyTorch 2.9.0 avec CUDA 12.8 a fonctionné sur la 4090 de l'auteur. Flash Attention est une installation optionnelle, nécessaire pour certains modèles. NVIDIA Cosmos nécessite en plus TransformerEngine, et le README inclut une commande avec variables d'environnement spécifique aux chemins conda de l'auteur. Le README ne précise pas quels modèles nécessitent Flash Attention ; cela reste une question de vérification par modèle.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 2 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 2 porte sur la commande, le fichier ou l API cités dans cette section : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Structure du jeu de données et cache sur disque

Un jeu de données se compose d'un ou plusieurs répertoires contenant des fichiers image ou vidéo et des fichiers de légende correspondants. Les légendes sont des fichiers .txt dont le nom de base correspond au fichier média : image1.png attend donc image1.txt dans le même répertoire. Une légende manquante affiche un avertissement et l'entraînement continue avec une légende vide. Les formats d'image chargeables par Pillow et les formats vidéo chargeables par ImageIO devraient fonctionner ; les vidéos WebP ne sont pas prises en charge, car ImageIO ne peut pas charger de WebP multi-images. Les latents et les embeddings de texte sont mis en cache sur disque avant l'entraînement, dans un répertoire cache à l'intérieur de chaque répertoire de jeu de données, via la bibliothèque Huggingface Datasets. Les caches sont réutilisés entre les exécutions. Trois options contrôlent ce comportement : --cache_only exécute le flux de mise en cache puis se termine ; --regenerate_cache force la régénération du cache ; --trust_cache charge les métadonnées du cache sans vérifier si les fichiers ont changé, ce qui, selon le README, peut accélérer le chargement pour les très grands jeux de données de plus de 100 000 images. Comme les sorties des encodeurs de texte sont mises en cache, le README indique que l'entraînement de LoRA pour les encodeurs de texte n'est pas pris en charge actuellement.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 3 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 3 porte sur la sortie et la limite explicitement décrites : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Fichiers de configuration, commande de lancement et reprise

Le README renvoie les utilisateurs au répertoire examples avant l'entraînement. Le fichier main_example.toml contient des commentaires expliquant la plupart des paramètres ; dataset.toml documente les options du jeu de données. La consigne est de copier une configuration, de la modifier et de changer au minimum tous les chemins, y compris ceux de la configuration du jeu de données. La commande de lancement montrée est : NCCL_P2P_DISABLE="1" NCCL_IB_DISABLE="1" deepspeed --num_gpus=1 train.py --deepspeed --config examples/hunyuan_video.toml. Le README précise que la série RTX 4000 nécessite ces deux variables d'environnement et que DeepSpeed signalera une erreur si elles sont absentes sur les GPU qui en ont besoin. Avec les checkpoints activés, relancer la même commande avec --resume_from_checkpoint reprend depuis le dernier checkpoint ; un nom de dossier de checkpoint peut être ajouté à cette option. Le README avertit que la reprise utilise la configuration passée en ligne de commande, et non celle enregistrée dans le répertoire de sortie. L'utilisateur doit s'assurer qu'elle correspond à la configuration précédente.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 4 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 4 porte sur la commande, le fichier ou l API cités dans cette section : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Répertoires de sortie et contenu des checkpoints

Chaque exécution crée un nouveau répertoire sous output_dir. Ce répertoire contient les checkpoints, les modèles enregistrés et les métriques Tensorboard. Les modèles et LoRA enregistrés apparaissent dans des répertoires nommés epoch1, epoch2, etc. Les checkpoints DeepSpeed apparaissent dans des répertoires nommés global_step1234. Le README décrit ces checkpoints comme contenant tout l'état d'entraînement, y compris les poids, l'état de l'optimiseur et l'état du dataloader, et précise qu'ils ne peuvent pas être utilisés directement pour l'inférence. Le répertoire du modèle enregistré contient les poids safetensors, un JSON de configuration d'adaptateur PEFT et le fichier de configuration diffusion-pipe pour suivre les paramètres de l'exécution. Le README ne précise pas les noms des métriques Tensorboard ni la version du format des checkpoints ; ces éléments ne sont donc pas couverts ici.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 5 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 5 porte sur la sortie et la limite explicitement décrites : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Réduction de VRAM et stratégie de parallélisme

Le fichier d'exemple wan_14b_min_vram.toml regroupe les paramètres de réduction de VRAM. Ils incluent l'optimiseur AdamW8BitKahan, l'échange de blocs avec blocks_to_swap = 32, le checkpointing d'activation unsloth via activation_checkpointing = 'unsloth', et l'option d'allocateur CUDA PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. Le README indique que expandable_segments a aidé pour l'entraînement vidéo et les buckets de multiples ratios d'aspect, mais a aussi parfois provoqué des erreurs CUDA aléatoires sur le système de l'auteur ; si l'entraînement passe les premières étapes, il continue généralement sans erreur. Le parallélisme est un hybride de parallélisme de données et de parallélisme par pipeline. L'option --num_gpus définit le nombre de GPU et pipeline_stages dans la configuration contrôle le degré de pipeline ; le degré de parallélisme de données est ensuite déterminé automatiquement pour utiliser toutes les GPU, ce qui signifie que le nombre de GPU doit être divisible par pipeline_stages. Avec 4 GPU et pipeline_stages=2, deux instances du modèle s'exécutent, chacune répartie sur deux GPU.

Le dépôt Diffusion Pipe fournit les éléments décrits dans son README pour construire un pipeline de génération ou de traitement par diffusion. Les modèles, fichiers de poids et contraintes matérielles non spécifiés restent hors de portée de cette synthèse. Contrôle 6 : cette lecture est limitée aux faits exposés par tdrussell/diffusion-pipe et ne transforme pas une affirmation du README en mesure indépendante.

Pour diffusion-pipe, le contrôle 6 porte sur la commande, le fichier ou l API cités dans cette section : consignez ce résultat avec la version du dépôt. Si le comportement diffère, le README de tdrussell/diffusion-pipe ne permet pas de conclure seul sur la cause.

Conclusion éditoriale

diffusion-pipe est un script d'entraînement parallèle par pipeline basé sur DeepSpeed pour modèles de diffusion, avec une longue liste de modèles image et vidéo pris en charge. Son fonctionnement s'articule autour de fichiers de configuration, de la mise en cache sur disque des latents et des embeddings de texte, et de la reprise sur checkpoint. Le README ne contient ni benchmarks ni résultats de production ; chacun doit donc les évaluer sur son propre matériel et avec son propre jeu de données. diffusion-pipe convient aux lecteurs qui acceptent les limites documentées par tdrussell/diffusion-pipe. Il ne convient pas à une décision fondée sur des promesses non accompagnées d exemples ou de mesures dans le README. Commencez par l entrée propre au projet, puis vérifiez la sortie, les dépendances et le comportement d erreur décrit dans ses fichiers.

Sources officielles

1. Official README
2. Project repository