Les points cl\u00e9s en bref<\/h2>\n\n\n- Liquidit\u00e9 plut\u00f4t qu’achat :<\/strong> Le Cloud AI Accelerator met \u00e0 disposition des GPU des donn\u00e9es d’entreprise distribu\u00e9es en temps r\u00e9el, sans r\u00e9plication ni staging de plusieurs semaines.<\/li>\n
- Connexion plut\u00f4t que copie :<\/strong> Les syst\u00e8mes on-premises et cloud se connectent \u00e0 AWS Bedrock, Azure AI Foundry et Google Vertex AI sans copier les donn\u00e9es.<\/li>\n
- Cisco comme ancre hybride :<\/strong> Le r\u00e9seau, la s\u00e9curit\u00e9 et UCS Compute soutiennent l’architecture \u00e0 travers AWS, Azure, Google Cloud et OCI.<\/li>\n<\/ul>\n<\/div>\n
\u00c0 lire aussi :<\/span>AWS et Nvidia : le million de GPU force les \u00e9quipes Platform<\/a> \/<\/span> FinOps voit tout, mais n’a aucun pouvoir<\/a><\/p>\nCe que Qumulo et Cisco ont annonc\u00e9<\/h2>\n
Qu’est-ce que la GPU-Liquidity ?<\/strong> La GPU-Liquidity d\u00e9signe l’approche visant \u00e0 rendre les GPU existants productifs plus rapidement, plut\u00f4t que d’en acqu\u00e9rir de nouveaux. Les donn\u00e9es sont accessibles sans longue phase de staging, permettant ainsi \u00e0 un acc\u00e9l\u00e9rateur de d\u00e9marrer son traitement r\u00e9el plus t\u00f4t. Le goulot d’\u00e9tranglement se d\u00e9place donc de l’acquisition mat\u00e9rielle vers la question de la rapidit\u00e9 \u00e0 laquelle les capacit\u00e9s existantes effectuent effectivement les calculs.<\/p>\nLe 26 mai, Qumulo a pr\u00e9sent\u00e9 le Cloud AI Accelerator, suivi peu apr\u00e8s par un deuxi\u00e8me \u00e9l\u00e9ment, l’architecture CloudBridge, d\u00e9voil\u00e9e juste avant le Cisco Live 2026. Le c\u0153ur des deux annonces repose sur la m\u00eame id\u00e9e : la capacit\u00e9 GPU est ch\u00e8re et rare, mais elle reste majoritairement inutilis\u00e9e. Non pas par manque de puissance de calcul, mais parce que les donn\u00e9es ne se trouvent pas \u00e0 temps l\u00e0 o\u00f9 l’acc\u00e9l\u00e9rateur en a besoin.<\/p>\n
Techniquement, l’architecture regroupe trois composants existants de Qumulo : Cloud Native Qumulo, la Cloud Data Fabric et une couche de cache nomm\u00e9e NeuralCache. Ensemble, ils doivent fournir aux GPU des donn\u00e9es distribu\u00e9es, 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\u00e9seau, la s\u00e9curit\u00e9 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 : \u00e0 l’approche d’un salon majeur, l’entreprise pr\u00e9sente les briques qui doivent d\u00e9finir son portefeuille pour l’ann\u00e9e.<\/p>\n
1. La faille \u00e0 95 % est un probl\u00e8me de donn\u00e9es<\/h2>\n
Le chiffre central de l’annonce est incommode. Si les GPUs ne sont utilis\u00e9s en moyenne qu’\u00e0 cinq pour cent, alors le poste le plus co\u00fbteux 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\u00e8le et encore moins de clusters trop petits. Cela vient de la pipeline pr\u00e9c\u00e9dente : les donn\u00e9es sont export\u00e9es depuis le syst\u00e8me source, mises au format appropri\u00e9, charg\u00e9es dans une couche Flash proche des GPU, puis seulement trait\u00e9es.<\/p>\n
\n5 %<\/div>\ntaux d’utilisation moyen des GPU dans l’entreprise, le reste est inactif car les donn\u00e9es doivent d’abord \u00eatre pr\u00e9par\u00e9es.<\/div>\nSource : Qumulo, Cloud AI Accelerator Announcement, 26 mai 2026<\/div>\n<\/div>\nCette observation correspond \u00e0 ce que les \u00e9quipes plateforme connaissent du terrain. Un cluster qui attend trois jours ses donn\u00e9es d’entra\u00eenement n’est pas \u00e9conomiquement un cluster, mais une r\u00e9serve. La discussion sur la p\u00e9nurie de GPU se d\u00e9place ainsi du service achats vers la question de savoir \u00e0 quelle vitesse la capacit\u00e9 existante peut effectivement fonctionner. Celui qui a obtenu l’an dernier un budget pour des acc\u00e9l\u00e9rateurs suppl\u00e9mentaires devrait d’abord v\u00e9rifier si les anciens \u00e9taient m\u00eame utilis\u00e9s.<\/p>\n
2. Connect statt Copy est le levier r\u00e9el<\/h2>\n
Le niveau technique exige : pas de copie. Au lieu de copier les donn\u00e9es vers un environnement proche d’une GPU, l’acc\u00e9l\u00e9rateur doit connecter directement les syst\u00e8mes existants Qumulo aux services d’inf\u00e9rence et d’entra\u00eenement des hyperscalers. De mani\u00e8re pr\u00e9cise, Qumulo cite AWS Bedrock, Azure AI Foundry et Google Vertex AI comme cibles atteignables sans avoir \u00e0 copier pr\u00e9alablement.<\/p>\n
La diff\u00e9rence n’est pas cosm\u00e9tique. Chaque copie implique des co\u00fbts de stockage, un risque de coh\u00e9rence et du temps. Qui supprime la copie, supprime aussi les semaines durant lesquelles le silicium co\u00fbteux attend sa nourriture. Pour les \u00e9quipes DACH avec des sites r\u00e9partis, un deuxi\u00e8me point est presque aussi important : les donn\u00e9es qui ne sont pas copi\u00e9es quittent moins souvent leur lieu contr\u00f4l\u00e9. Cela touche directement les exigences en mati\u00e8re de r\u00e9sidence des donn\u00e9es, qui d\u00e9terminent d\u00e9j\u00e0 chaque d\u00e9cision architecturale dans les secteurs r\u00e9glement\u00e9s.<\/p>\n
\n\n\n\nDimension<\/th>\n Staging classique<\/th>\n Cloud AI Accelerator<\/th>\n<\/tr>\n<\/thead>\n \n\nMouvement des donn\u00e9es<\/strong><\/td>\nExport, copie, r\u00e9plication<\/td>\n Connexion directe sans copie<\/td>\n<\/tr>\n \nTemps jusqu’\u00e0 la GPU<\/strong><\/td>\nJours ou semaines<\/td>\n Minutes au lieu d’une phase de staging<\/td>\n<\/tr>\n \nCout d’inactivit\u00e9<\/strong><\/td>\n\u00c9lev\u00e9, l’inactivit\u00e9 domine<\/td>\n R\u00e9duit gr\u00e2ce \u00e0 un d\u00e9marrage plus t\u00f4t<\/td>\n<\/tr>\n \nPort\u00e9e<\/strong><\/td>\nPar r\u00e9gion, par cloud<\/td>\n AWS, Azure, GCP, OCI plus UCS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n![\"Sch\u00e9ma](\"https:\/\/www.cloudmagazin.com\/wp-content\/uploads\/2026\/05\/post-iav0-hero-2.jpg\")
Connect statt Copy : Connexion directe des donn\u00e9es sources On-Premises vers les services GPU en temps r\u00e9el.<\/figcaption><\/figure>\n3. Qu’est-ce que Cisco apporte dans le setup hybride<\/h2>\n
La collaboration avec Cisco va au-del\u00e0 d’un logo sur la diapositive. Cisco apporte la couche r\u00e9seau et de s\u00e9curit\u00e9 n\u00e9cessaire pour permettre aux donn\u00e9es de circuler rapidement et sous contr\u00f4le \u00e0 travers les fronti\u00e8res cloud et site. Avec UCS, une base de calcul On-Premises s’ajoute, ramenant le mod\u00e8le hors de la pure monde cloud et rendant int\u00e9ressant pour les maisons qui ne veulent ou ne peuvent pas tout placer dans un hyperscaler.<\/p>\n
La seconde annonce, CloudBridge, vise un point de douleur similaire : la fameuse \u00ab taxe Flash \u00bb. Il s’agit du surco\u00fbt li\u00e9 au stockage Flash proche des GPUs, estim\u00e9 jusqu’\u00e0 400 % par Qumulo. Qui n’a plus besoin de charger enti\u00e8rement les donn\u00e9es d’entra\u00eenement dans cette couche co\u00fbteuse \u00e9vite ainsi une partie de la p\u00e9nurie mat\u00e9rielle, sans acheter de nouvelles capacit\u00e9s. C’est le noyau \u00e9conomique de toute cette histoire : pas plus de performance, mais moins de gaspillage.<\/p>\n
4. O\u00f9 l’architecture atteint ses limites<\/h2>\n
Quel que soit le c\u00f4t\u00e9 s\u00e9duisant de cette promesse, elle d\u00e9place les probl\u00e8mes au lieu de les r\u00e9soudre. Qui supprime la copie, transforme le r\u00e9seau en chemin critique. La latence et la bande passante entre la source de donn\u00e9es et la GPU d\u00e9cident alors si la th\u00e9orie se traduit en d\u00e9bit. C’est ma\u00eetrisable, mais c’est du travail, et il se produit en exploitation, pas dans le pitch.<\/p>\n
\n\n\u00c0 v\u00e9rifier<\/p>\n
\n- La latence r\u00e9seau devient le nouveau goulot d’\u00e9tranglement<\/li>\n
- D\u00e9pendance \u00e0 la Qumulo-Fabric en tant que fondement<\/li>\n
- Gouvernance au-del\u00e0 des fronti\u00e8res cloud et des sites<\/li>\n<\/ul>\n<\/div>\n\n
Ce qui est clair<\/p>\n
\n- Pas de r\u00e9copie, moins de risque de consistance<\/li>\n
- D\u00e9marrage plus rapide des GPUs existants<\/li>\n
- Option Multi-Cloud plus On-Premises via UCS<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
Il y a aussi la d\u00e9pendance. Une Data Fabric qui tient tout ensemble devient elle-m\u00eame le fondement, qu’on ne peut plus remplacer sans plus de r\u00e9flexion. Ce n’est pas un argument contre l’architecture, mais un point \u00e0 prendre en compte lors des n\u00e9gociations contractuelles et de la planification de sortie. Qui introduit la Data Fabric doit documenter d\u00e8s le d\u00e9part comment pourrait se pr\u00e9senter un d\u00e9part, tant que la question reste th\u00e9orique.<\/p>\n
Ce que les \u00e9quipes DACH doivent examiner concr\u00e8tement maintenant<\/h2>\n
Le test le plus honn\u00eate 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\u00e9clenchement d’une charge de travail et le premier lot trait\u00e9 ? Si cette dur\u00e9e est de l’ordre de jours, le levier est r\u00e9el. Si elle est de l’ordre de minutes, l’acc\u00e9l\u00e9rateur r\u00e9sout un probl\u00e8me qu’on n’a pas.<\/p>\n
La deuxi\u00e8me \u00e9tape est la question des co\u00fbts sans marketing. Les co\u00fbts des GPU inactifs peuvent \u00eatre quantifi\u00e9s d\u00e8s lors que l’utilisation et le tarif horaire sont compar\u00e9s. C’est seulement ce chiffre qui d\u00e9cide si la nouvelle Data Fabric est une investissement ou une couche suppl\u00e9mentaire. Un pilote propre avec un workload r\u00e9el, une utilisation pr\u00e9alable mesur\u00e9e et une condition d’arr\u00eat claire en dit plus qu’aucune architecture de r\u00e9f\u00e9rence. Celui qui mesure les deux m\u00e8ne la discussion avec le fournisseur \u00e0 \u00e9galit\u00e9 plut\u00f4t qu’\u00e0 la hauteur des diapositives.<\/p>\n
Foire aux questions<\/h2>\n\nQue signifie la liquidit\u00e9 GPU ?<\/strong><\/summary>\nOn entend par l\u00e0 rendre plus rapidement disponible la capacit\u00e9 GPU existante en rendant les donn\u00e9es pr\u00eates \u00e0 l’emploi sans \u00e9tape de mise en attente prolong\u00e9e. Le goulot d’\u00e9tranglement se d\u00e9place alors du rachat de nouvelles machines vers la question de savoir \u00e0 quel point t\u00f4t les acc\u00e9l\u00e9rateurs existants peuvent \u00eatre mis en \u0153uvre.<\/p>\n<\/details>\n\nDois-je copier mes donn\u00e9es vers le cloud ?<\/strong><\/summary>\nSelon les fabricants, non. L’acc\u00e9l\u00e9rateur cloud AI int\u00e8gre directement les syst\u00e8mes Qumulo existants aux services AWS Bedrock, Azure AI Foundry et Google Vertex AI, sans avoir besoin de copier les donn\u00e9es au pr\u00e9alable.<\/p>\n<\/details>\n\nQuels clouds sont pris en charge ?<\/strong><\/summary>\nQumulo cite AWS, Azure, Google Cloud et Oracle Cloud Infrastructure. Une version sur site via Cisco UCS compl\u00e8te le portrait pour les environnements hybrides.<\/p>\n<\/details>\n\nQuelle est la place de Cisco ?<\/strong><\/summary>\nCisco fournit le r\u00e9seau, la s\u00e9curit\u00e9 ainsi que le calcul local avec UCS. Cette couche d\u00e9termine si les donn\u00e9es peuvent atteindre rapidement les GPU \u00e0 travers les fronti\u00e8res des clouds et des sites.<\/p>\n<\/details>\n\nPour qui le mod\u00e8le vaut-il le coup ?<\/strong><\/summary>\nParticuli\u00e8rement pour les entreprises disposant de donn\u00e9es distribu\u00e9es et souffrant d\u2019un d\u00e9lai mesurable avant d\u2019obtenir une GPU. Qui lance d\u00e9j\u00e0 ses charges de travail en quelques minutes n\u2019a pas de goulot d\u2019\u00e9tranglement ici et en tire peu de b\u00e9n\u00e9fice.<\/p>\n<\/details>\n
- \n
- Liquidit\u00e9 plut\u00f4t qu’achat :<\/strong> Le Cloud AI Accelerator met \u00e0 disposition des GPU des donn\u00e9es d’entreprise distribu\u00e9es en temps r\u00e9el, sans r\u00e9plication ni staging de plusieurs semaines.<\/li>\n
- Connexion plut\u00f4t que copie :<\/strong> Les syst\u00e8mes on-premises et cloud se connectent \u00e0 AWS Bedrock, Azure AI Foundry et Google Vertex AI sans copier les donn\u00e9es.<\/li>\n
- Cisco comme ancre hybride :<\/strong> Le r\u00e9seau, la s\u00e9curit\u00e9 et UCS Compute soutiennent l’architecture \u00e0 travers AWS, Azure, Google Cloud et OCI.<\/li>\n<\/ul>\n<\/div>\n
\u00c0 lire aussi :<\/span>AWS et Nvidia : le million de GPU force les \u00e9quipes Platform<\/a> \/<\/span> FinOps voit tout, mais n’a aucun pouvoir<\/a><\/p>\n
Ce que Qumulo et Cisco ont annonc\u00e9<\/h2>\n
Qu’est-ce que la GPU-Liquidity ?<\/strong> La GPU-Liquidity d\u00e9signe l’approche visant \u00e0 rendre les GPU existants productifs plus rapidement, plut\u00f4t que d’en acqu\u00e9rir de nouveaux. Les donn\u00e9es sont accessibles sans longue phase de staging, permettant ainsi \u00e0 un acc\u00e9l\u00e9rateur de d\u00e9marrer son traitement r\u00e9el plus t\u00f4t. Le goulot d’\u00e9tranglement se d\u00e9place donc de l’acquisition mat\u00e9rielle vers la question de la rapidit\u00e9 \u00e0 laquelle les capacit\u00e9s existantes effectuent effectivement les calculs.<\/p>\n
Le 26 mai, Qumulo a pr\u00e9sent\u00e9 le Cloud AI Accelerator, suivi peu apr\u00e8s par un deuxi\u00e8me \u00e9l\u00e9ment, l’architecture CloudBridge, d\u00e9voil\u00e9e juste avant le Cisco Live 2026. Le c\u0153ur des deux annonces repose sur la m\u00eame id\u00e9e : la capacit\u00e9 GPU est ch\u00e8re et rare, mais elle reste majoritairement inutilis\u00e9e. Non pas par manque de puissance de calcul, mais parce que les donn\u00e9es ne se trouvent pas \u00e0 temps l\u00e0 o\u00f9 l’acc\u00e9l\u00e9rateur en a besoin.<\/p>\n
Techniquement, l’architecture regroupe trois composants existants de Qumulo : Cloud Native Qumulo, la Cloud Data Fabric et une couche de cache nomm\u00e9e NeuralCache. Ensemble, ils doivent fournir aux GPU des donn\u00e9es distribu\u00e9es, 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\u00e9seau, la s\u00e9curit\u00e9 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 : \u00e0 l’approche d’un salon majeur, l’entreprise pr\u00e9sente les briques qui doivent d\u00e9finir son portefeuille pour l’ann\u00e9e.<\/p>\n
1. La faille \u00e0 95 % est un probl\u00e8me de donn\u00e9es<\/h2>\n
Le chiffre central de l’annonce est incommode. Si les GPUs ne sont utilis\u00e9s en moyenne qu’\u00e0 cinq pour cent, alors le poste le plus co\u00fbteux 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\u00e8le et encore moins de clusters trop petits. Cela vient de la pipeline pr\u00e9c\u00e9dente : les donn\u00e9es sont export\u00e9es depuis le syst\u00e8me source, mises au format appropri\u00e9, charg\u00e9es dans une couche Flash proche des GPU, puis seulement trait\u00e9es.<\/p>\n
\n5 %<\/div>\ntaux d’utilisation moyen des GPU dans l’entreprise, le reste est inactif car les donn\u00e9es doivent d’abord \u00eatre pr\u00e9par\u00e9es.<\/div>\nSource : Qumulo, Cloud AI Accelerator Announcement, 26 mai 2026<\/div>\n<\/div>\nCette observation correspond \u00e0 ce que les \u00e9quipes plateforme connaissent du terrain. Un cluster qui attend trois jours ses donn\u00e9es d’entra\u00eenement n’est pas \u00e9conomiquement un cluster, mais une r\u00e9serve. La discussion sur la p\u00e9nurie de GPU se d\u00e9place ainsi du service achats vers la question de savoir \u00e0 quelle vitesse la capacit\u00e9 existante peut effectivement fonctionner. Celui qui a obtenu l’an dernier un budget pour des acc\u00e9l\u00e9rateurs suppl\u00e9mentaires devrait d’abord v\u00e9rifier si les anciens \u00e9taient m\u00eame utilis\u00e9s.<\/p>\n
2. Connect statt Copy est le levier r\u00e9el<\/h2>\n
Le niveau technique exige : pas de copie. Au lieu de copier les donn\u00e9es vers un environnement proche d’une GPU, l’acc\u00e9l\u00e9rateur doit connecter directement les syst\u00e8mes existants Qumulo aux services d’inf\u00e9rence et d’entra\u00eenement des hyperscalers. De mani\u00e8re pr\u00e9cise, Qumulo cite AWS Bedrock, Azure AI Foundry et Google Vertex AI comme cibles atteignables sans avoir \u00e0 copier pr\u00e9alablement.<\/p>\n
La diff\u00e9rence n’est pas cosm\u00e9tique. Chaque copie implique des co\u00fbts de stockage, un risque de coh\u00e9rence et du temps. Qui supprime la copie, supprime aussi les semaines durant lesquelles le silicium co\u00fbteux attend sa nourriture. Pour les \u00e9quipes DACH avec des sites r\u00e9partis, un deuxi\u00e8me point est presque aussi important : les donn\u00e9es qui ne sont pas copi\u00e9es quittent moins souvent leur lieu contr\u00f4l\u00e9. Cela touche directement les exigences en mati\u00e8re de r\u00e9sidence des donn\u00e9es, qui d\u00e9terminent d\u00e9j\u00e0 chaque d\u00e9cision architecturale dans les secteurs r\u00e9glement\u00e9s.<\/p>\n
\n\n\n
\n \nDimension<\/th>\n Staging classique<\/th>\n Cloud AI Accelerator<\/th>\n<\/tr>\n<\/thead>\n \n Mouvement des donn\u00e9es<\/strong><\/td>\n Export, copie, r\u00e9plication<\/td>\n Connexion directe sans copie<\/td>\n<\/tr>\n \n Temps jusqu’\u00e0 la GPU<\/strong><\/td>\n Jours ou semaines<\/td>\n Minutes au lieu d’une phase de staging<\/td>\n<\/tr>\n \n Cout d’inactivit\u00e9<\/strong><\/td>\n \u00c9lev\u00e9, l’inactivit\u00e9 domine<\/td>\n R\u00e9duit gr\u00e2ce \u00e0 un d\u00e9marrage plus t\u00f4t<\/td>\n<\/tr>\n \n Port\u00e9e<\/strong><\/td>\n Par r\u00e9gion, par cloud<\/td>\n AWS, Azure, GCP, OCI plus UCS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Connect statt Copy : Connexion directe des donn\u00e9es sources On-Premises vers les services GPU en temps r\u00e9el.<\/figcaption><\/figure>\n 3. Qu’est-ce que Cisco apporte dans le setup hybride<\/h2>\n
La collaboration avec Cisco va au-del\u00e0 d’un logo sur la diapositive. Cisco apporte la couche r\u00e9seau et de s\u00e9curit\u00e9 n\u00e9cessaire pour permettre aux donn\u00e9es de circuler rapidement et sous contr\u00f4le \u00e0 travers les fronti\u00e8res cloud et site. Avec UCS, une base de calcul On-Premises s’ajoute, ramenant le mod\u00e8le hors de la pure monde cloud et rendant int\u00e9ressant pour les maisons qui ne veulent ou ne peuvent pas tout placer dans un hyperscaler.<\/p>\n
La seconde annonce, CloudBridge, vise un point de douleur similaire : la fameuse \u00ab taxe Flash \u00bb. Il s’agit du surco\u00fbt li\u00e9 au stockage Flash proche des GPUs, estim\u00e9 jusqu’\u00e0 400 % par Qumulo. Qui n’a plus besoin de charger enti\u00e8rement les donn\u00e9es d’entra\u00eenement dans cette couche co\u00fbteuse \u00e9vite ainsi une partie de la p\u00e9nurie mat\u00e9rielle, sans acheter de nouvelles capacit\u00e9s. C’est le noyau \u00e9conomique de toute cette histoire : pas plus de performance, mais moins de gaspillage.<\/p>\n
4. O\u00f9 l’architecture atteint ses limites<\/h2>\n
Quel que soit le c\u00f4t\u00e9 s\u00e9duisant de cette promesse, elle d\u00e9place les probl\u00e8mes au lieu de les r\u00e9soudre. Qui supprime la copie, transforme le r\u00e9seau en chemin critique. La latence et la bande passante entre la source de donn\u00e9es et la GPU d\u00e9cident alors si la th\u00e9orie se traduit en d\u00e9bit. C’est ma\u00eetrisable, mais c’est du travail, et il se produit en exploitation, pas dans le pitch.<\/p>\n
\n\n\u00c0 v\u00e9rifier<\/p>\n
- \n
- La latence r\u00e9seau devient le nouveau goulot d’\u00e9tranglement<\/li>\n
- D\u00e9pendance \u00e0 la Qumulo-Fabric en tant que fondement<\/li>\n
- Gouvernance au-del\u00e0 des fronti\u00e8res cloud et des sites<\/li>\n<\/ul>\n<\/div>\n\n
Ce qui est clair<\/p>\n
- \n
- Pas de r\u00e9copie, moins de risque de consistance<\/li>\n
- D\u00e9marrage plus rapide des GPUs existants<\/li>\n
- Option Multi-Cloud plus On-Premises via UCS<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
Il y a aussi la d\u00e9pendance. Une Data Fabric qui tient tout ensemble devient elle-m\u00eame le fondement, qu’on ne peut plus remplacer sans plus de r\u00e9flexion. Ce n’est pas un argument contre l’architecture, mais un point \u00e0 prendre en compte lors des n\u00e9gociations contractuelles et de la planification de sortie. Qui introduit la Data Fabric doit documenter d\u00e8s le d\u00e9part comment pourrait se pr\u00e9senter un d\u00e9part, tant que la question reste th\u00e9orique.<\/p>\n
Ce que les \u00e9quipes DACH doivent examiner concr\u00e8tement maintenant<\/h2>\n
Le test le plus honn\u00eate 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\u00e9clenchement d’une charge de travail et le premier lot trait\u00e9 ? Si cette dur\u00e9e est de l’ordre de jours, le levier est r\u00e9el. Si elle est de l’ordre de minutes, l’acc\u00e9l\u00e9rateur r\u00e9sout un probl\u00e8me qu’on n’a pas.<\/p>\n
La deuxi\u00e8me \u00e9tape est la question des co\u00fbts sans marketing. Les co\u00fbts des GPU inactifs peuvent \u00eatre quantifi\u00e9s d\u00e8s lors que l’utilisation et le tarif horaire sont compar\u00e9s. C’est seulement ce chiffre qui d\u00e9cide si la nouvelle Data Fabric est une investissement ou une couche suppl\u00e9mentaire. Un pilote propre avec un workload r\u00e9el, une utilisation pr\u00e9alable mesur\u00e9e et une condition d’arr\u00eat claire en dit plus qu’aucune architecture de r\u00e9f\u00e9rence. Celui qui mesure les deux m\u00e8ne la discussion avec le fournisseur \u00e0 \u00e9galit\u00e9 plut\u00f4t qu’\u00e0 la hauteur des diapositives.<\/p>\n
Foire aux questions<\/h2>\n
\nQue signifie la liquidit\u00e9 GPU ?<\/strong><\/summary>\n
On entend par l\u00e0 rendre plus rapidement disponible la capacit\u00e9 GPU existante en rendant les donn\u00e9es pr\u00eates \u00e0 l’emploi sans \u00e9tape de mise en attente prolong\u00e9e. Le goulot d’\u00e9tranglement se d\u00e9place alors du rachat de nouvelles machines vers la question de savoir \u00e0 quel point t\u00f4t les acc\u00e9l\u00e9rateurs existants peuvent \u00eatre mis en \u0153uvre.<\/p>\n<\/details>\n
\nDois-je copier mes donn\u00e9es vers le cloud ?<\/strong><\/summary>\n
Selon les fabricants, non. L’acc\u00e9l\u00e9rateur cloud AI int\u00e8gre directement les syst\u00e8mes Qumulo existants aux services AWS Bedrock, Azure AI Foundry et Google Vertex AI, sans avoir besoin de copier les donn\u00e9es au pr\u00e9alable.<\/p>\n<\/details>\n
\nQuels clouds sont pris en charge ?<\/strong><\/summary>\n
Qumulo cite AWS, Azure, Google Cloud et Oracle Cloud Infrastructure. Une version sur site via Cisco UCS compl\u00e8te le portrait pour les environnements hybrides.<\/p>\n<\/details>\n
\nQuelle est la place de Cisco ?<\/strong><\/summary>\n
Cisco fournit le r\u00e9seau, la s\u00e9curit\u00e9 ainsi que le calcul local avec UCS. Cette couche d\u00e9termine si les donn\u00e9es peuvent atteindre rapidement les GPU \u00e0 travers les fronti\u00e8res des clouds et des sites.<\/p>\n<\/details>\n
\nPour qui le mod\u00e8le vaut-il le coup ?<\/strong><\/summary>\n
Particuli\u00e8rement pour les entreprises disposant de donn\u00e9es distribu\u00e9es et souffrant d\u2019un d\u00e9lai mesurable avant d\u2019obtenir une GPU. Qui lance d\u00e9j\u00e0 ses charges de travail en quelques minutes n\u2019a pas de goulot d\u2019\u00e9tranglement ici et en tire peu de b\u00e9n\u00e9fice.<\/p>\n<\/details>\n
- Connexion plut\u00f4t que copie :<\/strong> Les syst\u00e8mes on-premises et cloud se connectent \u00e0 AWS Bedrock, Azure AI Foundry et Google Vertex AI sans copier les donn\u00e9es.<\/li>\n