Par Fabrice Moizan, Directeur Général EMEAI et Asie Pacifique chez Graphcore
L’essor de l’IA est inéluctable, mais nécessite une puissance de calcul toujours plus élevée avec des architectures X86 qui montrent souvent leur limite. Pour répondre à la demande, les DSI provisionnent des processeurs graphiques pour accélérer les calculs. Mais, l’agrégation de plusieurs serveurs pour pallier la limite de puissance pose rapidement des problèmes d’architectures et d’espace au sein du datacenter. Pour surmonter ces obstacles et rationaliser son datacenter, Fabrice Moizan, milite pour une architecture désagrégée et découplée de l’informatique hôte. Explications.
L’hiver de l’IA est terminé. Après plusieurs phases, nous en sommes désormais au point où les applications se multiplient et les recherches toujours plus fécondes. Sur le versant des entreprises et des institutions de recherche, les puissances de calcul nécessaires sont toujours plus grandes. Fort heureusement, les ressources des datacenter sont aujourd’hui mieux pensées et les techniques de virtualisation et containerisation maîtrisées. Pour le machine learning, le couple X86 et processeurs graphiques fournit une puissance de calcul démultipliée. Mais avec des restrictions : les systèmes en rack proposés, X86 et accélérateur graphique, sont gourmandes en alimentation, nécessitent un système de refroidissement toujours plus performant et occupent plus de place que les serveurs standards. Ils peuvent également être peu flexibles, le rapport entre le calcul et l’accélérateur GPU étant fixe, ils offrent peu de flexibilité dès lors qu’il s’agit de jongler avec plusieurs charges de travail aux exigences différentes en matière de calcul hôte.
Par ailleurs, les calculs dédiés à l’IA sont eux aussi toujours plus gourmands en ressources. En réponse, la DSI rajoute un serveur, puis un autre, puis encore un autre… Une approche incrémentale qui ne résout ni le problème de déséquilibre entre le calcul hôte et l’accélération de l’IA et, pire, qui monopolise progressivement de la ressource au sein du datacenter au détriment d’autres tâches et avec une complexité croissante dans la gouvernance d’autres tâches.
L’IA : le quatrième pilier du datacenter
De notre point de vue, pour pallier une gouvernance trop complexe de la ressource, la puissance de calcul de l’IA doit être dissociée de l’informatique hôte et présentée sous une forme qui ne se contente pas de s’intégrer facilement aux datacenters modernes, mais qui en tire pleinement parti.
En effet, l’IA deviendra inévitablement le quatrième pilier du datacenter, aux côtés de l’informatique, des réseaux et du stockage (traditionnels), mais il faut prendre garde à ce que cela ne devienne pas des systèmes « boîte noire ». La désagrégation des serveurs est la réponse à ce problème qui se posera inévitablement.
Graphcore répond déjà à cette problématique d’administration avec l’architecture IPU-POD. C’est une solution élégante à ces problématiques d’infrastructures. Pour mémoire, IPU-POD est une famille de configurations de système basées sur l’IPU-M2000, une lame 1U qui fournit 1 pétaflops de calcul d’IA. Selon les besoins du DSI ou DTO, les serveurs sont plus ou moins puissants et peuvent délivrer de 4 pétaflops à 16 exaflops selon la configuration. Mais l’approche cœur est celle de serveurs hôtes désagrégés, avec ou sans commutateurs, selon le choix d’architecture.
Pourquoi la désagrégation ?
Dans un premier temps, l’approche désagrégée répond au besoin de passer rapidement à l’échelle en minimisant le nombre d’UGS serveurs à prendre en charge. En effet, en installant le logiciel de machine learning Poplar de Graphcore sur leurs serveurs, l’utilisateur bascule le calcul hôte au système basé sur l’IPU. La charge peut être augmentée ou réduite en fonction du calcul nécessaire, par exemple selon le type, NLP ou vision par exemple, il suffit d’ajuster de manière incrémentale la puissance de calcul nécessaire.
La résilience est aussi un autre avantage de la désagrégation. En cas de défaillance d’un serveur, le protocole standard de bascule de la pile réseau autorise une migration vers un autre serveur ou machine virtuelle de secours. Dans ce cadre, les systèmes Graphcore sont pris en charge par une suite d’outils de surveillance et de gestion conformes aux normes industrielles OpenBMC, RedFish DTMF, Prometheus et Grafana. Des outils qui permettent de remonter très en amont des alertes lorsqu’une défaillance est sur le point d’arriver.
Pour multiplier les workloads, il est aussi possible de créer des « IPUs virtuels » et découper les pods en pods virtuels isolés. Couplée à la prise en charge des outils d’orchestration standard de l’industrie tels que SLURM et Kubernetes, les machines virtuelles ou les conteneurs fonctionnant sur l’hôte peuvent être associés aux VPOD dans le système IPU. Pour le data-scientist, cette solution offre à la fois une réponse à la puissance nécessaire aux calculs de ses modèles et aussi la certitude que cette ressource lui sera seulement affectée et non partagée.
L’IA pour tous
Par ailleurs, avec ce type d’architecture et les systèmes IPU de Graphcore, le coût de possession est largement réduit comparé à un coût standard. Par exemple, dès que l’on évoque l’OPEX, la question pourrait être la suivante : « Quelle quantité d’énergie consommez-vous réellement pour exécuter, disons, une tâche BERT ? Pendant un an ? » Le calcul est assez vite réalisé et milite en faveur d’un système dédié, fondé sur un IPU. Pour rappel les performances de ces IPU sont par ailleurs largement supérieures au couple traditionnel X86 et GPU.
Du point de vue des dépenses d’investissement, l’équation est encore plus simple. Pour bénéficier de ce type d’architecture, le seul nouveau composant à ajouter à cette solution est le système IPU-M2000 basé sur l’IPU-POD. Les autres composants — le réseau et le stockage — sont déjà présents au sein des entreprises.
Adopter ce type d’architecture répond à la fois au souci de gouvernance du datacenter, mais permet surtout de prendre de l’avance dans l’utilisation de l’IA et disposer de son bénéfice concurrentiel.
