15 minutes. Objectif : donner du contexte sur ce qu'est un LLM, comment ça marche, et pourquoi tout ceci se traduit en besoins de calcul très importants.

Télévision, téléphone, scanner, voiture, avion. Et nous, avec l'IA, on aurait probablement fini sur un bûcher.

Animation pas à pas (6 clics). Les probabilités sont illustratives. Départ : le modèle reçoit une séquence, « Paris est la capitale de ». Clic 1 : il calcule la probabilité de chaque mot du vocabulaire (100 000 mots), **conditionnée** à tous les mots précédents, dans l'ordre exact où ils apparaissent. Clic 2 : on choisit le plus probable : « la ». Clic 3 : on l'ajoute à la fin de la séquence. Clic 4 : et on recommence, avec une séquence plus longue : le contexte a changé, la distribution aussi. « France » écrase tout. Clic 5 : on choisit « France ». Clic 6 : on l'ajoute. Et on recommence, ad nauseam. Insister sur « conditionnée » : c'est tout le sujet. Le modèle ne voit qu'une séquence et prédit la suite.

L'espace des textes possibles est colossal, et pourtant le modèle calcule une probabilité pour chaque mot, à chaque étape. Ces chiffres permettent de prendre la mesure de ce que fait un LLM: il calcule la probabilité de chaque séquence, parmi toutes les séquences possibles sur la base des séquences VUES pendant l'entraînement

C'est le pivot de la présentation : les probabilités conditionnelles, en pratique, c'est une fonction avec énormément de paramètres. Taille du modèle × nombre de mots = la facture. notion de parametres actifs.

Animation pas à pas (10 clics). Clics 1–3 : le modèle. 2 800 milliards de paramètres, stockés sur 4 bits (un demi-octet) : 1,4 To de poids. En FP8 (2,8 To), il ne tiendrait pas dans les 8 × 288 Go = 2,3 To des 8×B300. Clic 4 : le matériel. Ce qui compte n'est pas la puissance de calcul mais la bande passante mémoire : 8 × 8 To/s ≈ 64 To/s. Clic 5 : pour produire un mot, il faut relire tous les poids : 64 / 1,4 ≈ 45 lectures par seconde, donc ~45 mots/s pour chaque utilisateur. (Avec un seul utilisateur, seuls les 50 Md de paramètres actifs seraient lus ; avec 200 utilisateurs en parallèle, presque tous les experts servent.) Clic 6–7 : une lecture des poids sert tous les utilisateurs du lot : 200 × 45 ≈ 9 000 mots/s. La limite : la mémoire restante (~0,9 To) pour le contexte de chaque conversation → quelques centaines d'utilisateurs. Référence : DeepSeek a publié ~15 000 tokens/s par machine de 8 GPU, ~20 tokens/s par utilisateur. Clic 8–9 : on loue la machine à l'heure, qu'elle travaille ou non : 48 €/h ÷ 32 millions de mots/h ≈ 1,5 € par million de mots. Seul, le même utilisateur paierait ~300 € par million de mots. Clic 10 : cohérent avec les prix des API. Pourquoi pas les FLOPs : 10¹¹ opérations par mot, la machine plafonnerait vers 400 000 mots/s. On en est loin : c'est la mémoire qui limite.

Animation pas à pas (11 clics). Clics 1–4 : le calcul. Mixture of experts : pour chaque mot, seuls 50 milliards des 2 800 milliards de paramètres sont utilisés. Le coût de calcul dépend des paramètres actifs ; la mémoire, elle, dépend du total. Règle classique : ~6 opérations par paramètre actif et par mot (2 pour la passe avant, 4 pour la rétropropagation). 6 × 50·10⁹ × 16·10¹² ≈ 4,8·10²⁴ ≈ 5·10²⁴ opérations. (On néglige l'attention : +5 à 20 % selon la longueur de contexte.) Clics 5–7 : la machine. Un B300 fait ~5 PFLOPS en FP8 sur le papier, mais on n'atteint jamais la crête : le MFU (model FLOPs utilization) mesure la fraction réellement utile. Pour un MoE, les échanges entre GPU (all-to-all) et le déséquilibre entre experts le font chuter : DeepSeek-V3 a mesuré ~17 % de la crête FP8 de ses H800. On prend 20 %. Clic 8 : 5·10²⁴ / 10¹⁵ ≈ 4,8·10⁹ s ≈ 150 ans sur un seul GPU, soit ~1,3 million de GPU·h. Clics 9–10 : 1,3 M GPU·h × 6 € ≈ 8 M€. Clic 11 : en pratique, 1 000 B300 pendant ~8 semaines. C'est le coût d'un seul entraînement réussi : un plancher. Il faut ajouter les essais ratés, les expériences, les salaires, et l'accès à un cluster de milliers de GPU.

Même calcul que pour Kimi K3, en orange ce qui change. Modèle dense de 1 milliard de paramètres : tous actifs. ~2 000 mots par paramètre (bien au-delà de l'optimum « Chinchilla » de ~20, mais un petit modèle gagne à être sur-entraîné) : 2 000 milliards de mots. 6 × 10⁹ × 2·10¹² ≈ 1,2·10²² opérations, 400 fois moins que K3. MFU 40 % : un modèle dense n'a pas les échanges entre GPU d'un MoE, il exploite bien mieux la machine. 1,2·10²² / 2·10¹⁵ = 6·10⁶ s ≈ 70 jours ≈ 1 700 GPU·h ≈ 10 k€. Qui a besoin d'un modèle capable - de lire du chinois - et de générer un rapport financier - et de déboguer du COBOL ? Le vrai enjeu : comprendre ses données, son domaine — juridique, médical... Entraîner soi-même permet d'adapter le vocabulaire (tokenizer) au domaine.

Même calcul, en orange ce qui change par rapport au SLM. On part d'un modèle déjà entraîné (30 milliards de paramètres, dense) et on continue l'entraînement sur son propre corpus : ~1,5 milliard de mots, mille fois moins qu'un entraînement complet. 6 × 30·10⁹ × 1,5·10⁹ ≈ 2,7·10²⁰ opérations. MFU 40 % comme pour le SLM : modèle dense. 2,7·10²⁰ / 2·10¹⁵ ≈ 1,35·10⁵ s ≈ 37 h ≈ 225 €, soit 200 à 300 €. Le coût suit le nombre de mots : c'est l'entraînement initial qui coûte cher, l'adaptation est presque gratuite.

La slide à retenir. Un seul entraînement d'un modèle frontière, c'est « seulement » quelques M€ de calcul. Le vrai verrou est ailleurs : les essais ratés, les données, une équipe de ~80 personnes pendant plusieurs années, et l'accès à un cluster de milliers de GPU. Un petit modèle, c'est la version sur laquelle un labo peut itérer.