LoRA et QLoRA

Pourquoi ce chapitre est le plus utile

Le chapitre précédent a posé la question des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire. Celui-ci pose la question du budget : une fois le jeu SFT ou DPO prêt, comment l'utiliser pour modifier un modèle qui pèse plusieurs dizaines de milliards de paramètres, sans disposer d'un cluster de calcul dédié ?

Le fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire complet — recalculer et stocker un gradient pour chaque paramètre du modèle — reste hors de portée de la grande majorité des équipes, non par manque de compétence mais par manque de mémoire GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire. LoRALoRAIAMéthode d'adaptation légère d'un LLM : seules de petites matrices de rang faible sont entraînées, ce qui réduit fortement le coût GPU par rapport au fine-tuning complet.Voir dans le glossaire (Low-Rank Adaptation) et sa variante QLoRA (Quantized LoRA) répondent à cette contrainte en réduisant drastiquement le nombre de paramètres entraînés, sans toucher au modèle de base. Ce chapitre explique le mécanisme, les hyperparamètreshyperparamètreIARéglage choisi avant l'entraînement — vitesse d'apprentissage, taille du modèle, nombre d'itérations. Il se distingue des paramètres, ajustés automatiquement pendant l'entraînement.Voir dans le glossaire qui déterminent la qualité du résultat, et les pièges qui transforment un entraînement en temps perdu.

Le problème que résout l'adaptation à faible rang

Entraîner un modèle par descente de gradient classique exige de stocker, pour chaque paramètre entraînable, son gradient et généralement deux moments d'optimiseur (moyenne et variance, dans le cas d'Adam). Pour un modèle de 7 milliards de paramètres en précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire FP16, le fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire complet mobilise typiquement douze à seize fois la taille brute du modèle en mémoire GPU. Un GPU grand public de 24 Go de VRAM ne suffit pas, même pour un modèle de taille modeste.

LoRA part d'une observation empirique publiée par Hu et al. en 2021 : lorsqu'un modèle pré-entraîné est adapté à une tâche en aval, la mise à jour de poids nécessaire présente une intrinsic rank faible. Autrement dit, la matrice de différence entre les poids avant et après adaptation, bien que de dimension identique à la matrice de poids d'origine, peut être approximée avec une perte de qualité négligeable par le produit de deux matrices beaucoup plus petites.

Une matrice de rang r peut s'écrire comme le produit de deux matrices plus petites de dimensions correspondantes. Si la mise à jour réelle nécessaire pour adapter le modèle a un rang effectif faible, il est inutile de stocker et d'entraîner une matrice de la taille complète du modèle : une factorisation de rang r suffit à capturer l'essentiel du signal utile.

Le principe mathématique de LoRA

Pour une couche linéaire du modèle dont les poids sont représentés par une matrice W₀ de dimension d × d, le fine-tuning classique chercherait une nouvelle matrice W = W₀ + ΔW, où ΔW a la même dimension que W₀ et doit être entraînée intégralement.

LoRA gèle W₀ — il ne reçoit plus jamais de gradient — et remplace ΔW par le produit de deux matrices B et A beaucoup plus petites : ΔW = B · A, où B est de dimension d × r et A de dimension r × d, avec r (le rang) très inférieur à d. Le nombre de paramètres entraînables passe ainsi de d² à 2 × d × r, ce qui représente une réduction de plusieurs ordres de grandeur dès que r reste petit (typiquement entre 4 et 64) face à des dimensions de modèle de plusieurs milliers.

En pratique, B est initialisée à zéro et A selon une loi gaussienne, de sorte que ΔW vaut zéro au tout début de l'entraînement : le modèle adapté se comporte exactement comme le modèle de base tant qu'aucun gradient n'a encore été appliqué, ce qui stabilise le démarrage de l'entraînement.

Les hyperparamètres qui déterminent le résultat

Trois hyperparamètres gouvernent le comportement de LoRA, et leur mauvais réglage explique la majorité des adaptations décevantes.

• Le rang r — détermine la capacité d'expression de la mise à jour. Un rang trop faible (par exemple r=1 ou r=2) peut être insuffisant pour capturer une adaptation complexe ; un rang trop élevé rapproche l'entraînement d'un fine-tuning complet sans apporter de bénéfice proportionnel, tout en augmentant le risque de surapprentissagesurapprentissageIADéfaut d'un modèle qui mémorise ses exemples d'entraînement au lieu d'en dégager des régularités. Il excelle sur les données vues et échoue sur toute donnée nouvelle.Voir dans le glossaire sur un petit jeu de données.
• Le facteur d'échelle alpha — la mise à jour appliquée est en réalité (alpha / r) × B · A. Alpha contrôle donc l'amplitude de l'influence des adapters sur la sortie du modèle, indépendamment du rang choisi. Le ratio alpha/r est souvent plus déterminant en pratique que la valeur brute du rang.
• Les modules cibles (target_modules) — LoRA n'est pas appliqué à toutes les couches par défaut. Il faut choisir explicitement quelles matrices de projection reçoivent des adapters : projections de requête et de valeur de l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire seulement, ou également les projections de sortie et les couches du réseau feed-forward.

L'intuition selon laquelle « plus de paramètres entraînables donne un meilleur modèle » ne se vérifie pas systématiquement avec LoRA. Au-delà d'un certain rang, le gain de qualité stagne alors que le risque de surapprentissage sur un jeu de données de taille modeste augmente. Sur la plupart des tâches d'adaptation de style ou de domaine, un rang entre 8 et 32 couvre l'essentiel des besoins ; les rangs supérieurs à 64 se justifient surtout pour des extensions de capacité plus profondes.

Le tableau suivant résume les décisions structurantes entre les trois approches d'adaptation.

QLoRA : combiner quantification et adaptation

QLoRA, décrit par Dettmers et al. en 2023, part d'un constat simple : si les poids du modèle de base restent gelés pendant tout l'entraînement LoRA, il n'est pas nécessaire de les conserver en pleine précision. QLoRA quantifie le modèle de base en 4 bits avant l'entraînement, tout en gardant les adapters LoRA en précision plus élevée (BF16) pour les calculs de gradient.

Trois innovations techniques rendent cette combinaison viable sans dégradation notable de qualité :

• NF4 (NormalFloat 4-bit) — un format de quantification à 4 bits conçu pour représenter des poids dont la distribution suit approximativement une loi normale, comme c'est le cas dans un réseau entraîné. NF4 répartit ses niveaux de façon non uniforme, plus densément près de zéro, ce qui réduit l'erreur par rapport à un format à pas fixe.
• Double quantification — les constantes de quantification (calculées par blocs de poids) occupent elles-mêmes de la mémoire ; QLoRA les quantifie une seconde fois, ce qui économise environ 0,4 bit par paramètre supplémentaire, un gain significatif à l'échelle de plusieurs milliards de paramètres.
• Optimiseur paginé (paged optimizer) — s'appuie sur la mémoire unifiée du pilote GPU pour déplacer les états d'optimiseur vers la mémoire CPU lors des pics d'utilisation, évitant les interruptions par manque de mémoire lors de séquences particulièrement longues.

Pendant l'entraînement, chaque calcul de gradient nécessite de déquantifier temporairement les poids concernés vers une précision de calcul (BF16), effectuer l'opération, puis libérer cette représentation. Ce va-et-vient explique le léger surcoût en temps d'entraînement par rapport à LoRA classique, en échange d'une mémoire réduite qui rend l'adaptation de modèles de plusieurs dizaines de milliards de paramètres possible sur un unique GPU de 24 Go.

Certaines couches sont plus sensibles à la perte de précision que d'autres, en particulier les couches d'embeddingembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire et la tête de sortie (lm_head) sur des modèles multilingues ou à vocabulaire étendu. QLoRA laisse généralement ces couches en précision plus élevée par défaut, mais une configuration incorrecte qui quantifierait l'intégralité du modèle sans distinction peut provoquer une dégradation de qualité disproportionnée par rapport au gain mémoire obtenu. Vérifiez systématiquement la configuration de quantification appliquée par votre bibliothèque avant de lancer un entraînement long.

Choisir ses modules cibles : au-delà de l'attention

Une erreur fréquente consiste à limiter les adapters LoRA aux seules projections de requête et de valeur (q_proj et v_proj) de l'attention, configuration historiquement popularisée par l'article original. Des travaux ultérieurs ont montré qu'étendre les adapters aux projections de clé et de sortie, ainsi qu'aux couches du réseau feed-forward, améliore souvent la qualité finale à budget de paramètres comparable, en répartissant la capacité d'adaptation sur davantage de modules plutôt que sur un rang élevé concentré sur peu d'entre eux.

from peft import LoraConfig

config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

Ce réglage — rang 16, alpha 32 (ratio 2), adapters étendus à l'ensemble des projections d'attention et du bloc feed-forward — constitue un point de départ raisonnable pour une adaptation de domaine sur un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire causal, à ajuster ensuite selon les métriques de validation observées.

Le dropout appliqué spécifiquement aux adapters (lora_dropout) agit comme régularisation supplémentaire, utile lorsque le jeu de données d'entraînement est de taille modeste.

Fusion des adapters et déploiement

Un adapter LoRA entraîné peut être utilisé de deux façons en inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire. La première consiste à le charger séparément du modèle de base et à calculer W₀x + B·A·x à chaque passage avant, ce qui permet de changer d'adapter à la volée sans recharger le modèle complet — utile pour servir plusieurs tâches ou plusieurs clients depuis une seule copie du modèle de base en mémoire. La seconde consiste à fusionner l'adapter dans les poids de base en calculant explicitement W = W₀ + B·A une fois pour toutes, ce qui produit un modèle unique sans surcoût de calcul à l'inférence, mais perd la flexibilité de changement d'adapter à chaud.

Si un seul adapter doit être servi en production à volume élevé, la fusion élimine la latence supplémentaire liée au calcul séparé de la branche B·A à chaque inférence — un gain marginal par requête, mais mesurable à grande échelle. Si plusieurs adapters doivent coexister sur la même infrastructure (multi-tenant, plusieurs tâches), conservez-les séparés et chargez-les dynamiquement plutôt que de multiplier les copies complètes du modèle fusionné.

QLoRA introduit une contrainte supplémentaire pour la fusion : fusionner un adapter BF16 dans des poids de base encore quantifiés en 4 bits nécessite de déquantifier ces poids au préalable, ce qui annule une partie du bénéfice mémoire obtenu à l'entraînement. En pratique, un modèle entraîné avec QLoRA est le plus souvent déployé en conservant les adapters séparés au-dessus du modèle quantifié, ou après fusion sur des poids repassés en précision plus élevée.

Pièges fréquents en pratique

• Oublier de geler explicitement le modèle de base — certaines configurations laissent par erreur des paramètres du modèle de base entraînables en plus des adapters, ce qui annule une partie du gain mémoire et peut provoquer un oubli catastrophique.
• Choisir un rang uniforme sans tenir compte de la taille du modèle — un rang de 8 adapté à un modèle de 7 milliards de paramètres peut être sous-dimensionné pour un modèle de 70 milliards, où la capacité d'expression nécessaire croît avec la dimension des couches.
• Négliger le taux d'apprentissage spécifique aux adapters — initialisés à zéro et de dimension réduite, ils tolèrent généralement des taux d'apprentissage plus élevés qu'un fine-tuning complet ; réutiliser un taux calibré pour ce dernier ralentit inutilement la convergence.
• Comparer les coûts sans tenir compte du temps d'entraînement — QLoRA réduit la mémoire mais allonge le temps d'entraînement par rapport à LoRA classique en raison de la déquantification à la volée ; quand le GPU n'est pas le facteur limitant, LoRA classique reste souvent préférable.
• Appliquer un rang trop élevé sur un petit jeu de données — un adapter surdimensionné mémorise plutôt qu'il ne généralise, symptôme classique qu'un jeu de validation séparé permet de détecter tôt.

Checklist avant de lancer un entraînement LoRA ou QLoRA

• Le modèle de base est explicitement gelé, seuls les paramètres des adapters figurent dans la liste des paramètres entraînables
• Le rang r est choisi en cohérence avec la taille du modèle et la complexité de la tâche visée, pas fixé par défaut
• Le ratio alpha/r a été testé sur au moins deux valeurs différentes avant de figer la configuration
• Les modules cibles couvrent au minimum l'attention et idéalement le bloc feed-forward
• Un jeu de validation séparé permet de détecter un surapprentissage précoce des adapters
• Pour QLoRA, la configuration de quantification exclut explicitement les couches sensibles (embeddings, tête de sortie) si la bibliothèque utilisée ne le fait pas automatiquement
• La stratégie de déploiement (adapters séparés ou fusionnés) est décidée avant l'entraînement, car elle influence le choix de précision finale

Ce qu'il faut retenir avant le chapitre suivant

LoRA réduit le nombre de paramètres entraînés en approximant la mise à jour de poids nécessaire par le produit de deux matrices de rang faible, ramenant un fine-tuning hors de portée à un entraînement réalisable sur un GPU unique. QLoRA pousse ce principe plus loin en quantifiant le modèle de base en 4 bits, au prix d'un léger surcoût en temps de calcul mais avec une réduction supplémentaire de la mémoire nécessaire. Le rang, le facteur d'échelle alpha et le choix des modules cibles restent les leviers de réglage décisifs, et aucun de ces choix n'est universellement optimal : ils dépendent de la taille du modèle, du volume de données disponible et de l'écart entre le comportement de base et le comportement visé. Le chapitre suivant s'appuie sur ces mécanismes pour détailler la mécanique d'entraînement proprement dite : hyperparamètres globaux, formats de perte et diagnostics de convergence.