RAG, LoRA, QLoRA, Full FT : quelle méthode pour adapter un LLM à vos données

En 2021, adapter un modèle de langage à un vocabulaire ou un ton spécifique coûtait plusieurs dizaines de milliers d’euros et immobilisait un cluster de cartes graphiques pendant plusieurs jours. Aujourd’hui, la même adaptation peut tenir sur une seule carte professionnelle, pour un coût de calcul de quelques dizaines d’euros. Ce qui a changé entre les deux n’est pas la puissance des GPU : c’est la façon dont on entraîne.

Deux notions avant de choisir

Un paramètre est un nombre stocké dans le modèle. Un modèle « 70B » désigne 70 milliards de ces nombres. Quand on dit qu’on entraîne un modèle, on ajuste ces nombres pour qu’ils réduisent l’écart entre ce que le modèle produit et ce qu’on attend de lui.

Le gradient est le signal qui indique à chaque paramètre dans quel sens et de combien le déplacer pour réduire cet écart. Calculer un gradient est l’opération la plus coûteuse de l’entraînement : plus il y a de paramètres à ajuster, plus il y a de gradients à calculer et à stocker, et plus la facture en mémoire et en GPU grimpe.

Faut-il seulement entraîner le modèle ?

Avant de choisir une technique d’entraînement, il faut répondre à une question plus simple : est-ce qu’il faut entraîner quoi que ce soit ?

Si le besoin est que le modèle réponde à partir de vos documents, de votre base de connaissances ou de vos tickets, cite ses sources, et que ce contenu change souvent, la réponse la plus courante est le RAG (retrieval-augmented generation) : on indexe les documents sous forme de vecteurs, on récupère les passages pertinents au moment de la question, et on les fournit au modèle dans le prompt. Le modèle lui-même ne change pas.

Le RAG a trois avantages concrets. Aucun coût d’entraînement caché, puisqu’il n’y a pas d’entraînement. Les documents peuvent être mis à jour dans l’heure, sans réentraînement. Et la traçabilité est native : le modèle peut indiquer quel document et quel passage ont servi à sa réponse, ce qu’un modèle fine-tuné ne sait pas faire — l’information y est diluée parmi des milliards de paramètres, sans pointeur vers une source.

Le fine-tuning, à l’inverse, sert quand ce qu’il faut changer n’est pas l’accès à une information mais le comportement : un format de sortie imposé, un ton de marque, des règles de refus précises, ou un vocabulaire très spécialisé qu’un modèle généraliste maîtrise mal. Le RAG ne change pas la façon dont un modèle s’exprime ; le fine-tuning, si.

Trois niveaux d’entraînement, du plus complet au plus léger

Le fine-tuning complet

C’est la méthode historique, la plus simple à comprendre et la plus brutale. On reprend le modèle pré-entraîné et on poursuit l’entraînement sur son propre jeu de données : tous les paramètres bougent, et un gradient est calculé pour chacun d’eux à chaque exemple.

Le coût mémoire est le principal obstacle. Avec un optimiseur courant comme Adam, il faut conserver en VRAM non seulement les poids, mais aussi les gradients et l’état de l’optimiseur pour chaque paramètre — de l’ordre de plusieurs fois le poids du modèle en mémoire additionnelle. Pour un modèle de 70 milliards de paramètres, cela représente de l’ordre du téraoctet de VRAM au total, réparti sur plusieurs cartes à l’aide de techniques de partitionnement mémoire comme ZeRO ou FSDP plutôt que par simple duplication.

Le fine-tuning complet présente aussi un risque connu : l’oubli catastrophique. Si les 70 milliards de paramètres bougent trop, le modèle peut désapprendre des compétences générales qu’il possédait avant, sauf à équilibrer soigneusement le mélange d’exemples d’entraînement. Pour un run réel sur plusieurs milliers d’exemples, comptez de l’ordre de plusieurs milliers à quelques dizaines de milliers d’euros de calcul, sur plusieurs jours. C’est une méthode à réserver aux cas où l’adaptation doit être profonde et où le budget GPU est dédié.

LoRA

En 2021, une équipe de Microsoft Research publie une méthode qui change la donne : LoRA, pour Low-Rank Adaptation. L’idée consiste à geler l’intégralité des poids d’origine du modèle, puis à ajouter, à côté de certaines couches, deux petites matrices dont le produit s’additionne à la sortie de la couche gelée. On n’apprend pas une nouvelle version du modèle : on apprend une petite correction qu’on ajoute par-dessus.

Ces deux matrices sont minuscules comparées à une couche d’origine — de l’ordre de quelques centaines de milliers de paramètres contre plusieurs millions par couche. Sur un modèle de 70 milliards de paramètres, LoRA appliqué aux bonnes couches ramène la part réellement entraînée à environ 0,1 à 0,3 % du total.

Cela ne veut pas dire que la VRAM nécessaire chute dans les mêmes proportions : les poids gelés doivent tout de même être chargés en mémoire pour que le calcul puisse s’appuyer dessus. Pour un modèle de 70 milliards de paramètres stocké sur 16 bits, cela représente environ 140 gigaoctets, auxquels s’ajoutent les activations et l’état d’optimiseur des seules matrices LoRA — de l’ordre de 150 à 160 gigaoctets au total, soit deux cartes de la classe H100 plutôt que huit. Un autre bénéfice de LoRA est l’absence d’oubli catastrophique : le modèle d’origine reste intact, et il est possible de conserver plusieurs adaptateurs LoRA différents, un par cas d’usage, et de les activer selon le contexte.

QLoRA

En 2023, une équipe de l’université de Washington pousse le principe plus loin avec QLoRA. Le « Q » désigne la quantisation. Le coût restant de LoRA venait du fait que les poids gelés devaient rester en mémoire sur 16 bits. QLoRA les stocke à la place sur 4 bits — une compression qui fait perdre de la précision, largement invisible en pratique, un peu comme un format audio compressé.

Le papier original démontre qu’il devient possible d’affiner un modèle de 65 milliards de paramètres sur une seule carte de 48 gigaoctets, avec un niveau de performance proche de celui d’un entraînement classique sur 16 bits. Le modèle Guanaco qui en résulte atteint 99,3 % du niveau de ChatGPT sur le benchmark Vicuna, pour environ 24 heures d’entraînement sur une seule carte.

Sur un modèle de 70 milliards de paramètres, les poids quantifiés sur 4 bits représentent environ 35 à 40 gigaoctets, plus la marge nécessaire pour les activations et les adaptateurs LoRA — ce qui exige une carte professionnelle de 48 gigaoctets, pas une carte grand public de 24 gigaoctets. Sur une carte de 24 gigaoctets comme une RTX 4090, la fourchette réaliste en 4 bits se situe plutôt entre 13 et 34 milliards de paramètres — la carte, arrêtée de production fin 2024 et aujourd’hui en tension d’approvisionnement, reste néanmoins un point d’entrée pertinent pour cette taille de modèle. Pour un run de quelques dizaines d’heures sur une carte louée, comptez de l’ordre de quelques dizaines d’euros de calcul — l’ordre de grandeur que le papier original lui-même mentionne.

Ce qui décide vraiment combien ça coûte : la VRAM

Les trois techniques ci-dessus ne se distinguent pas d’abord par leur complexité d’implémentation, mais par la quantité de VRAM qu’elles exigent pour un même modèle de départ — et donc par le nombre et la classe de cartes nécessaires. C’est exactement la question de dimensionnement que nous traitons dans le cadre de notre offre infrastructure pour l’IA : combien de VRAM, quelle densité électrique par baie, et quel mode de virtualisation des accélérateurs selon la plateforme choisie.

Matrice de décision

Dans l’immense majorité des cas rencontrés en entreprise, la question se résout entre les deux premières lignes de ce tableau : RAG si le besoin porte sur l’accès à une information qui change, QLoRA si le besoin porte sur un comportement à apprendre avec peu d’exemples. Le fine-tuning complet reste l’exception plutôt que le point de départ.

Ce que cet article n’a pas traité

Cet article ne couvre pas le choix d’un framework précis pour mettre en œuvre ces techniques — Hugging Face PEFT et Axolotl sont deux pistes courantes, chacune avec ses propres compromis. Il ne couvre pas non plus les techniques de compression au-delà de 4 bits, ni le prompt engineering avancé, qui peut dans certains cas réduire encore le besoin de fine-tuning sans entraînement du tout. Enfin, la qualité du jeu de données d’entraînement — souvent plus déterminante que le choix de la technique elle-même — mériterait un article à part entière.