Après une longue attente de 8 heures, l'apprentissage est enfin terminé.

Quels ont été les résultats de l'ajustement du modèle FLUX 1-dev 12B sur DGX Spark (basé sur ARM) avec une consommation de seulement 90W ?

Aujourd'hui, je vais comparer les adaptateurs LoRA générés en fonction des étapes 250, 500, 750 et 1000, et parler de ce que j'ai découvert sur le 'point idéal d'apprentissage (Honey Spot)'.

1. Environnement et conditions de test

Commandbox 광고

  • Modèle de base : FLUX 1-dev (12B)

  • Ensemble de données : 40 images réalistes de personnes (1024x1024)

  • Échantillonneur : dpmpp_2m, euler

  • Matériel : DGX Spark (Mémoire unifiée de 120 Go)

  • Points de contrôle LoRA : Étape 250, 500, 750, 1000

2. Comparaison des résultats par étapes (La bataille des étapes)

J'ai testé la cohérence en générant des images réalistes avec des personnages entraînés.

🥉 Étape 250 : "Toi... qui es-tu?" (Sous-ajustement)

  • Résultat : L'ambiance est semblable à celle du sujet, mais si on demande : "Est-ce la même personne ?", on se gratte la tête. Les détails des traits du visage manquent.

  • Vitesse : La vitesse de génération était la plus rapide (moins de 100 secondes), mais la qualité n'était pas au rendez-vous.

  • Diagnostic : Sous-ajustement. Le modèle n'a pas encore suffisamment assimilé les caractéristiques des données.

🥈 Étape 500 : "Ah ! C'est toi !" (Bon ajustement)

  • Résultat : C'est clairement la personne que l'on a entraînée. Je ressens enfin que le LoRA fonctionne correctement.

  • Particularité : Parfois, lorsqu'on change d'expressions, cela peut ressembler à une autre personne, mais en général, la cohérence est excellente.

  • Diagnostic : Entrée dans la plage d'apprentissage optimale. À partir de ce point, il semble que cela puisse être utilisé dans un cadre réel avec 40 images de données.

🥇 Étape 750 : "L'esthétique de la stabilité" (Stable)

  • Résultat : Il n'y a pas beaucoup de différences avec l'étape 500, mais c'est un peu plus stable. Les caractéristiques de la personne se maintiennent bien dans diverses poses.

  • Diagnostic : C'est une prolongation de l'étape 500, on pourrait dire que c'est une sensation 'mûrie'.

🏅 Étape 1000 : "Parfait mais... trop parfait!" (Risque de surajustement)

  • Résultat : Cohérence de 100 %. Même lors d'un test à l'aveugle, il est difficile de distinguer de l'original.

  • Problème : Si l'on demande des expressions 'en colère', 'sexy', qui n'étaient pas dans les données d'apprentissage, cela perturbe la cohérence du personnage.

  • Diagnostic : À la limite du surajustement. Le modèle a mémorisé exagérément les données d'apprentissage ("Cette personne a cette expression"), et sa capacité de généralisation commence à diminuer.

3. Mystères techniques et analyse

Commandbox 광고

J'ai découvert deux questions techniques intéressantes (ou troublantes) pendant le processus de test.

1) Fichier LoRA de 5 Go ?

La taille des 4 fichiers LoRA générés était tous 5 Go. Normalement, un adaptateur LoRA devrait peser entre quelques dizaines et centaines de Mo.

Analyse :

Au début, je me suis demandé si "L'état de l'optimiseur ou l'ensemble de l'encodeur de texte avaient été stockés ensemble ?" Mais,
si on colle un LoRA de rang 256 à toutes les couches pour un modèle de 12B, le nombre de paramètres de LoRA peut vraiment atteindre plusieurs Go.
Donc, en se basant sur la norme SD1.5 que 'LoRA devrait faire entre quelques dizaines et quelques centaines de Mo', on ne peut pas appliquer cette intuition.
Il devient clair que dans des modèles de grande taille, le rang de LoRA et la portée de son application sont directement liés à la taille.
La prochaine fois, je prévois d'abaisser network_dim à un niveau de 64 à 128 pour rétablir l'équilibre entre taille et performance.

2) Diminution de la vitesse de génération (97-130 secondes)

Le temps de génération a augmenté par rapport à avant l'application de LoRA.

Analyse :

  1. Cause structurelle : LoRA ajoute le poids appris ($B \times A$) au poids de base ($W$), donc la charge computationnelle augmente.

  2. Goulot d'étranglement : En raison de la conception du script d'apprentissage, l'encodeur de texte T5XXL utilise une structure où il est chargé sur le CPU après mise en cache, Par conséquent, je suspecte qu'il y ait eu des allers-retours CPU↔GPU dans le pipeline d'inférence via un chemin similaire.
    Cependant, cette partie n'a pas encore été entièrement vérifiée au niveau du code, donc lors du prochain test :

  3. Je vais examiner ce qui se passe quand je force tous les TE à CUDA

  4. Et quand je change ma stratégie de cache,
    je comparerai comment cela affecte la vitesse et la qualité de génération.

4. Conclusion : À la recherche du 'point idéal' (Honey Spot)

La conclusion que j'ai tirée de ce long voyage de 8 heures est claire. "Apprendre beaucoup ne garantit pas des résultats meilleurs."

  1. Plage optimale : Sur la base d'un ensemble de 40 images, il semble que la plage de 400 à 600 étapes soit le point idéal alliant 'rapport qualité-prix' et 'qualité'. 1000 étapes ne sont pas seulement une perte de temps, mais peuvent également nuire à la flexibilité.

  2. Importance des données : Si l'on n'entraîne qu'une expression spécifique, on devient un 'robot d'expressions' incapable d'en produire d'autres. Lors de la constitution de l'ensemble de données, il est beaucoup plus important d'inclure diverses angles et expressions que d'augmenter le nombre d'étapes.

  3. Possibilités de DGX Spark : Bien que cela ait pris 8 heures et qu'il y ait eu des problèmes de configuration, le fait d'avoir réussi à ajuster un modèle de 12B avec 90W de puissance est encourageant.

Bien sûr, ce point idéal (plage de 400 à 600 étapes)
provient de conditions assez spécifiques, à savoir “40 images / FLUX 1-dev / cette configuration LoRA”.
Cependant, à partir de cette expérience, j'ai réalisé que :

  • Il faut d'abord explorer une plage d'étapes raisonnables en fonction du nombre de données
  • Et à l'intérieur de cette plage, il faut sauvegarder méticuleusement pour déterminer le point optimal.

5. Prochaine étape

Les objectifs du prochain test sont clairs.

  • Optimisation : Je vais explorer si je dois allouer tous les encodeurs de texte (TE) à CUDA, ou si cela relève de la conception du script FLUX LoRA (diminuer la VRAM en stockant le grand T5XXL dans le CPU après mise en cache).

  • Dieta LoRA : Comparer lorsque network_dim est réduit de 256 à 128 puis 64 en ce qui concerne la taille, la qualité et la cohérence.

  • Ciblage précis : Identifier le meilleur modèle en coupant finement la plage de 400 à 600 étapes sans atteindre 1000 étapes (sauvegarder tous les 50 étapes).

  • Introduction de légendes dans l'ensemble de données d'apprentissage :

    • Comparer 40 images de la même personne avec et sans légendes
    • Analyser du point de vue de la "diversité des expressions/postures vs surajustement"

La recherche sur l'IA à faible consommation d'énergie et efficace continue. Dans le prochain article, je reviendrai avec un LoRA qui a réussi sa diète !