Fine-tuning, retrieval ou prompt ? La décision est économique

« Faut-il faire du fine-tuning ? » est posé comme s’il s’agissait d’une question sur un modèle. C’est une question de budget, avec une forme à laquelle aucun benchmark ne répond : ce qui est payé une fois, ce qui est payé par question, et ce qui est payé à nouveau chaque fois que le monde bouge.

Les trois routes ne sont pas non plus trois façons de faire une seule chose, et les fournisseurs le disent plus clairement que la plupart des articles de blog. Le propre tableau d’OpenAI sur les cas où le fine-tuning supervisé est le plus adapté liste quatre usages : classification, traduction nuancée, génération de contenu dans un format spécifique, et correction d’échecs de suivi des instructions.¹ Aucun d’eux n’est « apprendre au modèle quelque chose qu’il ne sait pas ». Son résumé du bénéfice est que « vous pouvez utiliser des prompts plus courts avec moins d’exemples et de données de contexte, ce qui économise des coûts de tokens à grande échelle et peut réduire la latence » — un argument sur la facture, venant de l’entreprise qui vend la fonctionnalité.

Donc :

• Le fine-tuning enseigne la forme et le comportement. Le ton, le format, la structure d’une réponse, une limite que vous pouvez démontrer mais pas décrire. La version publiée la plus forte est l’hypothèse d’alignement superficiel de LIMA : la connaissance vient du préentraînement, l’alignement enseigne surtout dans quelle sous-distribution de formats parler — c’est pourquoi un millier d’exemples sélectionnés y ont suffi.²
• Le retrieval fournit les faits qui changent. C’est le seul des trois où une modification de votre documentation atteint la réponse sans toucher au modèle.
• Le prompting couvre la plupart des cas réels, et constitue la baseline honnête. L’apprentissage in-context est le standard depuis Language Models are Few-Shot Learners : la tâche est démontrée dans le prompt et aucun poids ne bouge.³

Deux articles mesurés ferment la porte sur l’erreur du milieu. Ovadia et ses collègues ont comparé l’injection de connaissance par fine-tuning non supervisé à l’injection par retrieval, et le retrieval a gagné de façon constante, y compris sur des faits que le modèle de base avait déjà vus lors du préentraînement.⁴ Gekhman et ses collègues ont mesuré les dégâts : les exemples qui introduisent de nouvelles connaissances sont ajustés lentement, et quand le modèle finit par les ajuster, son taux d’hallucination sur d’autres questions augmente.⁵ Enseigner des faits par fine-tuning ne se contente pas d’échouer ; cela dégrade des réponses sur lesquelles vous ne vous entraîniez pas.

Cette moitié est réglée. La moitié économique ne l’est pas, et c’est le reste du chapitre.

Un cas, exécuté de trois façons : du support technique sur votre propre documentation, qui change chaque semaine.

Le corpus est réel et se trouve sur ce disque : les 23 documents Markdown qu’un dépôt logiciel en activité conserve comme documentation interne — le guide de build, les règles de marque, le brief de traduction, dix manuels de service, les notes de performance et de sécurité. Mesuré avec o200k_base, l’encodage du chapitre 7 :

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Quarante-trois mille tokens constituent une taille confortable pour cette décision : cela tient dans n’importe quelle fenêtre moderne, donc les trois routes sont réellement disponibles. À dix millions, la décision est prise pour vous, et c’est le retrieval.

Maintenant, le travail que fait le mot « hebdomadaire ». Le churn documentaire est souvent affirmé ; ici, il est compté, à partir de l’historique de versions de ce dépôt :

Les documents bougent environ une semaine sur deux. Les chaînes visibles par l’utilisateur — qui sont ce sur quoi un service support est effectivement interrogé — ont bougé chaque semaine depuis leur création, à environ vingt commits par semaine. Quelle que soit la route choisie, elle doit survivre à cela, et « à quelle fréquence ce sur quoi vous avez entraîné change-t-il ? » s’avère avoir un nombre dans votre propre dépôt plutôt qu’une opinion.

Vingt questions support réalistes ont été écrites sur ce corpus, une par sujet, et chaque chiffre ci-dessous est calculé sur ces vingt questions.

La chose la plus simple qui fonctionne : mettre tout le corpus dans le system prompt, la question à la fin, et laisser le modèle la trouver.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Chaque nombre a été compté sauf le dernier : 150 output tokens est une hypothèse, choisie dans la plage des tours assistant facturés au chapitre 16. C’est le seul chiffre ici qui n’a pas été exécuté, il est appliqué de façon identique aux trois routes, et la section sur le break-even montre exactement de combien la conclusion bouge quand vous le modifiez.

Aux tarifs lus sur la page du fournisseur le 7 septembre 2026 — $1.50 par million d’input tokens, $9.00 par million d’output tokens⁶ — cela fait $0.066317 par question. Vous payez pour relire quarante-trois mille tokens afin d’en répondre treize.

La correction du chapitre 16 s’applique directement : le corpus est stable et il est au début, donc c’est un préfixe de cache parfait, et le relire coûte un dixième — $0.007864 par question, soit une réduction de 88 %. L’avertissement du chapitre 16 s’applique aussi, sous la forme que ce chapitre signalait sans la chiffrer. Ce fournisseur ne facture pas de prime d’écriture ; il facture un loyer. Un cache explicite coûte $0.000001 par token stocké par heure,⁶ donc garder 43,298 tokens au chaud coûte

que quelqu’un pose une question ou non. Cela fait $189.78 sur six mois, pour une salle vide. Divisez le loyer par l’économie par question et la condition tient en une ligne : mettre ce corpus en cache se rentabilise au-dessus de 0,74 question par heure — 546 par mois une fois la reconstruction hebdomadaire du cache comptée aussi. En dessous, la fonctionnalité que vous avez activée pour économiser de l’argent en perd.

Même route, même code, un flag, cinq fois la facture. Le chapitre 16 avait trouvé une version de ce problème causée par un timestamp au mauvais endroit ; ici, rien n’est mauvais sauf le trafic. Un cache est un pari sur le volume, et chez ce fournisseur vous le placez à l’heure.

Le retriever du chapitre 19, inchangé : découper aux limites de section avec un en-tête contextuel, indexer, placer les quatre meilleurs extraits dans le prompt. Mesuré sur les vingt questions :

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Quarante-deux fois moins de prompt tokens que la route une, à $0.002906 par question. L’index coûte $0.0070 à construire à $0.15 par million d’embedding tokens⁶ — moins que trois questions — et les mêmes $0.0070 pour le reconstruire de zéro chaque fois que la documentation change. Reconstruire tout l’index chaque semaine pendant six mois coûte dix-huit cents.

Un point mérite qu’on s’y arrête. Le retrieval détruit le prompt caching. Le préfixe stable est maintenant l’instruction système de 140 tokens ; à partir du token 141, le prompt diffère à chaque appel, parce que les extraits sont choisis par question. Et 140 tokens est inférieur à tous les minimums de cache cités au chapitre 16. Donc la route deux ne peut pas être mise en cache du tout, ce qui semble mauvais et ne l’est pas : ne pas mettre en cache 1,037 tokens coûte moins cher que mettre en cache 43,298.

C’est une règle générale à retenir : les deux grandes techniques d’économie de tokens sont mutuellement exclusives sur le même contenu, et celle qui gagne est celle qui supprime le plus de tokens. Le retrieval en supprime 97,6 %.

Entraîner sur deux cents exemples dans le style maison, puis poser des questions sans aucune documentation attachée.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

L’entraînement coûte 24,389 × 3 × $10.00 par million = $0.7317. C’est tout le coût de construction, moins qu’un café, ce qui explique exactement pourquoi tant d’équipes le paient avant de vérifier si cela aide.

Voici maintenant le piège, et c’est la raison d’être de ce chapitre. Un modèle fine-tuned ne coûte pas le même prix à exécuter que son modèle de base. La page de tarification le dit en une phrase : « pour l’inférence de modèle à partir de Gemini 3, le prix de prédiction d’un endpoint de modèle tuned sera 1,5 fois celui du modèle de base. »⁶ Pas l’entraînement. L’inférence, sur chaque token, aussi longtemps que le modèle vit.

Mettez donc cela dans une formule. Soit $p_i$ et $p_o$ les prix d’entrée et de sortie de base, $m$ le multiplicateur tuned, $L_R$ la longueur de prompt de la route que vous remplacez, $L_F$ la longueur de prompt après fine-tuning, et $O$ la longueur de la réponse. Le fine-tuning n’est moins cher par question que lorsque

Le premier terme est évident : votre nouveau prompt court, majoré. Le second ne l’est pas, et c’est là que part l’argent — la surtaxe sur la réponse, qui n’a rien à voir avec votre prompt et que l’entraînement ne peut pas raccourcir. Avec les nombres mesurés — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — le seuil est

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

À la longueur de réponse mesurée, 492 tokens — dont 450 sont la surtaxe de réponse, pas le prompt. Remplacer un prompt plus court que cela coûte plus cher par question, pour toujours, à n’importe quel volume ; et le seuil augmente linéairement avec la quantité de texte que produit votre assistant, donc un assistant qui écrit de longues réponses ne pourra jamais se fine-tune vers un token moins cher, quelle que soit la quantité de prompt supprimée.

Le même fait vu depuis l’autre bout est la phrase à retenir. Sur les $0.002088 par question de la route fine-tuned, 97,0 % correspond à la réponse. Le fine-tuning optimise les trois pour cent restants.

Quatre nombres décrivent n’importe laquelle de ces routes : ce que vous payez une fois, ce que vous payez quand la documentation change, ce que vous payez à l’heure quoi qu’il arrive, et ce que vous payez par question. Cela étend le computeCost du chapitre 16 sans le modifier.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Le modèle tuned n’est pas une grille tarifaire différente, c’est la même multipliée :

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Cette ligne mise en évidence est tout l’argument de la section précédente écrit en code : le multiplicateur tombe aussi sur output.

Six mois, avec la documentation rafraîchie chaque semaine :

Et les points de croisement, qui sont les quatre nombres dont un budget a réellement besoin :

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Lisez les deux premiers ensemble, car c’est le point du chapitre. Un corpus stationnaire rend le fine-tuning rentable en cent cinquante questions ; un corpus qui change chaque semaine déplace le même point de croisement d’un facteur vingt-sept, et rien n’a changé dans le modèle — seulement la fréquence à laquelle vous le payez à nouveau. Le coût de construction est une note de bas de page ; le coût de maintenance est la décision.

Si vous concluez maintenant qu’un service support très actif devrait faire du fine-tuning, l’arithmétique vous donne raison. C’est quand même faux, et la section suivante explique pourquoi.

La feuille de coûts a une colonne qu’elle ne peut pas calculer, donc cette section exécute le fine-tune : localement, sur un petit modèle ouvert, avec l’adaptateur écrit à la main plutôt qu’importé depuis une bibliothèque. Le chapitre 11 a construit LoRA ; le voici, sur les q_proj et v_proj des 24 couches de Qwen2.5-0.5B-Instruct au rang 8 :

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Les deux cents exemples d’entraînement viennent mécaniquement du corpus, donc ils se reproduisent : la question est un titre de section transformé en question, la réponse est le texte propre de cette section dans un style maison rigide — une ligne commençant par Short answer:, une ligne commençant par Source: avec le chemin du fichier. Le format est la forme enseignée ; le chemin est le fait. Puis deux nombres sur vingt questions tenues à part : la réponse sort-elle dans le style maison, et nomme-t-elle le fichier qui répond réellement à la question ?

Deux baselines rendent le tableau lisible, et les deux relèvent de l’insistance du chapitre 4 plutôt que d’une réflexion après coup. Dix des vingt bonnes réponses sont le même fichier, donc un modèle qui ignore la question et répond toujours CLAUDE.md obtient 10/20. Et le retriever a son propre plafond : sur ces vingt questions, ses quatre extraits contiennent le bon fichier 14 fois et le classent premier 7 fois, donc 14/20 est le maximum que tout lecteur pourrait obtenir en l’utilisant.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

La forme a été apprise, complètement et vite. De zéro à dix-neuf sur vingt, avec un adaptateur de 540,672 paramètres — 0,109 % du modèle — en cinq minutes d’entraînement sur un processeur sans carte graphique en vue.

Les faits ne l’ont pas été. Huit sur vingt n’est pas distinguable des dix obtenus en ignorant entièrement la question, et l’intervalle du chapitre 4 sur vingt échantillons le dit clairement. Ces chemins de fichiers étaient dans les données d’entraînement trois fois ; ce qui est sorti était l’habitude de terminer par une ligne Source: à l’apparence plausible. Interrogé avec la question en tête de ce chapitre, le modèle fine-tuned a répondu Short answer: 10.x . . . et cité CLAUDE.md. La bonne réponse, qui se trouve dans CLAUDE.md, est 18.17.0.

Puis la forme s’est cassée, et c’est la ligne qui justifie l’expérience. Donnez au modèle fine-tuned mille tokens d’extraits récupérés — une forme de prompt qu’il n’a jamais vue, puisque chaque prompt d’entraînement faisait vingt-huit tokens — et le style maison s’effondre de 19/20 à 1/20. Sur la question en tête de ce chapitre, il répond 18.17.0 — correctement, et sans aucun du format pour lequel il a été entraîné. Le fine-tuning n’a donc pas enseigné un format ; il a enseigné un format conditionné par les prompts du jeu d’entraînement, et le premier prompt qui avait l’air différent a emporté le format avec lui. Ce sur quoi vous faites du fine-tuning devient l’unique distribution d’entrée dans laquelle votre modèle est bon, et personne ne met cela dans la feuille de calcul.

Une dernière note sur la métrique, qui pointe directement vers le chapitre 29 : « source correcte » note ensemble la forme et le fait, ce qui explique pourquoi les deux lignes retrieval semblent mauvaises alors que les deux modèles ont trouvé le fait de cette question. Un seul nombre de bout en bout cachait trois choses — un retriever à 14/20 de recall, un reader de 0,5B et un format de citation — et choisir quoi corriger signifie les séparer avant de mesurer, pas après.

Maintenant, la colonne que les fournisseurs remplissent pour vous. Un modèle fine-tuned n’est pas un actif qui vous appartient ; c’est un bail sur le modèle de base de quelqu’un d’autre, avec une date de fin imprimée dessus. Le 7 septembre 2026, la section fine-tuning de la page de tarification d’OpenAI affichait cet avis en entier :

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁷

Le calendrier est daté au jour près : 7 mai 2026, fermé aux organisations qui n’avaient jamais fait de fine-tuning ; 2 juillet 2026, fermé à celles qui n’avaient pas exécuté d’inférence sur un modèle fine-tuned depuis soixante jours ; 6 janvier 2027, plus aucun nouveau job.⁸ La même page planifie l’arrêt des modèles fine-tuned eux-mêmes — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — le 23 octobre 2026, chacun avec un modèle de base de remplacement recommandé, une façon polie de dire : entraînez-le à nouveau.

L’autre fournisseur frontier ne vous a jamais vendu le bail. L’index de documentation d’Anthropic liste 699 pages et aucune ne porte sur le fine-tuning ; les sections de personnalisation de modèles de la page de tarification Bedrock couvrent Amazon Nova, Amazon Titan, Cohere, Meta et les modèles open-weight d’OpenAI, et aucun Claude.⁹¹⁰ Si votre architecture dépend d’un fine-tune, l’une des trois familles frontier vous est tout simplement indisponible, quel que soit le budget.

Le self-hosting remplace le bail sur un modèle par un bail sur une machine, et AWS fait cette arithmétique sur sa propre page : une unité de modèle de provisioned throughput pour un modèle personnalisé, engagement d’un mois, est « 1 unité de modèle × $21.18 × 24 heures × 31 jours = $15,757.92 » par mois.¹⁰ Louer directement le matériel est moins cher et pas gratuit — $3.99 par GPU-heure à la demande pour un H100, $1.99 en préemptible¹¹ — environ $2,900 par mois pour une carte qui doit rester allumée que quelqu’un pose une question ou non. Toute la route retrieval à dix mille questions par mois coûte $174.52 pour six mois.

C’est ici que LoRA mérite sa place, comme argument budgétaire plutôt que technique. Mesuré sur le même modèle, un adaptateur de rang 16 sur attention et les couches feed-forward fait 8,798,208 paramètres — 1,781 % du modèle, 17,6 Mo en bfloat16 — contre 0,988 Go de poids de base, et son état d’optimiseur et de gradient est de 140,77 Mo là où le full fine-tuning exige 7,90 Go, un facteur 56. La conséquence n’est pas un entraînement moins cher, mais qu’un même modèle de base chargé peut servir de nombreux adaptateurs, ce qui est la seule façon de diviser le coût fixe d’un GPU. L’entraînement managé le reflète : $0.48 par million de tokens en low-rank jusqu’à 16B contre $0.54 en full, avec un minimum de $4.00 par job.¹¹ Ce plancher est le détail. À 24,389 tokens pour trois époques, chaque réentraînement sur ce corpus facture $4.00 plutôt que les $0.04 calculés — $104 de minimums sur vingt-six exécutions hebdomadaires, pour quatre-vingt-onze cents d’arithmétique.

Deux colonnes supplémentaires qui n’apparaissent que sur la facture.

La résidence des données coûte environ dix pour cent, et deux fournisseurs convergent sur ce chiffre. OpenAI facture « une majoration de 10 % » sur les endpoints de résidence des données pour les modèles publiés le 5 mars 2026 ou après ;⁷ Vertex tarifie ses endpoints non globaux à $1.65 contre $1.50, les mêmes dix pour cent.⁶ Comparez cela aux cinquante pour cent que coûte un endpoint tuned et le folklore s’inverse : la résidence est bon marché et le fine-tuning ne l’est pas — et le fine-tuning n’est pas non plus l’option privée, puisque le corpus atteint le fournisseur dans les deux cas, une fois à l’entraînement au lieu d’une fois par appel.

Le prix le plus explicite jamais mis sur vos données figure sur la même page, qui liste deux fois un modèle fine-tuned : avec le partage de données activé, l’inférence est exactement moitié prix — $2.00 contre $4.00 en entrée, $8.00 contre $16.00 en sortie.⁷ Laisser le fournisseur conserver ce que vous avez envoyé vaut une remise de 50 %, ce qui vous dit ce que cela vaut pour lui.

La distillation — entraîner un petit modèle à vous sur les réponses d’un grand — est généralement proposée comme une sortie des deux problèmes. Chiffrez-la et ce n’en est pas une, parce que l’enseignant est le système que vous essayiez de remplacer : produire deux cents exemples d’entraînement en posant deux cents questions à la route retrieval coûte 200 × $0.002906 = $0.58, en plus des $0.73 pour s’entraîner dessus. La distillation se fait après que le pipeline de retrieval fonctionne, pour le rendre moins cher, et elle hérite de tous les faits que le retriever a mal récupérés.

L’argent est la moitié visible. L’autre arrive sous forme d’attente, avec la même cause que la facture : le modèle lit tout le prompt avant de dire un mot. Le chapitre 13 a mesuré le prefill face au decode sur un modèle que vous pouviez toucher ; voici la même mesure, une exécution, une machine, selon la longueur du prompt :

Les nombres absolus appartiennent à un modèle de 0,5B sur seize threads CPU et ne disent rien sur un modèle frontier hébergé. La forme se transfère exactement : le prefill augmente avec la longueur du prompt, et le coût par token grimpe à mesure que le terme quadratique du chapitre 9 commence à apparaître — 4.79 ms à mille tokens contre 6.04 ms à huit mille, une pénalité de 26 % pour le seul fait d’être plus long.

La conséquence pour les trois routes est directe. La route une prefill quarante-trois mille tokens par question, et un cache hit est ce qui rend cela supportable — le chapitre 16 a expliqué pourquoi : une lecture de cache remplace le travail de prefill, donc elle achète latence et argent en une seule transaction. La route deux prefill mille tokens et ajoute d’abord un aller-retour vers l’index. La route trois prefill vingt-huit tokens et n’ajoute rien, ce qui en fait mesurablement la plus rapide des trois pour répondre. Elle répond simplement à la mauvaise chose.

Trois échecs qui ressemblent à des problèmes de modèle et n’en sont pas — dix minutes ici économisent un mois plus tard :

Et l’exigence au-dessus de tout cela : cette décision ne peut pas être prise sans jeu d’évaluation, et le fournisseur qui vend le fine-tune le dit. Le guide d’OpenAI commence par « N’investissez dans le fine-tuning qu’après avoir mis en place des evals. Vous avez besoin d’un moyen fiable de déterminer si votre modèle fine-tuned est plus performant qu’un modèle de base », et ajoute que si cinquante bons exemples ne changent rien, le problème est la tâche ou le prompt, pas le volume de données.¹ Vingt questions, ce que ce chapitre a utilisé, montre un mécanisme et ne peut pas choisir un fournisseur — le chapitre 4 a mesuré pourquoi, et ce qu’il faut faire quand vingt cas sont tout ce que vous avez — les répéter, les appairer et mesurer l’écart entre les exécutions — relève du chapitre 29.

Quatre colonnes, et seule la dernière décide :

La règle qui en sort, et elle est assez courte pour être gardée : commencez par le prompt ; ajoutez le retrieval quand les faits bougent ; ne faites du fine-tuning que lorsque vous avez mesuré que ce qui vous manque encore est une forme, pas un fait — et chiffrez la réponse, pas le prompt, avant de le faire.

La version inconfortable, pour quiconque est arrivé avec sa décision déjà prise : dans le cas mesuré de ce chapitre, le fine-tuning est la route la moins chère au-dessus de quatre mille questions par mois, et sur les faits il ne parvient toujours pas à battre le fait de répondre CLAUDE.md à tout.

Tous les prix ici ont été par token, et chaque route était une façon différente d’arranger des tokens. Cela va cesser d’être vrai.

Le chapitre 21 quitte le texte. Une image entrant dans un modèle n’est pas une chaîne mais une grille de patches avec un nombre de tokens que vous n’avez pas choisi ; une minute parlée est facturée à la seconde chez un fournisseur et à l’audio token chez un autre ; la parole synthétique est vendue au caractère, la transcription à la minute, le compute brut à la GPU-seconde. La question à laquelle ce chapitre a répondu avec une seule fonction de coût — qu’est-ce qui est moins cher ? — ne peut même pas être posée tant que les unités ne correspondent pas, et aucune calculatrice sur Internet ne les normalise.

C’est aussi là que l’entraînement réapparaît : un adaptateur image avec un trigger word, et une voix clonée depuis un échantillon. Ce qui soulève la question par laquelle s’ouvre le prochain chapitre, et elle n’est pas rhétorique : si fine-tuning un modèle de langage est presque toujours le mauvais achat, pourquoi fine-tuning un modèle image est-il presque toujours le bon ?

Chaque prix, seuil et multiplicateur de ce chapitre a été lu sur la propre page du fournisseur le 7 septembre 2026 et est cité avec cette date, parce qu’ils bougeront tous. Les chiffres mesurés — comptes de tokens, tailles de chunks, tailles de retrieval, perte d’entraînement, scores, latences et comptes d’historique de versions — ont été produits sur une machine le même jour et sont reproductibles à partir du corpus décrit ci-dessus.

Les expériences locales ont utilisé Qwen/Qwen2.5-0.5B-Instruct avec greedy decoding, donc elles se reproduisent exactement ; l’adaptateur est la classe de douze lignes imprimée ci-dessus, au rang 8 sur q_proj et v_proj. Le corpus est la documentation Markdown suivie d’un dépôt logiciel en activité, hors deux journaux append-only, et son taux de changement a été compté à partir de l’historique de versions de ce dépôt.