iamchamp - stock.adobe.com

Actualites

Analytique : l’écosystème veut « recycler » les GPU délaissés par les fournisseurs de LLM

Parfois boudés par les géants de l'IA générative, les GPU Nvidia de générations antérieures trouvent une nouvelle utilité. Ils accélèrent les charges de travail analytiques. Microsoft et Starburst s'appuient sur la librairie cuDF pour convertir ces actifs coûteux en leviers de performance pour les traitements SQL, le reporting ou la détection de fraude.

Gaétan Raoul
par
Publié le: 10 nov. 2026

Depuis le lancement de la librairie RAPIDS en 2018 (récemment renommé CUDA-X), Nvidia suggère à ces clients d’exploiter ces GPU pour leur traitement de données. La promesse : accélérer les charges de travail en lot, l’exécution de modèles de machine learning et l’analytique.

Microsoft a rapidement suivi. Cloudera, Google (via Colab), AWS, Databricks, Starburst, IBM ou encore Snowflake sont quelques-uns des acteurs à prendre en charge cette capacité.

Nvidia et ses partenaires misent plus particulièrement sur cuDF (à prononcer « KOO-dee-eff »), une librairie dédiée au traitement de données tabulaires sur ses GPU. Elle est originellement basée sur la librairie Pandas et l’API DataFrame de Python, mais des déclinaisons pour C++ et Java existent. L’outil de Nvidia est également compatible avec les moteurs d’exécution Apache Spark, DuckDB, Presto, Velox et Polars.

Microsoft et Starburst font partie de ceux qui l’intègrent à leur moteur de requêtes SQL. C’est l’objectif du projet CoddSpeed, chez Microsoft, qui a donné lieu à une publication scientifique en mai 2026.

L’analytique, une seconde vie pour six générations de GPU

CoddSpeed va un peu plus loin : il introduit un mécanisme pour router les charges de travail vers des instances propulsées par des CPU, des GPU, des FPGA et des ASICS. Mais la fonctionnalité correspondante, en préversion limitée au sein de Microsoft Fabric DataWarehouse, promet d’accélérer par trois à dix fois les charges de travail liées à Power BI, le mirorring d’Oracle et Snowflake vers Fabric, l’analytique (agrégation, jointure, transformation) et les charges de travail en lecture.

 Starburst, lui, intègre cuDF au sein de sa distribution propriétaire de Trino, un fork open source de Presto. Il obtient des performances multipliées jusqu’à 6 fois avec des GPU Blackwell (Nvidia GB200) sur le benchmark TCP-H et jusqu’à 3,4 fois sur des puces Ada Lovelace (Nvidia L4). Les requêtes concurrentes sont en moyenne 2,6 fois plus rapide. Tout comme Microsoft, Starburst ne laisse pas de côté les CPU. Son moteur compile le SQL en direction d’opérateurs d’exécution pour le scan de tables, les filtres, les agrégations, les jointures, etc.

« Au moment de l’exécution, chaque opérateur vérifie si ses données d’entrée et l’opération à effectuer peuvent être traitées par le GPU. Si c’est le cas, il transfère le traitement à cuDF ; dans le cas contraire, il bascule de manière transparente vers le CPU. Aucune requête n’échoue en raison d’une couverture GPU incomplète », décrivent ses porte-parole, dans un billet de blog. La description du mécanisme de Microsoft est similaire.

Un GPU, c’est cher. En 2018, les entreprises n’en étaient pas fortement équipées et les superclusters financés par les hyperscalers sortaient à peine de terre. Les serveurs en place propulsaient surtout la génération de rendu 3D et les simulateurs industriels. La problématique tarifaire ne s’est pas arrangée. Loin de là. Mais, en huit ans, neuf générations de cartes Nvidia ont peuplé les centres de données des fournisseurs cloud et des entreprises (Kepler, Maxwell, Pascal, Volta, Turing, Ampere, Hopper, Grace Hopper, Blackwell). C’est en tout cas le constat effectué par Sprout, un spécialiste de la gestion du cycle de vie des GPU et de leur reconditionnement.

Cela s’explique pour deux raisons principales. Les hyperscalers ont étendu la durée d’utilisation de leurs serveurs de trois ans à six ans en moyenne. La durée de vie des instances GPU se situe entre six et huit ans et demi en moyenne, note Sprout. Dans un même temps, ils se sont fortement équipés pour l’entraînement, puis l’inférence des grands modèles de langage.

Actuellement, les charges de travail IA mobilisent principalement les dernières générations de GPU. Et le passage à l’inférence n’inverse pas la tendance. Nvidia ne supporte officiellement que six des neuf générations citées plus haut, dixit Jensen Huang, cofondateur et PDG de Nvidia, lors de la GTC à Berlin.

En outre, les modèles d’IA propriétaires et open weight utilisent majoritairement des librairies compatibles avec les puces Hopper, Grace Hopper, Blackwell, Grace Blackwell et les Vera Rubin, en cours de production. À noter que la compatibilité avec l’architecture Hopper (H100, H200) est déclinante. L’utilisation de l’encodage NVFP4, pris en charge à partir de la génération Blackwell, se généralise.

Un pari « gagnant-gagnant »

« Nous n’utilisons pas les derniers GPU haut de gamme de Nvidia. Ce n’est pas que nous ne le voulions pas, mais ils sont tout simplement très demandés. Les chiffres de performances que vous voyez sont donc obtenus avec d’anciens GPU », affirme Connor Cunningham, vice-président de l’ingénierie et ingénieur distingué chez Microsoft. Il répondait là à une question du MagIT, lors d’une session de l’événement FabCon à Barcelone, en septembre dernier.

En l’occurrence, les tests menés dans le cadre du projet CoddSpeed s’exécutent sur des GPU Nvidia A100 et H100. Certains résultats proviennent de benchmarks réalisés à l’aide de systèmes Nvidia GB200.

Toutefois, Maraki Ketema, la responsable du produit en question chez Microsoft, a d’emblée précisé que ce n’est pas forcément les GPU utilisés dans la version commerciale. La documentation ne précise pas cette information. Pour l’instant, la fonctionnalité est prise en charge dans les régions East US, East US 2 et South Central US en Amérique du Nord, South East Asia en Asie et Germany West Central, en Europe.

De ce que comprend LeMagIT des dires de Connor Cunningham, Microsoft utilise les ressources GPU libres, quand elles le sont. « Je ne peux pas encore me procurer des GPU dans toutes les régions », déplorait-il, le 30 septembre 2026.

« Autrement dit, cela permet de prolonger la durée de vie des GPU existants que nous avons dans nos centres de données. Et d’amortir ce coût sur une durée de vie utile plus longue », poursuit-il. « Il y a donc de nombreuses opportunités pour nous d’essayer d’en tirer parti. Ce sont des actifs coûteux, et nous pouvons générer une grande valeur pour nos clients ».

Cela veut aussi dire que les nouveaux GPU, une fois boudés par les fournisseurs de LLM et leurs clients, pourront accélérer davantage les charges de travail analytiques.

Justin Borgman, PDG de Starburst, croit également en cette boucle vertueuse. « En réalité, notre partenariat a commencé avec Nvidia en février 2026 pour tester la plateforme Starburst sur le CPU Vera. Nous avons noté un haut niveau de performance. Les CPU ne sont pas les plus efficaces dans tous les domaines, tout comme les GPU. L’association sur un même système comme Vera Rubin – qui rapproche les deux types de puces – est prometteur ».

Sur site, maximiser l’utilisation des fermes GPU

En entreprise, la tendance est différente. Certaines sociétés, principalement les institutions financières, se sont équipées ces trois dernières années. Les fermes de GPU ainsi constituées visent à propulser certains cas d’usage d’IA générative et agentique privés. Or, ces sociétés ont du mal à maximiser leur utilisation, dixit Chris Wright, CTO et SVP Global Engineering, chez Red Hat. « En France, j’ai eu un rendez-vous à une grande banque. Elle possède déjà un parc important de GPU. Les responsables cherchent à saturer ces infrastructures, de passer d’un taux d’utilisation de quelques pour cent à un taux idéal, entre 75 et 100 % », témoigne-t-il, auprès du MagIT.

Un constat confirmé par Justin Borgman qui évoque publiquement le cas de HSBC. La banque britannique s’en sert pour « accélérer » la détection de la fraude. « Les GPU Nvidia sont assez coûteux. […] Nous permettons à nos clients d’obtenir davantage de valeurs du matériel qu’ils ont déjà acheté et installé en y exécutant des charges de travail analytiques », affirme-t-il.

« Il peut s’agir de tâches de reporting par lots, de transformations, ou encore d’autres types d’analyses de longue durée que nous pouvons désormais raccourcir considérablement et qu’ils peuvent planifier lorsque ces GPU sont moins sollicités », ajoute-t-il.

En clair, au lieu d’exécuter des batch sur des serveurs CPU la nuit et d’attendre six heures, Starburst envisage d’en router une partie vers des GPU et de gagner près de quatre heures.

Comme elle dépend de CUDA 12 et 13, la librairie cuDF prend en charge les GPU à partir de l’architecture Volta (V100, V100S dans les data centers). « Nous prenons en charge les GPU d’anciennes générations », confirme également Justin Borgman. « Les porte-parole de Nvidia sont plus enclins à parler des nouvelles puces et charges de travail. Mais, je pense que c’est également bon pour eux. Cela permet à leurs clients de justifier des dépenses qu’ils ont engagées par le passé. Et une utilisation croissante des GPU est de nature à provoquer davantage d’achats de puces à l’avenir ».

Pour l’instant, hormis HSBC, quelques clients testent l’intégration de cuDF dans Starburst. « Nous sommes encore en phase d’apprentissage », souligne le dirigeant.

De son côté, Microsoft signale plusieurs limites temporaires (dont l’incompatibilité avec le format nvarchar) qui devraient disparaître à la disponibilité générale. Le géant du cloud prévient également que la consommation de capacités (CU) est contre-intuitive. Les GPU étant plus chers, le prix d’entrée est supérieur, mais les économies se matérialisent avec les charges de travail les plus rapides. Tripler les performances consomme deux fois plus de CPU. Les décupler permet de la réduire de 36 %.  

Pour approfondir sur Outils décisionnels et analytiques