Open Source Summit : Intel détaille son kit OPEA pour renverser Nvidia

Intel n’a pas manqué d’être présent sur le salon Open Source Summit qui se tenait la semaine dernière à Vienne pour promouvoir OPEA (Open Platform for Enterprise AI), son tout nouveau kit de développement alternatif à celui de Nvidia pour écrire des applications d’IA générative.

Sur le point d’arriver en version 1.0, OPEA a pour vocation de démontrer aux entreprises qu’elles peuvent se passer des outils de Nvidia pour façonner des chatbots et, par extension, qu’elles n’ont pas non plus besoin d’acheter des GPU de marque Nvidia pour les exécuter.

Ça tombe bien, OPEA saura produire des applications d’IA générative optimisées pour les processeurs d’Intel, mais aussi pour ceux d’AMD. Et pour cause : OPEA est un projet Open Source qu’Intel a mis sous la tutelle de la Linux Foundation. Le fondeur joue la carte du rassemblement pour mieux détrôner le leader du marché.

OPEA est complémentaire d’UXL, un autre projet de la Linux Foundation, pareillement supporté par Intel, mais qui vise, lui, à standardiser la programmation des GPU pour l’entraînement de modèles. Toujours dans le but de ne pas programmer des traitements de Machine Learning avec les outils de Nvidia et, donc, de pouvoir acheter des GPU ailleurs que chez Nvidia.

Pour comprendre où en est le projet OPEA, LeMagIT est allé à la rencontre d’Arun Gupta, le patron de la division Open Ecosystem Initiatives chez Intel (en photo en haut de cet article). Interview.

Doit-on comprendre que ce kit de développement est un prétexte pour vendre des puces Intel ?

Arun Gupta : Absolument pas ! Il ne s'agit pas uniquement d'Intel. Je pense que c'est un enjeu universel, et les défis universels requièrent une collaboration universelle. Lorsque nous avons parlé à nos partenaires, nous avons constaté que chacun construisait sa propre plateforme de développement sur mesure, mais tous créaient finalement des microservices similaires. Le projet OPEA est donc né pour résoudre cette redondance inutile d’efforts.

Nous avons tous besoin d’une pile Open source standardisée qui définit les microservices des différents composants : comment on récupère les informations source, comment on les intègre dans les prompts, comment on les priorise, comment on les transforme en bases de données vectorielles, etc.

Et nous voulons que le code produit par nos utilisateurs puisse s’exécuter depuis n’importe où, depuis le cloud. C’est le projet.

Alors, bien entendu, il y a un aspect produit. Nous assurons aux hébergeurs de cloud que le code produit par les entreprises avec OPEA s’exécutera sur nos processeurs Xeon et nos GPU Gaudi. Mais nous ne sommes pas les seuls à pouvoir le faire. AMD, notre concurrent a rejoint l’aventure et il doit pouvoir offrir le même aspect produit aux hébergeurs de cloud. Au départ, en avril de cette année, nous étions 14 fournisseurs à nous lancer dans cette aventure. À ce jour, nous sommes plus de 40.

Était-il important qu’OPEA soit un projet sous la tutelle de la Linux Foundation ?

C’était très important. D’abord parce que la Linux Foundation (LF) est l’endroit où se déroule le plus important travail de la communauté Open source. Et puis, c'est une gouvernance tierce neutre. Même si les premières contributions ont été apportées par Intel, nous ne voulons pas que cela soit considéré comme un projet Intel. Nous voulons qu'il soit considéré comme un projet géré par la communauté.

Et dans un style très classique de la LF, nous avons créé un comité technique de direction. Il y a dix membres dans le comité de direction. Seuls deux sont d'Intel, les huit autres ne le sont pas. Et ce sont eux qui définissent la feuille de route, la future direction du projet et tout le reste.

Tout le travail, tous les ajouts, toutes les modifications sont publics. Et il y a des groupes de travail qui fédèrent les discussions techniques. Bref, cela permet véritablement à OPEA de se prévaloir de la sagesse collective d’une communauté.

Oui, parce que l’objectif est de proposer une alternative plus politiquement correcte à la suite AI Enterprise de Nvidia, n’est-ce pas ?

Arun Gupta : C’est en quelque sorte le but. Les microservices NIM et les outils de personnalisation NeMo de Nvidia constituent une pile très fermée, contrôlée par un seul fournisseur, qui fait des choix arrêtés. OPEA est en revanche ouvert à toutes les technologies.

Par exemple, nous proposons à l’heure actuelle Redis comme base vectorielle. Mais nous avons aussi son concurrent Zilliz comme partenaire, ce qui signifie que nous pouvons utiliser sa base vectorielle commerciale Milvus en complément si tel est le désir d’un client. Nous travaillons aussi avec Pinecone pour intégrer leur base vectorielle.

OPEA étant un système ouvert, vous pouvez réellement réaliser toutes les intégrations technologiques que vous souhaitez.

Et puis, attendez, tout le monde ne peut pas se permettre de travailler avec Nvidia. Je veux dire, les GPU qui vont de pair avec leur plateforme de développement sont très chers, pas facilement disponibles. Si vous pouvez développer des applications d’IA qui se contentent d’un Xeon pour fonctionner, vous vous ouvrez bien plus de possibilités en matière d’infrastructure. Et encore plus si cela fonctionne sur des processeurs AMD, et pourquoi pas, à terme, sur des processeurs ARM. 

À date, quelles sont les possibilités avec OPEA ? Avez-vous, comme Nvidia, des LLM et des bouts de codes prêts à être assemblés pour que les entreprises développent leurs propres applications d’IA ?

Arun Gupta : Vous pouvez utiliser n’importe quel LLM en arrière-plan : des LLM Open source, des LLM propriétaires. Cela n’a pas d’importance. Et vous pouvez les utiliser tels quels, soit leur faire subir un surentraînement personnalisé par fine-tuning, soit les faire travailler à partir de documents internes en mode RAG.

À l’heure actuelle, l’essentiel de nos efforts de développement porte sur le RAG. Parce que c’est là où la demande est la plus forte : créer un chatbot qui a accès aux données de l’entreprise pour y puiser des réponses est véritablement essentiel.

Ces données d’entreprise se trouvent dans vos e-mails, dans vos PDF, dans vos systèmes ERP, etc. Pour les utiliser, il faut les vectoriser. Où que soit extraite cette donnée, vous la découpez en morceaux plus petits, vous créez un format d'empreinte, ce qui constitue une base de données vectorielles.

Une fois que cette préparation est terminée, lorsqu’une requête est formulée, vous convertissez son sens en empreintes, lesquelles vous permettent de récupérer la bonne quantité d’informations dans la base de données vectorielles et vous envoyez l’ensemble pour analyse au LLM. Ainsi, vous injectez votre contexte métier en tant que partie de la demande avant qu'elle ne soit envoyée au LLM. Et c'est là que réside la valeur.

Notre travail consiste à savoir correctement vectoriser. Actuellement, nous travaillons sur la vectorisation des bases de données en graphe, principalement avec l’aide de Neo4J.

Enfin, il faut savoir qu’une vectorisation ne se fait pas en temps réel, mais qu’elle doit être réalisée régulièrement pour que votre IA générative prenne en compte les données les plus récentes possibles. Nous avons des processus qui s’apparentent un peu à ceux des sauvegardes. Par exemple, vous allez régler le système pour qu’il vectorise toutes les nouvelles données chaque nuit.