Istio et Kueue pour certains, Traefik et Volcano pour d’autres ; parfois Kubeflow, parfois KubeRay, ou les deux… Les fournisseurs de plates-formes Kubernetes ont emprunté divers chemins pour démontrer leur conformité à la « spécification IA » élaborée par la CNCF.

Cette spec définit un ensemble de capacités, d’API et de configurations qu’un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité.

Un premier tour d’autocertification avec 9 éléments obligatoires

Les travaux avaient officiellement démarré cet été. Une v1 a été publiée depuis et un premier round de certification a été lancé. Plus précisément d’autocertification : le processus est pour le moment déclaratif. Une suite de tests automatisés est censée prendre le relais, mais pas avant 2026.

Beaucoup d’éléments inscrits dans la spécification ne sont, en tout cas pour le moment, pas obligatoires. Parmi eux :

• Assurer que des pilotes compatibles et les configs runtime correspondantes sont correctement installés et maintenus sur les nœuds dotés d’accélérateurs
• Faciliter le tirage de grosses images de conteneurs (par exemple à travers une réplication ou une mise en cache près des nœuds d’exécution)
• Permettre la gestion unifiée de jobs indépendants via un mécanisme gérant les API JobSet
• Autoriser le déploiement de conteneurs confidentiels dans des environnements d’exécution sécurisés (enclaves matérielles)
• Fournir un mécanisme de détection des accélérateurs en erreur, avec éventuellement une remédiation automatisée

9 éléments sont actuellement obligatoires. Dans les grandes lignes :

1. Prendre en charge l’allocation dynamique des ressources (DRA)
2. Gérer la Gateway API de Kubernetes, dans une implémentation permettant une « gestion avancée » pour les services d’inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services…)
3. Permettre d’installer et d’exploiter au moins une solution de planification des gangs
4. Gérer la mise à l’échelle verticale des groupes de nœuds contenant des types d’accélérateurs spécifiques
5. Si présent, assurer un fonctionnement correct de l’HorizontalPodAutoscaler pour les pods qui exploitent des accélérateurs
6. Exposer, pour les types d’accélérateurs pris en charge, des métriques granulaires, via un endpoint standardisé, et dans un format lisible par la machine (au minimum, taux d’utilisation par accélérateur + occupation mémoire)
7. Découverte et collecte de métriques de workloads dans un format standard
8. Isolation des accès aux accélérateurs depuis les conteneurs
9. Possibilité d’installer et d’exécuter de façon fiable au moins un opérateur IA complexe disposant d’un CRD

Chaque certification vaut pour un an et s’applique à une version spécifique de Kubernetes. En l’état, soit la 1.33 (8 solutions certifiées), soit la 1.34 (11 solutions certifiées).

Les 8 solutions (auto)certifiées sur Kubernetes 1.33

Premier dans l’ordre alphabétique, CoreWeave Kubernetes Services (CKS).
Entre autres commentaires insérés dans sa déclaration de conformité, le « néo-cloud » américain – voir notre article à son sujet – rappelle gérer le planificateur SUNK (Slurm on Kubernetes). Il explique aussi que l’isolation des accès est pour l’instant traitée avec des plug-in, en attendant de passer au DRA lorsque le support fournisseur sera plus mature.

DaoCloud Enterprise n’implémente pas le DRA (il faut dire que les API sont désactivées par défaut sur Kubernetes 1.33, de sorte que la spec n’impose pas la fonctionnalité). Destiné à l’exécution sur site, il ne fournit pas non plus d’autoscaler vertical.

Pour sa plate-forme Gardener, la NeoNephos Foundation (projet de la Fondation Linux Europe) livre une preuve d’implémentation de la Gateway API via Traefik. Et de la planification des gangs via Kueue. L’autoscaling horizontal est géré avec une stack associant Prometheus et DCGM (NVIDIA Datacenter GPU Manager). Comme « opérateur IA complexe », KubeRay a été choisi.

L’entreprise allemande Giant Swarm fournit la plate-forme du même nom. Elle n’a pas ajouté de commentaires à son autocertification. Les renvois vers sa documentation montrent toutefois que Kueue a été sélectionné pour démontrer la conformité sur la partie planification des gangs, et KubeRay en guise d’opérateur IA.

Red Hat est également au rendez-vous, avec la dernière version d’OpenShift (4.20). Lui aussi a opté pour Kueue. Comme opérateur IA, la filiale d’IBM a utilisé Kubeflow Trainer, avec plusieurs CRD (TrainJob, TrainingRuntime, ClusterTrainingRuntime). Elle précise, concernant les métriques d’accélérateurs, propose des opérateurs dédiés pour les GPU AMD en plus des GPU NVIDIA.

SUSE a autocertifié RKE2 (deuxième itération de Rancher Kubernetes Engine). Là aussi sans commentaires supplémentaires, mais avec un renvoi vers une nouvelle section de sa doc consacrée à la conformité vis-à-vis de la spec CNCF. On y découvre que Volcano a été privilégié pour la planification des gangs. Et que pour la collecte de métriques, la solution SUSE AI est mise en avant.

Red Hat a autocertifié un deuxième produit : ROSA (Red Hat OpenShift Service on AWS), dans sa dernière version. Avec, la même base que pour OpenShift, mais des validations spécifiques.

Talos Linux, OS immuable pour Kubernetes, a également été certifié, par son éditeur Sidero Labs. Lequel signale qu’aucun autoscaler vertical spécifique n’est fourni et que le produit n’embarque pas, en standard, d’outils d’observabilité.

Les 11 solutions (auto)certifiées sur Kubernetes 1.34

Premier dans l’ordre alphabétique, ACK (Alibaba Cloud Container Service for Kubernetes). Sa conformité a été démontrée en utilisant à la fois Spark et Ray. Sur la partie métriques, Alibaba a exploité son Prometheus managé.

AKS (Azure Kubernetes Service) a aussi été autocertifié. Microsoft a utilisé Istio, Kueue et DCGM, entre autres. Pour les opérateurs IA, il a fait un choix particulier au-delà de Ray : KAITO (Kubernetes AI Toolchain Operator), projet en sandbox à la CNCF et qui repose sur vLLM.

Baidu a autocertifié sa solution CCE (Cloud Container Engine). Avec Volcano pour l’implémentation Gateway API, du Prometheus managé pour l’autoscaling horizontal… et un déploiement SGLang pour la partie contrôleur IA.

Autocertifié sur Kubernetes 1.33, CKS (CoreWeave Kubernetes Service) l’est aussi sur la version 1.34.

Amazon a essentiellement recouru à ses propres services pour démontrer la conformité d’EKS (Elastic Kubernetes Service). Entre autres, son contrôleur AWS Load Balancer, son planificateur AWS Batch, son outil de supervision CloudWatch et son collecteur de métriques Neuron Monitor.

GKE (Google Kubernetes Engine) est également autocertifié. Comme Amazon, Google met en avant ses propres services… et un tuto, destiné à construire une plate-forme ML associant Ray et Kubeflow.

KKP (Kubermatic Kubernetes Platform) a sa propre stack MLA (« Monitoring Logging & Alerting »), exploitée dans le cadre de son autocertification. Il a aussi son propre contrôleur de passerelle (KubeLB).

Avec LKE (Linode Kubernetes Engine), Akamai a son propre autoscaler vertical. Pour les pods, il passe par l’adaptateur Prometheus. La collecte de métriques relatives aux accélérateurs passe par DCGM. Istio est utilisé comme implémentation référente de la Gateway API.

Istio a aussi été le choix d’Oracle pour démontrer la conformité d’OKE (OCI Kubernetes Engine). On aura noté que pour les métriques de workloads, le groupe américain a son propre projet OCI GPU Scanner, mis à disposition sous licence libre (UPL) et installable soit via Terraform, soit via Helm, soit comme add-on depuis la console OCI.

Autocertifié sur Kubernetes 1.33, Talos Linux l’est aussi sur la version 1.34.

Le dernier dans l’ordre alphabétique est VKS (VMware Kubernetes Service). VMware l’a autocertifié en s’appuyant notamment sur Istio, Kueue, Prometheus, DCGM et KubeRay.

Illustration

The post Kubernetes : les 17 premières plates-formes « certifiées IA » appeared first on Silicon.fr.

 

Dans l’écosystème Microsoft évolueront peut-être bientôt des « utilisateurs agentiques » ayant leur identité, leur place dans l’organigramme… et leur licence.

Des informations à ce sujet seront possiblement communiquées la semaine prochaine à la conférence Ignite. En attendant, il y a des faisceaux d’indices. Notamment un message publié début novembre dans le centre d’administration Microsoft 365. Il a disparu depuis, comme l’élement de roadmap associé. On a pu y apercevoir une nouvelle marque : Agent 365.

Les agents en question seraient créés à partir de modèles préconfigurés.
Il appartiendrait aux admins de choisir lesquels de ces modèles publier. Par défaut, l’ensemble des utilisateurs du locataire y auraient accès, à deux endroits : Teams (section Apps) et le magasin d’agents Microsoft 365. Leurs demandes de création d’agents sur la base de ces templates remonteraient aux admins. Qui, en cas d’approbation, auraient à assigner une licence A365 à chaque agent.

Le message publié dans le centre d’administration évoquait un déploiement progressif à partir de mi-novembre, sur desktop (dans Teams et Microsoft 365 Copilot).

Agent 365, une démarche avant tout commerciale

Au vu de ces quelques éléments, l’évolution qui se prépare ne semble pas tant technologique que commerciale. Il se dit d’ailleurs que la marque Agent 365 pourrait prendre le relais de Microsoft 365 Copilot. Potentiellement une manière d’atténuer la confusion que le branding actuel suscite jusqu’en interne.

Après deux ans de commercialisation, l’adoption de Microsoft 365 Copilot apparaît décevante. En tout cas d’après les affirmations d’Ed Zitron. L’intéressé, qui s’est fait une solide réputation de pourfendeur de l’IA générative, affirmait cet été que le taux de transformation au sein de la base Microsoft 365 était inférieur à 2 %. Un chiffre que Microsoft n’a pas démenti.

L’usage – mais pas forcément la conversion – a pu augmenter depuis, entre autres avec la mise à disposition gratuite de quelques fonctionnaltiés Copilot Chat dans Word, Excel, PowerPoint, OneNote et Outlook (essentiellement, des conversations basées sur le web et sur le fichier ouvert).
Divers abonnements initialement autonomes (Copilot pour les ventes, pour le service et pour la finance, par exemple) ont par ailleurs été fusionnés dans Microsoft 365 Copilot.

À consulter en complément sur le sujet Microsoft 365 Copilot :

Les conditions d’accès aux modèles d’Anthropic
Les leçons d’un test à grande échelle

Illustration générée par IA

The post Agent 365 : vers un nouveau modèle économique chez Microsoft appeared first on Silicon.fr.

Broadcom et VMware, cela fera bientôt deux ans.

Le 22 novembre 2023, le premier finalisait l’acquisition du second. Il n’allait pas tarder à en bouleverser la politique commerciale, avec les conséquences que l’on sait.

Quantité de fournisseurs d’offres concurrentes se sont engouffrés dans la brèche, tentant de capter le replatforming des parcs de VM. Red Hat n’y a pas fait exception. Il a évidemment mis en avant la conteneurisation sur OpenShift. Mais aussi la brique de virtualisation intégrée à la plate-forme depuis l’été 2020. Jusqu’à en faire un produit spécifique, lancé début 2025 : OpenShift Virtualization Engine, qui n’inclut pas de droit d’usage de conteneurs applicatifs.

Topologie localnet et instances personnalisées

Au-delà de la stratégie commerciale, OpenShift Virtualization a connu des évolutions fonctionnelles notables depuis la fusion Broadcom-VMware. Six versions mineures sont sorties, à commencer par la 4.15 (publiée le 27 février 2024 ; arrivée en fin de vie le 27 août 2025).

Cette version avait notamment apporté la gestion du branchement à chaud d’interfaces réseau secondaires sur les VM (hors interfaces SR-IOV). Elle avait aussi ajouté la prise en charge de la topologie localnet pour les réseaux secondaires OVN-Kubernetes (connexion à la sous-couche physique).

Autre élément ajouté : le KSM (kernel samepage merging). Cette fonctionnalité s’enclenche lorsqu’un nœud est surchargé. Elle déduplique les données identiques trouvées dans les pages mémoire des VM.

OpenShift Virtualization 4.15 a également permis d’activer l’accès aux logs console des invités et de configurer des clusters pour les workloads DPDK (Data Plane Development Kit, délégation du traitement des paquets TCP à des processus en espace utilisateur) sur SR-IOV. La console web avait été enrichie en parallèle pour permettre l’installation et l’édition de types d’instances personnalisés. Et pour importer des secrets depuis d’autres projets lors de l’ajout d’une clé SSH publique à une VM en cours de création ou d’un secret à une VM existante.

Hotplug de vCPU et accès headless aux VM

Le 27 juin 2024 sortait OpenShift Virtualization 4.16. Cette version est actuellement en phase de maintenance, jusqu’au 27 décembre 2025. Le support étendu durera jusqu’au 27 juin 2026. Avec elle, le hotplug de vCPU est passé en disponibilité générale.

Il est aussi devenu possible d’accéder à une VM à travers des services Kubernetes headless, en utilisant son nom de domaine interne. Et d’activer la feature gate AutoResourceLimits pour gérer automatiquement les limites CPU et mémoire des VM.

OpenShift Virtualization 4.16 a aussi ajouté la possibilité de sélectionner les options sysprep à la création de VM Windows plutôt que par après. Et d’exposer certaines métriques d’hôte ou d’invité au sein des VM, en ligne de commande ou via l’outil vm-dump-metrics.

Gestion de la densité des workloads et exposition de périphériques USB

OpenShift Virtualization 4.17, sorti le 1^er octobre 2024, arrivera en fin de vie le 1^er avril 2026, sans phase de support étendu.

Avec cette version, Red Hat a certifié la prise en charge de Windows Server 2025 comme OS invité. Il a aussi permis de sélectionner un namespace personnalisé pour ses golden images. Et donné la possibilité d’accroître la densité de workloads dans les VM en surréservant (overcommit) la RAM. Comme d’exposer des périphériques USB dans un cluster, de sorte que les propriétaires de VM peuvent ensuite les assigner.

Le hotplug de CPU et de mémoire depuis la console est passé en disponibilité générale avec OpenShift Virtualization 4.17. Même chose pour la configuration de stratégies d’éviction de VM à l’échelle d’un cluster.

Réseaux définis par l’utilisateur et changement à chaud de type d’instance

Sorti le 25 février 2025, OpenShift Virtualization 4.18 arrivera en fin de maintenance le 25 août 2026. Le support étendu durera jusqu’au 25 février 2027.

Depuis cette version, on peut connecter une VM à un réseau défini par l’utilisateur sur l’interface primaire. On peut aussi changer le type d’instance associé à une VM en cours d’exécution, sans redémarrage.

Autre ajout : la capacité de créer des snapshots de VM auxquelles on ajoute un vTPM. Et de les restaurer à partir de ces snapshots (mais pas d’en créer de nouvelles, ni de les cloner).

La console a quant à elle évolué pour permettre de contrôler simultanément l’état de plusieurs VM. Et de visualiser des métriques de niveau workload pour les ressources disque, CPU et réseau allouées.

Protection des VM et threads I/O multiples pour le stockage flash

OpenShift Virtualization 4.19 fut publié le 17 juin 2025. Il entrera en phase de maintenance le 17 décembre 2025 et n’aura pas de support étendu.

Avec cette version, RHEL 10 rejoint la liste des OS invités certifiés. Red Hat introduit aussi un mécanisme de protection des VM contre la suppression. Et permet de mettre à jour le type de machine pour plusieurs VM à la fois depuis le CLI OpenShift.

La topologie localnet sur OVN-Kubernetes est devenue utilisable pour connecter une VM à un réseau secondaire défini par l’utilisateur. Et il est devenu possible de configurer un manifeste NodeNetworkConfigurationPolicy pour activer l’écoute LLDP sur tous les ports Ethernet d’un cluster.

Autre nouveauté : la possibilité de configurer plusieurs threads I/O pour les VM utilisant de la mémoire flash. Quant à la console, elle a évolué pour proposer davantage d’actions groupées sur les VM (gestion des étiquettes, déplacement dans un autre dossier au sein d’un même namespace…). Des métriques supplémentaires ont par ailleurs été mises à disposition, concernant les migrations, les vNIC et le stockage alloué aux VM.

Topologie NUMA et saut de versions de correction

La dernière version mineure en date (4.20) est sortie le 21 octobre 2025. Elle arrivera en fin de vie le 21 avril 2027, sans support étendu.

Avec elle, Red Hat permet de sauter des versions de correction (pas besoin d’installer toutes les versions intermédiaires lorsqu’on met à jour).

Plusieurs éléments passent en disponibilité générale, dont la possibilité d’exploiter la topologie NUMA (non-uniform memory access) pour les VM. Elle permet de définir des zones au sein desquelles les CPU bénéficient d’un accès plus rapide aux ressources locales que les CPU externes.

Le profil KubeVirtRelieveAndMigrate, qui améliore la stabilité de l’éviction de VM lors des migrations à chaud, est également passé en disponibilité générale. Idem pour la possibilité de déployer OpenShift Virtualization sur OCI et en bare metal sur cluster ARM64.

Dans la console, on peut désormais, lors de migrations à chaud, spécifier le nœud vers lequel déplacer une VM. Parallèlement, la procédure de hotplug de disques s’est enrichie d’une étape optionnelle permettant de sélectionner un type de bus.

Illustration © Annika – Adobe Stock

The post Comment la virtualisation sur OpenShift a évolué depuis la fusion Broadcom-VMware appeared first on Silicon.fr.

Il y a avantage quantique lorsque l’association des méthodes quantiques et classiques est plus performante que les méthodes classiques seules.

Aux dernières nouvelles, c’est la définition que donne IBM.

Il n’en a pas toujours été ainsi. En tout cas dans la communication publique du groupe américain.
Encore récemment, il n’était pas explicitement question d’association classique-quantique. La notion était simplement décrite comme la capacité d’un ordinateur quantique à effectuer un calcul de manière plus précise, économique ou efficace (« more accurately, cheaply, or efficiently« ) qu’un ordinateur classique.

Avantage quantique : une méthodo, puis un tracker

Un livre blanc publié à l’été 2025 avec la start-up française PASQAL a témoigné de l’évolution du discours. Y est formulé le postulat selon lequel atteindre un avantage quantique à court terme suppose une intégration avec les infrastructures HPC.

Rappelant, à ce sujet, avoir publié des plug-in Slurm, les deux entreprises établissent surtout, par l’intermédiaire de ce whitepaper, une méthodologie de validation scientifique de l’avantage quantique.

Ce jalon posé, IBM a créé, avec BlueQubit (USA), Algorithmiq (Finlande) et des chercheurs du Flatiron Institute, un « tracker d’avantage quantique ». Lui et ses partenaires sur ce projet ont soumis diverses expérimentations, réparties en trois catégories :

• Estimation des observables quantiques
• Algorithmes quantiques variationnels (destinés à résoudre des problèmes combinatoires)
• Problèmes pour lesquels la vérification quantique est efficace

À travers son API C, Qiskit se rapproche du HPC

L’un des derniers marqueurs de rapprochement vis-à-vis des environnements HPC fut l’introduction d’une fonction autonome de transpilation de circuits dans l’API C de Qiskit. C’était avec la version 2.2 du SDK, publiée en octobre 2025.

Cette API, introduite au printemps 2025 avec Qiskit 2.0, est dotée d’une interface de fonction étrangère qui permet d’exploiter d’autres langages. En première ligne, C++, particulièrement populaire pour le calcul scientifique. Et, plus globalement, les langages compilés (Qiskit a été développé à l’origine en Python, un langage interprété).

Relay-BP, Samplomatic… Des briques à l’édifice de la correction d’erreurs

Entre les deux, Qiskit 2.1 a introduit la possibilité d’ajouter des flags à des régions spécifiques d’un circuit. Une bibliothèque logicielle – Samplomatic, en bêta – y a été adossée. Elle permet de personnaliser ces régions. Et, au bout, de faciliter la construction de circuits dynamiques (qui incorporent des opérations classiques au cours de leur exécution).

Cette personnalisation est aussi censée faciliter la mise en œuvre de techniques de correction d’erreurs.

Sur ce volet, IBM compte notamment avoir assemblé, pour fin 2025, un prototype de processeur. Appelé Loon, il doit réunir divers composantes-clés dont la faisabilité a déjà été démontrée séparément : connectivité à 6 voies, accroissement des couches de routage à la surface de la puce, coupleurs physiquement plus longs, techniques de réinitialisation plus rapide des qubits…

Parmi les autres composantes-clés annoncées cette année, il y a Relay-BP, un algorithme de décodage d’erreurs. IBM en a récemment annoncé une implémentation sur FPGA AMD. Il annonce « moins de 480 nanosecondes » par tâche de décodage, en reconnaissant qu’il reste du travail dans la perspective d’un passage à l’échelle.

Nighthawk en attendant Starling

Relay-BP est arrivé en avance par rapport à la feuille de route. Il était effectivement prévu pour 2026.

À ce même horizon, IBM entend ajouter à Qiskit des outils de profilage de workloads hybrides (quantique-classique). Il prévoit aussi de lancer Kookabura, puce censée réunir unité de calcul et mémoire quantique.

En attendant, la dernière nouveauté côté processeurs s’appelle Nighthawk. Elle prend la suite de la génération Heron avec moins de qubits pour commencer (120 contre 156), mais autant de portes logiques (5000), davantage de coupleurs (218 vs 176), un taux d’erreur médian réduit… et la perspective de monter en capacité :

• Pour 2026 : 7500 portes et jusqu’à 3 x 120 qubits
• Pour 2027 : 10 000 portes et jusqu’à 9 x 120 qubits
• Pour 2028 : 15 000 portes et jusqu’à 9 x 120 qubits

Un ordinateur quantique tolérant aux erreurs reste visé pour 2029. Avec, en ligne de mire, la puce Starling (100 millions de portes, 200 qubits). Blue Jay (1 milliard de portes, 2000 qubits) est censé suivre en 2030.

IBM prévoit un jeu d’instructions tolérant aux erreurs pour 2028

Depuis 2024, Qiskit est assorti d’un catalogue de fonctions : résolution d’équations différentielles (ColibriTD), de problèmes de classification (Multiverse Computing), de problèmes d’optimisation (Q-CTRL, Kipu Quantum), etc.

Ces fonctions trouveront une continuité sous la forme de bibliothèques d’applications quantiques. Les premières sont prévues pour 2027. IBM promet, pour la même échéance, un accélérateur pour au moins un workflow ayant démontré un avantage quantique. Puis, pour 2028, un jeu d’instructions tolérant aux erreurs.

À consulter en complément :

La roadmap d’IBM érige 2029 en année charnière
Transition post-quantique : l’agenda de l’ANSSI se remplit
D-Wave revendique la suprématie quantique : qui l’a fait avant lui ?
Avec son processeur quantique Ocelot, Amazon mise sur les qubits de chat

Illustration © IBM

The post IBM vise l’avantage quantique en tandem avec le HPC appeared first on Silicon.fr.