L'IA a acheté les GPU ; personne n'est chargé de les garder occupés

Acheter des GPU a une échéance, un budget et une équipe d'acquisition. Les garder occupés n'a aucun des trois. Un nouvel essai de Dharma AI, le fournisseur open source de modèles spécialisés, qualifie cet écart de problème structurel de l'IA d'entreprise : un GPU accumule des coûts à l'heure du calendrier, via le financement, la dépréciation, l'électricité et le refroidissement, qu'il calcule ou non quoi que ce soit, tandis que sa production ne s'accumule qu'à l'heure de calcul.

La leçon des compagnies aériennes : les revenus ne s'accumulent qu'en vol

L'essai s'appuie sur l'histoire de l'aviation. Les coûts d'un avion s'accumulent à l'heure du calendrier : financement, dépréciation, assurance de la cellule, maintenance programmée, contrats des équipages. Les revenus ne s'accumulent qu'à l'heure de vol. L'utilisation découle de presque tout ce que fait une compagnie aérienne, de la discipline de rotation à la conception du réseau. Deux compagnies disposant de flottes comparables peuvent aboutir à des économies très différentes ; l'écart s'explique par une seule mesure plutôt que par la taille de la flotte. Une flotte plus grande aide toujours. Elle n'a jamais été la variable décisive.

Le goulot d'étranglement s'est déplacé des modèles au calcul, puis au matériel inactif

La première vague de l'IA d'entreprise s'est jouée sur la qualité des modèles. Cette capacité s'accompagnait d'une dépendance, car l'IA de production s'exécute sur des GPU coûteux, dont l'offre est limitée et dont la demande dépasse de loin ce qui est disponible. En 2020, Microsoft a construit pour OpenAI un supercalculateur dédié : plus de 10 000 GPU et 285 000 cœurs CPU, conçus pour entraîner ce qui allait devenir GPT-3. Six ans plus tard, ce chiffre ressemble à un point de départ. Dès 2026, Anthropic exécutait des engagements multi-gigawatts simultanés sur quatre plateformes matérielles, Amazon, Google, Microsoft et AMD, tandis que Meta signait un accord comparable de son côté. S'engager auprès de quatre fournisseurs à la fois, voilà à quoi ressemble la rareté lorsque même un capital illimité ne peut pas en obtenir assez d'une seule source.

Le même schéma se manifeste en aval sous une forme différente. La tarification des API évolue linéairement avec les tokens, séparant presque complètement l'économie de la preuve de concept de celle de la production. Quelques milliers de requêtes par mois semble abordable ; le volume de production devient une ligne de coût qui ne se résorbe jamais tout à fait. La voie qui gagne du terrain consiste à posséder le matériel, en échangeant un coût variable contre un coût d'investissement fixe. AMD s'inscrit déjà dans ce mouvement : son poste de développement 128 Go coûte environ six fois moins cher que l'utilisation équivalente d'API cloud sur trois ans, selon les propres modélisations de l'entreprise, et exécute localement des modèles allant jusqu'à 200 milliards de paramètres. Le jour où un tel cluster est mis en service, la question passe de « peut-on obtenir des accélérateurs » à « peut-on les garder occupés ».

Signer pour le matériel est la partie qui a une échéance et un propriétaire. Le garder en l'air est la partie qui décide en silence si l'accord valait la peine d'être signé.

Des clusters occupés peuvent tout de même gaspiller l'essentiel de leur capacité

Les GPU fonctionnent en continu alors que la demande, elle, est intermittente ; une part de la capacité reste donc provisionnée mais inutilisée en dehors des pics. De meilleures prévisions régleraient le problème si chaque GPU pouvait absorber aussi bien tous les types de travail. Peu le peuvent. Le même matériel porte désormais l'entraînement, le fine-tuning, la quantification, l'inférence en temps réel, l'inférence par lots, la génération d'embeddings et l'évaluation de modèles, souvent sur le même cluster, et chaque charge de travail exige quelque chose de différent du silicium :

Charge de travail	Ce qu'elle exige du GPU
Inférence en temps réel	Une faible latence avant presque tout le reste ; une réponse lente compte comme un échec
Inférence par lots	Le débit ; tolère des délais qui peuvent s'étendre sur des heures
Entraînement	Une occupation continue, sur des périodes mesurées en heures ou en jours
Quantification	Une grande capacité, mais seulement brièvement

Un ordonnanceur réglé pour l'une de ces charges répartit mal les trois autres presque par défaut, et l'échec ne se voit pas toujours sur un tableau de bord d'utilisation : un cluster peut afficher un taux d'occupation élevé tandis que des tâches en file d'attente attendent un type de GPU occupé à exécuter autre chose. C'est ici que l'analogie aéronautique s'arrête. Un 737 inactif peut être redéployé sur presque n'importe quelle route. Un GPU inactif ne peut absorber qu'une charge de travail dont il peut réellement prendre en charge le profil de mémoire, de latence et de durée, ce qui rend l'orchestration plus difficile que la planification de flotte et transforme la question en : quelle charge de travail s'exécute sur quel GPU, quand, à quelle priorité.

La question de 3 h du matin, et l'enjeu du fournisseur dans la réponse

Le provisionnement est une décision prise une fois, au moment de l'achat. L'allocation, elle, est constante : à chaque fois qu'une tâche se termine, à chaque nouvelle requête, à chaque changement de priorité entre un service orienté client et une exécution d'entraînement interne. Aucun ingénieur ne surveille un tableau de bord à trois heures du matin pour décider si une exécution d'entraînement terminée doit confier son GPU à une tâche par lots en file d'attente ou le conserver pour un pic de trafic entrant. C'est pourquoi cette décision se déplace vers une couche d'orchestration, une discipline que l'essai appelle la gestion des GPU.

L'argument final de l'essai associe cette orchestration à la spécialisation. Les modèles spécifiques à une tâche peuvent effectuer des travaux précis pour une fraction du coût en ressources d'un grand modèle généraliste, libérant ainsi de la capacité. Mais la capacité libérée ne se convertit en rendement que si quelque chose décide activement de sa destination. La spécialisation sans orchestration libère une capacité que personne ne récupère ; l'orchestration sans spécialisation a moins de capacité qui vaille la peine d'être récupérée. Chacune relève le plafond de l'autre.

La logique se tient d'elle-même, avec un astérisque qu'il vaut la peine de mentionner. L'essai vient de Dharma AI, qui vend des modèles open source spécialisés, et se termine en orientant les lecteurs vers ses publications sur Hugging Face. La comparaison aéronautique est la moitié forte de l'argument. La conclusion selon laquelle la réponse réside dans des modèles spécialisés plus petits est aussi la thèse produit de l'entreprise qui la formule.

Personne ne devrait non plus s'attendre à ce que l'efficacité réduise la demande totale de calcul : une inférence moins chère est exécutée davantage, pas moins, comme l'a montré notre couverture de l'hypothèse des 314 milliards de dollars. Le matériel est déjà installé, déjà en dépréciation, déjà engagé, et il perd de l'argent à l'heure du calendrier. Les compagnies aériennes ont appris que le gagnant n'est rarement la plus grande flotte, mais celle qui fait voler le plus complètement ce qu'elle possède. L'IA d'entreprise parvient à la même discipline par une direction différente. La question est de savoir qui sera désigné pour en être responsable avant que les heures d'inactivité ne se cumulent.