# CUDA 13.5 généralise Vera Rubin et affine le contrôle MPS v3

_Publié le 4 novembre 2026 — https://ip73.fr/2026/11/04/cuda-13-5-generalise-vera-rubin-et-affine-le-controle-mps-v3/_

La sortie de CUDA 13.5, accompagnée du pilote Linux 620.70.06, marque une étape importante pour l'accélération informatique, notamment avec la généralisation du support pour l'architecture Vera Rubin. Cette mise à jour positionne l'écosystème NVIDIA pour les applications en production sur ces nouvelles plateformes. Mais au-delà de l'arrivée des nouveaux cœurs, ce qui frappe, c'est le raffinement des outils de gestion des ressources, en particulier autour du Multi-Process Service (MPS) v3.

MPS v3 remplace l'ancienne interface interactive de MPS v2 par une syntaxe de commandes basées sur des modules et des verbes, et il introduit des noms de serveurs et des espaces de noms (namespaces) configurables par fichiers. L'ancienne fonctionnalité de MPS v2 continue de fonctionner sans changement, mais MPS v3 est sélectionné explicitement en utilisant le drapeau `-p 3` ou en définissant la variable d'environnement `CUDA_MPS_PROTOCOL_VERSION` à 3. Il est à noter que si les deux sont définis, la variable d'environnement prime.

Cette nouvelle architecture permet une gestion beaucoup plus granulaire des ressources. Un serveur MPS est une entité gérée indépendamment, et contrairement à MPS v2 où un seul serveur pouvait être actif par UID, MPS v3 supporte désormais plusieurs serveurs nommés en même temps. Mais c'est le concept de namespace qui permet de vraiment structurer le travail. Il subdivise les ressources d'un serveur pour un groupe de clients, évitant ainsi de devoir créer un serveur dédié pour chaque groupe. C'est une architecture qui répond au besoin de mutualisation sans sacrifier l'isolation.

Les développeurs gagnent en finesse de contrôle sur le temps de calcul. Le *weighted timeslicing* permet d'attribuer des tours de calcul plus longs à certains serveurs. En parallèle, le *SM partition load balancing* laisse les partitions emprunter ou prêter des unités de calcul (SMs) lorsque les ressources sont disponibles. Ces réglages sont indépendants : une partition peut emprunter, prêter, ou faire les deux. MPS récupère les ressources empruntées avant de les réattribuer, mais l'application voit une taille de partition de base stable.

## Structurer les charges de travail avec les namespaces

La capacité à définir des namespaces permet, par exemple, d'appliquer des limites de mémoire épinglée ou des pourcentages de threads actifs à un groupe de clients donné, sans impacter les autres utilisateurs du même serveur. De plus, l'intégration du *cgroup-based routing* est un changement majeur, disponible depuis la version du pilote r620. En liant un sous-arbre *cgroup v2* à un namespace lors de sa création, le lanceur de charge de travail peut faire en sorte que les clients se connectant via le socket principal soient automatiquement dirigés vers la politique de ressources définie pour ce namespace. C'est une automatisation puissante qui simplifie l'orchestration des processus.

La syntaxe de MPS v3 est désormais basée sur des commandes *module verb*, ce qui est plus structuré. Pour créer un serveur nommé, on utilise une commande spécifique, et pour y créer un namespace, on peut spécifier des attributs comme un chemin *cgroup* pour le mappage automatique. Les namespaces subdivisent les ressources d'un serveur, incluant les limites de mémoire épinglée, le pourcentage de threads actifs, la priorité des clients et les partitions SM par périphérique.

Voici un aperçu de ce que permettent ces outils de contrôle :

| Fonctionnalité MPS v3 | Ce qu'elle permet | Impact principal | Priorité de contrôle |
| :--- | :--- | :--- | :--- |
| Server | Gestion d'instances de calcul indépendantes | Isolation au niveau du serveur | Niveau Haut (Server) |
| Namespace | Subdivision des ressources d'un serveur | Isolation au niveau du groupe de clients | Niveau Moyen (Namespace) |
| Cgroup Routing | Association automatique de processus | Déploiement automatisé des politiques | Niveau Bas (Client) |

## Les ajustements fins et les choix d'exploitation

CUDA 13.5 ne se contente pas de refondre les outils de contrôle ; il apporte aussi des capacités matérielles importantes. Le support de Windows sur Arm s'étend désormais à NVIDIA DGX Station pour Windows. Sur le plan des partitions SM, la nouvelle API permet aux applications de choisir entre des partitions uniformes ou des partitions qui englobent tous les SM disponibles dans un domaine de localité. Si l'on veut exploiter au maximum le matériel, on peut utiliser le drapeau `cudaDevSmResourceGroupLocalityDomainSupplementalSms` pour intégrer ces SM supplémentaires dans chaque domaine sélectionné, même si les partitions résultantes ne sont pas de taille identique. Cela offre un choix entre prédictibilité et utilisation maximale du matériel.

Un autre détail technique concerne le traitement de la mémoire. Pour les décisions d'éviction, MPS peut utiliser un mode de *polling* basé sur la lecture directe des usages et des limites, servant de filet de sécurité si les notifications de seuil *cgroup* venaient à manquer ou à être peu fiables. De plus, les assignments de partitions SM au niveau du namespace priment sur les réglages d'environnement. Si un namespace n'a pas d'assignation pour un périphérique, l'environnement conserve son rôle de repli.

En matière de communication, CUDA 13.5 ajoute le support de la communication multi-GPU directement dans les noyaux CUDA Tile. Les pointeurs *Unicast* permettent à un noyau d'accéder à la mémoire d'un autre GPU connecté par NVLink, tandis que les pointeurs *multicast* et les opérations *multimem* supportent les réductions sur les tissus NVIDIA NVSwitch avec NVLink SHARP.

Modifier un attribut de namespace, tel que le chemin *cgroup*, impose que les clients soient déconnectés avant que les nouvelles règles ne puissent prendre effet. La façon dont les namespaces substituent aux variables d'environnement requiert une nouvelle rigueur : il est essentiel de savoir précisément quel namespace un client cible, que ce soit via son socket ou son rattachement à un *cgroup v2* donné.

## Sources

- [MPS v3 Interface#](https://docs.nvidia.com/deploy/mps/latest/mpsv3-interface.html), docs.nvidia.com
- [MPS v3 Namespaces#](https://docs.nvidia.com/deploy/mps/latest/mpsv3-namespaces.html), docs.nvidia.com
- [NVIDIA CUDA 13.5 Brings NVIDIA Vera Rubin GA Support](https://developer.nvidia.com/blog/nvidia-cuda-13-5-brings-nvidia-vera-rubin-ga-support/), NVIDIA, 4 novembre 2026
- [NVIDIA CUDA 13.5 Released With Production Support For Vera Rubin](https://www.phoronix.com/news/NVIDIA-CUDA-13.5), Phoronix, 4 novembre 2026