KubeCON 2026 : la CNCF s’empare du sujet de l’inférence

Interview de Jonathan Bryce

LeMagIT est allé à la rencontre de Jonathan Bryce pour mieux comprendre la nouvelle stratégie autour de l’inférence qu’il insuffle à la CNCF depuis qu’il en a repris les rênes, l’été dernier. Et aussi discerner l’influence de ce récent donateur, de classe Platinum, qu’est Nvidia. Interview.

LeMagIT : Qu’allez-vous définir exactement dans AI Conformance Program et dans quelle mesure Nvidia compte-t-il y participer ?

Jonathan Bryce : L’AI Conformance Program sera à l’IA ce que notre précédent Kubernetes Conformance Program était à Kubernetes ; un ensemble de fonctionnalités et d’API qu’un éditeur doit prouver qu’il respecte pour être conforme au standard. Le Kubernetes Conformance Program a huit ans et tous les fournisseurs de cloud, comme tous les éditeurs d’une distribution Kubernetes s’y sont conformés.

Ce que ces programmes signifient, c’est que si j’utilise un outil, ou une méthodologie de déploiement, ou une application à façon qui est conforme à ce programme, alors cet outil, cette méthodologie ou cette application fonctionneront partout de la même façon.

Nous avons considéré qu’il était important de dédier un programme à la conformité de l’IA, car celle-ci a des besoins techniques qui vont au-delà de ce qui doit être standard dans Kubernetes. Par exemple, un support spécifique des accélérateurs, notamment ce concept de pilote DRA. Donc, une des premières exigences de l’AI Conformance Program est de supporter un pilote DRA, de sorte que toute plateforme d’exécution d’une IA soit capable d’accepter une application conçue pour prendre en charge le niveau de puissance de calcul du GPU.

Le concept de pilote DRA va au-delà de Nvidia. Nvidia a simplement offert à la fondation le code source qui permet de piloter ses GPU au travers d’une API standard et qui va permettre à une application utilisant un GPU de Nvidia de passer nos tests de conformité. Mais une application peut réussir les tests de conformité en utilisant un pilote DRA pour l’accélérateur d’une autre marque.

Nvidia a sa propre plateforme de développement : Cuda. S’agit-il de proposer une alternative à Cuda ?

Non. Il s’agit de standardiser la manière dont une application demande des ressources. Une application conforme qui utilise des GPU Nvidia sera par exemple une application qui dit de manière standard à l’API de Kubernetes qu’elle a besoin de telle version des bibliothèques Cuda pour fonctionner. Mais l’application conforme pourra aussi dire de manière standard « je veux utiliser un GPU AMD qui consomme moins et qui coûte moins cher ».

Donc le standard concerne davantage la manière dont l’application parle à l’infrastructure que la façon dont elle utilise l’infrastructure. De la même façon, l’API Kubernetes se moque de savoir que l’application est programmée en Java ou qu’elle utilise une base de données PostgreSQL. Elle permet juste à l’application de dire de manière standard qu’elle a besoin d’un serveur PostgreSQL.

Mais concrètement, vos efforts de standardisation vont-ils favoriser les concurrents de Nvidia ?

Je ne pense pas qu’il s’agisse de concurrencer les plateformes de Nvidia, il s’agit juste d’aider les gens à avoir le choix parmi plusieurs alternatives. Et à mon avis, vu les résultats de Nvidia, ils ont une grande marge de manœuvre avant d’être inquiétés par les ventes de la concurrence.

De toute façon, je pense qu’en favorisant le choix des accélérateurs matériels, nous allons étendre le marché et ce sera autant bénéfique à Nvidia qu’à ses concurrents. Parce que quand, en tant que leader, vous avez une très importante part de marché, votre seul désir est que le marché s’agrandisse rapidement pour que vous puissiez continuer de croître. Et cette croissance va aussi créer de nouveaux segments de marché qui seront autant d’opportunités de vente pour les concurrents.

L’accès au stockage de données est une autre thématique importante concernant les infrastructures pour l’IA. Allez-vous standardiser quelque chose à ce sujet ?

Oui. Je pense que d’une manière ou d’une autre cela se retrouvera dans les spécificités de notre programme de conformité pour l’IA. De la même manière que des fonctionnalités pour le stockage et le réseau sont arrivées dans l’API de Kubernetes.  

Mais un point typique du stockage en IA est le déchargement sur des disques des KV-Caches. Et à ce sujet, les réponses vont d’abord venir de LLM-d.

De quelle manière LLM-d est-il impliqué dans le stockage des IA ?

LLM-d concerne le routage des prompts vers plusieurs GPU. Comme vous le savez, vLLM, lui, ne fonctionne que sur un seul GPU. Mais si les capacités de ce GPU ne suffisent plus, vous voudrez router la requête vers un autre GPU plus puissant. C’est ce que fait LLM-d.

Mais encore faut-il que vous communiquiez à cet autre GPU tous les tokens qu’il a déjà traités ; vous n’allez pas lui redemander de les recalculer. Ces tokens sont dans la mémoire du premier GPU, dans un KV-Cache, et LLM-d a des fonctions pour récupérer ce KV-Cache sur disque, puis, de là, le mettre à la disposition des autres GPU.

Après, LLM-d n’en est qu’à ses débuts. Mais il implémente déjà des concepts liés au stockage, pour justement préremplir, depuis le stockage, des données déjà calculées et qui pourraient servir dans les prompts d’autres instances, avec la promesse d’accélérer la génération de réponse par 8, par 15 et même par 40 parfois.

C’est-à-dire que plutôt qu’implémenter un stockage accéléré pour un GPU, LLM-d va plutôt gérer un stockage global pour tout un cluster d’inférence. Et d’ailleurs, il le fait avec des algorithmes similaires à ceux de CSI, le système des pilotes Kubernetes pour le stockage.

LLM-d a-t-il vocation à chapeauter un pool de GPU hétérogènes et à distribuer leurs capacités de calcul aux applications ?

Non. Dans l’exemple que j’ai pris, LLM-d passe d’un GPU à un autre. Le second GPU vers lequel pourra être reroutée la suite d’une conversation avec une IA pourra en effet être d’une tout autre nature, d’une tout autre marque que le premier (sauf si, comme nous le disions, l’application nécessite de spécifiquement parler à des GPU qui utilisent des bibliothèques Cuda, auquel cas ce serait nécessairement un autre GPU Nvidia).

La gestion d’un pool global d’accélérateurs hétérogènes et la distribution de portions de puissance de calcul de ce pool à des IA sont plutôt le sujet d’un autre projet Open source : HAMi, également chapeauté par la CNCF.

HAMi a cette faculté de définir des tranches de puissance avec une granularité très fine. Certains GPU sont livrés avec la capacité d’être virtualisés, mais d’ordinaire ce n’est pas très précis : un GPU peut au mieux être divisé en 8, voire en 16 GPUs virtuels. HAMi va être capable de descendre bien plus bas. Il va aussi être capable d’augmenter dynamiquement la puissance d’un accélérateur virtuel et tout cela en puisant dans un pool constitué d’accélérateurs très différents.

HAMi est en ce moment beaucoup utilisé en Chine, où les entreprises déploient des clusters qui contiennent plusieurs types de GPU. Car il y a en Chine plusieurs entreprises qui développent des GPU alternatifs, avec différents profils de coûts et de performances.

Le point intéressant est qu’il est possible de combiner le fonctionnement d’HAMi avec celui de LLM-d. De sorte que LLM-d ne reroute plus les traitements vers un autre GPU de puissance fixe, mais vers un accélérateur virtuel proposé par HAMi avec la puissance attendue.

Notre but est véritablement de distribuer la puissance des GPU comme nous l’avons fait avec la puissance des serveurs applicatifs, des serveurs de base de données ou encore des serveurs pour les télécoms.