Arrêtez de concevoir l’infrastructure IA autour du GPU

Pourquoi les MSP devraient commencer par la charge de travail, pas par le matériel

Passer cinq minutes à une conférence sur l’IA et l’on peut facilement repartir en pensant que chaque déploiement IA réussi commence par l’achat de plus de GPU. C’est facile à comprendre. Le matériel domine la conversation. Les clients entendent parler des systèmes Blackwell, des tissus InfiniBand, des clouds hyperscale et des clusters IA de plus en plus massifs. Les fournisseurs se tournent naturellement vers les accélérateurs les plus récents et les systèmes les plus rapides parce qu’ils sont excitants, pertinents et relativement faciles à placer sur le marché.

Le problème n’est pas que le calcul ne compte pas. Il compte énormément.

Le problème, c’est que commencer par là peut amener les organisations à poser la mauvaise question. Le marché de l’IA n’est plus en phase d’expérimentation. L’IA est mise en production, les entreprises investissent de l’argent réel et elles attendent des résultats commerciaux mesurables. Les décisions d’infrastructure sont devenues beaucoup plus décisives qu’il y a deux ans. Pourtant, trop peu de décisions sont guidées par les exigences métier – les décisions technologiques restent en tête.

La première question ne devrait pas être « Quel GPU devons‑nous acheter ? »

« Quelle charge de travail essayons‑nous de prendre en charge ? » devrait être le point de départ.

Ce petit changement apparent influence presque chaque décision d’infrastructure qui suit.

Il n’existe pas d’infrastructure IA standard

Une des plus grandes idées fausses du marché est qu’il existe un plan directeur standard pour l’infrastructure IA. Il n’en existe pas.

Nous parlons de l’IA comme s’il s’agissait d’une charge de travail unique. En réalité, l’IA englobe un éventail énorme d’applications métier avec des exigences très différentes. Une plateforme d’IA vocale n’a pas les mêmes exigences d’infrastructure que l’imagerie médicale. La recherche de connaissances diffère de la génération d’images. La détection de fraude n’a rien à voir avec l’analyse prédictive, et aucune ne ressemble au traitement vidéo. Elles utilisent toutes l’IA. Elles utilisent simplement l’infrastructure de manière différente.

Vous ne concevez pas réellement une infrastructure pour « l’IA ». Vous concevez une infrastructure pour une application métier qui utilise l’IA. Cette distinction est importante. Chaque charge de travail impose des exigences uniques à l’infrastructure qui la supporte. Certaines nécessitent d’importantes ressources de calcul. D’autres dépendent fortement des performances de stockage parce qu’elles récupèrent continuellement de grands ensembles de données. Certaines sont limitées par le débit réseau, tandis qu’une autre peut vivre ou mourir sur la latence, chaque milliseconde affectant l’expérience client.

Il existe également une réalité pratique. L’infrastructure pour laquelle un modèle a été conçu n’est pas toujours celle qui est disponible au moment du déploiement. La disponibilité du matériel, les longs délais d’approvisionnement ou les échéances de déploiement peuvent obliger les organisations à utiliser des GPU, des accélérateurs ou des configurations d’infrastructure différents de ceux prévus initialement. Cela peut signifier re‑optimiser le modèle. Ou même le redessiner autour du matériel réellement déployable.

Les exigences de sécurité et de gouvernance sont tout aussi spécifiques à la charge de travail. Une application traitant des informations publiques a des exigences très différentes de celle qui gère des transactions financières, des dossiers de santé ou de la propriété intellectuelle propriétaire. La protection des données, la gestion des identités et des accès, la conformité, la souveraineté, les sauvegardes, la récupération et la disponibilité ne peuvent pas simplement être ajoutées après le déploiement. Ce sont des décisions architecturales.

Les exigences métier ajoutent une couche supplémentaire. À quelle vitesse l’application devra‑t‑elle évoluer ? Quels coûts d’exploitation sont soutenables ? Quel niveau de disponibilité l’entreprise exige‑t‑elle ? Quelle complexité l’organisation peut‑elle réellement gérer ? Ces questions recevront des réponses différentes selon chaque client. C’est pourquoi il n’existe pas d’infrastructure IA « taille unique ».

Les organisations qui commencent par un cloud, une plateforme matérielle ou un fournisseur préféré ne conçoivent pas correctement l’infrastructure IA. Les leaders commencent par la charge de travail et conçoivent une architecture autour de l’objectif métier.

La formation fait la une. L’inférence délivre la valeur métier.

L’attrait de l’industrie pour la formation est une autre raison pour laquelle les conversations sur l’infrastructure IA peuvent prendre la mauvaise direction.

Entraîner un grand modèle de langage est un défi d’ingénierie extraordinaire. D’énormes ensembles de données, des clusters GPU massifs, une puissance considérable et une infrastructure capable de fonctionner à pleine capacité pendant des jours, des semaines, voire des mois sont requis. C’est coûteux, techniquement impressionnant et attire naturellement l’attention.

La plupart des organisations, cependant, ne construisent pas le prochain modèle de pointe. Elles développent des applications de service client, des systèmes d’IA vocale, des copilotes pour employés, des assistants de connaissance, des outils de recherche, des plateformes de synthèse de documents, des systèmes de détection de fraude et des dizaines d’autres applications pratiques en utilisant des modèles déjà entraînés.

Ce sont des charges de travail d’inférence, et l’inférence change l’équation de l’infrastructure. Au lieu d’optimiser exclusivement pour le calcul maximal, les organisations peuvent devoir optimiser pour des temps de réponse rapides, une faible latence, des coûts d’exploitation prévisibles et des performances constantes.

Un client ne se soucie pas de la puissance du GPU sous‑jacent si un chatbot met cinq secondes à répondre. Un appelant ne se préoccupe pas des spécifications du cluster IA si un assistant vocal comprend mal les requêtes ou hésite pendant une conversation. Ils savent simplement que l’application ne fonctionne pas correctement.

Concevoir chaque environnement IA comme si vous entraîniez un modèle de base est donc généralement la mauvaise approche et souvent inutilement coûteuse.

L’objectif de la plupart des clients MSP n’est pas de construire le plus grand cluster GPU du monde. Mettre les applications IA en production rapidement, de façon fiable, sécurisée et économique est le but.

Le défi consiste à trouver le bon équilibre entre performance, sécurité, évolutivité, résilience et coût pour les charges de travail réellement exécutées.

Peut‑être que le GPU n’est pas votre goulot d’étranglement

Les GPU sont devenus les vedettes de l’infrastructure IA. Ils sont chers, difficiles à obtenir et faciles à comparer, ce qui en fait le point central de d’innombrables conversations d’infrastructure. Cependant, le GPU n’est peut‑être pas le facteur limitant une fois qu’une application IA atteint la production.

« Combien de GPU nous faut‑il ? » n’est pas la question que nous devrions poser, c’est plutôt « Qu’est‑ce qui ralentira cette application dans six mois ? »

La réponse peut également se situer ailleurs dans l’architecture.

Le stockage en est un bon exemple. D’énormes quantités de données sont consommées par les charges de travail IA – et ces ensembles de données croissent avec le temps. Même un GPU extrêmement puissant peut passer du temps précieux à attendre plutôt qu’à travailler, si le stockage ne fournit pas l’information assez rapidement. Ces données doivent également être protégées, sauvegardées, conservées, sécurisées et gérées tout au long de leur cycle de vie.

Tout autant, le réseau compte. Le débit, la latence, le trafic east‑west et la communication entre les clusters IA affectent toutes les performances de l’application. Un environnement de calcul bien conçu ne peut pas compenser indéfiniment un réseau mal conçu.

De plus, la sécurité doit faire partie de l’architecture dès le départ. Les questions à résoudre avant la production incluent: où résident les données sensibles, comment les réseaux sont segmentés, si les charges de travail communiquent via une connectivité privée ou publique, et comment les exigences de conformité et de souveraineté sont traitées.

Un autre facteur souvent négligé est la connectivité. Bien qu’ils ne fassent pas les gros titres, la diversité de la fibre, la diversité des routes, les relations de peering et la proximité géographique peuvent influencer de façon critique l’expérience utilisateur – sans parler de la résilience de la plateforme.

Les clients finaux ne savent pas et ne se soucient pas du GPU installé dans la baie. Ils veulent savoir si l’application répond immédiatement ou les laisse en attente.

L’infrastructure physique mérite également de l’attention. La disponibilité de l’alimentation, la capacité de refroidissement, la densité des racks et la capacité d’extension déterminent si le déploiement réussi d’aujourd’hui pourra accueillir la croissance de demain.

Puis il y a la gravité des données. À mesure que les ensembles de données s’étendent, déplacer des pétaoctets d’informations entre des sites, simplement parce que le calcul se trouve ailleurs, devient de plus en plus inefficace. Dans de nombreuses situations, rapprocher le calcul des données est à la fois plus pratique et moins coûteux.

C’est pourquoi l’architecture compte.

Pensez à une voiture de course – ce n’est pas parce qu’elle possède le meilleur moteur qu’elle gagnera. La transmission, les pneus, la suspension, le circuit, et surtout le pilote, sont tout aussi importants. L’infrastructure IA fonctionne de façon similaire.

Les organisations qui tirent le plus de valeur de l’IA ne seront pas nécessairement celles qui possèdent les plus grands clusters de GPU. Ce seront celles qui comprennent comment chaque couche de l’infrastructure fonctionne ensemble.

C’est la différence entre acheter une infrastructure et la concevoir.

Un cadre de planification centré sur la charge de travail

Les MSP ont l’opportunité de changer la conversation autour de l’infrastructure.

Au lieu de commencer par:

• Quel GPU ?
• Quel cloud ?
• Quel fournisseur ?

Commencez par la charge de travail:

• Quel problème métier résolvons‑nous ?
• S’agit‑il d’une charge de travail d’entraînement ou d’inférence ?
• Quelle latence l’application peut‑elle tolérer ?
• Où résident les données, et à quelle vitesse vont‑elles croître ?
• Quelles exigences de sécurité, de conformité et de souveraineté s’appliquent ?
• Comment la charge de travail évoluera‑t‑elle ?
• Quel niveau de disponibilité l’entreprise exige‑t‑elle ?
• Quel niveau de risque opérationnel est acceptable ?
• Quel sera le coût d’exploitation de cet environnement à mesure que l’utilisation augmente ?

Les réponses doivent déterminer l’architecture, et non l’inverse.

L’opportunité pour les MSP

Ce virage change le rôle du MSP.

Les clients n’ont pas besoin d’un autre partenaire capable de leur vendre de l’infrastructure. Ils ont besoin d’un partenaire capable de les aider à prendre de meilleures décisions d’infrastructure.

Une approche centrée sur la charge de travail est indispensable car elle permet aux MSP d’évaluer le calcul, le stockage, le réseau, la connectivité, la sécurité, l’emplacement des données, la disponibilité et le coût comme parties d’une architecture unique – plutôt que comme des décisions d’achat séparées.

De cette façon, vous pouvez contrôler les coûts, améliorer les performances et identifier les risques opérationnels et de sécurité avant que les applications n’atteignent la production.

Un modèle commercial plus avantageux pour le MSP se crée également.

Les MSP peuvent développer des services récurrents à plus forte valeur ajoutée autour de l’architecture, du déploiement, de l’optimisation, de la sécurité, de la gestion du cycle de vie, de la planification de capacité et de l’amélioration continue – au lieu de concurrencer principalement sur la réduction des marges matérielles.

La valeur ne réside pas dans la recommandation du dernier GPU ou de la plateforme cloud la plus récente. Elle réside dans la capacité à savoir quand un client en a besoin, quand il n’en a pas besoin, et ce qui doit être conçu autour de ces éléments.

L’infrastructure IA n’est finalement pas une décision matérielle. C’est une décision d’architecture guidée par la charge de travail, les données et le résultat métier que le client cherche à atteindre.

Les MSP qui comprennent cette distinction seront positionnés pour devenir quelque chose de bien plus précieux que les fournisseurs d’infrastructure.

Ils deviendront les personnes en qui les clients ont confiance pour les aider à décider quelle infrastructure ils ont réellement besoin.