Accueil › Glossaire › Compute-Optimal

Compute-Optimal (Optimisation du Compute)

Un modèle d’IA « compute-optimal » est un modèle dont la taille (paramètres) et le volume de données d’entraînement (tokens) sont calibrés pour tirer le maximum de performance d’un budget de calcul (FLOPs) donné. Le concept a été formalisé par le papier Chinchilla (DeepMind, 2022), qui a montré que la plupart des grands modèles étaient sous-optimaux : trop gros pour la quantité de données utilisée.

Le concept en pratique

Entraîner un LLM est un exercice d’allocation de ressources. Vous disposez d’un budget de compute (mesuré en FLOPs) déterminé par le nombre de GPU, la durée d’utilisation et le prix du cloud. Avec ce budget, vous devez choisir deux choses : la taille de votre modèle (N paramètres) et le volume de données d’entraînement (D tokens). Le choix « compute-optimal » est celui qui produit la meilleure performance (la loss la plus basse) pour votre budget fixe.

La relation fondamentale est simple :

C ≈ 6 × N × D

Chaque paramètre coûte environ 6 FLOPs par token d’entraînement (forward pass + backward pass). Pour un budget C fixe, augmenter N (taille du modèle) force à réduire D (volume de données), et inversement. Le point compute-optimal est le couple (N, D) qui minimise la loss pour C donné.

Avant Chinchilla : la taille comme priorité

Les scaling laws de Kaplan (OpenAI, 2020) suggéraient de privilégier la taille du modèle. Le ratio implicite était d’environ 1,7 tokens par paramètre. GPT-3 (175B paramètres, 300B tokens) suivait cette prescription. Le résultat : des modèles énormes mais « sous-alimentés » en données.

Chinchilla : l’équilibre taille-données

Le papier Chinchilla de DeepMind (2022) a renversé cette conclusion. En entraînant plus de 400 modèles de tailles variées, DeepMind a montré que le point compute-optimal nécessite un ratio d’environ 20 tokens par paramètre. Un modèle de 70B entraîné sur 1,4T tokens (ratio 20:1) surpasse un modèle de 280B entraîné sur 300B tokens (ratio ~1:1), pour le même budget de calcul.

Ce résultat a eu un impact considérable. Il a démontré que les modèles les plus performants de l’époque (GPT-3, Gopher, Megatron-Turing NLG) étaient tous sous-entraînés : trop de paramètres, pas assez de données.

Trois définitions de « compute-optimal » en 2026

Le terme « compute-optimal » a évolué depuis Chinchilla. Trois interprétations coexistent, chacune optimisant un critère différent.

1. Training-compute-optimal (Chinchilla, 2022)

C’est la définition originale. On minimise la loss pour un budget d’entraînement fixe. Le ratio optimal est ~20 tokens/paramètre. C’est le choix qui minimise le coût d’entraînement pour atteindre un niveau de performance donné.

Quand c’est pertinent : pour un modèle de recherche qui ne sera pas massivement déployé. Le coût d’inférence est négligeable par rapport au coût d’entraînement.

2. Inference-aware-optimal (Sardana et al., 2023)

Sardana et al. (MosaicML) ont étendu le cadre Chinchilla en intégrant le coût d’inférence. Au lieu de minimiser le compute d’entraînement seul, on minimise le coût total (entraînement + inférence sur toute la durée de vie du modèle). Le résultat : le ratio tokens/paramètre optimal augmente considérablement. Plus vous anticipez de requêtes en inférence, plus il est rentable d’entraîner un modèle plus petit sur plus de données.

Quand c’est pertinent : pour tout modèle déployé en production à grande échelle (chatbot, assistant, API). C’est l’approche dominante en 2026.

3. Test-time-compute-optimal (Snell et al., 2024)

La définition la plus récente. Au lieu de n’optimiser que le pre-training, on intègre le compute utilisé au moment de l’inférence elle-même (test-time compute). Les modèles de raisonnement comme o3 d’OpenAI ou le mode Extended Thinking de Claude « réfléchissent » plus longtemps sur les problèmes difficiles, en générant des tokens de raisonnement intermédiaires avant de produire la réponse.

La découverte clé de Snell et al. : pour les questions faciles et intermédiaires, augmenter le compute d’inférence d’un petit modèle peut être plus efficace que d’utiliser un modèle 14 fois plus grand. Autrement dit, un modèle de 7B qui « réfléchit » plus longtemps peut battre un modèle de 70B qui répond du tac au tac.

Quand c’est pertinent : pour les tâches de raisonnement complexe (mathématiques, code, planification) où la qualité de la réponse importe plus que la latence.

Le « Chinchilla Trap » expliqué

Le terme « Chinchilla Trap » désigne le piège de suivre aveuglément le ratio Chinchilla de 20:1. On obtient un modèle qui minimise le coût d’entraînement, mais qui est souvent trop gros pour être déployé économiquement.

Exemple concret : avec un budget de 10²⁴ FLOPs, le ratio Chinchilla prescrit un modèle d’environ 70B paramètres entraîné sur ~1,4T tokens. Ce modèle de 70B coûte ~$0,10-0,20 par million de tokens en inférence. Si vous servez 100 millions de requêtes (à 1 000 tokens par requête), le coût d’inférence atteint $10 000-20 000 par jour. Un modèle de 8B entraîné sur 15T tokens (le choix Llama 3) aurait un coût d’inférence ~10 fois inférieur, pour une performance légèrement inférieure mais souvent suffisante.

C’est pourquoi Meta a explicitement déclaré entraîner ses modèles Llama « au-delà de Chinchilla-optimal ». Mark Zuckerberg a noté que même à 15T tokens pour un modèle de 8B, la courbe de loss continuait de diminuer : le modèle n’avait pas encore atteint son asymptote.

La « Densing Law » : l’efficacité croissante

Un résultat publié dans Nature Machine Intelligence (Xiao et al., 2025) introduit le concept de « capability density » (densité de capacité) : la performance par paramètre. L’observation empirique, appelée « densing law », montre que la densité de capacité maximale des modèles open source double environ tous les 3,5 mois.

Concrètement, cela signifie que le nombre de paramètres nécessaires pour atteindre un niveau de performance donné diminue de façon exponentielle au fil du temps. Un modèle de 4B paramètres en 2025 (Gemma 3 4B) offre des performances comparables à un modèle de 27B de 2024 (Gemma 2 27B). Le point « compute-optimal » se déplace constamment vers des modèles plus petits et plus efficaces.

Les facteurs qui alimentent cette tendance incluent les progrès en architecture (MoE, attention clairsemée), en qualité de données (curation, données synthétiques), en techniques d’entraînement (distillation, RLHF), et en optimisation de l’inférence (quantization, FlashAttention).

Implications pratiques pour le choix de modèle

Pour les chercheurs

Le cadre Chinchilla reste l’outil de planification de référence. Si vous lancez un entraînement from scratch et que l’inférence n’est pas un facteur (modèle de recherche, peu de requêtes), visez un ratio de ~20 tokens/paramètre comme point de départ. Ajustez ensuite en fonction de vos courbes de loss expérimentales.

Pour les entreprises déployant en production

Utilisez le cadre inference-aware. Estimez votre volume d’inférence attendu (requêtes/jour × tokens/requête × durée de vie du modèle). Plus ce volume est élevé, plus vous devriez pencher vers un modèle plus petit entraîné sur plus de données. En pratique, cela signifie souvent choisir un modèle open weights existant (Llama 3.3 70B, Mistral Small 4, Gemma 3 27B) plutôt que d’entraîner le vôtre.

Pour les équipes ML avec des cas d’usage spécifiques

Le test-time compute scaling offre une alternative : plutôt que d’utiliser un modèle frontier coûteux, utilisez un modèle plus petit avec une stratégie d’inférence avancée (majority voting, tree search, chain-of-thought étendu). Un modèle de 7B avec une stratégie de recherche peut surpasser un modèle de 70B en greedy decoding sur des tâches de raisonnement, pour un coût total inférieur.

Compute-optimal en pratique : le routage multi-modèle

L’approche la plus sophistiquée en 2026 combine les trois définitions. Les équipes les plus avancées déploient un routeur qui dirige chaque requête vers le modèle le plus adapté :

• Requêtes simples (classification, extraction) : modèle compact (4B-8B), inférence rapide et peu coûteuse
• Requêtes intermédiaires (rédaction, résumé, Q&A) : modèle moyen (27B-70B), bon rapport qualité/coût
• Requêtes complexes (raisonnement multi-étapes, agents, code complexe) : modèle frontier via API (Claude Opus 4.6, GPT-5.4) ou modèle moyen avec test-time compute étendu

Ce routage est lui-même une forme d’optimisation compute : allouer le bon volume de calcul à chaque requête en fonction de sa difficulté estimée. C’est l’extension logique du concept compute-optimal, appliquée non plus à l’entraînement mais à l’ensemble du cycle de vie du modèle.

Historique et évolution du concept

Le concept d’optimisation du compute dans l’entraînement des modèles d’IA a traversé plusieurs phases distinctes :

Phase 1 : Scaling brut (2018-2021). Inspirée par les résultats de Kaplan et al., l’industrie empile les paramètres. GPT-2 (1,5B), GPT-3 (175B), Gopher (280B), Megatron-Turing NLG (530B). Le ratio tokens/paramètre reste bas (~1-2). Le modèle le plus gros gagne. Le compute est alloué principalement à la taille du modèle.

Phase 2 : Chinchilla-optimal (2022-2023). DeepMind démontre que l’équilibre taille-données est crucial. Le ratio optimal passe à ~20 tokens/paramètre. Les modèles comme LaMDA et PaLM de Google intègrent ces enseignements. Le paradigme change : « entraîner mieux » plutôt que « entraîner plus gros ».

Phase 3 : Inference-aware scaling (2023-2025). Meta, avec Llama, pousse le ratio à 100-1 800+ tokens/paramètre. Sardana et al. formalisent l’intégration du coût d’inférence dans l’optimisation. Le paradigme devient « entraîner le plus petit modèle qui résout le problème avec la qualité requise ». DeepSeek démontre qu’on peut atteindre des performances frontier avec un budget d’entraînement de ~5,6M$ grâce à l’efficacité architecturale (MoE) et la qualité des données.

Phase 4 : Multi-axis scaling (2025-2026). Trois axes de scaling coexistent : pre-training (taille + données), post-training (RLHF, distillation, DPO), et test-time compute (raisonnement étendu, search algorithms). Le concept de « compute-optimal » englobe désormais l’allocation du compute sur ces trois axes simultanément. Les modèles de raisonnement (o3, Extended Thinking de Claude) illustrent cette troisième dimension : allouer dynamiquement plus de compute au moment de la réponse pour les questions difficiles.

La « densing law » (Xiao et al., Nature Machine Intelligence, 2025) formalise le résultat de ces évolutions : la performance par paramètre double tous les 3,5 mois. Chaque génération de modèles fait mieux avec moins, grâce aux progrès simultanés en architecture, en données et en techniques d’entraînement.

Compute-optimal vs cost-optimal : une distinction importante

Le compute-optimal au sens strict minimise les FLOPs pour un niveau de performance. Le « cost-optimal » minimise le coût financier total, qui intègre des facteurs supplémentaires :

• Le prix des GPU/TPU (qui varie selon la génération : H100 vs H200 vs B200)
• L’utilisation des GPU (taux d’occupation, parallélisme, efficacité du code d’entraînement)
• Le coût de l’énergie (qui varie selon la localisation du datacenter)
• Le coût d’ingénierie (équipe ML, infrastructure DevOps)
• Le coût d’inférence sur la durée de vie du modèle

DeepSeek V3 est un exemple frappant de modèle « cost-optimal » : son architecture MoE, son utilisation efficace du matériel, et son pipeline d’entraînement optimisé lui permettent d’atteindre des performances frontier pour environ 5,6 millions de dollars, soit 10 à 100 fois moins que les estimations pour des modèles comparables. Le compute-optimal est un guide théorique, mais le cost-optimal est ce qui compte en pratique pour les équipes qui déploient de l’IA.

Verdict

Le concept de « compute-optimal » a évolué considérablement depuis Chinchilla. La définition originale (minimiser le compute d’entraînement) reste valide mais ne couvre qu’une partie du problème. Les praticiens de 2026 optimisent le coût total (entraînement + inférence + test-time compute) et non le seul coût d’entraînement.

Le message pratique est simple : ne suivez pas le ratio Chinchilla de 20:1 comme une règle absolue. Si vous déployez en production, entraînez un modèle plus petit sur plus de données. Si vous avez besoin de raisonnement complexe, investissez dans le test-time compute plutôt que dans un modèle plus gros. Et si vous n’entraînez pas votre propre modèle (ce qui est le cas de la majorité des utilisateurs), choisissez parmi les modèles existants celui qui offre le meilleur rapport performance/coût d’inférence pour votre cas d’usage. C’est la version la plus pragmatique de l’optimisation du compute.