« Entraîner un grand modèle coûte 100 millions de dollars » : il manque le dénominateur. Ce texte est daté du 2026-09-08 : on ne parie pas sur le tarif de la prochaine puce. D'abord ce que la facture contient, puis 6ND pour convertir le calcul en heures GPU, on découpe GPU, salle, électricité et Token, enfin un JSON de coût validable. Qui est le plus fort parmi les phares, voir Guerre des modèles 2026 ; une fois entraîné, il faut encore remettre l'objet à un programme, voir Qu'est-ce que le Structured Output.
En 2023, on a écrit le calcul de GPT-4 à « un peu plus de 60 millions de dollars ». En 2025, Llama 3 405B sur plus de dix mille H100 a circulé. En 2026, les phares — GPT-5.6, Claude Fable 5.1, Gemini 3.8 — ont un budget d'entraînement qui est « un projet datacenter », pas « un lot de cartes ». Deux ordres de grandeur d'écart : ce n'est pas une erreur de journaliste, c'est le périmètre. Certains ne comptent que les heures GPU du pré-entraînement réussi ; d'autres y mettent les runs ratés, le nettoyage des données, le cluster d'inférence et trois ans d'électricité.
Ce que la facture compte vraiment
On resserre les mots. Ici, « coût d'entraînement » désigne par défaut la facture de calcul et de salle d'un pré-entraînement dense mené à terme — sans l'inférence produit, sans le cluster d'évaluation en veille. Le TCO projet complet se multiplie encore par 1,3–2,0 : la même recette réussit rarement du premier coup.
| Poste | Part habituelle du TCO | Ce qu'on compte |
|---|---|---|
| Heures GPU / amortissement | 40 %–60 % | Location cloud, ou achat étalé sur 2–3 ans |
| Datacenter et réseau | 10 %–20 % | InfiniBand / NVLink, baies, construction |
| Électricité et refroidissement | 10 %–20 % | Cartes + CPU + switches × PUE × tarif |
| Données et annotation | 5 %–15 % | Nettoyage, licences, synthèse, humain |
| Personnes et runs ratés | 10 %–25 % | Recherche, ingénierie, relances, interruptions |
« 100 millions de dollars » n'est presque jamais une facture. C'est heures GPU × tarif, plus salle, électricité, données et personnes. À l'extérieur on ne publie que le calcul ; en interne on suit le TCO. Un écart du simple au double est courant.
Des paramètres et Token au calcul
Pour le pré-entraînement d'un Transformer dense, le secteur utilise l'approximation Kaplan / Chinchilla :
FLOPs d'entraînement ≈ 6 × N × D. N est le nombre de paramètres entraînables, D le nombre de Token. Forward ≈ 2ND, backward ≈ 4ND. Pour un mélange d'experts (MoE), estimez sur les paramètres activés, pas sur le total.
En heures GPU :
Heures GPU ≈ FLOPs d'entraînement ÷ (pic FLOP/s d'une carte × taux d'utilisation × 3600)
Le pic BF16 d'un H100 SXM s'écrit souvent ~990 TFLOPS. En entraînement, comm, checkpoint et pipeline de données poussent l'utilisation à 35 %–50 %. À 40 %, une carte fait ~4×1014 FLOP/s utiles. Prendre le pic de la fiche comme dénominateur rend la facture trop optimiste.
GPU : louer, acheter, utilisation
Tranches de prix qu'on peut recouper en public en 2026-09 (spot plus bas, annuel plus stable, écarts régionaux forts) :
| Accélérateur | Tarif cloud ~heure GPU | Autohébergé sur 3 ans (élec. incluse, ordre de grandeur) | Adapté à |
|---|---|---|---|
| H100 SXM | $1.5–$3.5 | $1.0–$1.8 | Classe 70B, gros clusters déjà là |
| H200 | $2.0–$4.0 | $1.3–$2.2 | Contexte plus long, batch plus gros |
| B200 / GB200 | $3.0–$6.0 | Selon l'approvisionnement, souvent au-dessus du H100 | Pré-entraînement phare 2026 |
Autohéberger n'est pas « prix de la carte ÷ heures » aussi net. Il faut encore switches, modules optiques, pièces, vacance, maintenance. Le cloud coûte une prime ; il évite d'avancer un bâtiment. Fine-tuner 8 cartes : le cloud a presque toujours raison. Tenir 2 000 cartes trois mois d'affilée : la finance commence à chiffrer l'autohébergement.
Le taux d'utilisation blesse plus que le tarif affiché. Cluster à 40 % ou à 20 % : la même recette 70B double le prix. Un learning rate raté, un checkpoint pourri, un hoquet de comm collective : ça entre dans les heures GPU, pas dans l'annexe du papier.
Datacenter : réseau, refroidissement, salle
Entraîner, ce n'est pas « beaucoup de cartes alignées ». La bande passante entre cartes décide si vous approchez 40 % d'utilisation. NVLink / NVSwitch gèrent l'intra-nœud ; InfiniBand ou un RoCE équivalent, l'inter-nœud. Réseau et modules optiques pour 10 000 H100 : souvent un reliquat sérieux du prix des cartes, pas un accessoire.
Côté salle, trois choses transforment « avoir des cartes » en « pouvoir entraîner » :
- Densité de puissance. Les vieux datacenters sont conçus pour 8–15 kW/baie. Une baie IA va souvent à 40–120 kW. Sans électricité, sans refroidissement liquide, les cartes baissent en fréquence ou tournent à vide.
- PUE. Les nouveaux campus IA sont souvent à 1,15–1,35. Un PUE 1,4 contre 1,2, c'est environ un sixième d'électricité en plus — sur un an, c'est de l'argent réel.
- Délai de construction. Poste, tours de refroidissement, foncier : plus lents que d'acheter des cartes. En 2026, ce qui bride l'entraînement phare, c'est souvent les mégawatts et le planning, pas « est-ce qu'on a l'algo ».
Donc « combien coûte l'entraînement » se reformule parfois : d'abord « avez-vous 20–80 MW de capacité », ensuite le prix des cartes.
Électricité : des watts aux dollars
Le TDP affiché d'une carte ne suffit pas. Une carte H100 fait ~700 W ; avec CPU, NIC, stockage et switches, 1,0–1,2 kW/GPU pour la puissance système est plus proche. Puis on multiplie par le PUE.
Ordre de grandeur :
Facture annuelle ≈ nombre de GPU × 1,1 kW × PUE × 8 760 × tarif
10 000 H100, PUE 1,25, $0.07/kWh : ≈ 1,1 × 1,25 × 8 760 × 0,07 × 10 000 ≈ 8,4 millions de dollars / an. À $0.12, on est à 14 millions. Et ce n'est pas encore le cluster d'inférence hors entraînement.
L'électricité est rarement le « plus gros poste », mais elle décide si le cluster peut tirer 24×7. Coupures, demand response, capacité d'été : ça pousse l'utilisation vers le bas. Le tarif horaire GPU n'a pas bougé ; la recette, elle, a renchéri.
Quatre échelles : 7B / 70B / 405B / phare
Ci-dessous : H100, 40 % d'utilisation, cloud $2.5 / heure GPU, pour le calcul du pré-entraînement réussi. Le TCO se multiplie encore par 1,4–2,0. Ce sont des ordres de grandeur 2026-09, pas un devis.
| Échelle | Token typiques | ~heures GPU | Calcul ($2.5) | Ordre de grandeur TCO projet |
|---|---|---|---|---|
| 7B dense | 2T | ~60 000 | ~$150 000 | $300 000–$1,5 M |
| 70B dense | 15T | ~4,4 M | ~$11 M | $20–40 M |
| Classe 405B | 15T+ | Dizaines de millions | $30–80 M | $80 M–$200 M |
| Phare 2026 | Non publié | Dizaines de milliers de cartes × plusieurs mois | Souvent >$100 M | $200 M–$1 Md+ |
La ligne 7B, beaucoup d'équipes la finissent dans le cloud : ce qui coûte, c'est les données et les personnes, pas les cartes. 70B, c'est déjà « il faut un planning de cluster dédié ». 405B et phare : capex. Poste électrique, achats pluriannuels, budget de runs ratés dans le dossier conseil. Comment découper les gammes, voir Choisir un modèle par tâche — l'immense majorité des produits doit acheter l'API, pas recopier cette ligne.
Token : un entraînement, une inférence qui brûle
Le Token apparaît des deux côtés, le tarif unitaire n'a rien à voir.
- Token d'entraînement : entrée de la recette. 70B × 15T, ~$11 millions de calcul, soit environ $0.7–$3 par million de Token d'entraînement (heures GPU seules). Données et personnes poussent plus haut.
- Token d'inférence : sortie produit. En 2026, l'API phare va souvent de quelques dizaines de cents à une quinzaine de dollars par million de Token, selon le modèle et le cache. L'inférence autohébergée, si l'utilisation est haute, peut descendre plus bas — après avoir payé le cluster.
100 millions de Token / jour à $3 / million : ~$90 000 par mois ; en trois mois on approche un « pré-entraînement 7B réussi ». Un milliard / jour : en quelques mois on dépasse un pré-entraînement 70B. Donc à l'extérieur on dit « l'entraînement coûte 100 millions » ; en interne, la finance regarde si la courbe d'inférence a dépassé le pic d'entraînement.
Le retry est un multiplicateur caché. Le prompt demande du JSON, le modèle l'enveloppe de markdown, vous rappelez : facture ×2. Dans une boucle Agent, un paramètre d'outil qui dérive : le saut suivant est mort. C'est pourquoi le contrat entre dans le décodeur, pas dans le system prompt — détail dans Structured Output et Pourquoi l'IA aime le JSON.
Pour les développeurs : pas le phare, les retry
Entraîner soi-même un pré-entraînement 70B+, pour 99 % des équipes, c'est le mauvais problème. En 2026, trois comptes plus petits :
- Combien de Token par appel. System prompt, blocs de retrieval, retours d'outils : tout entre dans le tarif d'entrée. Ce qui se valide en local, ne le renvoyez pas au modèle.
- Taux de retry sur échec. Parse raté, champ manquant, enum qui s'envole : c'est le « on a l'air de travailler » le plus cher. Schema passé, ensuite écriture en base.
- On change de modèle, pas de champs. Routez vers un Flash / mini moins cher ; le contrat reste le même JSON. Choisir un modèle : Guerre des modèles 2026.
Fine-tuning, distillation, poursuite de pré-entraînement : un autre étage. Souvent quelques centaines à quelques dizaines de milliers d'heures GPU, facture cloud à 4–6 chiffres. La recette, écrivez-la d'abord en objet : base_model, gpu_hours, usd, eval_pass_rate — pour pouvoir faire un Diff avec le tour suivant.
Une facture découpée
Voici un objet d'illustration : « 70B dense, 15T Token, H100, cloud $2.5 ». Ce n'est pas un devis ; c'est le contrat de champs. Montants en number, énumérations en chaînes, runs ratés inclus en boolean.
{
"run_id": "pretrain-70b-20260908-01",
"model_class": "dense-70b",
"tokens_trained": 15000000000000,
"gpu": "H100-SXM",
"utilization": 0.4,
"gpu_hours": 4420000,
"gpu_usd_per_hour": 2.5,
"compute_usd": 11050000,
"power_usd": 1800000,
"datacenter_usd": 4200000,
"data_usd": 2500000,
"staff_usd": 6000000,
"includes_failed_runs": true,
"retries_factor": 1.4,
"total_usd": 35770000,
"cost_per_million_train_tokens_usd": 2.38,
"currency": "USD"
}
Selon les règles d'inférence actuelles du site, cet échantillon donne :
| Champ | Type inféré | À faire après génération |
|---|---|---|
model_class / gpu / currency |
string | Refermer en enum, ne pas laisser de texte libre |
tokens_trained / gpu_hours / *_usd |
number | Ne pas écrire "11050000" ; un seul currency pour tous les montants |
utilization / retries_factor |
number | Ajouter une borne, éviter d'écrire 1.4 en "1.4x" |
includes_failed_runs |
boolean | Doit être true / false : ça décide si le périmètre se compare |
Deux runs se comparent si les champs de périmètre sont là. Sans includes_failed_runs, le Diff dit seulement que le total a dérivé — pas si vous avez relancé des runs ratés, ou si le tarif élec. a bougé. La Comparaison JSON de ce site lit un objet, pas deux morceaux de prose.
Recetter dans la Boîte à outils JSON
- Collez l'échantillon ci-dessus dans le formatage JSON, pour confirmer que ça parse.
- Générez le brouillon avec Structured Output ou JSON → Schema.
- Passez un second jeu de runs réels dans la validation Schema. Le premier échantillon est toujours trop propre.
- Deux tours d'entraînement / deux factures cloud : Comparaison JSON, pour voir si les heures GPU ont dérivé, ou si un champ de périmètre a disparu.
- Tableau pour un humain : tableau JSON ; validation front : Zod.
Tout se traite dans le navigateur, rien n'est envoyé au serveur.
FAQ
Combien coûte vraiment l'entraînement d'un grand modèle ?
Ça dépend de l'échelle. Un 7B se situe souvent entre quelques centaines de milliers et 1–2 millions de dollars ; un 70B, 20–40 millions ; un 405B, autour de 100 millions ; un cycle phare 2026 atteint souvent 200 millions à 1 milliard. Un seul chiffre n'a pas de sens.
Le plus gros poste de la facture, c'est le GPU ?
Les heures de calcul sont en général le plus gros poste. Le TCO complet ajoute encore électricité, refroidissement, réseau, salle, données et personnes. Seule, l'électricité pèse souvent 10 %–20 %, mais elle décide si le cluster peut tirer à fond.
C'est l'entraînement qui coûte cher, ou l'inférence ?
L'entraînement est un pic unique. Quand le produit atteint des centaines de millions de Token par jour, l'inférence dépasse en quelques mois un pré-entraînement 70B. Les développeurs tiennent d'abord les Token et les retry.
Comment estimer le nombre d'heures GPU nécessaires ?
Pour un Transformer dense : 6 × paramètres × nombre de Token pour les FLOPs, puis on divise par le pic d'une carte et le taux d'utilisation. Comptez 35 %–50 %, pas le pic de la fiche.
Comment un développeur récupère-t-il du coût de calcul sur la facture ?
Moins de retry. Structured Output et le Schema bloquent « on rappelle le modèle ». Le contrat se pose en JSON, pas dans le prompt.
En résumé
Le coût d'entraînement n'est pas un chiffre-slogan. C'est des heures GPU calculées par 6ND, multipliées par le tarif des cartes, plus salle, électricité, données et runs ratés. Un 7B se fait dans le cloud ; un 70B, c'est un cluster dédié ; 405B et phare 2026, c'est du capex. Pour la plupart des développeurs, ce qui coûte plus cher, ce sont les Token d'inférence et les retry après un parse raté. Rangez chaque entraînement, chaque fine-tuning, chaque facture cloud dans le même objet : champs, types, obligatoires, interrupteur de périmètre. Montants en number, énumérations refermées, includes_failed_runs forcément booléen. La forme juste, on compare deux runs — pas deux phrases qui disent « c'est cher ».