On dit que le budget informatique est le point de départ de la stratégie. Si tel est le cas, alors les stratégies d’IA sont bien vivantes.
Nos recherches les plus récentes indiquent que les entreprises allouent en moyenne 18 % de leur budget informatique à l'IA. Mais c'est la manière dont ces 18 % sont répartis qui nous donne un aperçu de leurs stratégies en matière d'IA.
Environ 18 % du budget de l’IA est aujourd’hui consacré aux services d’IA, c’est-à-dire à des applications tierces qui intègrent ou proposent une sorte d’outil d’IA. Le reste est consacré aux modèles (19 %), au développement (16 %), à la sécurité (9 %), aux technologies de données (11 %) et aux GPU (9 %).
Compte tenu de la répartition égale des dépenses entre la formation (50 %) et l’inférence (50 %) et du constat selon lequel l’IA sera distribuée dans le cloud public (80 %) et sur site (54 %), on peut supposer que les organisations prévoient des changements importants dans leur infrastructure pour prendre en charge le cycle de vie complet de l’IA.
Une partie de ce soutien nécessite un regard neuf sur le réseau.
La mise en place de l'infrastructure nécessaire pour prendre en charge à la fois la formation et l'inférence nécessite une attention particulière aux environnements d'application modernes, par exemple Kubernetes, et à la manière dont le trafic circulera entre les instances d'IA et entre les modèles et les applications qui les utilisent.
Bien que NVIDIA ne soit pas le seul fournisseur de technologie d’accélération (GPU, DPU, IPU, etc.), il ouvre la voie en matière d’architecture de référence. C’est dans ces détails que l’on retrouve les impacts significatifs sur l’architecture réseau et évolutive.
Il existe actuellement une angoisse considérable dans l’industrie à propos de l’utilisation d’une terminologie spécifique à Kubernetes. Alors que les opérateurs ont fini par comprendre la définition des pods et des clusters, les principaux fournisseurs de GPU falsifient ces définitions lorsqu'il s'agit de déployer des inférences à grande échelle.
Par exemple, NVIDIA fait référence aux pods AI, qui sont des clusters Kubernetes. Et ils appellent un ensemble de clusters liés une usine d'IA.
Je ne suis pas ici pour débattre de la terminologie (je remporte rarement ces débats), donc je me concentre plutôt sur ces unités de capacités d’IA et sur ce qu’elles signifient pour le réseau.
L’une des réalités de la mise à l’échelle de l’IA générative, en particulier, est la demande de cycles de calcul. Plus précisément, les cycles de calcul du GPU. Pour répondre à cette demande, en particulier pour les fournisseurs de services d’IA, il est nécessaire de créer des unités de calcul d’IA complexes. Ces unités sont ce que NVIDIA appelle des pods AI, mais d'autres auront sans doute leurs propres noms spéciaux pour elles. Il s’agit essentiellement de clusters Kubernetes.
Cela signifie beaucoup de trafic EW interne à l'unité de calcul IA, mais cela signifie également beaucoup de trafic NS vers ces unités de calcul IA. Et c’est là que nous nous trouvons face à un changement significatif à la frontière entre l’infrastructure traditionnelle des centres de données et les complexes de calcul d’IA émergents.
Il se passe beaucoup de choses à cette frontière, en particulier pour les fournisseurs de services qui ont besoin d’une isolation du réseau par locataire. Il existe également un besoin considérable de gestion du trafic L4-7, y compris la limitation du débit afin de ne pas surcharger les ressources de l’IA. Il existe également l’équilibrage de charge attendu pour l’évolutivité et la distribution, ainsi que des services réseau tels que les capacités CGNAT avancées.
Les entreprises ont également besoin de beaucoup de ces outils, car elles espèrent étendre leurs implémentations d’IA pour prendre en charge un ensemble croissant de cas d’utilisation commerciale, allant de la productivité à la génération de code et de contenu, en passant par l’automatisation des flux de travail et, bien sûr, l’intérêt croissant pour l’utilisation de l’IA pour les opérations. Bien que l’isolation par locataire ne soit pas une exigence de l’entreprise, elle peut être utile pour garantir que les charges de travail d’IA hautement prioritaires, telles que l’automatisation et l’analyse opérationnelle, ne sont pas étouffées par des charges de travail d’IA de moindre priorité.
Qu'il s'agisse d'un fournisseur de services ou d'une entreprise, le centre de données va subir des changements importants au niveau du réseau. L’insertion de charges de travail d’IA dans une architecture de centre de données traditionnelle peut entraîner une incapacité à évoluer ou même à fonctionner de manière fiable.
Il est important de comprendre les changements apportés à l'architecture du centre de données, tout comme de disposer d'outils et de technologies tels que BIG-IP Next SPK pour fournir les capacités nécessaires à la modernisation réussie du réseau du centre de données afin de prendre en charge chaque charge de travail d'IA et l'entreprise qui en dépendra en fin de compte.