Test-Time Compute vs Pre-Training : la fin des grands modèles ?

Depuis deux ans, une idée revient souvent dans la recherche IA : et si le vrai levier de progrès n’était plus seulement d’entraîner des modèles toujours plus gros, mais de leur donner plus de calcul au moment où ils répondent ? Cette approche porte un nom un peu technique, mais central : le test-time compute, aussi appelé inference-time scaling.

La question derrière ce débat est simple : faut-il encore investir massivement dans le pré-entraînement de modèles géants, ou peut-on obtenir une partie des gains en laissant le modèle “réfléchir” plus longtemps au moment de l’usage ?

TLDR : le pré-entraînement est encore nécessaire. Mais oui, le centre de gravité a commencé à bouger. Et ce déplacement change déjà la manière de concevoir les produits IA, les coûts d’infrastructure et même la concurrence entre acteurs.

Pre-training : le moteur historique des grands modèles

Pendant longtemps, la recette dominante a été la même : prendre plus de données, plus de paramètres, plus de calcul d’entraînement, et observer une amélioration régulière des performances. Les fameuses scaling laws ont largement validé cette intuition. Le papier Chinchilla de DeepMind a notamment montré qu’à budget de calcul donné, beaucoup de modèles étaient surtout sous-entraînés, et qu’il fallait mieux équilibrer taille du modèle et volume de données.

Concrètement, le pré-entraînement consiste à exposer un modèle à une immense quantité de texte, de code ou d’autres données pour qu’il apprenne les régularités du monde. C’est cette phase qui construit sa base de connaissances, ses intuitions statistiques, sa grammaire interne et une partie de ses capacités générales.

Sans ce socle, un modèle ne peut pas raisonner correctement sur des concepts qu’il n’a jamais appris à représenter. Le pré-entraînement reste donc la couche fondatrice.

Test-time compute : faire travailler le modèle au moment de répondre

Le test-time compute repose sur une idée différente : au lieu d’améliorer seulement le cerveau du modèle avant sa mise en production, on lui donne davantage de ressources pendant la résolution d’un problème.

Cela peut prendre plusieurs formes :

• générer plusieurs pistes de réponse au lieu d’une seule,
• décomposer un problème en étapes intermédiaires,
• vérifier des solutions candidates,
• revenir en arrière si un chemin paraît mauvais,
• allouer plus de tokens ou plus d’effort de raisonnement à certaines requêtes.

Autrement dit, on ne demande plus seulement au modèle de répondre vite. On lui demande parfois de chercher, tester, comparer et corriger avant de produire une réponse finale.

C’est précisément ce qui a rendu visibles les nouveaux modèles dits de “reasoning”, comme OpenAI o1, présenté en septembre 2024 comme une famille de modèles conçus pour “passer plus de temps à réfléchir avant de répondre”. DeepSeek a aussi popularisé cette direction avec DeepSeek-R1, annoncé en janvier 2025 puis amélioré en mai 2025.

Pourquoi cette approche séduit autant

La raison principale est économique autant que technique.

Pré-entraîner un très grand modèle coûte cher. Une fois qu’un acteur a déjà atteint une grande taille, chaque gain marginal demande souvent des budgets de calcul et de données de plus en plus lourds. Le test-time compute propose une autre courbe : faire mieux à l’usage, requête par requête, sans forcément reconstruire un modèle géant depuis zéro.

Des travaux de 2024 ont d’ailleurs montré qu’avec un certain budget d’inférence, augmenter intelligemment le calcul au moment de l’exécution peut être, sur certaines tâches difficiles, plus efficace qu’augmenter la taille du modèle. C’est un résultat important, car il ne dit pas que les grands modèles sont inutiles. Il dit que le compromis optimal entre entraînement et inférence est en train de changer.

Pour les entreprises, la promesse est forte : au lieu d’avoir un modèle énorme qui coûte cher pour tout le monde, on peut imaginer un système qui réserve son effort maximal uniquement aux requêtes complexes.

Ce que le grand public peut retenir

On peut résumer la différence ainsi :

Le pré-entraînement apprend au modèle à connaître le monde.

Le test-time compute l’aide à mieux s’organiser pour résoudre un problème donné.

Le premier construit les capacités générales. Le second améliore l’exploitation de ces capacités dans des cas exigeants.

Une analogie simple : le pré-entraînement, c’est les années d’études. Le test-time compute, c’est le temps qu’on vous laisse à l’examen, avec le droit d’écrire un brouillon, vérifier et recommencer. Un étudiant bien formé reste avantagé. Mais à niveau proche, celui qui a le temps de réfléchir peut produire une bien meilleure copie.

Est-ce la fin des grands modèles ?

Le titre est tentant, mais la réponse est non.

D’abord parce que le test-time compute ne remplace pas les connaissances apprises pendant l’entraînement. Un modèle peu compétent au départ ne devient pas excellent juste parce qu’on lui laisse plus de temps. Il peut explorer davantage, mais il explore avec les outils qu’il possède déjà.

Ensuite, parce que beaucoup de techniques de test-time compute fonctionnent mieux quand le modèle de base est déjà solide. Les gains à l’inférence s’appuient souvent sur une bonne capacité à générer des étapes utiles, à s’auto-évaluer ou à produire plusieurs solutions plausibles.

Enfin parce que les meilleurs résultats récents viennent rarement d’un seul levier. En pratique, les progrès combinent souvent :

• un bon pré-entraînement,
• du post-training,
• du reinforcement learning,
• et une allocation plus intelligente du calcul à l’inférence.

Le vrai changement n’est donc pas la disparition des grands modèles. C’est la fin d’une croyance plus simple : “plus gros à l’entraînement” ne suffit plus à expliquer seul les meilleurs progrès visibles.

Le vrai sujet : où mettre le budget de calcul

La question centrale devient presque une question de stratégie industrielle.

Vaut-il mieux dépenser son budget :

• en pré-entraînement pour améliorer le niveau de base de tout le modèle,
• ou en inférence pour rendre certaines requêtes nettement plus performantes ?

La réponse dépend beaucoup du produit.

Pour un assistant généraliste grand public, la latence et le coût par requête comptent énormément. On ne peut pas faire “réfléchir” chaque demande pendant trente secondes. Pour des usages plus rares mais critiques, comme le code, les maths, l’analyse documentaire ou certains workflows métier, accepter plus de calcul à l’inférence peut être rationnel si cela augmente fortement la fiabilité.

Autrement dit, le marché pourrait se segmenter davantage :

• des modèles rapides et peu coûteux pour les tâches courantes,
• des modèles de raisonnement plus lents et plus chers pour les tâches complexes.

Une conséquence importante pour les produits IA

Avant, beaucoup de produits IA misaient sur le choix du “meilleur modèle”. Demain, l’avantage compétitif viendra aussi de l’orchestration :

• quand déclencher un mode de raisonnement plus coûteux,
• combien de tentatives générer,
• comment vérifier une réponse,
• quand utiliser un modèle plus petit,
• quand escalader vers un modèle plus fort.

Les limites du test-time compute

Le test-time compute a quand même plusieurs coûts concrets :

• plus de latence,
• plus de coût par requête,
• plus de complexité d’orchestration,
• et parfois plus d’instabilité, car générer plusieurs chemins peut aussi multiplier les erreurs si la vérification est mauvaise.

Il n’est pas non plus utile partout. Les gains sont souvent particulièrement visibles sur les tâches à raisonnement explicite, comme les mathématiques, le code ou certains problèmes structurés. Sur des tâches simples, très courantes ou très sensibles à la rapidité, l’intérêt est plus faible.

Conclusion

C’est sans doute la fin d’une époque où l’on pouvait résumer les avancées de l’IA par une seule phrase : “on a entraîné un modèle plus gros”. Les modèles géants restent essentiels, mais ils ne suffisent plus. Ce qui compte maintenant, c’est l’équilibre entre ce que le modèle a appris avant et la quantité de calcul qu’on accepte de lui donner pendant qu’il travaille.

Pour les entreprises comme pour les équipes produit, la vraie question n’est donc pas “grand modèle ou pas”. La question est : où placer intelligemment le calcul pour obtenir le meilleur niveau de qualité, au bon coût, avec la bonne expérience utilisateur ?