La version 0.5.0 du pilote DRA (Dynamic Resource Allocation) de NVIDIA apporte des améliorations significatives à son support des déploiements GPU et des ComputeDomains, tout en renforçant la fiabilité générale de l’outil. Selon github.com, cette mise à jour intègre le support des déploiements avec l’opérateur NVIDIA GPU Operator en version 26.7.0, ce qui simplifie l’intégration dans les environnements Kubernetes.

Parmi les ajouts notables, on trouve désormais le support du passthrough sur les systèmes NVIDIA Grace et Blackwell, y compris les variantes de module VFIO. De plus, le pilote permet une gestion du partage de GPU à travers différents espaces de noms grâce à la fonctionnalité de Capacité Consommable (Consumable Capacity) de DRA. C’est une avancée qui permet de mieux gérer les ressources partagées sur des machines puissantes.

Gestion fine des ressources et topologies complexes

Ce qui change pour les administrateurs de clusters, c’est la complexification maîtrisée des configurations. Le support de l’IMEX géré par l’hôte (Host-managed IMEX) permet aux opérateurs de gérer le service nvidia-imex au niveau du hôte, au lieu de laisser le pilote DRA créer des DaemonSets dédiés pour chaque ComputeDomain. Cette option est actuellement en phase alpha, mais elle offre une flexibilité notable. Par ailleurs, le pilote enrichit les attributs de périphériques DRA en publiant des attributs de type liste, comme resource.kubernetes.io/numaNode, offrant une meilleure visibilité sur la topologie NUMA des GPUs.

La gestion de la partition du Fabric Manager est également étendue, permettant l’activation et la désactivation des partitions pour les configurations multi-GPU supportées via passthrough. En outre, la version apporte la prise en charge du MPS multi-utilisateur, essentielle pour des charges de travail gourmandes nécessitant le partage intensif des ressources de calcul.

L’intégration dans l’écosystème AI

Ces évolutions arrivent à un moment où l’infrastructure AI cherche à standardiser ses déploiements. NVIDIA pousse d’ailleurs, via son AI Cluster Runtime (AICR), à fournir des artefacts de configuration validés et reproductibles pour les clusters Kubernetes accélérés par GPU. D’après docs.nvidia.com, AICR génère des fichiers Helm, Terraform ou Flux basés sur la description de l’environnement, garantissant une provenance d’image ancrée au niveau SLSA Build Level 3.

Cette démarche de standardisation est d’ailleurs renforcée par les annonces concernant les futures architectures. Selon un article de NVIDIA daté de novembre 2026, la mise en place de clusters Kubernetes pour les nouvelles architectures, telles que le Vera Rubin NVL72, exige une coordination extrêmement précise entre les pilotes, les noyaux et les opérateurs. L’opérateur NVIDIA GPU Operator, mentionné dans la source 1, est un maillon de cette chaîne de validation.

En effet, pour les configurations avancées, le pilote DRA v0.5.0 a été utilisé dans des tests avec l’opérateur GPU Operator v26.7.0 afin de valider des scénarios complexes, notamment l’end-to-end pour les recettes de training et inference sur ces nouveaux systèmes.

On sait que les systèmes Kubernetes peuvent apparaître sains de l’extérieur, même si les performances des modèles d’IA sont décevantes pour l’utilisateur final. C’est pourquoi des outils d’observabilité sont de plus en plus sollicités, afin de passer d’une simple vérification du statut à une validation concrète de la latence en charge.

Il faudra surveiller comment ces fonctionnalités alpha, comme le Host-managed IMEX, seront intégrées dans les prochaines versions pour passer du stade de preuve de concept à une adoption massive par les plateformes de production.

Sources

• Release v0.5.0 · kubernetes-sigs/dra-driver-nvidia-gpu, github.com
• AI Cluster Runtime (AICR) | NVIDIA AI Cluster Runtime, docs.nvidia.com
• Making Kubernetes AI-Ready for NVIDIA Vera Rubin on Day One, NVIDIA, 2 novembre 2026
• Busy GPUs can hide slow AI inference on Kubernetes, The New Stack, 30 octobre 2026