Fine-tuning et modèles locaux : les deux questions auxquelles je n'ai pas su répondre. Avec les réponses.

Dans le dernier article, je racontais avoir séché sur la question « c’est quoi un harness » en entretien avec la compagnie X.

Ce que je n’ai pas dit : ce n’était pas le seul trou.

Il y en avait deux autres.

« Quelles sont les grandes approches de fine-tuning, et quand les utiliser ? » « Comment tu choisirais et déploierais un modèle local en production ? »

Deux fois, la même réponse honnête : je ne sais pas.

10 ans d’apps mobiles. Des agents IA qui tournent tous les jours chez moi. Et deux questions fondamentales sur lesquelles je n’avais qu’une intuition floue.

Alors j’ai fait la même chose que la dernière fois. Une semaine d’apprentissage ciblé. Et j’en sors avec une carte mentale que je peux te donner en 10 minutes de lecture.

C’est parti.

Partie 1 : les 3 familles de fine-tuning

Le fine-tuning, c’est prendre un modèle déjà entraîné et le spécialiser sur tes données.

Sur le papier, simple. En pratique, il y a trois approches très différentes. Les confondre, c’est cramer du budget pour rien.

Famille 1 : le full fine-tuning

Tu réentraînes tous les poids du modèle sur tes données.

C’est l’approche la plus puissante. C’est aussi la plus chère, et de loin.

Pourquoi ? Parce qu’entraîner, ce n’est pas juste faire tourner le modèle. Il faut stocker les gradients et les états de l’optimiseur. Compte 16 à 20 octets par paramètre. Pour un modèle 7B, ça fait plus de 120 Go de VRAM. Tu ne fais pas ça sur ta machine. Tu loues un cluster de GPU.

Quand l’utiliser :

• tu veux changer profondément le comportement du modèle (nouveau domaine, nouvelle langue peu couverte)
• tu as des dizaines de milliers d’exemples de qualité
• tu as le budget GPU et l’équipe pour gérer l’entraînement

Autrement dit : presque jamais pour une PME ou un produit early-stage. C’est l’outil des labos et des grosses boîtes.

Famille 2 : LoRA et QLoRA

C’est là que ça devient intéressant pour le commun des mortels.

L’idée de LoRA : au lieu de toucher aux milliards de paramètres du modèle, tu gèles tout et tu entraînes des petites matrices ajoutées à côté. Moins de 1 % des paramètres bougent.

Résultat concret : fine-tuner un modèle 7B devient faisable sur un seul GPU de 24 Go. Une RTX 4090, pas un cluster.

QLoRA pousse le truc plus loin : le modèle de base est compressé en 4 bits pendant l’entraînement. Un modèle 70B devient fine-tunable sur environ 48 Go de VRAM. Deux cartes grand public.

Et le bonus : le résultat de l’entraînement est un petit fichier « adapter » de quelques centaines de Mo. Tu peux en avoir plusieurs pour le même modèle de base. Un adapter par client, par ton, par tâche.

Quand l’utiliser :

• tu veux un style ou un format de sortie constant (ton de marque, JSON strict, résumés calibrés)
• tu as entre 500 et quelques milliers d’exemples propres
• tu veux un coût maîtrisé : quelques dizaines d’euros de GPU, pas quelques dizaines de milliers

C’est la famille par défaut. Si quelqu’un dit « on va fine-tuner », dans 90 % des cas il parle de ça — ou devrait.

Famille 3 : RLHF et DPO

Troisième famille, et c’est un autre sport : l’alignement par préférences.

Ici, tu n’apprends pas au modèle des connaissances ou un format. Tu lui apprends à préférer certaines réponses à d’autres. « Cette réponse est meilleure que celle-là. »

• RLHF : la méthode historique. Tu entraînes un modèle de récompense sur des jugements humains, puis tu optimises le modèle contre. Puissant, mais lourd et instable.
• DPO : la version simplifiée qui a gagné. Pas de modèle de récompense séparé. Tu donnes directement des paires « réponse préférée / réponse rejetée », et le modèle apprend le contraste. Même famille de résultat, pipeline beaucoup plus simple.

Quand l’utiliser :

• tu veux régler le comportement : refus, prudence, helpfulness, ton dans les cas ambigus
• tu as des paires de préférences (souvent issues de feedback utilisateur réel)
• tu as déjà fait un fine-tuning supervisé avant — c’est une couche de finition, pas un point de départ

C’est comme ça que sont polis les modèles que tu utilises tous les jours. Mais pour un produit classique, tu y touches rarement toi-même.

La règle d’or : RAG avant fine-tuning

Voilà le point que j’aurais dû sortir en entretien, et qui vaut plus que les trois familles réunies.

La plupart des cas « il nous faut du fine-tuning » sont en fait des cas RAG.

La question à poser : est-ce que ton problème est un problème de connaissance ou un problème de comportement ?

• « Le modèle ne connaît pas nos produits / nos docs / nos prix » → problème de connaissance → RAG. Tu vas chercher la bonne info au moment de la requête et tu la mets dans le contexte. À jour en permanence, sources traçables, aucun réentraînement.
• « Le modèle ne répond pas dans le bon format / le bon ton / la bonne structure » → problème de comportement → là, le fine-tuning (LoRA) a du sens.

Le fine-tuning est mauvais pour injecter des connaissances. Les faits appris se périment, le modèle hallucine ce qu’il a mal mémorisé, et chaque mise à jour de tes données demande un réentraînement.

Le RAG, lui, se met en place en quelques jours, se debug en lisant ce qui a été récupéré, et se met à jour en changeant un document.

Donc l’ordre : prompt soigné → RAG → fine-tuning. Dans ce sens. Tu montes d’un cran seulement quand le cran d’avant plafonne, mesures à l’appui.

Partie 2 : choisir et déployer un modèle local

Deuxième question ratée. Elle se découpe en quatre décisions.

Décision 1 : le sizing VRAM

Règle de pouce, à connaître par cœur :

VRAM nécessaire ≈ nombre de paramètres (en milliards) × octets par paramètre, plus 20 à 30 % de marge pour le contexte.

Concrètement :

• FP16 (pleine précision usuelle) : 2 octets par paramètre. Un 7B ≈ 14 Go. Un 70B ≈ 140 Go.
• Q8 (8 bits) : 1 octet. Un 7B ≈ 7 Go.
• Q4 (4 bits) : environ 0,5 à 0,6 octet. Un 7B ≈ 4 à 5 Go. Un 70B ≈ 40 Go.

La marge, c’est pour le KV cache : plus ton contexte est long et plus tu sers d’utilisateurs en parallèle, plus il gonfle. C’est lui qui te surprend en prod, pas les poids.

Traduction pratique :

• un Mac avec 16 Go de mémoire unifiée fait tourner un 7B-8B en Q4 confortablement
• une RTX 4090 (24 Go) fait tourner un 14B en Q4, voire un 32B serré
• un 70B en Q4 demande environ 48 Go : deux GPU, ou une grosse machine unifiée

Décision 2 : Ollama ou vLLM

Les deux font tourner des modèles. Ils ne jouent pas dans la même cour.

Ollama, c’est l’outil de dev. Installation en une commande, un ollama run et ça tourne, gestion des modèles intégrée. Parfait pour prototyper, tester des modèles, faire tourner un assistant perso. Sa limite : il est pensé pour un utilisateur à la fois.

vLLM, c’est l’outil de prod. Son métier : le throughput. Il traite les requêtes en batch continu et gère la mémoire du KV cache finement (PagedAttention). Sur une charge multi-utilisateurs, on parle d’un facteur 10 à 20 en tokens par seconde servis par rapport à une stack naïve. API compatible OpenAI, donc ton code client ne change pas.

La règle est simple :

• dev, proto, usage solo → Ollama
• prod, plusieurs utilisateurs simultanés, coût par token qui compte → vLLM

Prototyper sur Ollama puis déployer sur vLLM est un chemin tout à fait normal.

Décision 3 : la quantization

La quantization, c’est compresser les poids du modèle en réduisant leur précision. Q8 = 8 bits, Q4 = 4 bits.

Ce que tu gagnes : de la VRAM (moitié, puis quart), et de la vitesse.

Ce que tu perds :

• Q8 : quasi rien. Perte imperceptible dans la pratique. Si ça rentre en Q8, prends Q8.
• Q4 : une dégradation légère mais réelle. Le modèle reste bon en conversation et en synthèse, mais devient un peu moins fiable sur le raisonnement fin, le code pointu, le suivi d’instructions complexes.

Et une règle contre-intuitive qui vaut de l’or : un gros modèle quantizé bat presque toujours un petit modèle en pleine précision, à VRAM égale. Un 32B en Q4 ≈ 18 Go écrase un 7B en FP16 ≈ 14 Go. Si tu as le choix, prends plus de paramètres et quantize.

Décision 4 : le test qui compte

Dernier point, et c’est le plus important.

Les benchmarks publics (MMLU et compagnie) te disent qu’un modèle est bon en général. Ils ne te disent rien sur ton cas. Les modèles sont en partie optimisés pour ces benchmarks — c’est la vitrine, pas l’atelier.

Ce qui compte, ce sont tes golden paths : les 20 à 50 requêtes réelles qui représentent ce que ton produit doit réussir. Tes vrais documents, tes vrais formats de sortie, tes vrais cas tordus.

Le protocole tient en trois lignes :

1. construis ton set de golden paths une fois
2. fais-le passer sur 2-3 modèles candidats, aux quantizations que tu vises
3. compare les sorties côte à côte, et mesure ce qui est mesurable (format respecté, champs corrects, refus injustifiés)

Une après-midi de travail. Et à la fin, tu choisis ton modèle sur tes données, pas sur un leaderboard.

C’est exactement le même réflexe qu’en mobile : je ne choisis pas une lib sur ses stars GitHub, je la teste sur mon cas d’usage.

La carte mentale complète

Si je devais repasser cet entretien, voilà ma réponse en 30 secondes :

Fine-tuning :

• problème de connaissance → RAG, pas de fine-tuning
• problème de style/format → LoRA ou QLoRA, un GPU suffit
• problème de comportement profond → DPO, avec des paires de préférences
• full fine-tuning → presque jamais, sauf gros budget et vrai besoin de fond

Modèle local :

• sizing : paramètres × octets/param (2 en FP16, ~0,5 en Q4) + 20-30 % de marge
• Ollama pour le dev, vLLM pour la prod
• Q8 sans hésiter, Q4 en connaissance de cause, gros modèle quantizé > petit modèle précis
• décision finale sur tes golden paths, jamais sur les benchmarks publics

Deux « je ne sais pas » transformés en carte mentale. Une semaine chacune.

L’IA reste mon accélérateur, pas mon remplaçant. Mais un accélérateur, ça se pilote mieux quand tu comprends le moteur.

Pour finir

Si tu es en train de te demander « on fine-tune ou pas ? » ou « on passe en local ou pas ? » pour ton produit, la réponse tient rarement dans un article. Elle tient dans tes données, ton budget et tes golden paths.

J’aide des équipes à trancher ce genre de décision, puis à shipper la version simple qui marche.

Si c’est ton cas en ce moment, écris-moi. Un call de 30 minutes suffit souvent à éviter trois mois dans la mauvaise direction.