Magazine LLM Opensource · 15 September 2026

L’infrastructure LLM-native en 2026 : quand Kubernetes devient le système d’exploitation de l’IA

Qwen3.8-Max pèse 2,4 billions de paramètres, Kimi K3 et DeepSeek V4 Pro rivalisent avec les meilleurs modèles propriétaires, GLM-5.3 vient de talonner Kimi K3 au sommet des classements, Hy4 de Tencent s’ajoute à la course avec 770 milliards de paramètres — et pourtant le vrai goulot d’étranglement n’est plus le modèle, c’est l’infrastructure qui le sert. Pendant que les poids ouverts s’empilent sur Hugging Face, une bataille plus discrète mais tout aussi décisive se joue dans les couloirs de Kubernetes : comment ordonnancer des dizaines de milliers de GPU, partitionner finement les cartes les plus chères du marché, et surveiller en temps réel des clusters qui consomment des mégawatts. Bienvenue dans l’infrastructure LLM-native.

Le GPU est le nouveau pétrole, Kubernetes le nouveau pipeline

Il y a encore trois ans, déployer un LLM en production relevait de l’exploit artisanal : quelques GPU monolithiques, un script Python, et beaucoup de prières. En septembre 2026, la donne a changé du tout au tout. Alibaba a dévoilé Qwen3.8-Max, un modèle open source de 2,4 billions de paramètres avec une fenêtre de contexte d’un million de tokens — une taille qui aurait semblé absurde il y a deux ans. Kimi K3 de Moonshot AI, présenté comme le plus grand modèle open source jamais développé, a fait sensation fin juillet. Et la liste des modèles ouverts de qualité ne cesse de s’allonger : DeepSeek V4 Pro est sorti de sa préversion le 12 août 2026 (build V4 Pro 0813), GLM-5.3 de Z.ai a été lancé le 14 août 2026 — un modèle MoE de 743 milliards de paramètres qui réutilise la base de GLM-5.2 sans aucun nouveau paramètre, mais qui, par le seul post-entraînement, fait passer Terminal-Bench 3.0 de 4,6 % à 28,3 % et s’impose en tête du benchmark cybersécurité CyberGym avec 84,5 %, devançant Claude Sonnet 5 et GPT-5.6 Sol. Meta a publié les 10-11 août Muse Glimmer, un modèle agentique multimodal de 30 milliards de paramètres sous licence Apache 2.0, conçu pour tourner sur un simple PC ou Mac — un retournement spectaculaire après quatre mois de verrouillage. Et fin août, Tencent a ouvert à son tour les poids de Hy4 preview, un modèle de 770 milliards de paramètres (49 milliards d’actifs) avec un contexte d’un million de tokens, pensé pour le codage, la bureautique et la recherche scientifique.

Mais voici le paradoxe : un modèle de 2,4T de paramètres ne sert à rien s’il n’y a pas d’infrastructure capable de le faire tourner. Chaque requête d’inférence sur un tel modèle mobilise des centaines de gigaoctets de mémoire GPU, des dizaines de cartes interconnectées par NVLink, et une orchestration millimétrée pour que la latence reste acceptable. C’est là que Kubernetes entre en scène.

L’orchestrateur de conteneurs domine désormais le paysage : selon Jonathan Bryce, directeur exécutif de la CNCF, « 66 % des organisations utilisent déjà Kubernetes comme système d’exploitation pour l’IA », une statistique citée lors de l’annonce du programme du KubeCon Japan 2026. Les clusters de calcul pour l’IA atteignent des tailles que personne n’imaginait : Run:ai et CoreWeave démontrent des déploiements de plus de 50 000 GPU sur Kubernetes. OpenAI, selon des données non officielles rapportées par le blog Introl, orchestrerait 25 000 GPU à travers plusieurs clusters pour entraîner GPT, avec un taux d’utilisation de 97 % et des pannes GPU toutes les 2,5 heures en moyenne.

Ces chiffres, il faut le dire, sont à prendre avec des pincettes : ils proviennent d’une source unique, un blog tiers daté de décembre 2025, sans recoupement indépendant. Mais même s’ils sont approximatifs, ils dessinent une tendance claire : Kubernetes est devenu la couche de contrôle incontournable pour servir les LLM à grande échelle. Et avec cette centralité viennent deux défis majeurs : l’ordonnancement des GPU (comment allouer efficacement des ressources coûteuses et hétérogènes) et l’observabilité (comment savoir ce qui se passe réellement dans un cluster de plusieurs milliers de nœuds).

KubeCon 2026 : quand Kubernetes apprend à parler GPU

L’année 2026 a été marquée par une série d’événements qui cristallisent cette convergence. Le KubeCon + CloudNativeCon Japan, tenu fin juillet à Yokohama, a été le théâtre d’annonces majeures. Selon TechTimes, la communauté cloud-native y a franchi un cap : « l’ordonnancement GPU, l’observabilité et l’autorisation ont tous atteint la maturité de production en même temps, et c’est le premier KubeCon où les praticiens peuvent repartir en sachant que la pile complète est prête ». Trois conditions bloquantes ont été levées simultanément : la DRA (Dynamic Resource Allocation) a atteint la disponibilité générale dans Kubernetes 1.34 (sorti en août 2025) et est activée par défaut ; OpenTelemetry a gradué ; et un nouveau Special Interest Group « AI Infrastructure » a fait ses débuts sous Cloud Native Community Japan.

Mais l’annonce la plus spectaculaire est venue du KubeCon + CloudNativeCon Europe 2026, tenu à Amsterdam au printemps. Deux annonces majeures y ont été faites.

NVIDIA donne son pilote DRA au projet Kubernetes. Le constructeur a annoncé le don de son pilote Dynamic Resource Allocation (DRA) pour GPU au projet Kubernetes, avec un transfert de gouvernance vers le SIG-Node de la CNCF. La proposition a été soumise en février 2026 par Kevin Klues, ingénieur NVIDIA, sur la liste de diffusion des développeurs Kubernetes. Le code source est disponible sur GitHub sous licence Apache 2.0.

Cette décision est lourde de sens. Pendant des années, NVIDIA a maintenu ses pilotes GPU comme des composants propriétaires, intégrés à son GPU Operator mais contrôlés par l’entreprise. En les donnant à la communauté, NVIDIA acte une réalité : Kubernetes est devenu le système d’exploitation de l’IA, et il vaut mieux être un citoyen de première classe dans cet écosystème qu’un fournisseur périphérique.

La réception a été unanime, selon le site Goodtech.info qui cite les déclarations des acteurs : Sergey Kanzhelev, responsable du SIG-Node, s’est dit enthousiaste ; Microsoft collabore pour l’intégration avec Azure RDMA ; AWS a rendu DRA disponible en général sur EKS à partir de Kubernetes 1.33 ; Google Cloud l’adopte pour les GPU et TPU sur GKE ; Red Hat l’intègre dans OpenShift ; SUSE y voit un accélérateur pour sa distribution.

Le timing est crucial. Le pilote cible Kubernetes 1.32 et versions ultérieures, et DRA a atteint la disponibilité générale dans Kubernetes 1.34, sorti en août 2025 — un point confirmé par le blog officiel Kubernetes et par la couverture du KubeCon Japan 2026. Notons une divergence entre les sources : le blog Introl, daté de décembre 2025, affirmait déjà que DRA était GA en 1.31+. Il est possible que la version 1.31 ait introduit une première forme de DRA, affinée ensuite jusqu’à la GA complète en 1.34. Quoi qu’il en soit, la dynamique est claire : l’allocation dynamique des ressources est devenue une fonctionnalité standard de Kubernetes, et NVIDIA en a fait le véhicule de son support GPU de nouvelle génération.

IBM, Red Hat et Google Cloud donnent llm-d à la CNCF. Le même KubeCon Europe 2026 a vu l’annonce du don de llm-d, un framework open source d’inférence distribuée, à la CNCF comme projet sandbox. llm-d, lancé en 2025 par Neural Magic (acquis par Red Hat en 2025), est un blueprint Kubernetes réplicable pour déployer des stacks d’inférence pour n’importe quel modèle, sur n’importe quel accélérateur, dans n’importe quel cloud. Le mouvement est soutenu par NVIDIA et CoreWeave, ainsi que par AMD, Cisco, Hugging Face, Intel, Lambda et Mistral AI. Red Hat a officiellement lancé la communauté et le projet llm-d, comme l’a rapporté Computer Weekly.

Concrètement, llm-d transforme l’inférence LLM en un système distribué : il sépare les phases de préfill et de decode (désagrégation) et les exécute sur des pods distincts, permettant de scaler et de tuner chaque phase indépendamment. Il ajoute une couche de routage et d’ordonnancement LLM-aware via une extension de gateway qui route les requêtes en fonction de l’état du KV-cache, de la charge des pods et des caractéristiques matérielles, pour améliorer latence et débit. Enfin, il fournit une stack modulaire sur Kubernetes utilisant vLLM comme gateway d’inférence. L’objectif, selon Carlos Costa, IBM Research Distinguished Engineer, est de « faire du serving de modèles à grande échelle un workload cloud-native de première classe ».

Cette double annonce — DRA et llm-d — marque un tournant : la CNCF s’empare officiellement du sujet de l’inférence LLM, et les grands acteurs (NVIDIA, IBM, Red Hat, Google) alignent leurs stratégies sur Kubernetes comme socle commun.

DRA et le partitionnement fin : du GPU monolithique au GPU partagé

Pour comprendre l’importance de la DRA, il faut revenir à la situation antérieure. Kubernetes, à l’origine, traitait les GPU comme des ressources comptables opaques — une simple métrique nvidia.com/gpu sans notion de topologie, de partitionnement, ni de différence entre entraînement distribué et inférence. Le scheduler ne connaissait ni la topologie NVLink vs InfiniBand, ni les contraintes de co-placement. Résultat : des GPU sous-utilisés, des performances aléatoires, et une gestion des coûts approximative.

La DRA change la donne en permettant des demandes structurées basées sur des attributs : mémoire, partitions de calcul, contraintes de topologie. Comme le résume TechTimes, elle « permet aux workloads de déclarer des exigences spécifiques en matière de GPU et d’accélérateurs en utilisant des règles basées sur des expressions plutôt qu’en demandant des nombres entiers de dispositifs opaques ». Concrètement, elle ouvre la voie au partitionnement fin des GPU, une nécessité absolue quand une carte H100 coûte plusieurs dizaines de milliers d’euros et que personne ne veut la gaspiller pour un petit modèle d’inférence.

Trois grandes familles de partitionnement coexistent :

Le MIG (Multi-Instance GPU) de NVIDIA — la solution la plus mature. Elle permet de découper physiquement un GPU en plusieurs instances isolées, chacune avec sa propre mémoire et ses propres cœurs de calcul. Les découpages typiques vont de 1g.5gb (un septième du GPU, 5 Go de mémoire) à 2g.10gb (deux septièmes, 10 Go). Le MIG offre une isolation matérielle réelle : une instance qui plante n’affecte pas ses voisines. C’est la solution idéale pour l’inférence de modèles de petite et moyenne taille, où l’on peut servir plusieurs modèles sur une même carte physique sans risque d’interférence. NVIDIA a amélioré sa gestion MIG dans le GPU Operator 24.6+, qui ajoute également le support de l’architecture Blackwell.

Le time-slicing — une approche logicielle qui consiste à faire tourner plusieurs workloads sur un même GPU en partageant le temps de calcul. C’est simple à mettre en œuvre, mais l’isolation est faible : un workload gourmand en calcul peut dégrader les performances de ses voisins. Pour l’inférence LLM, c’est souvent un pis-aller, acceptable pour des charges légères ou des tests, risqué pour de la production.

Le vGPU (GPU virtuel) — une couche de virtualisation qui permet de partager un GPU physique entre plusieurs machines virtuelles ou conteneurs. Les solutions commerciales (NVIDIA vGPU, ou des alternatives open source) offrent un bon compromis entre flexibilité et isolation, mais ajoutent une couche de complexité et un léger surcoût en performance.

Le choix entre ces approches dépend du workload. Pour l’inférence de modèles de 7 à 13 milliards de paramètres, le MIG est souvent le meilleur choix : on peut servir plusieurs modèles sur une seule H100 avec une isolation correcte. Pour l’entraînement distribué, en revanche, le partitionnement est contre-productif : il faut au contraire agréger les GPU en groupes homogènes interconnectés par NVLink.

Un piège classique, rapporté par le blog Introl : une mauvaise planification qui sépare des GPU connectés via NVLink peut causer une dégradation de performance de 8x. Concrètement, si le scheduler place deux moitiés d’un modèle sur des GPU qui communiquent via le réseau plutôt que via NVLink, les transferts de données deviennent le goulot d’étranglement et les performances s’effondrent. C’est exactement le genre de problème que la DRA, avec ses contraintes de topologie, vise à résoudre.

Approche	Isolation	Performance	Cas d’usage typique	Coût
MIG (NVIDIA)	Matérielle (mémoire et calcul séparés)	Proche du natif, léger surcoût	Inférence multi-modèles, petits LLM	Élevé (nécessite GPU récents)
Time-slicing	Faible (partage du temps de calcul)	Variable, risque de dégradation	Tests, charges légères	Faible (logiciel pur)
vGPU	Moyenne (virtualisation)	Léger surcoût	Environnements virtualisés, multi-tenant	Moyen (couche logicielle)
GPU monolithique	Totale	Optimale	Entraînement distribué, gros modèles	Très élevé (sous-utilisation possible)

llm-d : le blueprint CNCF pour l’inférence distribuée

L’arrivée de llm-d à la CNCF est un événement majeur pour l’écosystème. Ce framework, né chez Neural Magic et porté par Red Hat, IBM et Google Cloud, répond à un besoin structurel : l’inférence LLM à grande échelle n’est pas un simple workload de serving, c’est un système distribué à part entière, avec des phases aux exigences radicalement différentes.

La désagrégation préfill/decode est l’innovation centrale. La phase de préfill (traitement du prompt) est compute-bound et gourmande en mémoire ; la phase de decode (génération token par token) est memory-bound et sensible à la latence. En les exécutant sur des pods séparés, llm-d permet de scaler horizontalement chaque phase indépendamment — par exemple, allouer plus de GPU au préfill pour absorber des pics de requêtes longues, tout en gardant un pool de decode stable pour la latence. C’est une approche que les grands fournisseurs (OpenAI, Anthropic) pratiquent en interne depuis des années, mais qui n’avait jamais été formalisée en open source de manière aussi complète.

La couche de routage LLM-aware est le deuxième pilier. L’extension de gateway proposée par llm-d route chaque requête en fonction de l’état du KV-cache (pour maximiser le cache hit), de la charge des pods et des caractéristiques matérielles (par exemple, préférer les GPU avec NVLink pour les gros modèles). C’est une amélioration mesurable de la latence et du débit par rapport à un round-robin classique.

Enfin, llm-d s’appuie sur vLLM comme moteur d’inférence de référence — un choix cohérent avec l’écosystème, puisque vLLM est devenu la bibliothèque standard pour le serving haute performance. Le framework est conçu pour être agnostique : n’importe quel modèle, n’importe quel accélérateur (NVIDIA, AMD, Intel, Habana, etc.), n’importe quel cloud. C’est cette neutralité qui a convaincu la CNCF d’en faire un projet sandbox, et qui explique le soutien d’AMD, Cisco, Hugging Face, Intel, Lambda et Mistral AI.

L’observabilité : OTel et la fin du black box

Le troisième pilier de l’infrastructure LLM-native, après l’ordonnancement et le serving, est l’observabilité. Un cluster de 50 000 GPU génère des téraoctets de métriques par seconde : utilisation mémoire, température, débit NVLink, taux de KV-cache hit, latence par requête, etc. Sans une couche d’observabilité standardisée, impossible de diagnostiquer une dégradation de performance, de dimensionner correctement les pools, ou de facturer précisément les équipes internes.

OpenTelemetry (OTel) a gradué et s’impose comme la colonne vertébrale de cette observabilité. Au KubeCon Japan 2026, la convergence entre l’ordonnancement GPU et la graduation d’OTel était le thème central, comme le souligne TechTimes : « l’ordonnancement GPU, l’observabilité et l’autorisation ont tous atteint la maturité de production en même temps ». Les métriques GPU standardisées via OTel permettent enfin de comparer des clusters hétérogènes, de suivre les coûts par workload, et d’anticiper les pannes.

La question de l’autorisation est également devenue critique : dans un cluster partagé entre plusieurs équipes, qui a le droit d’allouer des GPU ? Comment garantir que les workloads de production ne soient pas préemptés par des expérimentations ? Les mécanismes de quota et de priorité de Kubernetes, combinés à des politiques fines via OPA/Gatekeeper ou Kyverno, deviennent des éléments de première classe de la pile.

La convergence RL post-entraînement : le nouveau moteur de l’infrastructure

Le Ray Summit 2026, qui s’est tenu à San Francisco du 24 au 26 août, a mis en lumière un changement structurel : le post-entraînement par renforcement (RL) est devenu le principal moteur de convergence de l’infrastructure open source. Pour la première fois, la conférence vLLM s’est tenue en parallèle sous le même toit — un symbole fort de la fusion entre les couches d’entraînement et d’inférence.

Comme le rapporte TechTimes, « le post-entraînement RL exige une convergence de l’infrastructure open source ». Concrètement, le RL post-entraînement (RLHF, RLAIF, RLVR) nécessite des allers-retours constants entre génération (inférence) et évaluation (entraînement), avec des exigences de latence et de débit qui brouillent la frontière entre les deux. Les frameworks comme Ray (pour l’orchestration distribuée) et vLLM (pour l’inférence) doivent désormais être pensés ensemble, d’où la co-localisation des deux conférences.

Cette convergence a des implications directes pour l’infrastructure : les clusters doivent être capables de basculer dynamiquement entre des workloads d’entraînement (GPU monolithiques, NVLink) et des workloads d’inférence (partitionnement fin, MIG), parfois en quelques minutes. C’est exactement ce que la DRA et llm-d permettent, et c’est pourquoi ces annonces sont si importantes.

L’écosystème en septembre 2026 : une guerre froide des modèles qui s’intensifie

Pendant que l’infrastructure converge, la guerre des modèles fait rage. En septembre 2026, jamais autant de modèles open source n’ont tutoyé les meilleurs systèmes propriétaires. Les classements sont dominés par une poignée de poids lourds :

Qwen3.8-Max (Alibaba) : 2,4 billions de paramètres (95 milliards d’actifs), contexte d’un million de tokens. Le plus gros modèle open source jamais publié.
Kimi K3 (Moonshot AI) : présenté comme le plus grand modèle open source jamais développé, sorti fin juillet.
GLM-5.3 (Z.ai) : 743 milliards de paramètres MoE, lancé le 14 août. Sans nouveau paramètre, le post-entraînement seul fait passer Terminal-Bench 3.0 de 4,6 % à 28,3 % et le place en tête du benchmark CyberGym avec 84,5 %. Il talonne Kimi K3 au sommet des classements.
DeepSeek V4 Pro : sorti de préversion le 12 août 2026 (build V4 Pro 0813), 1,6 trillion de paramètres (49 milliards d’actifs), contexte d’un million de tokens. Prix d’entrée à 0,14 $/M tokens, sortie à 0,87 $/M tokens — nettement sous Kimi K3 sur OpenRouter, signe que la guerre des prix chinoise ne ralentit pas.
Hy4 preview (Tencent) : 770 milliards de paramètres (49 milliards d’actifs), contexte d’un million de tokens, ouvert fin août. Pensé pour le codage, la bureautique et la recherche scientifique.
Muse Glimmer (Meta) : 30 milliards de paramètres, multimodal agentique, licence Apache 2.0, conçu pour tourner sur un PC ou Mac.

Cette profusion de modèles de premier plan accentue la pression sur l’infrastructure. Chaque nouveau modèle est un défi d’ingénierie : comment le servir efficacement ? Comment le partitionner sur des GPU existants ? Comment garantir la latence pour des contextes d’un million de tokens ? Les outils comme vLLM, TensorRT-LLM et SGLang — comparés en détail par Spheron dans un guide de décision d’août 2026 — sont devenus des briques critiques, et leur choix dépend d’un arbitrage entre débit, latence et mémoire, plus que d’une course au leaderboard.

Côté sécurité, l’actualité récente rappelle que l’open source a aussi ses failles. Fin août, un chercheur a documenté une vulnérabilité dans l’API réseau d’Ollama permettant un empoisonnement persistant des modèles LLM dans les environnements d’agents IA — un problème d’architecture de communication plus que de code. Par ailleurs, une faille de sécurité présumée dans NVIDIA NemoClaw a circulé sur LinkedIn sans confirmation officielle de NVD/MITRE/NVIDIA (CVE-2026-65105, statut : non confirmé). Ces incidents soulignent que la sécurité est le talon d’Achille de l’écosystème open source, comme le notent plusieurs articles du magazine.

Enfin, le mystérieux modèle Ox Alpha, apparu sur OpenRouter le 20 août, a captivé la communauté : un modèle de raisonnement gratuit, spécialisé dans le code et les agents autonomes, dont l’origine est inconnue (certains suspectent un laboratoire chinois). Il restera accessible gratuitement jusqu’au 27 août. Un épisode qui illustre la vitalité et l’opacité du marché.

Conclusion : l’infrastructure est le nouveau champ de bataille

En septembre 2026, la conclusion s’impose : les modèles open source ont gagné la bataille de la qualité. Qwen3.8-Max, Kimi K3, GLM-5.3, DeepSeek V4 Pro, Hy4 — les poids ouverts rivalisent avec les meilleurs modèles propriétaires sur les benchmarks de codage, de cybersécurité et de raisonnement. Mais cette abondance crée un nouveau goulot d’étranglement : l’infrastructure.

Kubernetes s’est imposé comme la couche de contrôle universelle, avec 66 % des organisations qui l’utilisent comme système d’exploitation pour l’IA. La DRA, devenue GA en Kubernetes 1.34, permet un partitionnement fin des GPU. llm-d, donné à la CNCF, fournit un blueprint complet pour l’inférence distribuée. OpenTelemetry apporte l’observabilité. Et la convergence entre Ray et vLLM, symbolisée par le Ray Summit 2026, prépare l’ère du post-entraînement RL à grande échelle.

La prochaine bataille ne se jouera pas sur les leaderboards, mais dans les clusters : qui saura orchestrer le plus efficacement des dizaines de milliers de GPU, qui minimisera les coûts d’inférence, qui garantira la latence pour des contextes d’un million de tokens ? C’est là que se décidera la domination de l’écosystème open source.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens

📬 Restez à la pointe

Recevez chaque semaine les nouveautés de ce magazine par email.

💬 Une remarque, une correction ?

Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Kubernetes à l’heure des LLM géants : ordonnancement GPU, observabilité et la course à l’infrastructure