Ce qui détermine vraiment le taux de rendement du compute

Dans la Partie 1, on a parcouru la thèse de Sara Hooker : l'ère du « plus grand, c'est mieux » touche à sa fin. La question qui suit naturellement — et celle à laquelle Hooker consacre l'essentiel de son essai — est : si le compute n'est plus le levier dominant, qu'est-ce qui l'est ?

Sa réponse : c'est le taux de rendement d'une unité de compute qui compte désormais, et ce taux est tiré par quatre choses, dont une seule est « plus de paramètres ». Passons-les en revue dans l'ordre, parce que chacune a des implications sur la façon dont une équipe d'ingénierie devrait choisir ses modèles, concevoir ses pipelines d'entraînement et budgéter son infrastructure en 2026.

1. Paramètres : rendements décroissants, puis bizarrerie

En 2016, Inception comptait 23 M de paramètres. En 2025, Qwen3-235B-A22B en compte 235 milliards. Ce saut de quatre ordres de grandeur a acheté de vrais gains pendant un temps. Il a aussi exposé un fait profondément inconfortable : on ne comprend pas pourquoi on a besoin de la plupart de ces poids.

Hooker cite un corpus de travaux qui le rend concret :

• On peut retirer la majorité des poids entraînés après l'entraînement avec une perte minime de performance (Gale et al. 2019 ; Han et al. 2015 ; Evci et al. 2019 ; Hooker et al. 2020). C'est le résultat bien connu de sparsité / pruning.
• Mais — et c'est là le casse-tête — on ne peut pas atteindre la même performance si on démarre directement avec le plus petit réseau. Les poids en trop font quelque chose pendant l'entraînement qu'ils ne font pas à l'inférence.
• Denil et al. (2014) ont montré qu'un petit ensemble de poids peut être utilisé pour prédire 95 % des poids d'un réseau. L'espace est énormément redondant.

L'explication la plus simple est inconfortable : les deep nets sont des apprenants incroyablement inefficaces de la longue traîne. Les motifs fréquents sont appris tôt et à bas coût. Les rares — précisément ceux qui font qu'un modèle paraît « intelligent » sur les cas limites — exigent une part disproportionnée du compute et une part disproportionnée des poids, en grande partie parce qu'on entraîne avec une minimisation de loss moyenne et une exposition égale entre exemples. Le signal des attributs rares est dilué dans les mises à jour de batch.

Hooker appelle ça « construire une échelle vers la Lune » — techniquement, ça progresse, mais avec une structure de coûts qui ne peut pas continuer à payer. Si vous acceptez ce diagnostic, les trois leviers suivants ne sont pas des optimisations facultatives. Ce sont la vraie frontière.

2. Qualité des données : le levier sous-investi par tout le monde

La qualité des données compense le compute. Hooker rassemble un large corpus de preuves — déduplication, data pruning, priorisation des données — montrant que des corpus d'entraînement mieux curés réduisent le nombre de paramètres nécessaires pour atteindre une barre de capacité donnée. D'après Marion et al. (2023), Penedo et al. (2023), Singh et al. (2024b) et d'autres, de petits jeux de données bien curés peuvent égaler ou battre de plus gros utilisés naïvement. Le temps d'entraînement chute directement, et l'économie de compute est structurelle, pas incrémentale.

Pourquoi l'industrie sous-investit-elle chroniquement ici ? Trois raisons familières à quiconque a piloté une équipe ML :

1. Le travail de curation se planifie mal au trimestre. « Nettoyer la donnée », c'est un verbe qui ne rentre pas dans une slide de roadmap. « Entraîner un modèle 10× plus gros », si.
2. Le compute s'achète ; la donnée curée se construit. Vous pouvez virer de l'argent à NVIDIA et avoir des GPU au prochain trimestre. Vous ne pouvez pas virer de l'argent et avoir un corpus propre, dédupliqué, équilibré, juridiquement clair au prochain trimestre.
3. Les métriques de succès se font gamer. Les améliorations de benchmark dues à la qualité des données ont l'air identiques aux améliorations dues au scale sur un graphique, donc le crédit va à celui qui a crié le plus fort sur le scaling, pas à l'équipe data qui a fait, en silence, la déduplication.

Le glissement décrit par Hooker — de la donnée comme snapshot figé (MNIST, ImageNet, SQuAD) à la donnée comme objet malléable et optimisé — est l'un des changements de paradigme les plus importants de l'essai. C'est aussi là que les rendements asymétriques sont les plus élevés pour les équipes qui n'ont pas des budgets de hyperscaler mais ont de l'expertise métier. On y reviendra dans la Partie 3 sous « l'espace de données malléable ».

3. Techniques algorithmiques : l'effet cumulé silencieux

Le troisième levier est le plus sous-estimé, surtout parce qu'il n'arrive pas dans une grande percée mais par un filet continu de techniques qui, individuellement, ressemblent à de petites optimisations. Hooker énumère une liste partielle de ce qui a compensé le compute brut ces dernières années :

• Instruction fine-tuning. Apprendre aux modèles à suivre des instructions par-dessus le pré-entraînement.
• Distillation depuis de plus gros enseignants. Un petit « élève » capable, entraîné sur de la donnée synthétique d'un plus gros « enseignant », peut approcher l'enseignant à une fraction du coût d'inférence.
• Chain-of-thought reasoning. Un motif de prompting et d'entraînement qui améliore la performance multi-étapes sans changement de compute d'entraînement.
• Augmentation de la longueur de contexte. Des changements architecturaux et d'attention qui permettent au même modèle de conditionner sur bien plus d'information à l'inférence.
• Retrieval-augmented generation. Externaliser la longue traîne des faits vers une couche de retrieval. Réduit les hallucinations, réduit le besoin de mémoriser, réduit la pression sur les paramètres.
• RLHF et préférences. Constitutional AI, DPO, RLOO et autres variantes changent substantiellement le comportement sans proportionnellement plus de paramètres.

Davidson et al. (2023) estiment que les techniques purement de compute à l'inférence peuvent livrer 5×–20× d'amélioration sur la performance de base post-entraînement. Ce chiffre mérite qu'on s'y arrête. Une amélioration de capacité de 10× qui ne demande aucun ré-entraînement, c'est exactement le genre de chose qui casse les roadmaps « modèle plus gros l'an prochain ».

Pour les équipes d'ingénierie, la leçon pratique est : l'essentiel de votre roadmap IA devrait être algorithmique, pas capacitaire. Vous obtiendrez plus de levier en ajoutant une couche de retrieval bien implémentée, une passe de vérification, un modèle distillé spécifique à la tâche, ou une structure de prompt chain-of-thought, qu'en attendant la prochaine classe de taille de modèle.

4. Architecture : le plafond

L'architecture est le levier que tout le monde sous-estime parce qu'il bouge rarement. Mais quand il bouge, il remet à zéro toutes les scaling laws qui le précédaient. Hooker est directe :

Un nouveau design d'architecture peut fondamentalement changer la relation entre compute et performance, et rendre n'importe quelle scaling law existante non pertinente.

Les preuves historiques sont là. Les CNN ont changé la relation pour la vision (Ciresan et al. 2011 ; Krizhevsky et al. 2012 ; Szegedy et al. 2014). Les Transformers ont changé la relation pour le langage (Vaswani et al. 2017). Chacun d'eux a été un paradigm shift qui a rendu les courbes compute-performance précédentes obsolètes et a débloqué une décennie entière de travaux de suivi.

On est presque certainement dû pour un autre. L'essai est sans détour : l'architecture actuelle « montre tous les signes d'un plateau dans les rendements du compute supplémentaire » et « la prochaine avancée significative demandera une architecture entièrement différente ». Les deep nets sont particulièrement mauvais pour :

• L'apprentissage continu — ils subissent un oubli catastrophique quand de la donnée nouvelle interfère avec d'anciens comportements.
• La spécialisation de la connaissance — les mises à jour de gradient globales ne taillent pas des zones de compétence comme le font les systèmes biologiques.
• L'efficacité d'échantillonnage — il leur faut vastement plus d'exemples qu'à un enfant humain pour des tâches comparables.

Une nouvelle architecture qui réglerait ne serait-ce qu'un de ces points re-rebattrait tout le paysage. C'est pour ça que concentrer tout le capex sur le scaling de l'architecture actuelle est, dans le cadre de Hooker, sous-investir dans la source la plus probable du prochain saut.

Ce que ça change pour les leaders ingénierie

En tirant ensemble ces quatre leviers, voici ce que j'apporterais dans une conversation de planification au T3 2026 :

• Arrêtez de classer les modèles au nombre de paramètres. Classez-les sur la capacité-par-token-par-dollar sur votre vrai mix de tâches. La corrélation entre nombre de paramètres et ce ratio est désormais faible.
• Faites monter le data engineering dans l'organigramme. Si vous n'avez pas une personne senior qui possède curation, déduplication, conformité de licence et priorisation, vous laissez le plus gros levier gratuit au sol.
• Traitez les améliorations algorithmiques comme le premier coup par défaut. Avant de commander un fine-tune ou un déploiement d'un plus gros modèle, épuisez : retrieval, structure de prompt, passes de vérification, distillation, tool use, chain-of-thought. La plupart des équipes abandonnent trop tôt sur cette couche.
• Suivez sérieusement les changements d'architecture. Quand la prochaine architecture post-transformer arrivera (et elle arrivera), les équipes qui auront sur-investi dans une infrastructure en forme de transformer — pipelines, ops, engagements vendeur — seront les plus lentes à s'adapter. La diversité architecturale dans votre stack est une couverture.
• Ne confondez pas « stratégie IA » et « choix de modèle ». Le modèle est une décision parmi tant d'autres. La donnée, le retrieval, la vérification, le design human-in-the-loop — c'est là que se joue le travail différenciant.

Le cadrage de Hooker — taux de rendement d'une unité de compute — est le bon à internaliser. Il déplace la conversation de « à quel point grand » vers « combien de capacité par unité de coût, et quels sont les leviers qui la déplacent ». C'est une conversation que les équipes d'ingénierie peuvent réellement gagner, et que les CFO peuvent réellement chiffrer.

---

Suite de la série : Au-delà du scaling — les nouveaux espaces d'optimisation pour le progrès IA. Méthodes sans gradient, compute à l'inférence comme levier de premier rang, espace de données malléable, systèmes agentiques, et ce que la mort du scaling change (et ne change pas) sur l'impact environnemental.