🧠Guide des hyperparamètres LoRA

Rang LoRA optimal, alpha, nombre d'époques, taille de lot et accumulation de gradient, QLoRA vs LoRA, modules cibles et plus encore !

Les hyperparamètres LoRA sont des paramètres ajustables qui contrôlent la manière dont la Low-Rank Adaptation (LoRA) affine les LLM. Avec de nombreuses options (comme le taux d'apprentissage et les époques) et des millions de combinaisons possibles, choisir les bonnes valeurs est crucial pour obtenir précision, stabilité, qualité et moins d'hallucinations lors de l'affinage.

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 le 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 inconnues. L'objectif est d'obtenir un modèle qui généralise bien, pas un qui se contente de mémoriser.

❓Mais qu'est-ce que LoRA ?

Dans les LLM, nous avons des poids de modèle. Llama 70B possède 70 milliards de nombres. Au lieu de modifier ces 70 milliards de nombres, nous ajoutons des matrices fines A et B à chaque poids, et optimisons celles-ci. Cela signifie que nous n'optimisons qu'1 % des poids.

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

🔢 Hyperparamètres clés pour l'affinage

Taux d'apprentissage

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

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

• Taux d'apprentissage faibles : Donnent un entraînement plus stable et plus précis mais peuvent nécessiter plus d'époques pour converger, augmentant le temps d'entraînement global. Bien que les faibles taux d'apprentissage soient souvent considérés comme provoquant du sous-apprentissage, ils peuvent en réalité conduire le surapprentissage ou même empêcher le modèle d'apprendre.

• Plage typique: 2e-4 (0,0002) à 5e-6 (0.000005). 🟩 Pour un affinage 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 l'affinage 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 des données d'entraînement.

• Plus d'époques : Peuvent aider le modèle à mieux apprendre, mais un nombre élevé peut le faire mémoriser les données d'entraînement, nuisant à ses performances 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 insuffisamment entraîné si le nombre est insuffisant pour que le modèle apprenne les schémas 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 d'affinage en 4 bits.

• LoRA : Affinage en 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 : Affinage en 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 d'adaptateur LoRA. Un rang plus élevé augmente la capacité du modèle mais aussi l'utilisation de la mémoire.	8, 16, 32, 64, 128 Choisir 16 ou 32
Alpha LoRA (lora_alpha)	Mets à l'échelle la force des ajustements fins 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 à zéro une fraction des activations LoRA pendant l'entraînement pour empêcher 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
Pas d'échauffement (Warmup) - étapes	Augmente progressivement le taux d'apprentissage au début de l'entraînement.	5-10 % du nombre total d'étapes
Type de planificateur	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 — 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.

🌳 Accumulation de gradient et équivalence de la 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. Cela 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

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

• Une Une taille de lot effective plus petite peut introduire plus de variance.

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

Paramètre	Description	Réglage recommandé
Taille de lot ( : Assurez-vous que les paramètres)	Le nombre d'échantillons traités en 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 gradient (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 : Assurez-vous que les paramètres 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 du gradient. Elle influence directement la stabilité de l'entraînement, la qualité et les performances finales du modèle.	4 à 16 Recommandé : 16 (à partir de 2 * 8)

Le compromis VRAM & performances

Supposons 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 utilise le moins de VRAM, mais au prix d'un entraînement légèrement plus lent. Pour éviter les erreurs OOM (mémoire insuffisante), préférez toujours définir un : Assurez-vous que les paramètres plus petit et augmenter gradient_accumulation_steps pour atteindre votre Taille de lot effective.

🦥 Correctif d'accumulation de gradient Unsloth

L'accumulation de gradient et les tailles de lot sont désormais entièrement équivalentes dans Unsloth grâce à nos corrections de bug pour l'accumulation de gradient. Nous avons implémenté des corrections de bugs spécifiques pour l'accumulation de gradient 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 : Assurez-vous que les paramètres et gradient_accumulation_steps qui produisaient le même Taille de lot effective (c.-à-d., batch_size × gradient_accumulation_steps = 16) n'entraînaient pas des comportements d'entraînement équivalents. 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 graphique, 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 application de nos correctifs, les courbes de perte s'alignent maintenant correctement, quel que soit le mode d'obtention du Taille de lot effective de 16 :

(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 la clé 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 d'affinage. Un rang plus grand 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 affinages 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 affinage complet. Bien qu'il soit possible de retirer des modules pour réduire l'utilisation de la mémoire, nous le déconseillons fortement afin de préserver la qualité maximale car les gains sont minimes.\

3. lora_alpha = 16,

   Un facteur d'échelle qui contrôle la force des ajustements fins. Le régler égal au rang (r) est une base fiable. Une heuristique populaire et efficace consiste à le régler au double du rang (r * 2), ce qui amène 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, # Prend en charge n'importe quelle valeur, mais = 0 est optimisé

   Une technique de régularisation qui aide à prévenir le surapprentissage en mettant aléatoirement à zéro une fraction des activations LoRA à chaque étape d'entraînement. Des recherches récentes suggèrent que pour les courtes sessions d'entraînement communes dans l'affinage, 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 un surapprentissage.\

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

   Laissez ceci à "none" pour un entraînement plus rapide et une utilisation de 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 or "unsloth" pour des contextes très longs

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

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 prenons en charge le LoRA à rang stabilisé

   Une fonctionnalité avancée qui implémente Rank-Stabilized LoRA. Si réglé sur True, la mise à l'échelle effective devient lora_alpha / sqrt(r) au lieu du standard lora_alpha / r. Cela peut parfois améliorer la stabilité, en particulier pour des rangs plus é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' premiers vecteurs singuliers des poids pré-entraînés. Cela peut améliorer la précision mais peut causer un pic de mémoire significatif au début 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 l'affinage, évitez d'utiliser np.allclose() pour 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 avec des tolérances numériques lâches. Merci à contributeurs pour cette section.

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

• L'utilisation de comparaisons de somme de contrôle ou de hachage (par ex., MD5)

• Calculer la somme des différences absolues entre tenseurs

• Inspection desstatistiques du tenseur (par ex., moyenne, variance) manuellement

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

📐Relation entre LoRA Alpha et Rank

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 de mise à l'é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 fines A et B par alpha divisé par le rang. Cela signifie que nous devrions garder alpha/rang au moins = 1.

Selon le papier 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, définissez use_rslora = True dans Unsloth.

Notre recommandation est de définir 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 la 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 aux MLP.

Le graphique montre les scores RougeL (plus élevé est meilleur) 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. 🔥 Ceci donne la meilleure performance globale.

2. QLoRA-FFN : LoRA uniquement sur les 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.

😎 L'entraînement uniquement sur les complétions, en masquant les entrées

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

NE PAS entraînement uniquement sur les complétions :

UTILISATEUR : Bonjour quelle est la valeur de 2+2 ? ASSISTANT : La réponse est 4. UTILISATEUR : Bonjour quelle est la valeur de 3+3 ? ASSISTANT : La réponse est 6.

Entraînement sur les complétions uniquement :

UTILISATEUR : Bonjour quelle est la valeur de 2+2 ? ASSISTANT : La réponse est 4. UTILISATEUR : Bonjour quelle est la valeur de 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, en particulier pour les ajustements fins conversationnels multi‑tours ! Nous le faisons dans nos carnets conversationnels ici.

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

Pour les modèles Llama 3, 3.1, 3.2, 3.3 et 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 LLMs
    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 sauts de 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 et le sous‑apprentissage

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

Le modèle mémorise les données d'entraînement, y compris leur bruit statistique, et échoue par conséquent à généraliser à des 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 le redimensionnement de l'alpha LoRA — multipliez simplement la valeur alpha de chaque matrice LoRA par 0,5. Cela réduit effectivement l'impact de l'ajustement fin.

Ceci est étroitement lié à la fusion / la 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 le alpha de moitié.

Solution :

• Ajuster le taux d'apprentissage : Un taux d'apprentissage élevé conduit souvent au surapprentissage, surtout lors de courtes sessions d'entraînement. Pour un entraînement plus long, un taux plus élevé peut mieux fonctionner. Il est préférable d'expérimenter les deux pour voir lequel donne les meilleurs résultats.

• 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 gradients.

• Expansion du jeu de données - agrandissez votre jeu de données en combinant ou concaténant des jeux de données open source avec votre jeu. Choisissez des jeux 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 de l'alpha LoRA - réduisez l'alpha après l'entraînement et pendant l'inférence - cela rendra l'ajustement fin moins prononcé.

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

Sous‑apprentissage (Trop générique)

Le modèle ne parvient pas à capturer les schémas 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 :

• Ajuster le taux d'apprentissage : Si le taux actuel est trop bas, l'augmenter peut accélérer la convergence, en particulier pour les sessions d'entraînement courtes. Pour des sessions plus longues, essayez plutôt de baisser le taux d'apprentissage. Testez les deux approches pour voir laquelle fonctionne le mieux.

• Augmenter le nombre d'époques d'entraînement : Entraînez pendant davantage 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 est généralement compris 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 de façon plus vigoureuse.

Le fine‑tuning n'a pas d'approche « meilleure » unique, seulement des bonnes pratiques. L'expérimentation est la clé pour trouver ce qui convient à vos besoins spécifiques. Nos carnets 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 grand merci à Eyera pour avoir contribué à ce guide !