Aller au contenu principal
xAI montre les difficultés d'exploiter de nombreux GPU en parallèle
InfrastructureThe Information AI45min

xAI montre les difficultés d'exploiter de nombreux GPU en parallèle

Résumé IASource uniqueImpact UE
Source originale ↗·

xAI, la société d'intelligence artificielle d'Elon Musk, dispose d'environ 500 000 GPU Nvidia, l'une des plus grandes collections de puces serveur parmi les développeurs d'IA ayant rendu leurs données publiques. Pourtant, selon un mémo interne révélé par Business Insider, le taux de Model Flops Utilization (MFU) de xAI n'atteignait que 11 % ces dernières semaines, soit la proportion de puissance de calcul réellement exploitée sur l'ensemble des chips disponibles. Un score de 100 % représenterait une utilisation totale et théoriquement parfaite de l'infrastructure.

Ce chiffre est particulièrement frappant dans un secteur où les GPU Nvidia sont devenus une ressource rare et âprement disputée. Les développeurs d'IA se battent pour en obtenir, et subissent une pression intense pour en tirer le maximum. Un chercheur d'une entreprise concurrente interrogé sur le sujet a reconnu que dépasser 40 % d'utilisation restait difficile pour la plupart des acteurs du secteur, mais a qualifié le taux de 11 % d'« incroyablement bas ». Ce qui rend la situation encore plus surprenante, c'est que xAI est réputée pour configurer ses clusters GPU selon les recommandations officielles de Nvidia.

La racine du problème tient à la nature même de l'entraînement des modèles d'IA : une activité dite « en rafales », marquée par des pics soudains d'utilisation suivis de périodes creuses, le temps que les chercheurs analysent les résultats et décident de la prochaine étape. Ce schéma rend l'optimisation du taux d'utilisation structurellement difficile, contrairement à l'inférence, phase où les modèles sont déployés pour les utilisateurs finaux, qui génère une charge plus régulière et prévisible. La course aux GPU bat son plein dans toute l'industrie, mais l'écart entre les ressources accumulées et leur efficacité réelle soulève des questions sur la rentabilité de ces investissements massifs, à l'heure où les valorisations de l'IA reposent en partie sur la capacité à exploiter cette infrastructure.

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Mistral AI sécurise 830 millions de dollars en dette pour exploiter son premier centre de données en France
1Maddyness 

Mistral AI sécurise 830 millions de dollars en dette pour exploiter son premier centre de données en France

Mistral AI a finalisé un financement par dette de 830 millions de dollars destiné à l'exploitation de son premier centre de données souverain en France. Cette opération, distincte d'une levée de fonds en capital classique, permet à la startup parisienne fondée en 2023 de conserver sa structure actionnariale tout en mobilisant des ressources massives pour une infrastructure physique propre. Ce passage à l'hébergement en propre marque un tournant stratégique majeur : Mistral ne dépend plus uniquement des hyperscalers américains comme AWS ou Azure pour faire tourner ses modèles. Disposer d'un datacenter français signifie une maîtrise totale de la chaîne de traitement des données, un argument de poids auprès des clients institutionnels et des gouvernements européens soucieux de souveraineté numérique. Ce mouvement s'inscrit dans une course mondiale à la puissance de calcul où les acteurs de l'IA réalisent que le contrôle de l'infrastructure est aussi stratégique que les modèles eux-mêmes. Mistral, qui compte parmi ses clients la Commission européenne et plusieurs États membres, consolide ainsi sa position de champion européen face aux géants américains. L'opération pourrait également préfigurer une introduction en bourse ou un partenariat industriel à grande échelle dans les mois à venir.

UEMistral AI construit un datacenter souverain en France, réduisant la dépendance aux hyperscalers américains et offrant aux institutions publiques et gouvernements européens une alternative crédible pour le traitement souverain des données.

💬 C'est le move qu'on attendait depuis que Mistral a commencé à vendre aux gouvernements. Un datacenter souverain en France, c'est pas un bonus symbolique, c'est la condition pour décrocher les gros contrats institutionnels sans que personne te demande où tournent les données. Et 830 millions en dette plutôt qu'en capital, ça dit beaucoup sur leur ambition : ils préservent l'actionnariat pour ce qui vient après.

InfrastructureOpinion
1 source
Que cache le grand partenariat entre Meta et Amazon autour des puces CPU ?
2Le Big Data 

Que cache le grand partenariat entre Meta et Amazon autour des puces CPU ?

Le 24 avril 2026, Meta Platforms a officialisé un accord de plusieurs milliards de dollars avec Amazon Web Services portant sur l'accès à des dizaines de millions de cœurs de puces Graviton sur une durée estimée entre trois et cinq ans. Les puces concernées sont les Graviton5, gravées en 3 nanomètres, conçues en interne par Amazon via Annapurna Labs sur architecture Arm. Meta devient ainsi l'un des cinq plus grands clients de cette gamme de processeurs. Selon Nafea Bshara, vice-présidente d'AWS, le critère décisif pour Meta a été le rapport performance/prix, dans un contexte où les coûts d'infrastructure liés à l'IA atteignent des niveaux inédits. L'accord marque une rupture avec la logique purement GPU qui dominait les décisions d'infrastructure depuis deux ans et confirme un rééquilibrage profond des architectures de calcul à grande échelle. Ce retour des CPU au premier plan n'est pas un hasard. L'essor des agents IA, ces systèmes capables d'exécuter des tâches complexes de manière autonome, génère des besoins de calcul différents de ceux de l'entraînement des grands modèles. Les CPU jouent un rôle central dans les phases dites de post-entraînement, où les modèles sont ajustés pour des usages spécifiques, ainsi que dans la gestion de l'orchestration en amont et en aval des GPU. Loin de les remplacer, ils les complètent en optimisant l'ensemble de la chaîne de traitement. Pour Meta, qui déploie Meta AI à des centaines de millions d'utilisateurs et développe activement des expériences agentiques, la capacité à absorber des volumes massifs d'inférences à coût maîtrisé est devenue un avantage compétitif direct. Cet accord s'inscrit dans une stratégie d'infrastructure délibérément diversifiée. Meta multiplie les partenariats avec Nvidia, AMD et Arm Holdings, refusant toute dépendance à une architecture unique. La collaboration avec Amazon remonte à 2016, mais bascule ici vers un engagement sur une technologie CPU spécifique, ce qui est inédit dans leur relation. Sur le plan géographique, la majorité des déploiements sera réalisée aux États-Unis, dans un contexte de souveraineté technologique et de sécurisation des chaînes d'approvisionnement devenues des enjeux stratégiques. Du côté d'Amazon, valider Meta comme client de référence renforce la crédibilité des Graviton face aux solutions concurrentes et soutient une intégration verticale plus large : AWS vient d'annoncer 5 milliards de dollars supplémentaires investis dans Anthropic, qui utilisera elle aussi ces mêmes puces maison.

InfrastructureOpinion
1 source
Definity intègre des agents dans les pipelines Spark pour détecter les erreurs en amont des systèmes d'IA autonomes
3VentureBeat AI 

Definity intègre des agents dans les pipelines Spark pour détecter les erreurs en amont des systèmes d'IA autonomes

Definity, une startup spécialisée dans la fiabilité des pipelines de données, basée à Chicago, a annoncé mercredi une levée de fonds de 12 millions de dollars en série A, menée par GreatPoint Ventures avec la participation de Dynatrace, StageOne Ventures et Hyde Park Venture Partners. La société a développé une approche radicalement différente de la surveillance des pipelines : plutôt que d'analyser ce qui s'est passé après l'exécution d'un job, elle intègre un agent directement à l'intérieur du moteur Spark ou DBT, pendant que le pipeline tourne. Concrètement, un agent JVM s'installe en une seule ligne de code sous la couche plateforme, capturant en temps réel le comportement des requêtes, la pression mémoire, le déséquilibre des données et les patterns de shuffle. L'agent peut alors intervenir activement : réallouer des ressources à mi-parcours, stopper un job avant que des données corrompues ne se propagent, ou bloquer un pipeline en aval si la table d'entrée en amont est périmée. Un client entreprise a identifié 33 % de ses opportunités d'optimisation dès la première semaine de déploiement, réduit de 70 % l'effort de débogage, et résout désormais les problèmes Spark complexes jusqu'à dix fois plus vite. L'enjeu va bien au-delà de l'efficacité opérationnelle : avec l'essor des systèmes d'IA agentiques, la fiabilité des données en entrée devient critique. Un pipeline qui échoue silencieusement ou livre des données obsolètes ne casse plus seulement un tableau de bord, il compromet l'ensemble du système d'IA qui en dépend. La distinction est fondamentale : la détection et la prévention sont en temps réel, tandis que l'analyse des causes profondes et les recommandations d'optimisation s'effectuent à la demande, avec tout le contexte d'exécution déjà assemblé. L'agent n'ajoute qu'environ une seconde de calcul sur un job d'une heure. Seules les métadonnées transitent à l'extérieur, et un déploiement entièrement on-premises est disponible pour les environnements sensibles. Les outils existants, qu'il s'agisse de Datadog (qui a racheté Metaplane l'an dernier), des system tables Databricks, ou de plateformes comme Unravel Data et Acceldata, lisent tous les métriques une fois le job terminé. Comme le résume Roy Daniel, CEO et co-fondateur de Definity : « Le moment où vous apprenez qu'un problème s'est produit, il s'est déjà produit. » Le marché de l'observabilité des données est en pleine structuration, porté par la multiplication des pipelines complexes et l'exigence croissante des systèmes d'IA en production. Nexxen, plateforme adtech opérant de large pipelines Spark pour la publicité en temps réel, fait partie des premiers clients en production. La participation de Dynatrace au tour de table est notable : l'entreprise, spécialiste de l'observabilité IT, investit ainsi dans une approche concurrente à ses propres capacités de monitoring, signe que la niche de l'exécution inline commence à être prise au sérieux.

UEDynatrace, éditeur autrichien d'observabilité IT coté en bourse, participe au tour de table de Definity, signalant l'intérêt croissant des acteurs européens pour la surveillance inline des pipelines de données critiques aux systèmes d'IA en production.

InfrastructureActu
1 source
kvcached : mémoire KV Cache élastique, service LLM en rafales et partage GPU multi-modèles
4MarkTechPost 

kvcached : mémoire KV Cache élastique, service LLM en rafales et partage GPU multi-modèles

La gestion de la mémoire GPU représente l'un des défis les plus concrets du déploiement de modèles de langage en production, et kvcached apporte une réponse directe à ce problème. Ce projet open source, conçu comme une surcouche à vLLM, remplace l'allocateur statique de cache KV par une solution élastique et dynamique. Un tutoriel récent détaille son implémentation pas à pas, en déployant deux modèles Qwen2.5 (versions 0,5 milliard et 1,5 milliard de paramètres d'Alibaba) via une API compatible OpenAI sur les ports 8001 et 8002, avec vLLM 0.10.2 et une extension CUDA compilée à l'installation. L'activation se fait via quelques variables d'environnement, ENABLEKVCACHED et KVCACHEDAUTOPATCH, sans modifier le code source du serveur d'inférence. L'enjeu est significatif pour quiconque gère des infrastructures d'IA avec des charges de travail irrégulières. Avec l'allocation statique classique, la mémoire VRAM est réservée au démarrage du serveur et reste bloquée, que le modèle soit sollicité ou non. kvcached permet au contraire à la mémoire de se redistribuer en temps réel selon l'activité effective de chaque modèle. Dans un scénario multi-modèles sur un seul GPU, cela signifie concrètement qu'un modèle inactif libère de la mémoire au profit d'un autre qui subit un pic de requêtes, ce que les ingénieurs appellent une charge "bursty". Les expériences du tutoriel mesurent et visualisent directement cette différence en termes d'utilisation VRAM et de latence, avec une limite de contexte fixée à 2 048 tokens. Ce type d'outil s'inscrit dans une tendance de fond : optimiser l'utilisation des GPU pour réduire les coûts d'inférence, qui constituent désormais la majorité des dépenses opérationnelles des applications LLM à grande échelle. vLLM, maintenu par une communauté active et adopté par des dizaines d'entreprises d'infrastructure IA, reste la référence pour le serving haute performance, mais son modèle d'allocation mémoire statique montre ses limites face aux charges variables. Des projets comme kvcached, qui s'y greffent sans réécriture profonde, offrent une voie pragmatique vers une meilleure densité de déploiement. La prochaine étape logique, suggérée par la structure même du tutoriel, est l'extension à des architectures de serveurs partagés entre plusieurs équipes ou clients, ce que l'on appelle le multi-tenant serving, qui deviendra incontournable à mesure que les coûts GPU restent élevés.

UELes équipes techniques françaises déployant des LLMs en production via vLLM pourraient réduire leurs coûts GPU grâce à cette optimisation open source, sans impact réglementaire ou stratégique propre à la France/UE.

InfrastructureTuto
1 source