Le projet Open Programmable Infrastructure de la Linux Foundation a publié OPI Abstraction v0.1.0 le 29 juillet 2026, sa première version coordonnée après quatre ans de travaux. C'est une couche d'API neutre vis à vis des fournisseurs, répartie sur 26 dépôts, qui couvre l'intégration Kubernetes, le provisionnement matériel et l'observabilité des unités de traitement de données et d'infrastructure. Elle introduit aussi les OPI Blueprints, des modèles de déploiement de référence, à commencer par un blueprint de déport de fonction réseau Kubernetes bâti avec F5 NGINX, Intel et Red Hat. Si vous avez regardé une carte SmartNIC avant de buter sur le SDK propriétaire, cette version vise exactement ce problème.
The short answer
Le projet Open Programmable Infrastructure, hébergé par la Linux Foundation, a publié OPI Abstraction v0.1.0 le 29 juillet 2026. C'est une couche d'API neutre vis à vis des fournisseurs et indépendante du matériel, répartie sur 26 dépôts, qui couvre les API, les ponts, l'outillage, l'intégration Kubernetes, le provisionnement matériel et l'observabilité des DPU et des IPU. La version introduit également les OPI Blueprints, à commencer par un blueprint de déport de fonction réseau Kubernetes développé avec F5 NGINX, Intel et Red Hat, utilisant Red Hat OpenShift pour l'orchestration et F5 NGINX comme contrôleur de diffusion applicative. Un livre blanc associé sur la montée en charge des écosystèmes DPU et IPU a été publié le 20 juillet 2026.
Il existe une catégorie de matériel que beaucoup d'équipes d'infrastructure ont acheté, monté en baie, puis discrètement utilisé comme une carte réseau ordinaire. Les cartes réseau programmables sont techniquement impressionnantes et opérationnellement pénibles depuis des années, et la raison n'a jamais vraiment été le silicium.
Le problème visé
Un DPU ou un IPU est une carte réseau dotée de ses propres cœurs, de sa mémoire et de son système d'exploitation. Elle exécute du travail d'infrastructure qui consommerait sinon des cycles hôte : commutation virtuelle, encapsulation d'overlay, terminaison de protocoles de stockage, application de politiques de trafic. Sur un hôte rempli d'accélérateurs coûteux, chaque cœur rendu à la charge de travail est un cœur que vous n'achetez pas deux fois.
L'obstacle a toujours été logiciel. Chaque fournisseur expose ces capacités via son propre SDK, sa propre chaîne d'outils, son propre modèle de provisionnement, sa propre télémétrie. Écrire une couche d'orchestration pour deux fournisseurs revient à l'écrire deux fois, et pour un troisième, une troisième fois. Multipliez cela par un cycle de renouvellement matériel et la décision rationnelle, pour la plupart des équipes, a été de ne rien bâtir dessus.
C'est cette fragmentation que la Linux Foundation dit viser : SDK propriétaires, chaînes d'outils, API et modèles opérationnels, chacun formant un mur distinct.
Ce que contient la v0.1.0
La version est une couche d'API neutre vis à vis des fournisseurs et indépendante du matériel, répartie sur 26 dépôts. Ceux ci couvrent les définitions d'API elles mêmes, des ponts vers les interfaces existantes, de l'outillage, des intégrations Kubernetes, le provisionnement matériel et l'observabilité.
Le provisionnement et l'observabilité méritent une mention particulière, car ce sont les parties que l'on sous estime. Faire accélérer un chemin de paquets par un DPU, c'est la démonstration. Imager, configurer, superviser et mettre à niveau de façon cohérente une flotte entière au fil d'un renouvellement matériel, c'est le vrai métier, et c'est là que la divergence entre fournisseurs fait le plus mal.
Le second volet, les OPI Blueprints, n'est pas de la surface d'API supplémentaire mais des modèles de déploiement de référence. Le premier est le blueprint de déport de fonction réseau Kubernetes, développé avec F5 NGINX, Intel et Red Hat, avec Red Hat OpenShift pour l'orchestration et F5 NGINX comme contrôleur de diffusion applicative. Keysight Technologies figure aussi parmi les contributeurs.
Un blueprint bat la documentation pour une raison précise : il est tranché et testé de bout en bout. Il nomme les composants, les versions et le câblage, si bien qu'un premier déploiement relève de la reproduction et non du projet d'intégration. Joel Moses, directeur technique systèmes et plateformes chez F5, décrit ces modèles réutilisables comme la base sur laquelle les entreprises bâtissent des architectures résilientes, formulation commerciale enveloppant un point réel.
Il existe également un livre blanc, publié le 20 juillet 2026, intitulé Accelerating the AI Era: The Critical Role of Open Programmable Infrastructure in Scaling DPU and IPU Ecosystems.
Lisez bien le numéro de version
Il s'agit d'une v0.1.0, et la prendre pour autre chose serait une erreur.
Une première version coordonnée signifie que la forme des API est arrêtée et publiée, pas gelée. Il faut s'attendre à des ruptures. Ce qu'elle établit réellement, c'est un vocabulaire partagé et un déploiement de référence fonctionnel, exactement ce dont un écosystème fragmenté a besoin avant toute stabilisation.
La posture raisonnable pour la plupart des équipes est une évaluation en laboratoire sur du matériel déjà présent, pas un plan de migration. Prenez un DPU que vous possédez, déroulez le blueprint, et mesurez quelle part des capacités de votre fournisseur remonte réellement à travers l'API neutre. Cette réponse, fournisseur par fournisseur, est celle qui compte, et elle ne figure dans aucun communiqué.
Notez aussi la chronologie. OPI a été annoncé en 2022, ce qui place cette première version coordonnée à environ quatre ans de travaux. Les organismes de normalisation avancent à ce rythme, et il n'existe pas de version plus rapide de cette histoire. Arpit Joshipura, de la Linux Foundation, attribue l'urgence à l'IA, moteur d'un basculement de fond dans la façon dont les organisations envisagent la couche d'infrastructure. Simon Horman, de Red Hat, qui préside le comité technique, présente la normalisation de cette couche comme essentielle aux environnements cloud natifs.
Pourquoi les grappes IA changent le calcul
Les DPU relevaient du confort dans les flottes généralistes. Dans l'infrastructure IA, ils s'approchent du nécessaire, pour deux raisons.
La première est la contention de processeur hôte. Quand un nœud porte plusieurs accélérateurs valant plus que le reste du serveur réuni, dépenser des cœurs hôtes en traitement de paquets constitue une taxe directe sur la partie coûteuse. Le déport n'est pas une optimisation, c'est de la capacité récupérée.
La seconde est le trafic est ouest. Les trames d'entraînement et d'inférence déplacent des volumes énormes entre nœuds, et les fonctions réseau qui traitent ce trafic se trouvent directement sur le chemin du temps d'exécution des tâches. C'est la même pression qui pousse la bande passante d'interconnexion et le déplacement de l'optique dans le boîtier : le réseau a cessé d'être un service autour du calcul pour devenir une partie du calcul.
Une couche d'abstraction n'accélère rien de tout cela. Ce qu'elle fait, c'est rendre la capacité adressable depuis une couche d'orchestration sans intégration propre à chaque plateforme, ce qui est toute la différence entre un matériel autour duquel on planifie et un matériel qu'on se contente de démontrer.
Que faire concrètement
Si vous exploitez Kubernetes sur des nœuds équipés de cartes programmables, le blueprint est l'objet concret qui vaut une après midi. Reproduisez le, mesurez le, et observez ce qu'il fait à l'utilisation processeur d'un nœud sous charge réelle.
Si vous spécifiez du matériel pour un chantier livré en 2027, ajoutez une question à la grille fournisseur : quelle est votre couverture OPI, quels dépôts implémentez vous, et quel est votre engagement à mesure que les API se stabilisent. Les réponses varieront beaucoup aujourd'hui, et cette variance est elle même instructive.
Si vous aviez évalué des DPU il y a deux ou trois ans avant de les remiser faute de logiciel, voici une raison raisonnable d'y revenir. Non parce que le problème est résolu, mais parce qu'il existe pour la première fois une surface commune d'évaluation, et parce que l'écosystème Kubernetes dans lequel elle s'insère a nettement mûri entre temps.
Sources et pour aller plus loin
- Communiqué de la Linux Foundation : première version coordonnée d'OPI, Abstraction
- Site du projet Open Programmable Infrastructure
- Phoronix : OPI Abstraction v0.1 published with aiming to standardize DPU/IPU ecosystems
- Communiqué PR Newswire pour OPI Abstraction
- Linux Foundation : l'annonce initiale du projet OPI
Questions fréquentes
Qu'est ce qu'un DPU ou un IPU, et pourquoi faut il une norme ?
Une unité de traitement de données ou d'infrastructure est une carte réseau programmable dotée de ses propres cœurs, de sa mémoire et de son système d'exploitation, placée entre l'hôte et le réseau. Elle exécute le travail qui consommait auparavant des cycles hôte : commutation virtuelle, encapsulation, terminaison de protocoles de stockage, application de politiques de trafic. La norme est nécessaire parce que chaque fournisseur expose ces capacités via son propre SDK, sa propre chaîne d'outils, son propre modèle de provisionnement et son propre format de télémétrie. Écrire une couche d'orchestration valable chez deux fournisseurs revient aujourd'hui à l'écrire deux fois, et c'est précisément pourquoi beaucoup de capacité DPU achetée dort dans les baies.
Que contient exactement OPI Abstraction v0.1.0 ?
Une couche d'API neutre vis à vis des fournisseurs et indépendante du matériel, répartie sur 26 dépôts. Ces dépôts couvrent les API elles mêmes, des ponts vers les interfaces existantes, de l'outillage, des intégrations Kubernetes, le provisionnement matériel et l'observabilité. La version introduit aussi la notion d'OPI Blueprints, qui sont des modèles de déploiement de référence plutôt que de la surface d'API supplémentaire. Le premier d'entre eux est le blueprint de déport de fonction réseau Kubernetes. En parallèle du code, OPI a publié le 20 juillet 2026 un livre blanc intitulé Accelerating the AI Era: The Critical Role of Open Programmable Infrastructure in Scaling DPU and IPU Ecosystems.
Que fait le blueprint de déport de fonction réseau Kubernetes ?
C'est un modèle de déploiement de qualité production qui montre comment sortir une fonction réseau des processeurs hôtes pour la porter sur un DPU dans un environnement Kubernetes. Il a été développé conjointement par F5 NGINX, Intel et Red Hat, avec Red Hat OpenShift pour l'orchestration et F5 NGINX comme contrôleur de diffusion applicative, Keysight contribuant également au projet. L'intérêt d'un blueprint par rapport à de la documentation, c'est qu'il est tranché et testé de bout en bout : il nomme les composants, les versions et le câblage, si bien que le premier déploiement relève de la reproduction et non du projet d'intégration. Joel Moses, directeur technique systèmes et plateformes chez F5, présente ces modèles réutilisables comme la base sur laquelle les entreprises bâtissent des architectures résilientes.
Un numéro v0.1.0 signifie t il que c'est prêt pour la production ?
Non, et le numéro de version est ici le signal honnête. Une 0.1.0 est une première version coordonnée, ce qui signifie en pratique que la forme des API est arrêtée et publiée, pas gelée. Attendez vous à des ruptures. Ce que v0.1.0 établit réellement, c'est un vocabulaire commun et un déploiement de référence qui fonctionne, exactement ce dont un écosystème fragmenté a besoin avant toute stabilisation. La bonne posture pour la plupart des équipes est une évaluation en laboratoire sur du matériel déjà possédé, pas un plan de migration. Le blueprint est la partie à valeur immédiate, car il fonctionne aujourd'hui quelle que soit l'évolution des API.
Qui est derrière OPI et depuis quand ?
OPI est hébergé par la Linux Foundation et a été annoncé en 2022 pour promouvoir des standards ouverts de l'infrastructure programmable, ce qui place cette première version coordonnée à environ quatre ans de travaux. Les contributeurs cités autour de cette version comprennent F5 NGINX, Intel, Red Hat et Keysight Technologies. Arpit Joshipura, directeur général et vice président senior réseau, edge et IoT à la Linux Foundation, décrit l'IA comme le moteur d'un basculement de fond dans la façon dont les organisations envisagent la couche d'infrastructure. Simon Horman, de Red Hat, qui préside le comité technique, présente la normalisation de cette couche comme essentielle à l'avenir des environnements cloud natifs.