Cette page est une vue d’ensemble du fine‑tuning LoRA avec l’Ostris AI Toolkit. Pour une recette spécifique à un modèle, allez directement à l’un de ces guides :

• Entraîner une LoRA FLUX.2 Dev avec AI Toolkit
• Entraîner une LoRA LTX-2 avec AI Toolkit
• Entraîner une LoRA Z‑Image Turbo avec AI Toolkit
• Entraîner une LoRA Qwen Image 2512 avec AI Toolkit
• Entraîner une LoRA Qwen‑Image‑Edit‑2511 avec AI Toolkit
• Entraîner une LoRA Qwen‑Image‑Edit‑2509 avec AI Toolkit
• Entraîner une LoRA Wan 2.2 I2V 14B avec AI Toolkit
• Entraîner une LoRA Wan 2.2 T2V 14B avec AI Toolkit

À la fin de ce guide, vous devriez :

• Comprendre les idées clés derrière l’entraînement LoRA (ce qui se passe réellement quand vous fine‑tunez un modèle).
• Savoir comment l’AI Toolkit est structuré et à quoi sert chaque panneau.
• Comprendre ce que font les paramètres essentiels (learning rate, rank, steps, noise schedule, DOP, etc.) pour pouvoir les ajuster de façon intentionnelle.
• Être capable d’entraîner des LoRAs sur votre machine ou via le RunComfy Cloud AI Toolkit, puis de les réutiliser dans vos workflows habituels de génération.

---

Table des matières

• 1. Qu’est‑ce que l’Ostris AI Toolkit ? (entraîneur LoRA pour modèles de diffusion)
• 2. Modèles pris en charge dans l’Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)
• 3. Installer l’Ostris AI Toolkit en local et utiliser le RunComfy Cloud AI Toolkit
• 4. Vue d’ensemble de l’interface Web d’Ostris AI Toolkit (Dashboard, Datasets, New LoRA Job)
• 5. Bases de l’entraînement LoRA et hyperparamètres clés dans AI Toolkit
• 6. Relier les concepts LoRA aux paramètres d’AI Toolkit
• 7. Workflow express : entraîner une LoRA utilisable dans Ostris AI Toolkit
• 8. Dépannage du training LoRA dans AI Toolkit : erreurs fréquentes et correctifs

1. Qu’est‑ce que l’Ostris AI Toolkit ? (entraîneur LoRA pour modèles de diffusion)

Ostris AI Toolkit est une suite d’entraînement orientée modèles de diffusion pour l’image et la vidéo. Elle ne gère pas les modèles de langage ni l’audio ; tout ce qui est pris en charge est soit un modèle de diffusion de type DDPM (comme SD 1.5 ou SDXL), soit un diffusion‑transformer moderne comme Flux, Wan, Qwen‑Image, Z‑Image ou OmniGen2. Le toolkit est construit autour d’adaptateurs de type LoRA : en pratique, quand vous fine‑tunez avec AI Toolkit, vous ne réentraînez pas tout le réseau, vous entraînez de petites LoRA (ou des adaptateurs légers similaires) au‑dessus d’un modèle de base gelé.

Fonctions clés d’Ostris AI Toolkit pour l’entraînement LoRA

AI Toolkit fournit un moteur d’entraînement commun et un système de configuration unifié pour toutes les familles de modèles prises en charge. Chaque famille (Flux, Z‑Image Turbo, Wan 2.2, Qwen‑Image, SDXL, etc.) a ses propres presets, mais toutes s’insèrent dans la même structure : chargement du modèle, quantification, définition de l’adaptateur LoRA/LoKr, hyperparamètres d’entraînement, gestion des datasets et règles d’échantillonnage. C’est pour ça que l’interface Web se ressemble, que vous entraîniez une LoRA Flux, une LoRA Z‑Image Turbo ou une LoRA vidéo Wan.

Par‑dessus ce moteur, AI Toolkit propose à la fois une CLI et une interface Web complète. La CLI lance les jobs directement depuis des configs YAML ; l’interface Web est une couche graphique au‑dessus de ces mêmes configs. Dans l’UI, “AI Toolkit” désigne souvent l’écran New Job : vous choisissez une famille de modèle, un type de LoRA et un rank, vous réglez learning rate et steps, vous attachez un ou plusieurs datasets et vous définissez la fréquence de génération de samples (images ou vidéos). Des panneaux dédiés existent pour Job, Model, Quantization, Target, Training, Regularization, Datasets et Sample, si bien que vous n’avez presque jamais besoin de toucher au YAML brut. Que vous l’exécutiez en local ou via un setup cloud comme le RunComfy Cloud AI Toolkit, le workflow est le même.

---

Outils intégrés pour entraîner des LoRAs dans l’Ostris AI Toolkit

AI Toolkit intègre plusieurs fonctionnalités “batteries included” qu’il faudrait sinon assembler à la main :

• Quantification et modes low‑VRAM – quantification configurable du transformer en 8/6/4 bits (et 3 bits avec recovery adapters) + offloading de couches, pour que des modèles lourds comme Flux ou Wan puissent être entraînés sur des GPU 24–48 Go, avec des compromis qualité/vitesse maîtrisables.
• Adaptateurs LoRA / LoKr – support de LoRA standard et de LoKr (variante plus compacte mais moins universellement supportée), sélectionnable via Target Type pour choisir entre compatibilité maximale et adaptateurs plus petits mais plus “capables”.
• Differential Output Preservation (DOP) – une loss de régularisation qui compare les sorties du modèle de base et du modèle avec LoRA sur des images de régularisation, et pénalise les changements indésirables. Cela aide à réduire le “bleeding” (quand tout commence à ressembler à votre sujet).
• Differential Guidance pour modèles turbo – un terme de guidance optionnel à l’entraînement (très utilisé pour Z‑Image Turbo) qui focalise la mise à jour sur “ce qui doit changer” par rapport au modèle de base, améliorant l’adaptation sur des modèles distillés few‑step sans détruire leur avantage de vitesse.
• Entraînement multi‑stades par niveau de bruit – des phases high‑noise et low‑noise séparées pour équilibrer apprentissage de structure globale (composition, pose) et raffinement des détails (textures, contours).
• Cache des latents et des embeddings texte – Cache Latents et Cache Text Embeddings échangent de l’espace disque contre de la vitesse et moins de VRAM, particulièrement utile sur de petits GPU ou en session cloud pour itérer vite.
• EMA (Exponential Moving Average) – une copie lissée optionnelle des poids de la LoRA, qui peut stabiliser la convergence, surtout avec des petits datasets.

L’interface Web expose ces fonctions via des contrôles clairs, et comme la mise en page est cohérente entre modèles, une fois que vous comprenez comment AI Toolkit entraîne une LoRA sur une base (par ex. Flux), vous pouvez appliquer le même raisonnement à Z‑Image Turbo, Wan, Qwen‑Image et d’autres modèles de diffusion.

---

2. Modèles pris en charge dans l’Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)

AI Toolkit prend actuellement en charge les familles suivantes :

• Modèles IMAGE – image unique (Flux, Z‑Image Turbo, Qwen‑Image, SD, etc.).
• Modèles INSTRUCTION / EDIT – édition d’image / instruction‑following (Qwen‑Image‑Edit, Flux Kontext, HiDream E1).
• Modèles VIDÉO – texte‑vers‑vidéo et image‑vers‑vidéo (série Wan 2.x).

---

2. Modèles pris en charge dans l’Ostris AI Toolkit (Flux, Wan, Z‑Image, Qwen‑Image, SDXL)

AI Toolkit prend actuellement en charge les familles suivantes :

• Modèles IMAGE – image unique (Flux, Z‑Image Turbo, Qwen‑Image, SD, etc.).
• Modèles INSTRUCTION / EDIT – édition d’image / instruction‑following (Qwen‑Image‑Edit, Flux Kontext, HiDream E1).
• Modèles VIDÉO – texte‑vers‑vidéo et image‑vers‑vidéo (série Wan 2.x).

---

3. Installer l’Ostris AI Toolkit en local et utiliser le RunComfy Cloud AI Toolkit

3.1 Installer Ostris AI Toolkit en local sur Linux et Windows

Le README officiel sur GitHub donne des instructions simples pour Linux et Windows.

Sous Linux :

git clone https://github.com/ostris/ai-toolkit.git
cd ai-toolkit

python3 -m venv venv
source venv/bin/activate

# installer PyTorch avec CUDA (ajuster la version si besoin)
pip3 install --no-cache-dir torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 \
  --index-url https://download.pytorch.org/whl/cu126

pip3 install -r requirements.txt

Sous Windows, vous pouvez soit suivre le même schéma avec python -m venv venv et .\venv\Scripts\activate, soit utiliser le script batch communautaire AI‑Toolkit Easy Install, qui encapsule tout le processus en un clic et ouvre automatiquement l’UI dans votre navigateur (dernière version).

Pour démarrer l’interface Web une fois les dépendances installées :

cd ui
npm run build_and_start

L’interface sera disponible sur http://localhost:8675. Si vous l’exécutez sur une machine distante, définissez d’abord AI_TOOLKIT_AUTH avec un mot de passe pour limiter l’accès (voir les notes de sécurité dans le repo GitHub AI Toolkit).

---

3.2 Utiliser RunComfy Cloud AI Toolkit pour entraîner des LoRAs (sans installation locale)

Si vous ne voulez pas vous occuper des drivers GPU, de CUDA ou d’installations locales, vous pouvez utiliser le RunComfy Cloud AI Toolkit. Dans ce mode :

• AI Toolkit tourne entièrement dans le cloud : vous ouvrez un navigateur et vous êtes dans l’UI.
• Vous avez accès à des GPU puissants (80 Go et 141 Go de VRAM), idéals pour entraîner des LoRAs lourdes sur FLUX, Qwen‑Image, Z‑Image Turbo ou Wan.
• Vos datasets, configs, checkpoints et jobs passés restent dans un workspace persistant lié à votre compte RunComfy.
• Entraînement, playground pour tester le modèle et workflows ComfyUI sont réunis au même endroit.

Ouvrez‑le ici : Cloud AI Toolkit sur RunComfy

---

4. Vue d’ensemble de l’interface Web d’Ostris AI Toolkit (Dashboard, Datasets, New LoRA Job)

Quand vous ouvrez l’interface Web (en local ou sur RunComfy), la barre latérale gauche propose quelques pages essentielles :

4.1 Dashboard et Training Queue

Le Dashboard affiche les jobs actifs et récents en un coup d’œil. C’est surtout une page de statut rapide.

La page Training Queue vous permet de :

• voir l’état de chaque job (queued, running, finished, failed),
• ouvrir les logs pour déboguer,
• arrêter ou supprimer un job,
• télécharger les checkpoints et les samples générés.

Pensez‑y comme au “centre de contrôle”. Toutes les LoRAs que vous entraînez apparaissent ici.

---

4.2 Gestionnaire de datasets

La page Datasets vous permet de définir des datasets nommés que vous attacherez ensuite à vos jobs :

• vous sélectionnez ou uploadez des dossiers d’images ou des clips vidéo,
• l’UI les scanne et affiche résolutions, quantités et présence de captions / metadata,
• chaque dataset reçoit un nom interne qui apparaîtra ensuite dans le menu Target Dataset.

C’est ici que vous créez :

• vos datasets de training principaux (personnage, style, photos produit),
• et des datasets de régularisation optionnels (autres personnes, autres camions, fonds génériques, etc.) pour DOP ou régularisation classique.

---

4.3 New Job : l’écran central de configuration LoRA

La page New Job est le cœur d’AI Toolkit. Un job revient essentiellement à :

Entraîner une LoRA de type X sur le modèle Y, avec le dataset Z, et ces hyperparamètres.

L’écran est divisé en panneaux :

• JOB – nom du job et sélection GPU.
• MODEL – quel modèle de base fine‑tuner.
• QUANTIZATION – niveau de compression du modèle de base.
• TARGET – LoRA vs LoKr et rank.
• SAVE – précision des checkpoints et fréquence de sauvegarde.
• TRAINING – learning rate, steps, optimizer, schedule de timesteps.
• ADVANCED / Regularization – EMA, Differential Guidance, DOP.
• DATASETS – quels datasets utiliser et comment.
• SAMPLE – fréquence de génération des images/vidéos de sample pendant le training.

Le reste de ce guide sert surtout à relier ces panneaux aux concepts LoRA sous‑jacents.

---

5. Bases de l’entraînement LoRA et hyperparamètres clés dans AI Toolkit

Avant de toucher aux réglages, il aide d’avoir un bon modèle mental de ce que fait LoRA pendant l’entraînement.

5.1 Comment LoRA fonctionne dans les modèles de diffusion

Un modèle de diffusion moderne est surtout une pile de blocs transformer avec de grosses matrices de poids. En fine‑tuning “classique”, on mettrait à jour tous ces poids directement, ce qui est coûteux et facile à overfit.

Dans toutes les familles supportées (Flux, Z‑Image Turbo, Wan, Qwen‑Image), le backbone est un large diffusion‑transformer. LoRA ne remplace pas la matrice originale W ; elle ajoute une mise à jour low‑rank construite à partir de deux matrices apprises A et B. On peut le voir comme : W_new = W + alpha A B, où W est gelée, A et B sont entraînables, et alpha est un facteur d’échelle qui contrôle la force de la LoRA à l’inférence.

Le rank détermine la largeur de A et B, donc la capacité de la mise à jour LoRA. Un rank plus élevé est plus expressif mais plus lourd (paramètres et compute). Un rank plus bas donne un adaptateur plus petit et plus “focalisé”, généralement plus dur à overfit.

---

5.2 Hyperparamètres LoRA importants

Ces noms existent partout ; AI Toolkit les expose clairement.

Learning Rate (Learning Rate)

• Contrôle la taille du pas à chaque update de l’optimizer.
• Trop bas : l’entraînement est lent et peut ne pas bien s’ajuster à votre dataset.
• Trop haut : la loss oscille ou explose, et la LoRA devient bruitée/instable, voire totalement overfit.

Pour les LoRAs diffusion, 0.0001 est un excellent point de départ. Beaucoup de configs Wan et Flux publiées se situent entre 0.0001 – 0.0002.

---

Batch Size et Gradient Accumulation

• Batch Size est le nombre d’images/clips traités en parallèle pour chaque calcul de gradient.
• Gradient Accumulation signifie “accumuler les gradients sur N batches avant d’appliquer une update”, ce qui simule un batch plus grand sans exiger plus de VRAM.

Le batch effectif est : Batch Size × Gradient Accumulation

Un batch effectif plus élevé donne des gradients plus stables et une meilleure généralisation, mais coûte plus de compute. Beaucoup tournent avec Batch Size = 1 et Gradient Accumulation = 2–4 sur des GPU 24 Go.

---

Steps (Steps)

C’est le nombre d’updates de l’optimizer. C’est le bouton principal pour “combien de temps entraîne‑t‑on”.

• Trop peu de steps → underfitting : la LoRA modifie à peine le modèle de base.
• Trop de steps → overfitting : la LoRA mémorise et se “répand” dans tout.

Le bon nombre dépend de la taille du dataset, de sa diversité, du rank et du learning rate.

Pour des LoRAs personnage typiques (20–50 images) sur des modèles modernes, 2 000–3 000 steps est une bonne plage de départ.

---

Rank (Linear Rank)

• Le rank détermine le nombre de degrés de liberté de votre LoRA.
• Doubler le rank double grosso modo la capacité et le nombre de paramètres.

Intuition pratique :

• Rank 16–32 suffit pour la plupart des personnages et styles sur de gros modèles comme Flux ou Wan.
• Des ranks élevés overfitent plus facilement de petits datasets ; des ranks plus bas obligent la LoRA à généraliser.

---

Weight Decay (Weight Decay)

Le weight decay est une régularisation standard : il ramène légèrement les poids vers zéro à chaque step.

• Il réduit le risque que la LoRA “accroche” des valeurs extrêmes qui reproduisent parfaitement les images d’entraînement mais généralise mal.
• Des valeurs comme 0.0001 sont courantes et généralement sûres. Vous n’avez souvent pas besoin d’y toucher avant d’observer un overfitting évident.

---

Schedule des timesteps

Les modèles diffusion apprennent à débruiter sur une gamme de niveaux de bruit. Vous choisissez quels timesteps sont échantillonnés plus souvent :

• High noise : le modèle apprend la structure globale, la composition, les grandes formes.
• Low noise : le modèle apprend les textures et les détails fins.
• Mid noise : là où structure et détails se rencontrent ; très utile pour les visages/personnages.

Les paramètres Timestep Type et Timestep Bias dans AI Toolkit sont des contrôles UI pour ce scheduling, que l’on détaillera plus loin.

---

Composition du dataset et captions

Même avec des hyperparamètres parfaits, de mauvaises données donnent une mauvaise LoRA :

• Utilisez des images propres et variées qui correspondent toutes au concept (même personne, même marque, même style), mais avec des poses, lumières et arrière‑plans différents.
• Les captions doivent lier clairement un trigger word unique au concept, pour pouvoir activer la LoRA plus tard sans “dérégler” le vocabulaire du modèle de base.

Pour les LoRAs vidéo (Wan, HiDream E1), la logique est la même, mais avec des clips courts au lieu d’images individuelles, et l’échantillonnage de frames devient une partie du design du dataset.

---

6. Relier les concepts LoRA aux paramètres d’AI Toolkit

On va maintenant parcourir l’écran New Job panneau par panneau et relier chaque paramètre aux concepts ci‑dessus.

6.1 Panneau JOB : projet, GPU et trigger word

Le panneau JOB est simple mais important :

Training Name - c’est le label du job et il devient une partie des noms de dossiers/fichiers de sortie. Beaucoup incluent le modèle et le trigger word, par exemple flux_dev_skschar_v1.

GPU ID - en installation locale, cela sélectionne votre GPU physique. Sur le cloud AI Toolkit de RunComfy, laissez la valeur par défaut ; le type réel de GPU (H100 / H200, etc.) est choisi plus tard quand vous lancez le job depuis Training Queue.

Trigger Word - si vous indiquez un mot ici, AI Toolkit va le préfixer à toutes les captions pendant l’entraînement (sans modifier durablement vos fichiers). C’est pratique si vos captions n’ont pas de trigger cohérent. Utilisez un token inventé que le modèle de base ne connaît pas (ex. sks_char_neo), afin que la LoRA n’entre pas en compétition avec un sens déjà existant.

---

6.2 Panneau MODEL : choisir et charger le modèle de base

Model Architecture est l’endroit où vous choisissez dans la liste (Flux, Z‑Image Turbo, Wan 2.2, Qwen‑Image, etc.). Quand vous en sélectionnez une :

• AI Toolkit charge une configuration preset adaptée à ce modèle : type de sampling, defaults du noise schedule, et parfois des chemins d’adaptateurs.

Name or Path est l’ID du modèle Hugging Face (repo id) du checkpoint de base.

• Dans la plupart des builds, choisir un Model Architecture remplit automatiquement l’ID recommandé ici — laissez‑le tel quel sauf raison particulière.
• Si vous le remplacez, utilisez le format org-ou-user/model-name (optionnellement org-ou-user/model-name@revision).

Si le modèle est gated (Flux.1‑dev, Flux.2‑dev, certaines variantes Wan, etc.), vous devez accepter la licence et définir HF_TOKEN dans un fichier .env pour qu’AI Toolkit puisse le télécharger.

Selon le modèle, vous verrez aussi des options comme Low VRAM ou Layer Offloading ici ou dans des panneaux proches :

• Low VRAM compresse et offload des parties du modèle pour qu’il tienne sur des GPU plus petits, au prix de la vitesse.
• Layer Offloading déplace agressivement des parties entre CPU et GPU ; à n’utiliser que si Low VRAM ne suffit pas, car cela peut être plus lent et parfois moins stable.

Ces switches ne changent pas ce que la LoRA apprend ; ils changent surtout comment AI Toolkit fait tenir le modèle de base en mémoire, en échangeant de la vitesse et de la stabilité contre la capacité à rentrer dans votre matériel.

---

6.3 Panneau QUANTIZATION : précision vs VRAM

Le panneau QUANTIZATION contient généralement :

• Transformer (ex. float8, 6-bit, 4-bit, 3-bit ARA),
• Text Encoder (souvent float8 (default)).

Ce que ça signifie :

• Le transformer est la partie lourde du modèle qui traite les latents et la cross‑attention avec le texte.
• Le text encoder convertit les prompts en embeddings.

Quantifier le transformer :

• float8 est le plus sûr et précis ; il utilise plus de VRAM mais a une perte de qualité minimale.
• 6-bit est un excellent compromis pour 24 Go : faible perte de qualité pour une économie correcte.
• 4-bit et 3-bit ARA sont plus agressifs ; 3-bit ARA combine des poids 3‑bit avec un accuracy recovery adapter qui récupère partiellement la précision.

Quantifier le text encoder :

• Les text encoders sont beaucoup plus petits, donc on les laisse généralement en float8.
• Certains setups avancés figent ou unload le text encoder (voir Unload TE et Cache Text Embeddings plus loin) ; dans ce cas, sa quantification compte moins.

Concrètement :

• Sur un GPU 24 Go pour fine‑tuner Flux ou Wan, Transformer = 6-bit, Text Encoder = float8 est un bon point de départ.
• Avec 48 Go+, gardez float8 partout sauf si vous avez besoin de cette mémoire pour très hautes résolutions ou de longues séquences vidéo.

---

6.4 Panneau TARGET : type de LoRA et rank

Le panneau TARGET décrit l’adaptateur que vous entraînez :

• Target Type - en général LoRA. Certaines builds affichent aussi LoKr (Low‑Rank Kronecker), une variante plus compacte mais pas universellement supportée. Pour une compatibilité maximale—surtout si vous voulez utiliser votre LoRA dans beaucoup de setups ComfyUI ou Automatic1111—LoRA reste le choix sûr.
• Linear Rank - c’est le rank LoRA dont on a parlé : plus le rank est élevé, plus la LoRA a de capacité, plus le fichier est gros, plus la VRAM augmente, et plus le risque d’overfitting est élevé sur de petits datasets. Intuition pour les diffusion‑transformers modernes (Flux, Z‑Image Turbo, Wan 2.x, Qwen‑Image, OmniGen2, Chroma, Lumina2, etc.) :
• 8–16 : compact et plus “généralisant”. Bon point de départ pour des bases fortes comme Z‑Image Turbo et beaucoup de setups SDXL / SD 1.5, surtout si votre dataset est petit (5–40 images ou quelques clips courts).
• 16–32 : plage typique pour des LoRAs style/personnage sur de gros backbones comme Flux, Wan 2.x ou Qwen. En pratique, vous démarrez souvent à 16 et ne montez à 32 que si vous avez assez de données et que la LoRA reste trop faible.
• 64+ : rarement nécessaire. À envisager seulement si vous avez un dataset grand et diversifié et que vous voulez volontairement une LoRA très forte, avec beaucoup de VRAM.

Sur SD 1.5 / SDXL, vous pouvez aussi voir un Conv Rank (rank convolutionnel), qui cible davantage des couches texture/style. Un Conv Rank élevé renforce plutôt comment l’image est rendue (traits, grain/bruit), tandis que Linear Rank influence davantage ce qu’il y a dans l’image.

---

6.5 Panneau SAVE : précision des checkpoints et fréquence de sauvegarde

SAVE contrôle comment vos checkpoints LoRA sont écrits :

• Data Type
• BF16 (bfloat16) est un excellent default : stable numériquement et efficace.
• FP16 est légèrement plus précis, mais rarement visible sur des LoRAs classiques.
• FP32 est très précis mais très lourd ; à utiliser seulement si vous savez pourquoi.
• Save Every

  Le nombre de steps entre checkpoints. Si vous mettez Save Every = 250 et Steps = 3000, vous pouvez obtenir 12 checkpoints (mais voir le champ suivant). En général, vous voudrez que Save Every corresponde à Sample Every dans le panneau SAMPLE afin que chaque checkpoint ait des previews correspondants.

• Max Step Saves to Keep

  Combien de checkpoints conserver sur disque. Si c’est 4, seuls les 4 plus récents sont gardés ; les anciens sont supprimés pour économiser de l’espace.

---

6.6 Panneau TRAINING : optimizer, steps et noise schedule

Batch Size et Gradient Accumulation

Comme indiqué plus haut :

• Batch Size = images/clips par forward pass.
• Gradient Accumulation = combien de passes vous accumulez avant une update.

Si la VRAM est serrée, vous pouvez faire :

• Batch Size = 1, Gradient Accumulation = 4 → se comporte comme un batch 4, mais demande quatre fois plus de passes.

Assurez‑vous que votre batch effectif ne soit pas supérieur à la taille du dataset : vous ne voulez pas demander l’équivalent de 16 images par step si vous n’en avez que 10 au total.

---

Steps

C’est le total des steps d’optimizer, pas des “epochs”.

• 2000–3000 steps est une baseline fréquente pour des LoRAs Flux / Qwen / Z‑Image Turbo / OmniGen2 / Chroma (et beaucoup de LoRAs Wan 2.x) avec des datasets de 20–50 images ou de petits clips.

Il vaut souvent mieux entraîner un peu moins et garder un bon checkpoint intermédiaire que de pousser à des counts absurdes en espérant que le dernier soit le meilleur.

---

Optimizer (Optimizer)

Vous verrez généralement :

• AdamW8Bit – AdamW avec états d’optimizer 8‑bit. Cela économise de la mémoire et fonctionne très bien pour des datasets petits à moyens.
• Adafactor – plus économe en mémoire, scalable, mais parfois plus délicat à régler.

Pour la plupart des LoRAs dans AI Toolkit, AdamW8Bit est le bon choix, sauf si vous avez des OOM liés aux états d’optimizer.

---

Learning Rate

Un bon default est 0.0001. Si :

• la LoRA apprend à peine, essayez 0.00015–0.0002,
• vous observez un overfitting rapide ou des samples bruités, essayez 0.00005–0.00008.

Évitez de sauter directement à des rates élevées comme 0.0005 sauf si une recette spécifique le recommande (par ex. certaines configs turbo expérimentales).

---

Weight Decay

Comme décrit plus haut, 0.0001 est un bon default de “régularisation douce”. Si votre LoRA mémorise clairement des images même avec un nombre de steps raisonnable, augmenter légèrement le weight decay est un outil utile.

---

Timestep Type et Timestep Bias

Ces deux paramètres façonnent quels timesteps sont privilégiés dans l’entraînement.

• Timestep Type peut être :
• Linear – échantillonnage uniforme des timesteps sur toute la plage de bruit.
• Sigmoid – concentration sur les timesteps intermédiaires (bien pour les visages/personnages).
• Weighted ou d’autres presets – schedules spécifiques au modèle.
• Timestep Bias peut être :
• Balanced – pas de bias additionnel.
• High Noise – biais vers les timesteps précoces (latents très bruités) ; met l’accent sur structure globale/composition.
• Low Noise – biais vers les timesteps tardifs (presque clean) ; met l’accent sur les détails/texture.

Pour des LoRAs personnage sur des modèles FlowMatch, Weighted + Balanced est un excellent point de départ : la LoRA apprend le concept à mi‑dénoyautage, ce qui correspond souvent à ce que l’on observe à l’inférence.

---

Sampler / Noise Type à l’entraînement

Sur les anciens modèles SD, AI Toolkit utilise des samplers DDPM ; sur les modèles FlowMatch comme Flux, Z‑Image Turbo et Wan 2.x, il utilise FlowMatch par défaut. En général, vous n’avez pas besoin de le changer : le preset choisit le bon sampler et le scheduling.

---

EMA (Exponential Moving Average)

• Use EMA active la conservation d’une copie lissée des poids de la LoRA au fil du temps.
• Si activée, EMA Decay (par ex. 0.99) contrôle à quelle vitesse l’EMA oublie les updates précédentes :
• 0.9 = réagit vite, moins lisse.
• 0.99 = plus lisse.
• 0.999+ = très lisse mais s’adapte plus lentement.

EMA peut améliorer la stabilité sur de petits datasets mais consomme de la mémoire. Sur un budget VRAM serré, il est raisonnable de laisser Use EMA off sauf recommandation spécifique.

---

Optimisations du Text Encoder

• Unload TE – unload le text encoder de la VRAM entre les steps. Économise de la mémoire mais impose des rechargements fréquents, ce qui peut être lent sur HDD.
• Cache Text Embeddings – exécute le text encoder une fois par caption puis stocke les embeddings ; les steps suivants réutilisent ces embeddings. Échange disque contre vitesse/VRAM.

Pour la plupart des workflows :

• Si vous avez assez de VRAM : laissez les deux off.
• Si vous manquez de VRAM mais avez un SSD rapide et que vos captions sont effectivement statiques (pas de DOP, pas de réécriture dynamique du trigger, pas de dropout de caption qui dépend de changements de texte par step) : activez Cache Text Embeddings.
• Si vous utilisez des fonctionnalités qui modifient les prompts à chaque step — par exemple Differential Output Preservation (DOP), substitution dynamique du trigger dans les captions, ou des setups qui reposent sur un comportement de dropout dépendant du step — laissez Cache Text Embeddings = OFF, afin que le text encoder recode le prompt réel à chaque batch.
• N’utilisez Unload TE qu’en dernier recours (pour des LoRAs ultra “trigger‑only” où les captions sont ignorées), car cela désactive en pratique l’entraînement basé sur les captions.

---

6.7 Panneau ADVANCED / Regularization : DOP et Differential Guidance

Differential Output Preservation (Differential Output Preservation)

Quand vous activez cette option, vous demandez à AI Toolkit de :

1. Exécuter le modèle de base et le modèle avec LoRA sur un ensemble d’images de régularisation.
2. Ajouter un terme de loss qui pénalise la LoRA lorsqu’elle modifie des sorties qui devraient rester inchangées.

Contrôles :

• DOP Loss Multiplier – intensité de cette loss de préservation ; 0.1–1.0 est typique. Pensez à 1.0 comme “la préservation est très importante”.
• DOP Preservation Class – un label texte qui décrit ce que vous protégez, comme "person" ou "truck". Cela aide le text encoder à comprendre les captions de régularisation.

Pour utiliser DOP efficacement, vous devez :

• avoir au moins un dataset marqué Is Regularization dans le panneau DATASETS,
• captionner ces images sans votre trigger word (ce sont des exemples “génériques”).

Bonnes situations pour DOP :

• Votre LoRA personnage fait que toutes les personnes ressemblent à votre sujet.
• Votre LoRA produit transforme tous les logos en votre marque, même sans trigger word.

Blank Prompt Preservation est une variante où la régularisation est exécutée avec des prompts vides, ce qui encourage la LoRA à ne pas perturber le comportement “sans prompt”.

---

Do Differential Guidance (Do Differential Guidance)

Principalement utilisé pour les LoRAs Z‑Image Turbo :

• AI Toolkit compare les sorties base et adaptées et utilise un signal de différence pour renforcer ce que la LoRA doit changer.
• Differential Guidance Scale contrôle à quel point cette différence influence les updates ; la documentation Hugging Face Z‑Image Turbo LoRA donne des valeurs d’exemple qui fonctionnent bien en pratique.

Activer Differential Guidance :

• aide les LoRAs Z‑Image Turbo à s’adapter en profondeur malgré la distillation few‑step,
• marche mieux en combinaison avec des text embeddings en cache et des learning rates/steps soigneusement réglés.

Pour les modèles non turbo (Flux, Qwen, SDXL), vous laissez généralement Do Differential Guidance off sauf si un tutoriel spécifique le recommande.

---

6.8 Panneau DATASETS : ce sur quoi vous entraînez vraiment

Chaque bloc de dataset dans le panneau DATASETS correspond à un dataset de la page Datasets.

Champs importants :

• Target Dataset – quel dataset ce bloc référence.
• LoRA Weight – importance relative de ce dataset par rapport aux autres dans le job.
• Default Caption – caption de secours si une image n’a pas de fichier de caption.
• Caption Dropout Rate
• Num Frames (pour les modèles vidéo)
• Cache Latents
• Is Regularization
• Flip X, Flip Y
• Resolutions (buckets 256–1536)

Ce que ça veut dire en pratique :

• Combiner plusieurs datasets avec LoRA Weight

  Si vous avez plusieurs datasets (par ex. “close‑ups” et “full‑body”), vous pouvez les équilibrer via LoRA Weight. Un dataset avec un poids 2 sera échantillonné environ deux fois plus souvent qu’un poids 1.

• Default Caption et Caption Dropout Rate
• Default Caption est pratique si vous avez oublié de captionner certaines images et voulez au moins une description minimale (incluant le trigger).
• Caption Dropout Rate supprime ou vide aléatoirement les captions sur une partie des exemples :
• proche de 0 → la LoRA apprend une forte dépendance aux captions,
• proche de 1 → la LoRA se comporte davantage comme un style “always on”.
• Is Regularization

  Activez‑le quand le dataset doit servir à DOP/régularisation, pas comme données principales. Ces images ne doivent pas contenir votre trigger et couvrent généralement des exemples génériques (autres personnes, autres camions, etc.).

• Cache Latents

  Quand c’est activé, AI Toolkit pré‑calcule les encodages latents et les stocke, si bien que les steps suivants n’ont pas à réencoder chaque image. L’entraînement est plus rapide, mais l’usage disque explose : des centaines ou milliers d’images à haute résolution peuvent consommer des dizaines de Go. Vous devrez nettoyer ces latents manuellement si vous ne voulez pas qu’ils persistent.

• Num Frames (vidéo uniquement)

  Pour les LoRAs Wan/HiDream, cela décide combien de frames sont échantillonnées dans chaque clip pendant l’entraînement. Plus de frames → meilleur apprentissage du mouvement, mais plus de VRAM ; les presets choisissent en général des valeurs sensées.

• Flip X et Flip Y

  Augmentations de données automatiques :

• Flip X (flip horizontal) double effectivement le dataset mais miroir tout, y compris des caractéristiques asymétriques et du texte.
• Flip Y (flip vertical) a rarement du sens pour des images réalistes.
• Resolutions

  Ces paramètres définissent dans quelles tailles AI Toolkit “bucketise” vos images. Il ne fait que réduire pour entrer dans le bucket ; il n’upscale jamais. Si vous activez 768 et 1024 :

• 900×900 → réduit à 768×768.
• 1200×1200 → réduit à 1024×1024.

---

6.9 Panneau SAMPLE : suivre l’apprentissage en temps réel

Le panneau SAMPLE définit comment AI Toolkit génère des previews pendant l’entraînement.

Champs principaux :

• Sample Every – nombre de steps entre previews.
• Sampler – FlowMatch ou DDPM selon le modèle.
• Width / Height – résolution des previews.
• Seed et Walk Seed.
• Guidance Scale.
• Num Frames et FPS (pour les previews vidéo).
• Sample Steps.
• Toggles avancés : Skip First Sample, Force First Sample, Disable Sampling.

Ensuite, vous pouvez ajouter plusieurs Sample Prompts, chacun avec son prompt, une résolution/seed optionnelle, LoRA Scale, et éventuellement une image de contrôle.

Comment cela se relie à l’entraînement :

• Sample Every vs Save Every : idéalement, ces deux valeurs doivent correspondre pour que chaque checkpoint sauvegardé ait ses previews. Si vous en changez une, changez l’autre.
• Sampler : gardez celui recommandé par le preset :
• FlowMatch pour Flux, Z‑Image Turbo, Wan, OmniGen2, etc.
• DDPM pour SD 1.5 / SDXL.
• Résolution/steps des previews
• 1024×1024 avec Sample Steps = 20–25 donne des previews claires sans être trop lent pour la plupart des modèles image.
• En vidéo, monter Num Frames/FPS rend les previews plus réalistes mais coûte cher ; les presets sont en général ajustés.
• Seeds et Walk Seed
• Un Seed fixe avec Walk Seed off signifie que chaque checkpoint utilise exactement le même bruit, ce qui facilite la comparaison.
• Activer Walk Seed incrémente le seed par prompt et ajoute de la variété. C’est agréable pour parcourir, mais un peu moins “apples‑to‑apples”.

En pratique, beaucoup de gens :

• gardent Sample Every = Save Every = 250,
• définissent 3–6 prompts qui couvrent leurs cas d’usage,
• gardent au moins un prompt à seed fixe pour suivre visuellement la convergence.

---

7. Workflow express : entraîner une LoRA utilisable dans Ostris AI Toolkit

Cette section est volontairement compacte. Vous connaissez déjà le sens des réglages via les sections 5–6 : voici le workflow le plus court qui produit de manière fiable une bonne LoRA dans Ostris AI Toolkit sans retoucher tout partout.

7.1 Préparer les données (la partie qu’on ne “répare” pas avec des réglages)

• Commencez avec un dataset petit et propre (LoRAs image : ~20–50 bonnes images ; LoRAs vidéo : quelques clips courts et de haute qualité).
• Choisissez un trigger token unique (mot inventé) et gardez‑le cohérent dans les captions, ou utilisez l’injection de trigger au niveau du job.
• Visez la variété, pas le volume : angles, lumières, arrière‑plans et compositions différents, tout en gardant le concept central identique.

Optionnel (uniquement si vous vous attendez à du “bleeding”) :

• Préparez un dataset de régularisation (même classe, identités/objets différents) sans votre trigger token — vous ne l’utiliserez que si vous activez DOP ensuite.

---

7.2 Créer un dataset dans Ostris AI Toolkit

Dans l’UI Ostris AI Toolkit :

1. Allez dans Datasets → New Dataset.
2. Uploadez vos images/clips + captions (ou metadata).
3. Vérifications rapides avant de lancer :
• le count est correct,
• les captions sont détectées (ou vous utilisez volontairement une default caption / l’injection de trigger),
• les résolutions semblent cohérentes avec vos buckets.

---

7.3 Créer un nouveau job : partir des presets, puis ne changer que 5 choses

Ouvrez New Job et choisissez la bonne famille (ou suivez la recette spécifique si vous entraînez FLUX.2, Z‑Image Turbo, Qwen‑Image‑Edit ou une LoRA vidéo Wan).

Concentrez‑vous maintenant sur ces 5 contrôles à fort impact :

1) Comportement du trigger

• Si vos captions contiennent déjà le trigger : laissez le trigger du job vide.
• Sinon : renseignez Trigger Word pour qu’il soit préfixé automatiquement.

2) Capacité de la LoRA

• Commencez avec Rank 16 pour la plupart des concepts personnage/style.
• Montez à Rank 32 seulement si la LoRA reste trop faible après un run raisonnable (ou si vous avez un dataset plus grand/plus varié).

3) Durée d’entraînement

• Commencez avec 2 000–3 000 steps pour une LoRA image typique de 20–50 images.

  (L’objectif est de trouver le meilleur checkpoint, pas de “finir le maximum de steps”.)

4) Learning rate

• Utilisez un default prudent comme 0.0001 sauf si une recette spécifique recommande autre chose.

5) Buckets de résolution (et réalité VRAM)

• Choisissez un bucket “confort” que votre GPU tient de manière stable (souvent 768 ou 1024 pour les modèles image modernes).
• N’ajoutez des buckets plus hauts que si vous avez de la marge VRAM et que vous savez que vous en avez besoin.

Deux habitudes simples qui font gagner des heures :

• Mettez Save Every = Sample Every (ex. tous les 250 steps) pour que chaque checkpoint ait ses previews correspondants.
• Gardez au moins un prompt de sample à seed fixe pour comparer vos checkpoints “à l’identique”.

---

7.4 Un sampling qui aide vraiment à choisir le bon checkpoint

Plutôt que beaucoup de prompts, utilisez trois prompts — ils diagnostiquent 90 % des problèmes :

• Prompt d’activation (avec trigger) : prouve que la LoRA “s’active”.
• Prompt de généralisation (avec trigger, attributs différents) : vérifie la flexibilité au‑delà des captions de training.
• Leak test (sans trigger) : vérifie si la LoRA détourne le modèle de base.

Si le leak test commence à dériver vers votre concept, vous avez dépassé le sweet spot : choisissez un checkpoint plus tôt.

---

7.5 Diagnostic rapide : changer un bouton, pas dix

Quand le résultat n’est pas bon, ajustez une seule de ces choses à la fois :

• Trop faible / s’active à peine → augmentez d’abord les steps, puis envisagez le rank.
• Trop fort / overfit / leak sans trigger → utilisez d’abord un checkpoint plus tôt, puis réduisez steps (ou rank).

  Si ça continue de “bleeder” : activez DOP avec un dataset de régularisation adapté.

• OOM / VRAM instable → baissez d’abord le bucket/la résolution, puis réduisez le rank ; seulement ensuite, utilisez des options plus agressives d’économie de mémoire.

---

7.6 Exporter et utiliser votre LoRA

Depuis Training Queue ou depuis le dossier de sortie d’AI Toolkit :

• Téléchargez le meilleur checkpoint (un fichier LoRA .safetensors).
• Si vous utilisez le RunComfy Cloud AI Toolkit, ces fichiers sont aussi stockés sur votre page Custom Models, où vous pouvez copier le lien du modèle, les télécharger et les tester dans le playground ou dans ComfyUI.

---

8. Dépannage du training LoRA dans AI Toolkit : erreurs fréquentes et correctifs

Dataset introuvable ou vide

Symptômes :

• Le job s’arrête immédiatement.
• Les logs mentionnent “no images found” (ou similaire).

Vérifications :

• Dans Datasets, confirmez que le dataset affiche le bon nombre d’images.
• Assurez‑vous que Target Dataset dans le job pointe vers le bon dataset.
• Si vous utilisez des metadata en JSONL, vérifiez que le fichier est présent et correctement formaté.

---

Téléchargement du modèle de base / erreurs Hugging Face

Symptômes :

• Erreurs 403/404 lors du téléchargement.
• Logs indiquant un accès manquant.

Correctifs :

• Acceptez la licence sur Hugging Face si le modèle est gated (Flux dev, certaines variantes Wan, etc.).
• Ajoutez HF_TOKEN=your_read_token dans un fichier .env à la racine d’AI Toolkit.

---

CUDA out‑of‑memory pendant l’entraînement ou le sampling

Symptômes :

• Erreurs “CUDA out of memory” au démarrage du job ou lors de la génération des samples.

Options :

• Dans DATASETS :
• Désactivez les hautes résolutions (1280, 1536) et restez sur 768/1024.
• Dans TARGET :
• Réduisez Linear Rank (32 → 16).
• Dans QUANTIZATION / MODEL :
• Activez Low VRAM.
• Utilisez une quantification plus agressive du transformer (float8 → 6‑bit).
• Dans TRAINING :
• Réduisez Batch Size ou Gradient Accumulation.
• Dans SAMPLE :
• Baissez la résolution des previews et Sample Steps,
• Réduisez Num Frames pour les previews vidéo.

Si vous entraînez dans RunComfy Cloud AI Toolkit, la sortie la plus simple est souvent de passer le job sur un GPU avec plus de VRAM et de relancer, en réduisant certaines options agressives de quantification/Low VRAM et en utilisant une config plus simple et plus rapide. Avec plus de VRAM et moins de “hacks”, chaque step est plus rapide et vous pouvez itérer sur plus de checkpoints au lieu de perdre du temps à micromanager la mémoire.

---

La LoRA overfit et détourne le modèle de base

Symptômes :

• Toutes les personnes ressemblent à votre sujet.
• Tous les camions ressemblent à votre produit même sans trigger word.

Atténuations :

• Baissez Linear Rank.
• Utilisez un checkpoint plus tôt (ex. 2000 steps au lieu de 3000).
• Augmentez légèrement Weight Decay.
• Ajoutez un dataset de régularisation de la même classe (Is Regularization = on).
• Activez Differential Output Preservation avec un DOP Loss Multiplier raisonnable (ex. 0.2–0.5) et une DOP Preservation Class adaptée ("person", "truck", etc.).