Affiner un LLM : 98% sur un 7B, LoRA face au mur 1,4 To

Rendre un LLM fiable sur des formulaires complexes coûte cher en contexte et en corrections humaines. Un projet rapporte qu’un Mistral 7B affiné avec QLoRA atteint environ 98% de précision sur des rapports médicaux, contre 35% avec prompts et RAG, tout en supprimant des coûts d’API estimés autrement à 320 000 $. Mais l’affinage complet d’un modèle géant réclame jusqu’à 1,4 To de VRAM et peut altérer des compétences acquises, d’où l’intérêt pratique de LoRA/QLoRA.

Le plein affinage exige jusqu’à 1,4 To de VRAM et peut dégrader le modèle

Un affinage complet d’un grand modèle s’avère prohibitif en pratique. Pour un modèle de 70 milliards de paramètres en FP16, il faut stocker en VRAM les poids ainsi que deux moments supplémentaires par paramètre liés à l’optimiseur Adam. Les besoins grimpent alors entre 1,2 et 1,4 To de VRAM, un seuil largement inaccessible pour la plupart des équipes. Au-delà du coût matériel, l’affinage complet peut aussi détruire des connaissances déjà présentes, en raison de la mise à jour de l’ensemble des paramètres et du risque d’écraser des capacités générales de langage et de raisonnement. C’est précisément ce double écueil – ressources et stabilité – qui motive l’usage de LoRA, une approche décrite par Hu et al. pour spécialiser efficacement un modèle fondamental sur des tâches aval.

Sur un rapport synoptique de cancer du sein, un 7B affiné atteint environ 98%

Une équipe rapporte avoir affiné un modèle de 7 milliards de paramètres pour remplir des rapports synoptiques de cancer du sein, une tâche exigeant un ordre strict des champs, une logique très ramifiée et l’identification d’un type histologique parmi 40 sous-types sans hallucination, sous peine d’invalider toute la sortie. Avec des prompts système agressifs et un peu de RAG sur Claude Opus 4.6, la précision plafonnait à environ 35%, au prix d’un contexte de l’ordre de 30 000 tokens et de sorties comportant omissions, sous-sections superflues et hallucinations nécessitant une relecture intégrale. Après affinage d’un Mistral 7B via QLoRA, l’équipe indique une précision d’environ 98%, soit 63 points de pourcentage de mieux, tout en supprimant les coûts d’API pour cette tâche. Les dépenses d’exploitation à l’échelle avec un modèle de pointe avaient été évaluées à environ 320 000 $. L’équipe précise que ce résultat « gratuit » n’inclut pas le prix de l’affinage, l’exécution locale à grande échelle ni la mesure de l’énergie par appel.

Quand privilégier l’affinage: formats rigides, coûts de contexte et règles qui se chevauchent

L’affinage s’impose lorsque le format de sortie tolère peu d’erreurs: modèles d’entreprise ancrés avec branches conditionnelles multiples, documents juridiques propres à chaque juridiction non vus en pré-entraînement, ou formulaires médicaux redondants mais à remplir de manière parfaitement correcte. À grande échelle, des prompts système de plusieurs milliers ou dizaines de milliers de tokens par appel alourdissent coûts et latence, alors qu’un modèle affiné peut intégrer ces schémas et se passer de ce ballast. Les prompts système montrent aussi leurs limites quand les règles se recoupent et que l’arbre décisionnel explose, comme l’illustre un cas où il devenait déraisonnable de tout encoder en tableau. La qualité du contexte déclinant avec la longueur, un prompt cumulant 50 règles risque d’en omettre et d’invalider la sortie. Enfin, pour imposer une voix de marque dans l’assistance client, l’affinage fonctionne souvent mieux que des instructions répétées: maintenir un ton particulier requiert un prompt dédié à chaque échange, et un gabarit de 2 000 tokens fait vite grimper la facture.

Ce que le RAG apporte mieux et l’option d’un mix

Une règle empirique chez les praticiens veut que le RAG serve d’abord à augmenter les connaissances du modèle quand la base change souvent, quand l’accès à des documents et politiques évolutifs est crucial, ou quand on ne dispose que de quelques centaines d’exemples d’entraînement. Le RAG peut aussi suffire si un petit prompt système modifie déjà le comportement de manière fiable. De son côté, l’affinage agit principalement sur le comportement de sortie, tout en pouvant, dans certains cas, injecter de nouvelles connaissances. Les frontières ne sont pas nettes et relèvent du jugement. Dans la pratique, les solutions efficaces combinent les deux: l’équipe qui a augmenté son 7B n’a pas supprimé totalement prompts système ni RAG, mais elle a fortement réduit sa dépendance à ces leviers.

Objectif SFT et mécanique LoRA: rang faible, matrices A/B et gamma

L’affinage prolonge l’objectif de pré-entraînement, qui consiste généralement à prédire le prochain token. En supervision (SFT), le même objectif causal s’applique à des paires prompt–complétion, beaucoup de configurations ne calculant la perte que sur les tokens de réponse. Mathématiquement, il s’agit d’entropie croisée sur les tokens; la différence tient surtout au jeu de données, massif et brut en pré-entraînement, ciblé en affinage. Il est d’ailleurs possible d’ajouter des connaissances par affinage sans recourir à des paires prompt–complétion, en introduisant de nouvelles données au même objectif. Côté mécanisme, LoRA gèle les poids d’origine et ajoute au passage avant une mise à jour de rang faible: au lieu de mettre à jour une matrice complète (par exemple 4096×4096 dans une projection de transformateur), on apprend des matrices A et B de petite dimension qui composent la correction. Le passage avant s’écrit sous la forme h = W0 x + (alpha/r) B A x. Dans les bibliothèques comme Hugging Face ou PEFT, le terme alpha/r est remplacé par un hyperparamètre gamma équivalent. Comprendre ces éléments – notamment le choix du rang (8 plutôt que 32, par exemple) et l’effet d’alpha – évite l’« affutage à l’aveugle » et rend le débogage plus méthodique.