Fine-tuning efficace

Les chapitres précédents ont montré comment utiliser les LLM via des API, structurer des prompts et orchestrer des agents. Mais que faire lorsque le modèle ne répond pas correctement à une tâche spécifique, malgrè un prompt optimisé ? La réponse classique est le fine-tuning : reprendre l’entrainement du modèle sur un jeu de données spécialisé. Le problème est que le fine-tuning complet d’un modèle de plusieurs milliards de paramètres exige une infrastructure coûteuse — des dizaines de GPU, des centaines de gigaoctets de mémoire, des jours de calcul.

Le fine-tuning efficace (parameter-efficient fine-tuning, PEFT) résout ce problème en ne modifiant qu’une fraction infime des paramètres du modèle. L’idée centrale, formalisée par la méthode LoRA (Hu et al., 2021), est que les mises à jour de poids nécessaires pour adapter un LLM à une tâche donnée vivent dans un sous-espace de faible dimension. Au lieu de modifier les \(d \times d\) paramètres d’une matrice de poids, on apprend deux petites matrices de rang \(r \ll d\) dont le produit approxime la mise à jour. Le résultat : 99 % des paramètres restent gelés, la mémoire requise chute de manière spectaculaire, et l’entrainement peut se faire sur un seul GPU grand public.

Ce chapitre présente les méthodes PEFT de manière à la fois théorique et pratique. Nous formaliserons LoRA et ses variantes, comparerons les différentes approches de fine-tuning efficace, puis réaliserons un fine-tuning complet de GPT-2 (124M parametres) avec la bibliothèque peft de Hugging Face — le tout exécutable sur une machine à 8 Go de RAM.

Pourquoi le fine-tuning efficace ?

Le fine-tuning classique (full fine-tuning) consiste à reprendre l’entrainement de tous les paramètres d’un modèle pré-entrainé sur un jeu de données spécifique à la tâche cible. Pour un modèle de \(N\) paramètres, cela implique de stocker en mémoire les \(N\) poids du modèle, les \(N\) gradients correspondants, et l’état de l’optimiseur (pour Adam, \(2N\) valeurs supplémentaires : les moyennes mobiles du premier et du second ordre). Le coût mémoire total est donc d’environ \(16N\) octets en précision mixte (FP16 pour les poids et gradients, FP32 pour l’état de l’optimiseur).

Définition 107 (Fine-tuning complet)

Le fine-tuning complet (full fine-tuning) d’un modèle pré-entrainé de paramètres \(\theta \in \mathbb{R}^N\) consiste à minimiser une fonction de perte \(\mathcal{L}\) sur un jeu de données \(\mathcal{D}_{\text{task}}\) en mettant à jour tous les paramètres :

\[\theta^* = \arg\min_{\theta} \sum_{(x, y) \in \mathcal{D}_{\text{task}}} \mathcal{L}(f_\theta(x), y)\]

Le coût mémoire d’entrainement est d’environ \(16N\) octets (poids FP16 + gradients FP16 + etats d’optimiseur FP32), auxquels s’ajoutent les activations intermédiaires. Pour un modèle de 7 milliards de paramètres, cela représente environ 112 Go de mémoire GPU — bien au-delà de la capacité d’un GPU grand public.

Pour un modèle de 7B parametres, le full fine-tuning nécessite environ 112 Go de VRAM, soit au minimum deux GPU A100 de 80 Go. Pour un modèle de 70B, il faut un cluster entier. Cette barrière économique a motivé le développement des méthodes PEFT.

Définition 108 (Fine-tuning efficace en paramètres (PEFT))

Le fine-tuning efficace en paramètres (Parameter-Efficient Fine-Tuning, PEFT) désigne une famille de méthodes qui adaptent un modèle pré-entrainé à une tache spécifique en n’entrainant qu’un petit nombre de paramètres \(\phi\), avec \(|\phi| \ll N\). Le modèle pré-entrainé \(\theta_0\) reste gelé (frozen) et seuls les paramètres \(\phi\) sont mis à jour :

\[\phi^* = \arg\min_{\phi} \sum_{(x, y) \in \mathcal{D}_{\text{task}}} \mathcal{L}(f_{\theta_0, \phi}(x), y)\]

Le ratio \(|\phi| / N\) est typiquement de l’ordre de 0,1 % à 1 %, ce qui réduit la mémoire nécessaire d’un à deux ordres de grandeur par rapport au fine-tuning complet.

Remarque 102 (Full fine-tuning vs PEFT : compromis)

Le fine-tuning complet donne en théorie les meilleurs résultats, puisque l’espace de recherche est maximal. En pratique, cependant, les methodes PEFT atteignent souvent des performances comparables, voire supérieures, au full fine-tuning. Ce paradoxe apparent s’explique par deux facteurs : (1) le fine-tuning complet sur un petit jeu de données risque le surapprentissage (overfitting), tandis que les méthodes PEFT agissent comme un régularisateur implicite en restreignant l’espace des mises à jour ; (2) les mises à jour nécessaires pour adapter un LLM pré-entrainé à une tâche spécifique sont effectivement de faible rang — elles n’exploitent qu’un petit sous-espace de l’espace des paramètres.

Show code cell source

Hide code cell source

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import seaborn as sns
import torch
import torch.nn as nn
import torch.optim as optim

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)
torch.manual_seed(42)
np.random.seed(42)

Show code cell source

Hide code cell source

# Comparaison mémoire : full fine-tuning vs PEFT
model_sizes = ["1.3B\n(ex: OPT-1.3B)", "7B\n(ex: LLaMA-2-7B)", "13B\n(ex: LLaMA-2-13B)", "70B\n(ex: LLaMA-2-70B)"]
params_b = np.array([1.3, 7, 13, 70])

# Full FT : ~16 bytes par paramètre (FP16 poids + FP16 grad + FP32 optimizer states)
full_ft_gb = params_b * 16

# LoRA : poids gelés FP16 (2 bytes) + trainable params ~0.5% * 16 bytes + activations
lora_gb = params_b * 2 + params_b * 0.005 * 16

# QLoRA : poids gelés 4-bit (0.5 bytes) + trainable params ~0.5% * 16 bytes
qlora_gb = params_b * 0.5 + params_b * 0.005 * 16

x = np.arange(len(model_sizes))
width = 0.25

fig, ax = plt.subplots(figsize=(12, 5))
bars1 = ax.bar(x - width, full_ft_gb, width, label="Full fine-tuning", color="#C44E52")
bars2 = ax.bar(x, lora_gb, width, label="LoRA (FP16)", color="#4C72B0")
bars3 = ax.bar(x + width, qlora_gb, width, label="QLoRA (4-bit)", color="#55A868")

ax.set_xlabel("Taille du modèle")
ax.set_ylabel("Mémoire GPU estimée (Go)")
ax.set_title("Mémoire requise pour l'entrainement selon la méthode")
ax.set_xticks(x)
ax.set_xticklabels(model_sizes)
ax.legend()
ax.set_yscale("log")

for bars in [bars1, bars2, bars3]:
    for bar in bars:
        height = bar.get_height()
        ax.annotate(f'{height:.0f}',
                    xy=(bar.get_x() + bar.get_width() / 2, height),
                    xytext=(0, 3), textcoords="offset points",
                    ha='center', va='bottom', fontsize=8)

plt.show()

LoRA : Low-Rank Adaptation

LoRA (Low-Rank Adaptation), proposé par Hu et al. (2021), est la méthode PEFT la plus influente et la plus utilisée. Son principe repose sur une observation empirique fondamentale : les mises à jour de poids nécessaires pour adapter un LLM pré-entrainé ont un rang intrinsèque faible. Autrement dit, la matrice \(\Delta W\) qui représente la différence entre les poids adaptés et les poids originaux peut être bien approximée par un produit de deux matrices de faible rang.

Définition 109 (LoRA (Low-Rank Adaptation))

Soit \(W_0 \in \mathbb{R}^{d_{\text{out}} \times d_{\text{in}}}\) une matrice de poids pré-entrainée (par exemple, une projection \(W_Q\), \(W_K\), \(W_V\) ou \(W_O\) dans un bloc d’attention). LoRA remplace la mise à jour de \(W_0\) par une décomposition de faible rang :

\[W = W_0 + \Delta W = W_0 + B A\]

où \(B \in \mathbb{R}^{d_{\text{out}} \times r}\) et \(A \in \mathbb{R}^{r \times d_{\text{in}}}\), avec \(r \ll \min(d_{\text{out}}, d_{\text{in}})\). Les poids originaux \(W_0\) sont gelés (pas de gradient). Seuls \(B\) et \(A\) sont entrainés. L’initialisation est \(A \sim \mathcal{N}(0, \sigma^2)\) et \(B = 0\), de sorte que \(\Delta W = 0\) au debut de l’entrainement. Le passage avant devient :

\[h = W_0 x + \frac{\alpha}{r} B A x\]

où \(\alpha\) est un facteur d’échelle (typiquement \(\alpha = r\) ou \(\alpha = 2r\)).

Propriété 24 (Nombre de paramètres entrainables de LoRA)

Pour une matrice de poids \(W_0 \in \mathbb{R}^{d_{\text{out}} \times d_{\text{in}}}\), LoRA introduit \(r \times (d_{\text{out}} + d_{\text{in}})\) paramètres entrainables. Pour un Transformer avec \(L\) couches et LoRA appliqué aux projections \(W_Q\) et \(W_V\) de dimension \(d \times d\), le nombre total de paramètres entrainables est :

\[|\phi|_{\text{LoRA}} = 2 \times L \times 2 \times d \times r = 4 L d r\]

Pour GPT-2 small (\(L = 12\), \(d = 768\), \(r = 8\)), cela donne \(|\phi| = 4 \times 12 \times 768 \times 8 = 294\,912\) paramètres, soit 0,24 % des 124 millions de paramètres totaux.

Remarque 103 (Le rang r : un hyperparamètre central)

Le rang \(r\) est le principal hyperparamètre de LoRA. Un rang trop faible limite la capacité d’adaptation du modèle ; un rang trop élevé augmente le nombre de paramètres sans gain proportionnel et risque le surapprentissage. En pratique, \(r \in \{4, 8, 16, 32, 64\}\) couvre la plupart des scénarios. Hu et al. (2021) ont montré que pour de nombreuses tâches, \(r = 4\) ou \(r = 8\) suffisent, confirmant que les mises à jour de poids vivent effectivement dans un sous-espace de très faible dimension.

Propriété 25 (Compromis rang-performance)

La relation entre le rang \(r\) et la performance suit généralement une courbe à rendements décroissants :

• Pour \(r = 1\) a \(r = 4\) : gain rapide de performance.

• Pour \(r = 4\) a \(r = 16\) : gain marginal décroissant.

• Pour \(r > 16\) : plateau, voire dégradation par surapprentissage sur de petits jeux de données.

Ce comportement est cohérent avec l’hypothèse du faible rang intrinsèque : les premières composantes principales de \(\Delta W\) capturent l’essentiel de l’adaptation, et les composantes supplémentaires n’ajoutent que du bruit.

Remarque 104 (Le facteur d’échelle alpha)

Le facteur \(\alpha\) dans LoRA contrôle l’amplitude de la mise à jour \(\Delta W\). Le ratio \(\alpha / r\) agit comme un taux d’apprentissage effectif pour les paramètres LoRA. En pratique, on fixe souvent \(\alpha = r\) (ratio de 1) ou \(\alpha = 2r\) (ratio de 2). Lorsqu’on augmente le rang \(r\), il est courant de garder \(\alpha\) constant (par exemple \(\alpha = 16\)), ce qui diminue automatiquement l’amplitude relative de chaque composante. Cette convention simplifie le réglage des hyperparamètres : le taux d’apprentissage reste stable indépendamment du rang choisi.

Implémentons LoRA from scratch pour comprendre le mécanisme en détail.

Show code cell source

Hide code cell source

class LoRALinear(nn.Module):
    """Couche linéaire avec adaptation LoRA.

    La couche originale W_0 est gelée. Seules les matrices A et B
    sont entrainables. La sortie est : h = W_0 @ x + (alpha/r) * B @ A @ x
    """

    def __init__(self, in_features, out_features, rank=4, alpha=1.0):
        super().__init__()
        # Couche linéaire originale (gelée)
        self.linear = nn.Linear(in_features, out_features, bias=False)
        self.linear.weight.requires_grad = False

        # Matrices LoRA (entrainables)
        self.A = nn.Parameter(torch.randn(rank, in_features) * 0.01)
        self.B = nn.Parameter(torch.zeros(out_features, rank))

        self.rank = rank
        self.alpha = alpha
        self.scaling = alpha / rank

    def forward(self, x):
        # Passage avant : W_0 @ x + scaling * B @ A @ x
        base_output = self.linear(x)
        lora_output = (x @ self.A.T @ self.B.T) * self.scaling
        return base_output + lora_output

# Démonstration
d_in, d_out, r = 768, 768, 8
layer = LoRALinear(d_in, d_out, rank=r, alpha=8.0)

# Compter les paramètres
total_params = sum(p.numel() for p in layer.parameters())
trainable_params = sum(p.numel() for p in layer.parameters() if p.requires_grad)
frozen_params = total_params - trainable_params

print(f"Dimension : {d_in} x {d_out}")
print(f"Rang LoRA : r = {r}")
print(f"Paramètres totaux    : {total_params:>10,}")
print(f"Paramètres gelés     : {frozen_params:>10,} ({frozen_params/total_params:.2%})")
print(f"Paramètres entrainés : {trainable_params:>10,} ({trainable_params/total_params:.2%})")
print(f"\nRatio de compression : {total_params / trainable_params:.1f}x")

Dimension : 768 x 768
Rang LoRA : r = 8
Paramètres totaux    :    602,112
Paramètres gelés     :    589,824 (97.96%)
Paramètres entrainés :     12,288 (2.04%)

Ratio de compression : 49.0x

Show code cell source

Hide code cell source

# Vérification : au debut de l'entrainement, Delta W = 0 (B est initialisé à zero)
x = torch.randn(4, d_in)  # batch de 4 exemples

# Sortie avec LoRA (Delta W = 0 car B = 0)
with torch.no_grad():
    out_lora = layer(x)
    out_base = layer.linear(x)

print("Différence max entre sortie base et sortie LoRA (début) :",
      (out_lora - out_base).abs().max().item())
print("=> LoRA n'altère pas le modèle au début de l'entrainement.")

Différence max entre sortie base et sortie LoRA (début) : 0.0
=> LoRA n'altère pas le modèle au début de l'entrainement.

Exemple 75 (Calcul du nombre de paramètres LoRA)

Considérons un modèle de type LLaMA-7B avec \(L = 32\) couches, \(d_{\text{model}} = 4096\), et LoRA applique aux matrices \(W_Q\) et \(W_V\) avec un rang \(r = 16\). Le nombre de paramètres entrainables est :

\[|\phi| = 2 \times 32 \times 2 \times 4096 \times 16 = 8\,388\,608 \approx 8{,}4\text{M}\]

Le modele complet a environ 6,7 milliards de paramètres. Le ratio est donc :

\[\frac{|\phi|}{N} = \frac{8{,}4 \times 10^6}{6{,}7 \times 10^9} \approx 0{,}13\%\]

On entraine donc \(800\times\) moins de paramètres qu’avec le fine-tuning complet. En mémoire, cela passe d’environ 112 Go (full FT) a environ 16 Go (poids FP16 gelés + LoRA entrainable), ce qui tient sur un seul GPU A100-40G ou meme un GPU grand public avec QLoRA.

Show code cell source

Hide code cell source

# Diagramme de l'architecture LoRA
fig, ax = plt.subplots(figsize=(10, 6))
ax.set_xlim(0, 10)
ax.set_ylim(0, 8)
ax.set_aspect("equal")
ax.axis("off")

# Entrée x
ax.annotate("", xy=(2, 3.5), xytext=(2, 1.5),
            arrowprops=dict(arrowstyle="->", lw=2, color="#333333"))
ax.text(2, 0.9, "$x$", fontsize=16, ha="center", fontweight="bold")

# Branche principale : W_0 (gelée)
rect_w0 = plt.Rectangle((1, 3.5), 2, 1.2, facecolor="#AECDE0", edgecolor="#4C72B0",
                          linewidth=2, zorder=3)
ax.add_patch(rect_w0)
ax.text(2, 4.1, "$W_0$\n(gele)", fontsize=11, ha="center", va="center",
        fontweight="bold", color="#2C5F7C")

ax.annotate("", xy=(2, 5.8), xytext=(2, 4.7),
            arrowprops=dict(arrowstyle="->", lw=2, color="#333333"))

# Branche LoRA : A puis B
# Flèche de x vers A
ax.annotate("", xy=(5.5, 2.2), xytext=(2.3, 1.5),
            arrowprops=dict(arrowstyle="->", lw=2, color="#C44E52"))

# Matrice A
rect_a = plt.Rectangle((4.8, 2.2), 1.8, 0.9, facecolor="#F5C6C6", edgecolor="#C44E52",
                         linewidth=2, zorder=3)
ax.add_patch(rect_a)
ax.text(5.7, 2.65, "$A$\n$r \\times d$", fontsize=10, ha="center", va="center",
        fontweight="bold", color="#8B2020")

# Fleche A vers B
ax.annotate("", xy=(5.7, 4.0), xytext=(5.7, 3.1),
            arrowprops=dict(arrowstyle="->", lw=2, color="#C44E52"))

# Matrice B
rect_b = plt.Rectangle((4.8, 4.0), 1.8, 0.9, facecolor="#F5C6C6", edgecolor="#C44E52",
                         linewidth=2, zorder=3)
ax.add_patch(rect_b)
ax.text(5.7, 4.45, "$B$\n$d \\times r$", fontsize=10, ha="center", va="center",
        fontweight="bold", color="#8B2020")

# Flèche B vers addition
ax.annotate("", xy=(3.2, 5.8), xytext=(5.2, 4.9),
            arrowprops=dict(arrowstyle="->", lw=2, color="#C44E52"))

# Point d'addition
circle = plt.Circle((2.5, 6.0), 0.3, facecolor="#FFFACD", edgecolor="#333333",
                      linewidth=2, zorder=4)
ax.add_patch(circle)
ax.text(2.5, 6.0, "$+$", fontsize=16, ha="center", va="center", fontweight="bold")

# Sortie h
ax.annotate("", xy=(2.5, 7.2), xytext=(2.5, 6.3),
            arrowprops=dict(arrowstyle="->", lw=2, color="#333333"))
ax.text(2.5, 7.5, "$h = W_0 x + \\frac{\\alpha}{r} B A x$", fontsize=13,
        ha="center", fontweight="bold")

# Annotations
ax.text(7.2, 3.5, "Paramètres\nentrainables\n($2dr$ params)", fontsize=10,
        ha="center", color="#C44E52", fontweight="bold",
        bbox=dict(boxstyle="round,pad=0.3", facecolor="#FFF0F0", edgecolor="#C44E52"))
ax.text(-0.3, 4.1, "Paramètres\ngelés\n($d^2$ params)", fontsize=10,
        ha="center", color="#2C5F7C", fontweight="bold",
        bbox=dict(boxstyle="round,pad=0.3", facecolor="#EBF5FB", edgecolor="#4C72B0"))

ax.set_title("Architecture LoRA : décomposition de faible rang", fontsize=14, pad=15)
plt.show()

Remarque 105 (Economies de mémoire)

L’économie de mémoire de LoRA ne vient pas uniquement du nombre réduit de paramètres entrainables. Puisque les poids originaux \(W_0\) sont gelés, l’optimiseur n’a pas besoin de stocker leurs états (moyennes mobiles pour Adam). Concrètement, pour une couche de dimension \(d \times d\) :

• Full fine-tuning : \(d^2\) poids (FP16) + \(d^2\) gradients (FP16) + \(2 d^2\) états Adam (FP32) = \(16 d^2\) octets.

• LoRA (\(r \ll d\)) : \(d^2\) poids gelés (FP16, pas de gradient ni d’état) + \(2dr\) poids LoRA (FP16) + \(2dr\) gradients (FP16) + \(4dr\) états Adam (FP32) = \(2d^2 + 16dr\) octets.

Pour \(d = 4096\) et \(r = 16\), le ratio est \(\frac{2d^2 + 16dr}{16d^2} = \frac{2 + 16r/d}{16} \approx 0{,}13\), soit une réduction de 87 % de la mémoire par couche.

QLoRA : LoRA quantifié

Remarque 106 (Fusion des poids LoRA à l’inférence)

Un avantage majeur de LoRA est la possibilité de fusionner les matrices entrainables dans les poids originaux après l’entrainement : \(W_{\text{merged}} = W_0 + \frac{\alpha}{r} BA\). Le modèle résultant a exactement la même architecture que le modèle original, sans aucune couche supplémentaire. L’inférence est donc aussi rapide qu’avec le modèle non adapté. De plus, on peut maintenir plusieurs ensembles de poids LoRA (pour différentes tâches ou domaines) et les charger à la demande, sans dupliquer les poids du modèle de base.

QLoRA (Quantized LoRA), proposé par Dettmers et al. (2023), pousse l’économie de mémoire encore plus loin en combinant LoRA avec la quantification du modèle de base. L’idée est de stocker les poids gelés \(W_0\) en précision 4 bits au lieu de 16 bits, tout en effectuant les calculs LoRA en précision normale.

Définition 110 (Quantification)

La quantification (quantization) d’un modèle neuronal consiste à représenter ses poids (et éventuellement ses activations) avec un nombre réduit de bits. Un poids stocké en FP16 (16 bits) occupe 2 octets ; en INT8, 1 octet ; en 4 bits (NF4 ou INT4), 0,5 octet. La quantification introduit une erreur d’approximation, mais les techniques modernes (quantification par blocs, calibration sur un petit echantillon) permettent de maintenir cette erreur à un niveau négligeable.

Définition 111 (QLoRA)

QLoRA (Dettmers et al., 2023) combine trois innovations pour permettre le fine-tuning de modèles de plusieurs dizaines de milliards de paramètres sur un seul GPU grand public :

1. NormalFloat4 (NF4) : un format de quantification 4 bits dont les niveaux de quantification sont optimaux pour des poids suivant une distribution normale. Les 16 niveaux de NF4 sont espaces de manière à minimiser l’erreur de quantification attendue sous \(\mathcal{N}(0, \sigma^2)\).

2. Double quantification : les constantes de quantification (une par bloc de 64 poids) sont elles-mêmes quantifiées en FP8, ce qui réduit leur empreinte mémoire de 0,5 bit par paramètre a 0,127 bit par paramètre.

3. Optimiseurs pagés : lorsque la mémoire GPU est insuffisante, les états de l’optimiseur sont automatiquement pagés (swapped) vers la memoire CPU via le mécanisme de mémoire virtuelle unifiée de NVIDIA (CUDA unified memory).

Le passage avant calcule \(h = \text{dequant}(W_0^{\text{NF4}}) \cdot x + \frac{\alpha}{r} B A x\), où la déquantification est effectuée à la volée en BFloat16.

Propriété 26 (Empreinte mémoire de QLoRA)

Pour un modèle de \(N\) paramètres avec QLoRA (NF4 + double quantification), l’empreinte mémoire totale est :

\[M_{\text{QLoRA}} \approx 0{,}5 N + 0{,}127 N / 64 + 16 \times |\phi| \text{ octets}\]

où le premier terme correspond aux poids NF4 (4 bits par paramètre), le second aux constantes de quantification doublement quantifiées, et le troisième aux paramètres LoRA entrainables avec leurs gradients et états d’optimiseur. Pour un modèle de 65B avec \(|\phi| \approx 16\)M, cela donne environ \(33 + 0{,}02 + 0{,}26 \approx 33{,}3\) Go — compatible avec un seul GPU de 48 Go.

Remarque 107 (Catastrophic forgetting et PEFT)

Le catastrophic forgetting (oubli catastrophique) est un phénomène où le fine-tuning fait perdre au modèle les capacités acquises lors du pré-entrainement. Les méthodes PEFT atténuent naturellement ce problème : puisque les poids originaux \(W_0\) restent inchangés, le modèle conserve intégralement ses connaissances pré-entrainées. L’adaptation se fait par addition (\(W_0 + BA\)) plutôt que par remplacement, ce qui préserve la structure apprise. Cette propriéte est particulièrement précieuse lorsqu’on fine-tune un modèle généraliste pour une tâche de niche sans vouloir dégrader ses performances générales.

Show code cell source

Hide code cell source

# Comparaison détaillée de la mémoire : Full FT vs LoRA vs QLoRA
# Pour un modèle de 7B paramètres
N = 7e9

categories = [
    "Poids du modèle",
    "Gradients",
    "Etats optimiseur",
    "Paramètres LoRA\n+ gradients + optimizer",
]

# Full FT (tout en FP16, optimizer FP32)
full_ft = [
    N * 2 / 1e9,       # poids FP16
    N * 2 / 1e9,       # gradients FP16
    N * 4 * 2 / 1e9,   # 2 etats Adam FP32
    0,                  # pas de LoRA
]

# LoRA FP16 (poids geles FP16, LoRA 0.5% trainable)
lora_trainable = N * 0.005
lora_fp16 = [
    N * 2 / 1e9,                        # poids gelés FP16
    0,                                    # pas de gradients pour les gelés
    0,                                    # pas d'optimizer pour les gelés
    lora_trainable * 16 / 1e9,           # LoRA params + grad + optimizer
]

# QLoRA (poids gelés NF4, LoRA 0.5% trainable)
qlora = [
    N * 0.5 / 1e9,                       # poids gelés NF4 (4 bits)
    0,                                    # pas de gradients pour les gelés
    0,                                    # pas d'optimizer pour les gelés
    lora_trainable * 16 / 1e9,           # LoRA params + grad + optimizer
]

x = np.arange(len(categories))
width = 0.25

fig, ax = plt.subplots(figsize=(12, 5))

bars1 = ax.barh(x + width, full_ft, width, label="Full fine-tuning", color="#C44E52")
bars2 = ax.barh(x, lora_fp16, width, label="LoRA (FP16)", color="#4C72B0")
bars3 = ax.barh(x - width, qlora, width, label="QLoRA (NF4)", color="#55A868")

ax.set_xlabel("Mémoire GPU (Go)")
ax.set_yticks(x)
ax.set_yticklabels(categories)
ax.legend(loc="lower right")
ax.set_title(f"Décomposition de la mémoire GPU pour un modèle de {N/1e9:.0f}B paramètres")

# Totaux
for i, (f, l, q) in enumerate(zip(full_ft, lora_fp16, qlora)):
    if f > 0:
        ax.text(f + 0.3, i + width, f"{f:.1f}", va="center", fontsize=9, color="#C44E52")
    if l > 0:
        ax.text(l + 0.3, i, f"{l:.1f}", va="center", fontsize=9, color="#4C72B0")
    if q > 0:
        ax.text(q + 0.3, i - width, f"{q:.1f}", va="center", fontsize=9, color="#55A868")

ax.text(8, -1.0,
        f"Total:  Full FT = {sum(full_ft):.0f} Go  |  LoRA = {sum(lora_fp16):.1f} Go  |  QLoRA = {sum(qlora):.1f} Go",
        fontsize=11, fontweight="bold",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="#F5F5F5", edgecolor="#CCCCCC"))

plt.show()

Autres méthodes PEFT

LoRA n’est pas la seule méthode de fine-tuning efficace. Plusieurs approches antérieures et alternatives existent, chacune avec ses avantages spécifiques. Nous les présentons brièvement pour les situer par rapport a LoRA.

Définition 112 (Adapters)

Les adapters (Houlsby et al., 2019) sont de petits modules insérés a l’intérieur de chaque couche du Transformer. Un adapter typique consiste en une projection descendante (\(d \to r\)), une activation non linéaire (ReLU ou GELU), et une projection montante (\(r \to d\)), plus une connexion résiduelle :

\[h = h + f(h W_{\text{down}}) W_{\text{up}}\]

où \(W_{\text{down}} \in \mathbb{R}^{d \times r}\) et \(W_{\text{up}} \in \mathbb{R}^{r \times d}\). Contrairement à LoRA, les adapters ajoutent de la profondeur (deux couches supplémentaires) et introduisent une non-linéarite. Ils sont insérés après la couche d’attention et après la couche feed-forward de chaque bloc Transformer.

Définition 113 (Prefix tuning)

Le prefix tuning (Li et Liang, 2021) apprend un ensemble de vecteurs « virtuels » \(P_K, P_V \in \mathbb{R}^{l \times d}\) (où \(l\) est la longueur du préfixe) qui sont préposés (prepended) aux clés et valeurs de chaque couche d’attention. Le modèle traite ces vecteurs comme s’ils correspondaient a \(l\) tokens supplémentaires au début de la séquence, mais ces tokens n’ont pas de représentation dans le vocabulaire — ils sont directement paramétrisés dans l’espace des clés et valeurs. Seuls les paramètres du préfixe sont entrainés ; le modèle reste gelé.

Définition 114 (Prompt tuning)

Le prompt tuning (Lester et al., 2021) est une version simplifiée du prefix tuning ou l’on apprend un ensemble de \(k\) embeddings virtuels \([e_1, \ldots, e_k] \in \mathbb{R}^{k \times d}\) qui sont préposés à la séquence d’entrée uniquement à la couche d’embedding (et non à chaque couche d’attention). Le nombre de paramètres entrainables est \(k \times d\), typiquement de l’ordre de quelques milliers à quelques dizaines de milliers — encore moins que LoRA. Le prompt tuning est particulièrement efficace pour les très grands modèles (\(> 10\)B paramètres).

Show code cell source

Hide code cell source

# Tableau comparatif des methodes PEFT
fig, ax = plt.subplots(figsize=(13, 5))
ax.axis("off")

methods = [
    ["Méthode", "Ou agit-elle ?", "Params typ.", "Non-linéarité", "Inférence\noverhead", "Performance\nrelative"],
    ["Full fine-tuning", "Tous les poids", "100 %", "—", "Aucun", "Référence"],
    ["Adapters\n(Houlsby 2019)", "Modules insérés\naprès attn + FFN", "0,5–3 %", "Oui (GELU)", "Latence ajoutée\n(couches supp.)", "~98–100 %"],
    ["Préfix tuning\n(Li & Liang 2021)", "Préfixe K, V\na chaque couche", "0,1–1 %", "Non", "Léger (tokens\nvirtuels)", "~95–99 %"],
    ["Prompt tuning\n(Lester 2021)", "Embedding\nd'entrée", "< 0,01 %", "Non", "Négligeable", "~90–98 %\n(dépend taille)"],
    ["LoRA\n(Hu 2021)", "Matrices Q, V\n(ou toutes)", "0,1–1 %", "Non", "Aucun\n(fusion possible)", "~99–100 %"],
    ["QLoRA\n(Dettmers 2023)", "LoRA + quant.\n4-bit du modèle", "0,1–1 %", "Non", "Déquant.\na la volée", "~98–100 %"],
]

colors_row = ["#E8EAF6"] + ["#FFFFFF", "#F5F5F5"] * 3
table = ax.table(cellText=methods[1:], colLabels=methods[0],
                 cellLoc="center", loc="center")
table.auto_set_font_size(False)
table.set_fontsize(9)
table.scale(1.0, 2.0)

for (row, col), cell in table.get_celld().items():
    if row == 0:
        cell.set_facecolor("#4C72B0")
        cell.set_text_props(color="white", fontweight="bold")
    else:
        cell.set_facecolor(colors_row[row - 1])
    cell.set_edgecolor("#CCCCCC")

ax.set_title("Comparaison des méthodes de fine-tuning efficace", fontsize=13, pad=20)
plt.show()

L’un des avantages distinctifs de LoRA par rapport aux adapters et au prefix tuning est qu’à l’inférence, les matrices LoRA peuvent être fusionnées (merged) dans les poids originaux : \(W_{\text{merged}} = W_0 + BA\). Le modèle résultant a exactement la même architecture et la même vitesse d’inférence que le modèle original — il n’y a aucun coût supplémentaire. Les adapters, en revanche, ajoutent des couches supplémentaires qui ralentissent l’inférence, et le préfix tuning consomme une partie de la fenêtre de contexte.

Adaptation de domaine en pratique

Avant de se lancer dans un fine-tuning, il est essentiel de se poser la bonne question : le fine-tuning est-il nécessaire ? Dans de nombreux cas, le prompt engineering ou le RAG (Retrieval-Augmented Generation) suffisent. Le fine-tuning est justifié lorsque le modèle doit apprendre un style, un format, un vocabulaire technique ou un comportement que le prompt seul ne peut pas capturer de manière fiable.

Critère	Prompt engineering	RAG	Fine-tuning
Quand l’utiliser	Tache bien spécifiable par instruction	Besoin de connaissances factuelles à jour	Style/format spécifique, vocabulaire de domaine
Données requises	Aucune	Base documentaire	100 à 10 000 exemples annotés
Coût	Nul	Moyen (indexation, retrieval)	Elevé (GPU, temps)
Latence	Faible	Moyenne (retrieval + génération)	Faible (modèle spécialisé)
Maintenance	Facile (modifier le prompt)	Moyenne (mise à jour de l’index)	Lourde (ré-entrainement)
Risque de régression	Nul	Faible	Possible (forgetting)

Remarque 108 (Quand le fine-tuning est-il justifié ?)

Le fine-tuning PEFT est particulièrement indiqué dans les situations suivantes :

• Adaptation de style : le modèle doit générer du texte dans un style précis (juridique, médical, poétique) que le prompting ne capture pas de manière fiable.

• Suivi de format : le modèle doit produire systématiquement un format de sortie strict (JSON spécifique, formulaire structuré).

• Vocabulaire de domaine : le modèle doit maitriser un jargon technique absent de ses données de pré-entrainement.

• Petit modèle performant : on souhaite obtenir les performances d’un grand modèle sur une tâche spécifique avec un petit modèle, pour réduire les coûts d’inférence.

En revanche, si le besoin est principalement factuel (« quelles sont les dernières recommandations ? »), le RAG est généralement plus adapté.

La préparation du jeu de données est l’étape la plus critique. Un jeu de données de fine-tuning doit être représentatif de la tâche cible, propre (pas de bruit, d’erreurs ou de biais systématiques), et suffisamment divers pour éviter le surapprentissage sur des patterns superficiels. En pratique, quelques centaines d’exemples de haute qualité valent mieux que des milliers d’exemples médiocres.

Remarque 109 (Qualite des données et décontamination)

La qualite du jeu de données de fine-tuning est plus importante que sa taille. Quelques bonnes pratiques :

• Déduplication : retirer les exemples dupliqués ou quasi-dupliqués qui biaiseraient l’entrainement vers des formulations répétitives.

• Décontamination : s’assurer que le jeu de test n’est pas présent dans le jeu d’entrainement (risque de surestimation des performances).

• Diversité : couvrir la variété des cas d’usage attendus (formulations différentes, niveaux de complexité, cas limites).

• Annotation cohérente : pour les tâches supervisées, les annotations doivent être cohérentes entre annotateurs (accord inter-annotateurs \(\kappa > 0{,}8\)).

Un jeu de 500 exemples bien annotés et divers sera généralement plus efficace qu’un jeu de 10 000 exemples bruités ou homogènes.

Remarque 110 (Evaluation des modèles fine-tunés)

L’évaluation d’un modèle fine-tuné doit aller au-delà de la perte d’entrainement. Il est recommandé de mesurer :

• La perte de validation sur un ensemble de test disjointe du jeu d’entrainement, pour détecter le surapprentissage.

• Des métriques spécifiques à la tâche (ROUGE pour la génération, F1 pour la classification, exact match pour l’extraction)

• La performance sur des tâches générales (benchmarks standards comme MMLU, HellaSwag), pour vérifier l’absence de régression catastrophique.

• L”évaluation humaine lorsque les métriques automatiques sont insuffisantes (qualité stylistique, cohérence, utilité).

Fine-tuning de GPT-2 avec LoRA

Passons a la pratique. Nous allons fine-tuner GPT-2 small (124M paramètres) avec LoRA sur un petit corpus de recettes de cuisine françaises. L’objectif est de montrer que même avec un entrainement minimal (quelques minutes sur CPU), le modèle adapté génère du texte significativement différent du modèle original lorsqu’on le sollicite sur le thème de la cuisine.

Exemple 76 (Fine-tuning de GPT-2 avec LoRA)

Nous utilisons GPT-2 small (124M paramètres, ~500 Mo en memoire) avec la bibliotheque peft de Hugging Face. La configuration LoRA cible les matrices de projection d’attention (\(W_Q\), \(W_V\)) avec un rang \(r = 8\), ce qui ajoute environ 295 000 paramètres entrainables (0,24 % du total). Le jeu de données est un ensemble de 60 courtes phrases sur la cuisine française. L’entrainement se fait en 1 époque avec un batch size de 2, ce qui prend environ 2 à 3 minutes sur CPU et utilise moins de 3 Go de RAM.

Show code cell source

Hide code cell source

from transformers import GPT2LMHeadModel, GPT2Tokenizer

# Charger GPT-2 small (124M paramètres, ~500 Mo)
model_name = "gpt2"
tokenizer = GPT2Tokenizer.from_pretrained(model_name)
tokenizer.pad_token = tokenizer.eos_token

base_model = GPT2LMHeadModel.from_pretrained(model_name)
print(f"Modèle : {model_name}")
print(f"Paramètres totaux : {sum(p.numel() for p in base_model.parameters()):,}")
print(f"Taille mémoire estimée : ~{sum(p.numel() * p.element_size() for p in base_model.parameters()) / 1e6:.0f} Mo")

Modèle : gpt2
Paramètres totaux : 124,439,808
Taille mémoire estimée : ~498 Mo

Show code cell source

Hide code cell source

# Génération AVANT fine-tuning (modèle original)
def generate_text(model, tokenizer, prompt, max_length=80):
    """Génère du texte à partir d'un prompt."""
    inputs = tokenizer(prompt, return_tensors="pt")
    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_length=max_length,
            do_sample=True,
            temperature=0.8,
            top_p=0.9,
            repetition_penalty=1.2,
            pad_token_id=tokenizer.eos_token_id,
        )
    return tokenizer.decode(outputs[0], skip_special_tokens=True)

prompt = "Recette de cuisine : pour préparer un bon"
print("=== Avant fine-tuning ===")
print(f"Prompt : {prompt}")
print(f"Génération : {generate_text(base_model, tokenizer, prompt)}")

=== Avant fine-tuning ===
Prompt : Recette de cuisine : pour préparer un bon

Génération : Recette de cuisine : pour préparer un bonne du Monde, dans les réalites et leur cet électrique.
Sous chef à nouvelle mais en avec sont parler sur la montre entrevirée que vos découtons était des faveurs comme qu'il est rés

Show code cell source

Hide code cell source

import warnings
warnings.filterwarnings("ignore", message=".*loss_type.*")
warnings.filterwarnings("ignore", message=".*fan_in_fan_out.*")

from peft import LoraConfig, get_peft_model, TaskType

# Configuration LoRA
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=8,                       # rang de la décomposition
    lora_alpha=16,             # facteur d'échelle (alpha/r = 2)
    lora_dropout=0.05,         # dropout pour régulariser
    target_modules=["c_attn"], # GPT-2 utilise c_attn pour Q, K, V combinées
    bias="none",
    fan_in_fan_out=True,       # requis pour les couches Conv1D de GPT-2
)

# Appliquer LoRA au modèle
model = get_peft_model(base_model, lora_config)
model.print_trainable_parameters()

trainable params: 294,912 || all params: 124,734,720 || trainable%: 0.2364

Show code cell source

Hide code cell source

# Dataset : courtes phrases sur la cuisine française (réduit pour timeout)
cuisine_texts = [
    "Pour préparer un gratin dauphinois, il faut des pommes de terre, de la crème fraîche et du fromage râpé.",
    "La ratatouille est un plat provençal composé de zucchini, aubergines, poivrons et tomates.",
    "Le beurre est l'ingrédient essentiel de la cuisine française traditionnelle.",
    "Une bonne blanquette de veau nécessite une cuisson lente à feu doux pendant deux heures.",
    "Le coq au vin se prépare avec un coq, du vin rouge de Bourgogne, des lardons et des champignons.",
    "La quiche lorraine se compose de pâte brisée, de lardons, d'oeufs et de crème fraîche.",
    "Le pot-au-feu est un plat convivial à base de boeuf et de légumes cuits longuement dans un bouillon.",
    "La sauce béchamel est une sauce blanche à base de beurre, de farine et de lait.",
    "Le clafoutis aux cerises est un dessert simple et rustique du Limousin.",
    "Le confit de canard se conserve dans sa propre graisse pendant plusieurs mois.",
    "La galette des rois se prépare avec de la pâte feuilletée et de la frangipane.",
    "Le gratin de zucchini se fait avec des zucchini tranchés, de la crème et du parmesan.",
    "La mousse au chocolat nécessite du chocolat noir, des oeufs et une pincée de sel.",
    "La brioche se prépare avec de la farine, du beurre, des oeufs et de la levure de boulanger.",
    "La salade niçoise réunit thon, olives noires, anchois, tomates et haricots verts.",
    "Le poulet rôti se cuit au four avec des herbes de Provence et un filet d'huile d'olive.",
    "Le far breton est un gâteau dense à base d'oeufs, de farine, de lait et de pruneaux.",
    "La tartiflette savoyarde se prépare avec des pommes de terre, du reblochon et des lardons.",
    "La daube provençale est un ragoût de boeuf mariné et cuit dans du vin rouge.",
    "Les madeleines de Commercy se préparent avec de la farine, du beurre, des oeufs et du citron.",
]

print(f"Nombre de phrases d'entrainement : {len(cuisine_texts)}")
print(f"Exemple : {cuisine_texts[0][:80]}...")

Nombre de phrases d'entrainement : 20
Exemple : Pour préparer un gratin dauphinois, il faut des pommes de terre, de la crème fra...

Show code cell source

Hide code cell source

# Tokenisation du dataset
encodings = tokenizer(
    cuisine_texts,
    truncation=True,
    max_length=128,
    padding="max_length",
    return_tensors="pt",
)

# Dataset simple avec PyTorch
class SimpleDataset(torch.utils.data.Dataset):
    def __init__(self, encodings):
        self.input_ids = encodings["input_ids"]
        self.attention_mask = encodings["attention_mask"]

    def __len__(self):
        return len(self.input_ids)

    def __getitem__(self, idx):
        return {
            "input_ids": self.input_ids[idx],
            "attention_mask": self.attention_mask[idx],
            "labels": self.input_ids[idx].clone(),
        }

dataset = SimpleDataset(encodings)
dataloader = torch.utils.data.DataLoader(dataset, batch_size=2, shuffle=True)

print(f"Nombre de batches : {len(dataloader)}")
print(f"Tokens par exemple : {encodings['input_ids'].shape[1]}")

Nombre de batches : 10
Tokens par exemple : 128

Show code cell source

Hide code cell source

# Entrainement (1 époque, ~30s sur CPU)
import sys
optimizer = optim.AdamW(model.parameters(), lr=5e-4, weight_decay=0.01)
num_epochs = 1

model.train()
losses = []

for epoch in range(num_epochs):
    epoch_losses = []
    for i, batch in enumerate(dataloader):
        optimizer.zero_grad()
        outputs = model(
            input_ids=batch["input_ids"],
            attention_mask=batch["attention_mask"],
            labels=batch["labels"],
        )
        loss = outputs.loss
        loss.backward()
        optimizer.step()
        epoch_losses.append(loss.item())
        losses.append(loss.item())
        
        if i % 10 == 0:
            print(f"  Batch {i}/{len(dataloader)} — Loss: {loss.item():.4f}", flush=True)

    avg_loss = np.mean(epoch_losses)
    print(f"Epoque {epoch + 1}/{num_epochs} — Perte moyenne : {avg_loss:.4f}", flush=True)

print(f"\nEntrainement terminé. Perte finale : {losses[-1]:.4f}", flush=True)

`loss_type=None` was set in the config but it is unrecognized. Using the default loss: `ForCausalLMLoss`.

  Batch 0/10 — Loss: 6.6910

Epoque 1/1 — Perte moyenne : 6.2843

Entrainement terminé. Perte finale : 4.6822

Show code cell source

Hide code cell source

# Courbe de perte d'entrainement
fig, ax = plt.subplots(figsize=(10, 4))

ax.plot(losses, color="#4C72B0", alpha=0.4, linewidth=0.8, label="Perte par batch")

# Moyenne glissante
window = max(1, len(losses) // 15)
if len(losses) >= window:
    smoothed = np.convolve(losses, np.ones(window)/window, mode="valid")
    ax.plot(range(window - 1, len(losses)), smoothed, color="#C44E52",
            linewidth=2.5, label=f"Moyenne glissante (fenêtre={window})")

# Séparateurs d'époques
batches_per_epoch = len(dataloader)
for e in range(1, num_epochs):
    ax.axvline(e * batches_per_epoch, color="#999999", linestyle="--", alpha=0.5)
    ax.text(e * batches_per_epoch + 0.5, max(losses) * 0.95,
            f"Epoque {e + 1}", fontsize=9, color="#999999")

ax.set_xlabel("Batch")
ax.set_ylabel("Perte (cross-entropy)")
ax.set_title("Courbe d'entrainement — Fine-tuning LoRA de GPT-2 sur recettes de cuisine")
ax.legend()
plt.show()

Show code cell source

Hide code cell source

# Génération APRES fine-tuning
model.eval()

prompts = [
    "Recette de cuisine : pour préparer un bon",
    "La cuisine française est connue pour",
    "Les ingrédients principaux de ce plat sont",
]

print("=== Apres fine-tuning LoRA ===\n")
for prompt in prompts:
    print(f"Prompt : {prompt}")
    generated = generate_text(model, tokenizer, prompt, max_length=100)
    print(f"Génération : {generated}")
    print("-" * 60)

=== Apres fine-tuning LoRA ===

Prompt : Recette de cuisine : pour préparer un bon

Génération : Recette de cuisine : pour préparer un bonnée, s'apparre à une désociation (bètat des développement) qui aucun quand il avant sauver les pendant mains par la bibliotheque.
(9/30): Dauphin , et nous pas sur leur fait en rétude du gastronomique ; au vie entendienlement seule .
------------------------------------------------------------
Prompt : La cuisine française est connue pour

Génération : La cuisine française est connue pour tous les ducs que l'avoir, et à ce bien sa féri-faire.
The following is a list of the restaurants and cafes that I have visited in La Pâteau de Lavezzi (the site where my parents bought us all their furniture). The restaurant lists below are based on information from locals:
------------------------------------------------------------
Prompt : Les ingrédients principaux de ce plat sont

Génération : Les ingrédients principaux de ce plat sont quelques vos inégliches répenses dans les études férés. Le prétique du jeune monde, se l'un homme et la défense entre avoir à tous jours en français des peux autres qui nombès pour lequel Âleur hommage que ne devrait pas au plus ont parlement
------------------------------------------------------------

Show code cell source

Hide code cell source

# Comparaison du nombre de paramètres : full FT vs LoRA pour différents rangs
d_model = 768
n_layers = 12
total_params = 124_000_000  # GPT-2 small

ranks = [1, 2, 4, 8, 16, 32, 64, 128]
# LoRA sur c_attn (projections Q, K, V combinées : 768 -> 2304)
# et c_proj (projection de sortie : 768 -> 768)
lora_params = [4 * n_layers * d_model * r for r in ranks]  # simplification Q, V
lora_pct = [p / total_params * 100 for p in lora_params]

fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(13, 5))

# Nombre absolu de paramètres
ax1.bar(range(len(ranks)), [p / 1000 for p in lora_params], color="#4C72B0")
ax1.set_xticks(range(len(ranks)))
ax1.set_xticklabels([str(r) for r in ranks])
ax1.set_xlabel("Rang LoRA ($r$)")
ax1.set_ylabel("Paramètres entrainables (milliers)")
ax1.set_title("Paramètres LoRA selon le rang")
ax1.axhline(y=total_params / 1000, color="#C44E52", linestyle="--", alpha=0.7)
ax1.text(0.5, total_params / 1000 * 1.05, f"Full FT : {total_params/1e6:.0f}M",
         color="#C44E52", fontsize=9)

# Pourcentage
ax2.plot(ranks, lora_pct, 'o-', color="#55A868", linewidth=2, markersize=8)
ax2.set_xlabel("Rang LoRA ($r$)")
ax2.set_ylabel("Paramètres entrainables (% du total)")
ax2.set_title("Fraction des paramètres entrainés")
ax2.set_xscale("log", base=2)

for r, pct in zip(ranks, lora_pct):
    ax2.annotate(f"{pct:.2f}%", (r, pct), textcoords="offset points",
                 xytext=(0, 10), ha="center", fontsize=8)

fig.suptitle("GPT-2 small (124M params) : paramètres entrainables selon le rang LoRA",
             fontsize=13, y=1.02)
plt.show()

Résumé

Ce chapitre a présenté les méthodes de fine-tuning efficace qui permettent d’adapter les grands modèles de langage à des taches spécifiques sans mobiliser des ressources prohibitives. Les points essentiels sont les suivants.

1. Le fine-tuning complet d’un LLM met à jour tous les \(N\) paramètres et nécessite environ \(16N\) octets de mémoire GPU (poids + gradients + etats d’optimiseur). Pour les modèles de plusieurs milliards de paramètres, cela requiert un matériel coûteux.

2. Les méthodes PEFT (Parameter-Efficient Fine-Tuning) ne modifient qu’une fraction infime des paramètres (typiquement 0,1 a 1 %). Le modèle pré-entrainé reste gelé, ce qui réduit la mémoire, accélère l’entrainement et atténue l’oubli catastrophique.

3. LoRA (Hu et al., 2021) est la méthode PEFT dominante. Elle décompose la mise à jour de chaque matrice de poids en un produit de deux matrices de faible rang : \(\Delta W = BA\), avec \(B \in \mathbb{R}^{d \times r}\) et \(A \in \mathbb{R}^{r \times d}\). Le rang \(r\) contrôle le compromis entre capacitŕ d’adaptation et nombre de paramètres.

4. QLoRA (Dettmers et al., 2023) combine LoRA avec la quantification 4 bits (NormalFloat4) du modèle de base, permettant le fine-tuning de modèles de 65B paramètres sur un seul GPU de 48 Go. La double quantification et les optimiseurs pagés complètent le dispositif.

5. Les alternatives à LoRA incluent les adapters (modules insérés dans le Transformer), le prefix tuning (vecteurs virtuels préposés aux clés et valeurs) et le prompt tuning (embeddings virtuels à l’entrée). LoRA se distingue par l’absence de coût d’inférence supplémentaire après fusion des poids.

6. Le choix entre fine-tuning, prompt engineering et RAG dépend du type d’adaptation recherchée : le fine-tuning excelle pour le style, le format et le vocabulaire de domaine ; le RAG est préférable pour les connaissances factuelles à jour ; le prompt engineering suffit pour les tâches bien spécifiables.

7. En pratique, le fine-tuning de GPT-2 small avec LoRA (\(r = 8\)) n’ajoute que 0,24 % de paramètres entrainables. L’entrainement sur 60 phrases pendant 3 époques se fait en quelques minutes sur CPU, avec une empreinte mémoire inférieure à 3 Go — accessible sur n’importe quelle machine moderne.