F5 fait évoluer l’inférence de l’IA de l’intérieur vers l’extérieur
La renaissance des infrastructures a un slogan : laisser les serveurs servir et inférer l'inférence.
Aux débuts de la technologie, j’ai passé des années à tester et à analyser les accélérateurs SSL. Ces petites cartes ont été conçues pour résoudre un problème important résultant de la croissance explosive du commerce et des affaires numériques, à savoir que les fonctions de sécurité utilisant SSL consommaient des cycles CPU et étaient une source importante de problèmes de performances. Ainsi, l’industrie, y compris F5, a développé du matériel pour décharger ces fonctions et permettre aux serveurs de servir .
Aujourd'hui, nous voyons les mêmes problèmes surgir avec l'IA, en particulier l'inférence, et, sans ironie, nous voyons le même type de solutions surgir, à savoir du matériel spécialisé qui permet aux serveurs de servir et d'inférer .
Ouais, je ne suis pas sûr que ce soit grammaticalement correct, mais continuons comme ça pour l’instant, d’accord ? Merci.
Comme nous l’avons souligné, les applications d’IA sont des applications modernes dans leur construction architecturale . Mais au cœur d’une application d’IA se trouve l’inférence, et c’est là que l’IA diverge des applications modernes « normales ».
L'inférence en action
Nous avons vu comment les complexes de calcul d’IA sont construits à partir de banques de CPU et de GPU . Ces ressources de calcul ont des ratios et des équilibres qui doivent être maintenus pour que le cluster fonctionne efficacement. Chaque fois qu'un processeur ne parvient pas à suivre, un GPU très coûteux reste inactif.
Vous voyez, seule une partie du traitement d’un serveur d’inférence est réellement de l’inférence. Une grande partie de ce traitement est un traitement Web standard de requêtes HTTP et API. C'est la partie du service d'inférence qui utilise le processeur et qui est souvent surchargée. Lorsque cela se produit, les GPU sont de moins en moins utilisés, car le côté serveur de l’inférence se retrouve embourbé dans la gestion des requêtes.
C'est probablement la raison pour laquelle 15 % des organisations signalent que moins de 50 % de leurs GPU disponibles et achetés sont utilisés ( État de l'infrastructure de l'IA à grande échelle 2024 ).
Une partie du problème ici est l’utilisation des ressources CPU pour ce qui devrait être un travail d’infrastructure. Des services tels que la gestion du trafic, les opérations de sécurité et la surveillance consomment également des ressources CPU et contribuent à la charge sur le système global. Cela conduit à une réduction de la capacité et des performances des serveurs d'inférence et conduit à une moindre utilisation des ressources GPU.
Heureusement, cette renaissance de l’infrastructure vise à conserver les ressources du processeur pour le travail d’inférence en déchargeant les opérations d’infrastructure sur une nouvelle unité de traitement : le DPU.
Ce qui est intéressant avec les DPU, c’est qu’ils prennent en charge deux modes différents. D'une part, ils peuvent décharger la mise en réseau comme RDMA sur Infiniband ou Ethernet. Cela aide énormément lors de la création d'un complexe de calcul d'IA dans lequel des quantités importantes de données vont circuler, comme la formation d'un modèle d'IA ou la mise à l'échelle d'inférences pour une large base d'utilisateurs.
Mais les DPU peuvent également être configurés en mode « DPU ». Dans Kubernetes, cela les fait apparaître comme un nœud distinct sur lequel des fonctions telles que la livraison d'applications et la sécurité peuvent s'exécuter. Cela réserve efficacement la puissance de calcul du processeur aux services d'inférence en « déchargeant » les charges de travail d'infrastructure les moins prévisibles et les plus exigeantes sur leur propre nœud dans le cluster. Cela permet à des solutions comme F5 BIG-IP Next SPK (Service Proxy for Kubernetes) de gérer et de sécuriser les requêtes NS AI entrantes via l'API et de les distribuer correctement au service d'inférence approprié au sein du complexe de calcul AI.
Cette approche signifie que les organisations peuvent tirer parti des connaissances et des investissements existants dans la gestion de l’infrastructure Kubernetes, car notre solution est native de Kubernetes. Cœur, cloud, périphérie : cela n’a pas d’importance car l’opération se déroule au niveau du cluster et est cohérente dans tous les environnements.
Il sépare également la responsabilité de la gestion de la distribution des applications et des services de sécurité, ce qui permet aux équipes d'opérations réseau et de sécurité de gérer l'infrastructure indépendamment des charges de travail d'IA gérées par les équipes d'opérations de développement et de ML.
Enfin, l’exploitation du DPU pour la distribution et la sécurité des applications répond mieux aux besoins multi-locataires des organisations. Il ne s’agit pas seulement d’isoler les charges de travail des clients, mais également de modéliser les charges de travail. Nous savons, grâce à nos recherches, que les organisations utilisent déjà, en moyenne, 2,9 modèles différents . Être capable de gérer l’utilisation de chacun via une solution cohérente permettra une plus grande confiance dans la sécurité et la confidentialité des données consommées et générées par chaque modèle individuel.
Ce n’est pas la première fois que F5 travaille avec les DPU NVIDIA sur des cas d’utilisation liés à l’IA . Mais c'est la première fois que nous travaillons ensemble pour développer une solution permettant d'aider les clients de toutes tailles à créer des complexes de calcul d'IA évolutifs et sécurisés afin qu'ils puissent exploiter en toute sécurité et en toute confiance la puissance de l'inférence dans n'importe quel environnement et optimiser l'utilisation des ressources GPU, afin qu'ils ne restent pas inactifs .