🧠Guide des hyperparamètres LoRA pour l'affinage

Apprenez étape par étape les meilleurs réglages pour l'affinage des LLM - rang & alpha LoRA, époques, taille de batch + accumulation de gradient, QLoRA vs LoRA, modules cibles, et plus encore.

Les hyperparamètres LoRA sont des réglages ajustables qui régissent la façon dont l'Adaptation à Faible Rang affine les LLM. Avec de nombreux choix (par ex., taux d'apprentissage et époques) et d'innombrables combinaisons, choisir les bonnes valeurs est essentiel pour la précision, la stabilité, la qualité et la réduction des hallucinations. Bien fait, LoRA peut égaler les performances d'un fine-tuning complet tout en utilisant 4× moins de VRAM.

Vous apprendrez les meilleures pratiques pour ces paramètres, basées sur des enseignements tirés de centaines d'articles de recherche et d'expériences, et verrez comment ils impactent le modèle. Bien que nous recommandions d'utiliser les paramètres par défaut d'Unsloth, comprendre ces concepts vous donnera un contrôle total. L'objectif est de modifier les valeurs des hyperparamètres pour augmenter la précision tout en contrebalançant le surapprentissage ou le sous-apprentissage. Le surapprentissage se produit lorsque le modèle mémorise les données d'entraînement, nuisant à sa capacité à généraliser à de nouvelles entrées non vues. L'objectif est d'obtenir un modèle qui généralise bien, pas un modèle qui se contente de mémoriser.

❓Mais qu'est-ce que LoRA ?

Dans les LLM, nous avons des poids de modèle. Llama 70B a 70 milliards de nombres. Plutôt que de changer les 70 milliards de nombres, nous ajoutons des matrices minces A et B à chaque poids, et optimisons celles-ci. Cela signifie que nous n'optimisons que 1 % des poids.

Au lieu d'optimiser les poids du modèle (en jaune), nous optimisons 2 matrices minces A et B.

🔢 Hyperparamètres clés du Fine-tuning

Taux d'apprentissage

Définit dans quelle mesure les poids du modèle sont ajustés à chaque étape d'entraînement.

• Taux d'apprentissage élevés : Mènent à une convergence initiale plus rapide mais peuvent rendre l'entraînement instable ou empêcher de trouver un minimum optimal si trop élevés.

• Taux d'apprentissage faibles : Donnent un entraînement plus stable et précis mais peuvent nécessiter plus d'époques pour converger, augmentant le temps total d'entraînement. Bien que l'on pense souvent que des taux faibles provoquent du sous-apprentissage, ils peuvent en réalité entraîner le surapprentissage ou même empêcher le modèle d'apprendre.

• Plage typique: 2e-4 (0.0002) à 5e-6 (0.000005). 🟩 Pour un fine-tuning LoRA/QLoRA normal, nous recommandons 2e-4 comme point de départ. 🟦 Pour l'apprentissage par renforcement (DPO, GRPO etc.), nous recommandons 5e-6 . ⬜ Pour le fine-tuning complet, des taux d'apprentissage plus faibles sont généralement plus appropriés.

Époques

Le nombre de fois que le modèle voit l'ensemble complet de données d'entraînement.

• Plus d'époques : Peuvent aider le modèle à mieux apprendre, mais un grand nombre peut le faire mémoriser les données d'entraînement, nuisant à sa performance sur de nouvelles tâches.

• Moins d'époques : Réduisent le temps d'entraînement et peuvent prévenir le surapprentissage, mais peuvent aboutir à un modèle sous-entraîné si le nombre est insuffisant pour que le modèle apprenne les motifs sous-jacents du jeu de données.

• Recommandé : 1-3 époques. Pour la plupart des jeux de données basés sur des instructions, s'entraîner plus de 3 époques offre des rendements décroissants et augmente le risque de surapprentissage.

LoRA ou QLoRA

LoRA utilise une précision 16 bits, tandis que QLoRA est une méthode de fine-tuning en 4 bits.

• LoRA : Fine-tuning 16 bits. C'est légèrement plus rapide et légèrement plus précis, mais consomme beaucoup plus de VRAM (4× plus que QLoRA). Recommandé pour les environnements 16 bits et les scénarios où la précision maximale est requise.

• QLoRA : Fine-tuning 4 bits. Légèrement plus lent et marginalement moins précis, mais utilise beaucoup moins de VRAM (4× moins). 🦥 LLaMA 70B tient dans <48GB de VRAM avec QLoRA dans Unsloth - plus de détails ici.

Hyperparamètres et recommandations :

Hyperparamètre	Fonction	Paramètres recommandés
Rang LoRA (r)	Contrôle le nombre de paramètres entraînables dans les matrices adaptatrices LoRA. Un rang plus élevé augmente la capacité du modèle mais aussi l'utilisation mémoire.	8, 16, 32, 64, 128 Choisissez 16 ou 32
Alpha LoRA (lora_alpha)	Ajuste la force des ajustements du fine-tuning par rapport au rang (r).	r (standard) ou r * 2 (heuristique courante). Plus de détails ici.
Dropout LoRA	Une technique de régularisation qui met aléatoirement une fraction des activations LoRA à zéro pendant l'entraînement pour prévenir le surapprentissage. Pas très utile, donc nous le réglons par défaut à 0.	0 (par défaut) à 0.1
Décroissance des poids	Un terme de régularisation qui pénalise les poids importants pour prévenir le surapprentissage et améliorer la généralisation. N'utilisez pas des valeurs trop élevées !	0.01 (recommandé) - 0.1
Étapes d'échauffement	Augmente progressivement le taux d'apprentissage au début de l'entraînement.	5-10% du nombre total d'étapes
Type de scheduler	Ajuste dynamiquement le taux d'apprentissage pendant l'entraînement.	linéaire ou cosine
Graine (random_state)	Un nombre fixe pour assurer la reproductibilité des résultats.	N'importe quel entier (par ex., 42, 3407)
Modules cibles	Spécifiez quelles parties du modèle vous souhaitez appliquer les adaptateurs LoRA — soit l'attention, le MLP, ou les deux. Attention : q_proj, k_proj, v_proj, o_proj MLP : gate_proj, up_proj, down_proj	Recommandé de cibler toutes les principales couches linéaires : q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj.

🌳 Équivalence entre accumulation de gradients et taille de lot

Taille de lot effective

Configurer correctement votre taille de lot est crucial pour équilibrer la stabilité de l'entraînement avec les limitations de VRAM de votre GPU. Ceci est géré par deux paramètres dont le produit est la Taille de lot effective. Taille de lot effective = batch_size * gradient_accumulation_steps

• Un Taille de lot effective plus grande conduit généralement à un entraînement plus fluide et plus stable.

• Un Taille de lot effective plus petite peut introduire davantage de variance.

Bien que chaque tâche soit différente, la configuration suivante offre un excellent point de départ pour obtenir une Taille de lot effective de 16, qui fonctionne bien pour la plupart des tâches de fine-tuning sur les GPU modernes.

Paramètre	Description	Réglage recommandé
Taille de lot (batch_size)	Le nombre d'exemples traités dans une seule passe avant/arrière sur un GPU. Principal facteur d'utilisation de la VRAM. Des valeurs plus élevées peuvent améliorer l'utilisation du matériel et accélérer l'entraînement, mais seulement si elles tiennent en mémoire.	2
Accumulation de gradients (gradient_accumulation_steps)	Le nombre de micro-lots à traiter avant d'effectuer une seule mise à jour des poids du modèle. Principal facteur du temps d'entraînement. Permet de simuler une plus grande batch_size pour économiser de la VRAM. Des valeurs plus élevées augmentent le temps d'entraînement par époque.	8
Taille de lot effective (Calculé)	La véritable taille de lot utilisée pour chaque mise à jour de gradient. Elle influence directement la stabilité de l'entraînement, la qualité et la performance finale du modèle.	4 à 16 Recommandé : 16 (à partir de 2 * 8)

Le compromis VRAM & performance

Supposez que vous souhaitiez 32 échantillons de données par étape d'entraînement. Vous pouvez alors utiliser l'une des configurations suivantes :

• batch_size = 32, gradient_accumulation_steps = 1

• batch_size = 16, gradient_accumulation_steps = 2

• batch_size = 8, gradient_accumulation_steps = 4

• batch_size = 4, gradient_accumulation_steps = 8

• batch_size = 2, gradient_accumulation_steps = 16

• batch_size = 1, gradient_accumulation_steps = 32

Bien que toutes ces configurations soient équivalentes pour les mises à jour des poids du modèle, elles ont des exigences matérielles très différentes.

La première configuration (batch_size = 32) utilise le plus de VRAM et échouera probablement sur la plupart des GPU. La dernière configuration (batch_size = 1) utilise le le moins de VRAM, mais au prix d'un entraînement légèrement plus lent. Pour éviter les erreurs OOM (out of memory), préférez toujours définir un batch_size plus petit et augmentez gradient_accumulation_steps pour atteindre votre Taille de lot effective.

🦥 Correction d'accumulation de gradient d'Unsloth

L'accumulation de gradients et les tailles de lot sont désormais entièrement équivalentes dans Unsloth grâce à nos corrections de bugs pour l'accumulation de gradients. Nous avons implémenté des corrections spécifiques qui résolvent un problème courant où les deux méthodes ne produisaient pas les mêmes résultats. C'était un défi connu dans la communauté, mais pour les utilisateurs d'Unsloth, les deux méthodes sont désormais interchangeables.

Lisez notre article de blog pour plus de détails.

Avant nos corrections, des combinaisons de batch_size et gradient_accumulation_steps qui donnaient le même Taille de lot effective (c.-à-d., batch_size × gradient_accumulation_steps = 16) n'entraînaient pas un comportement d'entraînement équivalent. Par exemple, des configurations comme b1/g16, b2/g8, b4/g4, b8/g2, et b16/g1 ont toutes un Taille de lot effective de 16, mais comme le montre le graphe, les courbes de perte ne s'alignaient pas lors de l'utilisation de l'accumulation de gradient standard :

(Avant - Accumulation de gradient standard)

Après l'application de nos corrections, les courbes de perte s'alignent désormais correctement, indépendamment de la façon dont le Taille de lot effective de 16 est atteint :

(Après - 🦥 Accumulation de gradient Unsloth)

🦥 Hyperparamètres LoRA dans Unsloth

Ce qui suit démontre une configuration standard. Bien qu'Unsloth fournisse des valeurs par défaut optimisées, comprendre ces paramètres est essentiel pour un réglage manuel.

1. r = 16, # Choisissez n'importe quel nombre > 0 ! Suggestion 8, 16, 32, 64, 128

   Le rang (r) du processus de fine-tuning. Un rang plus élevé utilise plus de mémoire et sera plus lent, mais peut augmenter la précision sur des tâches complexes. Nous suggérons des rangs comme 8 ou 16 (pour des fine-tunings rapides) et jusqu'à 128. Utiliser un rang trop grand peut provoquer du surapprentissage et nuire à la qualité de votre modèle.\

2. target_modules = ["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj",],

   Pour des performances optimales, LoRA devrait être appliqué à toutes les principales couches linéaires. La recherche a montré que cibler toutes les couches majeures est crucial pour égaler les performances d'un fine-tuning complet. Bien qu'il soit possible de retirer des modules pour réduire l'utilisation mémoire, nous le déconseillons fortement afin de préserver la qualité maximale, car les économies sont minimes.\

3. lora_alpha = 16,

   Un facteur d'échelle qui contrôle la force des ajustements du fine-tuning. Le régler égal au rang (r) est une base fiable. Une heuristique populaire et efficace est de le régler au double du rang (r * 2), ce qui pousse le modèle à apprendre de manière plus agressive en donnant plus de poids aux mises à jour LoRA. Plus de détails ici.\

4. lora_dropout = 0, # Accepte n'importe quelle valeur, mais = 0 est optimisé

   Une technique de régularisation qui aide à prévenir le surapprentissage en mettant aléatoirement une fraction des activations LoRA à zéro à chaque étape d'entraînement. Des recherches récentes suggèrent que pour les courts entraînements courants dans le fine-tuning, lora_dropout peut être un régularisateur peu fiable. 🦥 Le code interne d'Unsloth peut optimiser l'entraînement lorsque lora_dropout = 0, le rendant légèrement plus rapide, mais nous recommandons une valeur non nulle si vous suspectez du surapprentissage.\

5. bias = "none",    # Accepte n'importe quelle valeur, mais = "none" est optimisé

   Laissez ceci sur "none" pour un entraînement plus rapide et une utilisation mémoire réduite. Ce réglage évite d'entraîner les termes de biais dans les couches linéaires, ce qui ajoute des paramètres entraînables pour peu ou pas de gain pratique.\

6. use_gradient_checkpointing = "unsloth", # True ou "unsloth" pour un contexte très long

   Les options sont True, False, et "unsloth". 🦥 Nous recommandons "unsloth" car cela réduit l'utilisation mémoire d'environ 30% supplémentaires et prend en charge des fine-tunings avec un contexte extrêmement long. Vous pouvez en lire plus sur notre article de blog sur l'entraînement avec long contexte.\

7. random_state = 3407,

   La graine pour assurer des exécutions déterministes et reproductibles. L'entraînement implique des nombres aléatoires, donc fixer une graine est essentiel pour des expériences cohérentes.\

8. use_rslora = False,  # Nous supportons le LoRA stabilisé par le rang

   Une fonctionnalité avancée qui implémente Rank-Stabilized LoRA. Si réglé sur True, le facteur d'échelle effectif devient lora_alpha / sqrt(r) au lieu du standard lora_alpha / r. Cela peut parfois améliorer la stabilité, en particulier pour des rangs élevés. Plus de détails ici.\

9. loftq_config = None, # Et LoftQ

   Une technique avancée, proposée dans LoftQ, initialise les matrices LoRA avec les 'r' principaux vecteurs singuliers des poids pré-entraînés. Cela peut améliorer la précision mais provoquer un pic significatif de mémoire au démarrage de l'entraînement.

Vérification des mises à jour des poids LoRA :

Lors de la validation que LoRA les poids de l'adaptateur ont été mis à jour après le fine-tuning, évitez d'utiliser np.allclose() pour la comparaison. Cette méthode peut manquer des changements subtils mais significatifs, en particulier dans LoRA A, qui est initialisée avec de petites valeurs gaussiennes. Ces changements peuvent ne pas être considérés comme significatifs sous des tolérances numériques larges. Merci aux contributeurs pour cette section.

Pour confirmer de manière fiable les mises à jour des poids, nous recommandons :

• Utiliser des comparaisons de sommes de contrôle ou de hachage (par ex., MD5)

• Calculer la somme des différences absolues entre tenseurs

• Inspecter les statistiques detenseur (par ex., moyenne, variance) manuellement

• Ou utiliser np.array_equal() si une égalité exacte est attendue

📐Relation entre Alpha LoRA et Rang

Il est préférable de définir lora_alpha = 2 * lora_rank ou lora_alpha = lora_rank

$$\hat{W} = W + \frac{\alpha}{\text{rank}} \times AB$$

rsLoRA autres options d'échelle. sqrt(r) est la meilleure.

$$\hat{W}_{\text{rslora}} = W + \frac{\alpha}{\sqrt{\text{rank}}} \times AB$$

La formule pour LoRA est à gauche. Nous devons mettre à l'échelle les matrices minces A et B par alpha divisé par le rang. Cela signifie que nous devons garder alpha/rang au moins = 1.

Selon le article rsLoRA (rank stabilized lora), nous devrions plutôt mettre à l'échelle alpha par la racine carrée du rang. D'autres options existent, mais théoriquement c'est l'optimum. Le graphique de gauche montre d'autres rangs et leurs perplexités (plus bas est meilleur). Pour activer cela, réglez use_rslora = True dans Unsloth.

Notre recommandation est de régler alpha égal au rang, ou au moins 2 fois le rang. Cela signifie alpha/rang = 1 ou 2.

🎯 Modules cibles LoRA et QLoRA vs LoRA

Utilisez : target_modules = ["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj",] pour cibler à la fois MLP et attention couches pour augmenter la précision.

QLoRA utilise une précision 4 bits, réduisant l'utilisation de la VRAM de plus de 75%.

LoRA (16 bits) est légèrement plus précis et plus rapide.

Selon des expériences empiriques et des articles de recherche comme l'original article QLoRA, il est préférable d'appliquer LoRA à la fois aux couches d'attention et MLP.

Le graphique montre les scores RougeL (plus élevé est mieux) pour différentes configurations de modules cibles, comparant LoRA et QLoRA.

Les 3 premiers points montrent :

1. QLoRA-All : LoRA appliqué à toutes les couches FFN/MLP et Attention. 🔥 Celle-ci donne les meilleures performances globales.

2. QLoRA-FFN : LoRA uniquement sur FFN. Équivalent à : gate_proj, up_proj, down_proj.

3. QLoRA-Attention : LoRA appliqué uniquement aux couches d'Attention. Équivalent à : q_proj, k_proj, v_proj, o_proj.

😎 S'entraîner uniquement sur les complétions, en masquant les entrées

Le article QLoRA montre que masquer les entrées et s'entraîner seulement sur les complétions (sorties ou messages de l'assistant) peut encore augmenter la précision de quelques points de pourcentage (1%). Ci-dessous est démontré comment cela est fait dans Unsloth :

PAS s'entraîner seulement sur les complétions :

UTILISATEUR : Bonjour, combien font 2+2 ? ASSISTANT : La réponse est 4. UTILISATEUR : Bonjour, combien font 3+3 ? ASSISTANT : La réponse est 6.

Entraînement sur les complétions seulement :

UTILISATEUR : Bonjour, combien font 2+2 ? ASSISTANT : La réponse est 4. UTILISATEUR : Bonjour, combien font 3+3 ? ASSISTANT : La réponse est 6.

L'article QLoRA indique que s'entraîner uniquement sur les complétions augmente considérablement la précision, surtout pour les fine-tunings conversationnels multi-tours ! Nous faisons cela dans nos notebooks conversationnels ici.

Pour activer l'entraînement sur les complétions dans Unsloth, vous devrez définir les parties instruction et assistant. 🦥 Nous prévoyons d'automatiser cela davantage pour vous à l'avenir !

Pour Llama 3, 3.1, 3.2, 3.3 et les modèles 4, vous définissez les parties comme suit :

from unsloth.chat_templates import train_on_responses_only
trainer = train_on_responses_only(
    trainer,
    instruction_part = "<|start_header_id|>user<|end_header_id|>\n\n",
    response_part = "<|start_header_id|>assistant<|end_header_id|>\n\n",
)

Pour les modèles Gemma 2, 3, 3n, vous définissez les parties comme suit :

from unsloth.chat_templates import train_on_responses_only
trainer = train_on_responses_only(
    trainer,
    instruction_part = "<start_of_turn>user\n",
    response_part = "<start_of_turn>model\n",
)

🔎Entraînement uniquement sur les réponses de l'assistant pour les modèles de vision, VLMs

Pour les modèles de langage, nous pouvons utiliser from unsloth.chat_templates import train_on_responses_only comme décrit précédemment. Pour les modèles de vision, utilisez les arguments supplémentaires dans UnslothVisionDataCollator comme avant !

class UnslothVisionDataCollator :
def __init__(
    self,
    ...
    # from unsloth.chat_templates import train_on_responses_only
    # trainer = train_on_responses_only(
    #     trainer,
    #     instruction_part = "<|start_header_id|>user<|end_header_id|>\n\n",
    #     response_part = "<|start_header_id|>assistant<|end_header_id|>\n\n",
    # )
    train_on_responses_only = False, # ÉQUIVALENT à train_on_responses_only pour les LLM
    instruction_part = None, # ÉQUIVALENT à train_on_responses_only(instruction_part = ...)
    response_part    = None, # ÉQUIVALENT à train_on_responses_only(response_part = ...)
    force_match      = True, # Faire correspondre aussi les retours à la ligne !
)

Par exemple pour Llama 3.2 Vision :

UnslothVisionDataCollator(
    model, tokenizer,
    ...
    train_on_responses_only = True,
    instruction_part = "<|start_header_id|>user<|end_header_id|>\n\n",
    response_part = "<|start_header_id|>assistant<|end_header_id|>\n\n",
    ...
)

🔑 Éviter le surapprentissage & le sous-apprentissage

Surapprentissage (Mauvaise généralisation/Trop spécialisé)

Le modèle mémorise les données d'entraînement, y compris le bruit statistique, et par conséquent ne parvient pas à généraliser aux données non vues.

Si votre perte d'entraînement descend en dessous de 0.2, votre modèle est probablement le surapprentissage — ce qui signifie qu'il peut mal performer sur des tâches non vues.

Une astuce simple est la mise à l'échelle de l'alpha LoRA — multipliez simplement la valeur alpha de chaque matrice LoRA par 0.5. Cela réduit effectivement l'impact du fine-tuning.

Ceci est étroitement lié à la fusion / moyenne des poids. Vous pouvez prendre le modèle de base original (ou instruct), ajouter les poids LoRA, puis diviser le résultat par 2. Cela vous donne un modèle moyenné — ce qui est fonctionnellement équivalent à réduire l'alpha de moitié.

Solution :

• Ajustez le taux d'apprentissage : Un taux d'apprentissage élevé conduit souvent au surapprentissage, surtout lors de courts entraînements. Pour des entraînements plus longs, un taux plus élevé peut mieux fonctionner. Il est préférable d'expérimenter les deux pour voir lequel fonctionne le mieux.

• Réduire le nombre d'époques d'entraînement. Arrêtez l'entraînement après 1, 2 ou 3 époques.

• Augmenter weight_decay. Une valeur de 0.01 ou 0.1 est un bon point de départ.

• Augmenter lora_dropout. Utilisez une valeur comme 0.1 pour ajouter de la régularisation.

• Augmenter la taille de lot ou les étapes d'accumulation de gradient.

• Expansion du jeu de données - augmentez la taille de votre jeu de données en combinant ou en concaténant des jeux de données open source avec votre jeu de données. Choisissez ceux de meilleure qualité.

• Arrêt précoce basé sur l'évaluation - activez l'évaluation et arrêtez lorsque la perte d'évaluation augmente pendant quelques étapes.

• Mise à l'échelle alpha LoRA - réduisez l'alpha après l'entraînement et pendant l'inférence - cela rendra le fine-tuning moins prononcé.

• Moyennage des poids - ajoutez littéralement le modèle instruct original et le fine-tune puis divisez les poids par 2.

Sous-apprentissage (Trop générique)

Le modèle ne parvient pas à capturer les motifs sous-jacents des données d'entraînement, souvent en raison d'une complexité insuffisante ou d'une durée d'entraînement trop courte.

Solution :

• Ajustez le taux d'apprentissage : Si le taux actuel est trop bas, l'augmenter peut accélérer la convergence, surtout pour les courts entraînements. Pour des runs plus longs, essayez plutôt d'abaisser le taux d'apprentissage. Testez les deux approches pour voir laquelle fonctionne le mieux.

• Augmenter les époques d'entraînement : Entraînez plus d'époques, mais surveillez la perte de validation pour éviter le surapprentissage.

• Augmenter le rang LoRA (r) et l'alpha : le rang doit au moins être égal au nombre alpha, et le rang doit être plus grand pour les modèles plus petits/jeux de données plus complexes ; il se situe généralement entre 4 et 64.

• Utiliser un jeu de données plus pertinent pour le domaine : Assurez-vous que les données d'entraînement sont de haute qualité et directement pertinentes pour la tâche cible.

• Diminuer la taille de lot à 1. Cela fera que le modèle se mette à jour plus vigoureusement.

Le fine-tuning n'a pas d'approche "meilleure" unique, seulement des meilleures pratiques. L'expérimentation est la clé pour trouver ce qui fonctionne pour vos besoins spécifiques. Nos notebooks définissent automatiquement des paramètres optimaux basés sur de nombreuses recherches et nos expériences, vous offrant un excellent point de départ. Bon fine-tuning !

Remerciements : Un énorme merci à Eyera pour avoir contribué à ce guide !