Module 3 — Affinage complet et son coût réel

Avant d'expliquer pourquoi les techniques économes en paramètres ont pris le dessus, il faut comprendre ce que l'affinage complet demande. La plupart des débutants sous-estiment ce coût d'un facteur cinq à dix, ce qui donne des devis irréalistes et des essais qui ne rentrent pas en mémoire. Ce module fait le calcul en entier pour notre modèle de 7 milliards de paramètres.

Ce qu'est un affinage complet

Un affinage complet reprend tous les poids du modèle et les met à jour par descente de gradient sur votre jeu, exactement comme le pré-entraînement l'a fait à plus grande échelle. Aucune couche n'est gelée, aucun adaptateur n'est ajouté : chaque poids peut bouger à chaque pas. Cette liberté est totale et c'est d'ailleurs son intérêt — pour une tâche qui exige une réorganisation profonde des représentations, elle reste supérieure. Elle a aussi trois coûts qui se cumulent : mémoire, calcul, et oubli catastrophique.

Calcul de la mémoire, pas à pas

La règle à retenir concerne quatre composantes qui vivent sur le GPU pendant l'entraînement : les poids, les gradients, les états de l'optimiseur et les activations intermédiaires. Prenons notre modèle de 7 milliards de paramètres, entraîné en précision mixte bfloat16 avec Adam — la configuration standard.

Les poids en bfloat16 occupent 2 octets par paramètre. Pour 7 milliards :

$$7 \times 10^9 \times 2 = 14 \text{ Go}$$

Les gradients ont la même taille que les poids, donc encore 14 Go. À chaque passe arrière, un gradient est calculé pour chaque paramètre.

Les états d'Adam sont deux moments — moment 1 (moyenne) et moment 2 (variance) — stockés en float32 pour la stabilité numérique. Chaque moment fait 4 octets par paramètre, donc deux moments font 8 octets. Certaines implémentations conservent aussi une copie des poids en float32 pour la mise à jour, ce qui ajoute 4 octets. Sans cette copie :

$$7 \times 10^9 \times 8 = 56 \text{ Go}$$

Avec la copie float32 des poids (fréquente) : $7 \times 10^9 \times 12 = 84 \text{ Go}$.

Les activations intermédiaires, retenues pour la passe arrière, dépendent de la longueur de séquence, de la taille de lot et de l'architecture. Pour 7 milliards de paramètres, une séquence de 4 096 jetons et un lot de 4, comptez 10 à 20 Go supplémentaires selon que la recomputation d'activations (gradient checkpointing) est active.

Total minimal, sans recomputation, sans copie float32 des poids :

$$14 + 14 + 56 + 15 \approx 100 \text{ Go}$$

Cent gigaoctets pour un modèle de 7 milliards. On atteint ici l'ordre de grandeur d'un A100 80GB ou d'un H100 80GB, et il faut souvent en assembler deux avec parallélisme de données pour respirer. C'est très loin des 24 Go d'un RTX 4090 ou d'un L4 accessibles sur portable — le module 6 montrera comment QLoRA change tout cela.

Le calcul, résumé en tableau

Composante	Formule pour N paramètres	Pour 7 milliards
Poids (bfloat16)	$2N$ octets	14 Go
Gradients (bfloat16)	$2N$ octets	14 Go
Moments 1 et 2 (float32)	$8N$ octets	56 Go
Copie float32 des poids	$4N$ octets	28 Go
Activations (lot 4, séq. 4 096)	variable	10 à 20 Go

Deux règles pratiques en découlent. D'abord, l'optimiseur pèse plus que le modèle : Adam avec ses deux moments fait à lui seul quatre fois la taille des poids. Les optimiseurs SGD sans moment économiseraient cette place, mais convergent mal sur les grands modèles. Ensuite, la mémoire d'activation est le seul poste qu'on peut faire baisser sans changer d'algorithme : en réduisant le lot, en raccourcissant la séquence, ou en activant la recomputation.

L'oubli catastrophique

Le coût matériel est une chose ; l'oubli catastrophique est un piège plus insidieux et propre à l'affinage complet. Le mécanisme est simple : en mettant à jour tous les poids sur votre jeu, le modèle « oublie » une partie de ce qu'il savait faire avant. Un modèle de 7 milliards affiné exclusivement sur des comptes rendus de réunion peut se mettre à rédiger des poèmes en prose de réunion ou à répondre à des questions générales dans le style « ## Décisions — ... ». La distribution de sortie a été tirée trop loin de son pré-entraînement.

Trois amortisseurs existent. Le premier est de mélanger au jeu d'affinage un petit volume d'exemples génériques — 10 à 20 % de conversations variées — pour rappeler au modèle qu'il n'est pas devenu un spécialiste unique. Le deuxième est de régulariser vers les poids initiaux par une pénalité de type EWC (Elastic Weight Consolidation). Le troisième — le plus efficace en pratique — est de ne pas affiner en complet : les adaptateurs PEFT, dont LoRA, ne modifient pas les poids pré-entraînés et n'oublient donc rien mécaniquement.

Quand l'affinage complet reste-t-il justifié ?

Trois situations le rendent préférable malgré son coût.

D'abord, quand la tâche demande une réorganisation profonde des représentations : passer d'un modèle anglais à un modèle exclusivement français, ou d'un modèle généraliste à un modèle strictement médical. LoRA touche trop peu de paramètres pour opérer ce genre de bascule.

Ensuite, quand le volume de données est très important — plusieurs centaines de milliers d'exemples de qualité — et que la tâche est très spécifique. À ce volume, la capacité limitée d'un adaptateur devient un plafond.

Enfin, quand vous contrôlez le calcul et que le budget suit : les grands laboratoires publient régulièrement des versions instruites de modèles ouverts par affinage complet, parce que la qualité maximale reste leur objectif et que quelques milliers d'heures de GPU sont dans leur enveloppe.

Le devis honnête

Pour un projet en entreprise, le devis d'un affinage complet d'un modèle de 7 milliards de paramètres sur cent mille exemples oscille entre 5 000 et 15 000 dollars sur A100, hors coût d'ingénierie et hors itérations d'échec. Le module 5 montrera qu'un LoRA équivalent coûte quelques dizaines de dollars. La différence, presque toujours, ne se justifie pas.

En résumé

• L'affinage complet met à jour tous les poids ; les gradients et les états d'optimiseur pèsent plus que le modèle lui-même.
• Un modèle de 7 milliards en bfloat16 avec Adam demande environ 100 Go de mémoire GPU — deux A100 80GB en parallélisme de données en pratique.
• L'oubli catastrophique est mécanique dès qu'on modifie tous les poids ; il se limite par mélange, régularisation, ou en évitant l'affinage complet.
• L'affinage complet reste justifié pour une réorganisation profonde, un très grand volume, ou par les laboratoires qui publient les modèles de base.

Module suivant : la famille des méthodes économes en paramètres qui rendent l'affinage praticable pour tous.