7 min. de lecture

La charge moyenne des GPU en entreprise se situe autour de cinq pour cent. Le reste reste inactif, car les données doivent d’abord être copiées, mises en staging et positionnées avant qu’une charge de travail ne démarre. Qumulo et Cisco ont présenté le 26 mai une architecture conçue pour combler exactement cette lacune : optimiser l’utilisation des accélérateurs existants plutôt que d’en acquérir de nouveaux.

Les points clés en bref

• Liquidité plutôt qu’achat : Le Cloud AI Accelerator met à disposition des GPU des données d’entreprise distribuées en temps réel, sans réplication ni staging de plusieurs semaines.
• Connexion plutôt que copie : Les systèmes on-premises et cloud se connectent à AWS Bedrock, Azure AI Foundry et Google Vertex AI sans copier les données.
• Cisco comme ancre hybride : Le réseau, la sécurité et UCS Compute soutiennent l’architecture à travers AWS, Azure, Google Cloud et OCI.

À lire aussi :AWS et Nvidia : le million de GPU force les équipes Platform  /  FinOps voit tout, mais n’a aucun pouvoir

Ce que Qumulo et Cisco ont annoncé

Qu’est-ce que la GPU-Liquidity ? La GPU-Liquidity désigne l’approche visant à rendre les GPU existants productifs plus rapidement, plutôt que d’en acquérir de nouveaux. Les données sont accessibles sans longue phase de staging, permettant ainsi à un accélérateur de démarrer son traitement réel plus tôt. Le goulot d’étranglement se déplace donc de l’acquisition matérielle vers la question de la rapidité à laquelle les capacités existantes effectuent effectivement les calculs.

Le 26 mai, Qumulo a présenté le Cloud AI Accelerator, suivi peu après par un deuxième élément, l’architecture CloudBridge, dévoilée juste avant le Cisco Live 2026. Le cœur des deux annonces repose sur la même idée : la capacité GPU est chère et rare, mais elle reste majoritairement inutilisée. Non pas par manque de puissance de calcul, mais parce que les données ne se trouvent pas à temps là où l’accélérateur en a besoin.

Techniquement, l’architecture regroupe trois composants existants de Qumulo : Cloud Native Qumulo, la Cloud Data Fabric et une couche de cache nommée NeuralCache. Ensemble, ils doivent fournir aux GPU des données distribuées, provenant de l’on-premises, de l’edge et de plusieurs clouds, sous forme d’une source logique unique. Cisco fournit pour sa part le réseau, la sécurité et, avec UCS, la base de calcul on-premises. Selon le fabricant, l’offre est disponible via AWS, Azure, Google Cloud et Oracle Cloud Infrastructure. Ce timing n’est pas un hasard : à l’approche d’un salon majeur, l’entreprise présente les briques qui doivent définir son portefeuille pour l’année.

1. La faille à 95 % est un problème de données

Le chiffre central de l’annonce est incommode. Si les GPUs ne sont utilisés en moyenne qu’à cinq pour cent, alors le poste le plus coûteux du budget IA est le temps pendant lequel rien ne se passe. Dans la plupart des cas, cela ne vient pas de l’architecture du modèle et encore moins de clusters trop petits. Cela vient de la pipeline précédente : les données sont exportées depuis le système source, mises au format approprié, chargées dans une couche Flash proche des GPU, puis seulement traitées.

Cette observation correspond à ce que les équipes plateforme connaissent du terrain. Un cluster qui attend trois jours ses données d’entraînement n’est pas économiquement un cluster, mais une réserve. La discussion sur la pénurie de GPU se déplace ainsi du service achats vers la question de savoir à quelle vitesse la capacité existante peut effectivement fonctionner. Celui qui a obtenu l’an dernier un budget pour des accélérateurs supplémentaires devrait d’abord vérifier si les anciens étaient même utilisés.

2. Connect statt Copy est le levier réel

Le niveau technique exige : pas de copie. Au lieu de copier les données vers un environnement proche d’une GPU, l’accélérateur doit connecter directement les systèmes existants Qumulo aux services d’inférence et d’entraînement des hyperscalers. De manière précise, Qumulo cite AWS Bedrock, Azure AI Foundry et Google Vertex AI comme cibles atteignables sans avoir à copier préalablement.

La différence n’est pas cosmétique. Chaque copie implique des coûts de stockage, un risque de cohérence et du temps. Qui supprime la copie, supprime aussi les semaines durant lesquelles le silicium coûteux attend sa nourriture. Pour les équipes DACH avec des sites répartis, un deuxième point est presque aussi important : les données qui ne sont pas copiées quittent moins souvent leur lieu contrôlé. Cela touche directement les exigences en matière de résidence des données, qui déterminent déjà chaque décision architecturale dans les secteurs réglementés.

3. Qu’est-ce que Cisco apporte dans le setup hybride

La collaboration avec Cisco va au-delà d’un logo sur la diapositive. Cisco apporte la couche réseau et de sécurité nécessaire pour permettre aux données de circuler rapidement et sous contrôle à travers les frontières cloud et site. Avec UCS, une base de calcul On-Premises s’ajoute, ramenant le modèle hors de la pure monde cloud et rendant intéressant pour les maisons qui ne veulent ou ne peuvent pas tout placer dans un hyperscaler.

La seconde annonce, CloudBridge, vise un point de douleur similaire : la fameuse « taxe Flash ». Il s’agit du surcoût lié au stockage Flash proche des GPUs, estimé jusqu’à 400 % par Qumulo. Qui n’a plus besoin de charger entièrement les données d’entraînement dans cette couche coûteuse évite ainsi une partie de la pénurie matérielle, sans acheter de nouvelles capacités. C’est le noyau économique de toute cette histoire : pas plus de performance, mais moins de gaspillage.

4. Où l’architecture atteint ses limites

Quel que soit le côté séduisant de cette promesse, elle déplace les problèmes au lieu de les résoudre. Qui supprime la copie, transforme le réseau en chemin critique. La latence et la bande passante entre la source de données et la GPU décident alors si la théorie se traduit en débit. C’est maîtrisable, mais c’est du travail, et il se produit en exploitation, pas dans le pitch.

Il y a aussi la dépendance. Une Data Fabric qui tient tout ensemble devient elle-même le fondement, qu’on ne peut plus remplacer sans plus de réflexion. Ce n’est pas un argument contre l’architecture, mais un point à prendre en compte lors des négociations contractuelles et de la planification de sortie. Qui introduit la Data Fabric doit documenter dès le départ comment pourrait se présenter un départ, tant que la question reste théorique.

Ce que les équipes DACH doivent examiner concrètement maintenant

Le test le plus honnête n’est pas la fiche technique, mais la propre pipeline. Qui veut savoir si la GPU-Liquidity apporte quelque chose mesure d’abord son propre Time-to-GPU : combien de temps faut-il entre le déclenchement d’une charge de travail et le premier lot traité ? Si cette durée est de l’ordre de jours, le levier est réel. Si elle est de l’ordre de minutes, l’accélérateur résout un problème qu’on n’a pas.

La deuxième étape est la question des coûts sans marketing. Les coûts des GPU inactifs peuvent être quantifiés dès lors que l’utilisation et le tarif horaire sont comparés. C’est seulement ce chiffre qui décide si la nouvelle Data Fabric est une investissement ou une couche supplémentaire. Un pilote propre avec un workload réel, une utilisation préalable mesurée et une condition d’arrêt claire en dit plus qu’aucune architecture de référence. Celui qui mesure les deux mène la discussion avec le fournisseur à égalité plutôt qu’à la hauteur des diapositives.

Foire aux questions

Que signifie la liquidité GPU ?

On entend par là rendre plus rapidement disponible la capacité GPU existante en rendant les données prêtes à l’emploi sans étape de mise en attente prolongée. Le goulot d’étranglement se déplace alors du rachat de nouvelles machines vers la question de savoir à quel point tôt les accélérateurs existants peuvent être mis en œuvre.

Dois-je copier mes données vers le cloud ?

Selon les fabricants, non. L’accélérateur cloud AI intègre directement les systèmes Qumulo existants aux services AWS Bedrock, Azure AI Foundry et Google Vertex AI, sans avoir besoin de copier les données au préalable.

Quels clouds sont pris en charge ?

Qumulo cite AWS, Azure, Google Cloud et Oracle Cloud Infrastructure. Une version sur site via Cisco UCS complète le portrait pour les environnements hybrides.

Quelle est la place de Cisco ?

Cisco fournit le réseau, la sécurité ainsi que le calcul local avec UCS. Cette couche détermine si les données peuvent atteindre rapidement les GPU à travers les frontières des clouds et des sites.

Pour qui le modèle vaut-il le coup ?

Particulièrement pour les entreprises disposant de données distribuées et souffrant d’un délai mesurable avant d’obtenir une GPU. Qui lance déjà ses charges de travail en quelques minutes n’a pas de goulot d’étranglement ici et en tire peu de bénéfice.

Source image : Image de titre et images de contenu générées par IA (mai 2026), certificat C2PA intégré à l’image