AMD a présenté Spur publiquement le 7 août, un ordonnanceur de jobs sous licence Apache 2.0 écrit en Rust qui répond à sbatch, squeue et scancel exactement comme Slurm. L'argument est que les grappes GPU ont dépassé un ordonnanceur conçu à une époque où la ressource intéressante était le processeur, et que la bonne façon de corriger cela n'est pas de demander à tout le monde de réécrire ses scripts de soumission. Le calendrier mérite aussi un regard. NVIDIA a racheté SchedMD, l'entreprise derrière Slurm, en décembre 2025. Huit mois plus tard, AMD dispose d'une alternative qui lit les mêmes fichiers de jobs. Nous avons regardé ce que Spur fait vraiment différemment, et quelle part de la promesse de compatibilité est achevée.
The short answer
Spur est un ordonnanceur de jobs orienté GPU qu'AMD a écrit en Rust et publié sous Apache 2.0. Il réplique l'état de la grappe par un consensus Raft embarqué plutôt que par une base externe, injecte les accélérateurs via le Container Device Interface plutôt que par des greffons fournisseurs, embarque un maillage WireGuard pour les grappes multisites, et fait entrer les charges Kubernetes dans le même pool de GPU que les jobs batch. Surtout, il accepte les commandes et les directives Slurm existantes, si bien que l'adopter ne commence pas par une réécriture des scripts. La compatibilité continue explicitement de s'étendre.
Quiconque a déjà migré un ordonnanceur sait où se trouve vraiment la douleur, et ce n'est pas dans l'ordonnanceur. C'est dans les quatre cents scripts de soumission qui supposent que #SBATCH --gres=gpu:4 veut dire quelque chose, dans la supervision qui analyse la sortie de squeue, et dans ce chercheur dont la chaîne de traitement tourne depuis 2019 et qui ne réécrira rien. AMD semble l'avoir compris, parce que l'argument principal de Spur n'est pas un algorithme d'ordonnancement. C'est que vos scripts existants continuent de fonctionner.
Ce qu'est Spur, et de quoi il est fait
Spur est un ordonnanceur de jobs écrit en Rust, développé par AMD dans le cadre de ses travaux d'écosystème ouvert et publié sous Apache 2.0 sur github.com/ROCm/spur. Anush Elangovan, vice-président en charge du logiciel IA chez AMD, l'a mis en avant publiquement le 7 août, le billet technique ROCm ayant été publié plus tôt dans l'été.
Les démons paraîtront familiers à quiconque a exploité Slurm, et c'est délibéré. spurctld est le contrôleur, il détient l'état de la grappe et prend les décisions d'ordonnancement en gRPC sur le port 6817. spurd tourne sur chaque nœud de calcul, découvre les ressources et exécute les jobs, sur le port 6818. spurrestd expose l'API REST. spur-cli est un binaire multi-appel, et c'est la partie astucieuse : invoqué sous le nom sbatch, il se comporte comme sbatch, le même procédé que busybox, ce qui explique qu'il suffise de le placer dans le PATH devant les vrais outils Slurm pour rediriger les soumissions.
L'argument justifiant de le construire est que Slurm vient d'un monde où le travail de l'ordonnanceur consistait à allouer des cœurs et de la mémoire, les GPU ayant été greffés ensuite comme ressource générique. La description historique est juste. L'alternative vers laquelle se tournent la plupart des sites est Kubernetes, et là le reproche est différent : il faut assembler un système batch fonctionnel à partir de greffons de périphériques, d'un ordonnanceur comme Volcano et d'un gestionnaire de files comme Kueue, et l'on se retrouve à empiler plusieurs projets avant qu'un entraînement ne démarre. Spur affirme que la conscience du GPU appartient au cœur de l'ordonnanceur plutôt qu'à un adaptateur.
Concrètement, cela veut dire la conscience de la topologie. Quand un entraînement réclame soixante-quatre accélérateurs MI300X reliés en XGMI, le placement sur huit nœuds n'est pas interchangeable, parce que l'interconnexion entre deux GPU d'un même nœud n'a rien à voir avec le lien entre deux baies. Un ordonnanceur qui traite les accélérateurs comme une ressource dénombrable vous remettra volontiers une allocation catastrophique du point de vue topologique, qui satisfait la demande et tourne à une fraction de la vitesse.
Les parties réellement différentes
Trois choix méritent l'attention de ceux qui exploitent des grappes plutôt que d'en lire la description.
La gestion de l'état est celle qui nous intéresse en premier. Spur embarque le consensus Raft dans le contrôleur, si bien que l'état d'ordonnancement se réplique entre réplicas avec élection automatique du leader et sans base externe. Comparez avec ce qu'exige un plan de contrôle Slurm redondant : un contrôleur de secours, un répertoire d'état accessible aux deux sur du stockage partagé, et slurmdbd devant MySQL pour la comptabilité. Retirer la dépendance au système de fichiers partagé du chemin de défaillance d'un ordonnanceur n'est pas anodin, parce qu'en pratique c'est ce système de fichiers qui emporte la grappe entière. AMD annonce une bascule en moins d'une seconde. Raft apporte sa propre contrainte, la perte de quorum arrêtant tout ordonnancement, si bien qu'un plan de contrôle à deux nœuds n'est pas de la redondance.
La gestion des périphériques passe par le Container Device Interface, la spécification neutre qui décrit les accélérateurs aux moteurs de conteneurs, plutôt que par des greffons par fournisseur. La conséquence pratique est que Spur n'est pas structurellement un ordonnanceur réservé à AMD bien qu'AMD l'ait écrit, ce qui compte pour quiconque exploite du silicium hétérogène.
L'intégration Kubernetes est la plus ambitieuse et la moins éprouvée. Un spur-k8s-operator surveille des ressources personnalisées SpurJob et les soumet au contrôleur, de sorte que charges Kubernetes et jobs batch puisent dans un pool de GPU unique. Les sites qui coupent aujourd'hui leurs accélérateurs en deux, l'inférence d'un côté et l'entraînement de l'autre, sont la cible. Cette coupure statique est du gaspillage pur et tous ceux qui la subissent le savent, mais unifier les deux ordonnanceurs est réellement difficile, et il s'agit du code le plus récent du projet.
Pour les grappes multisites, un maillage WireGuard intégré construit un overlay unique pour les communications entre jobs, sur site comme dans le cloud. Au-delà du cœur, AMD décrit également Spur-Cloud, qui ajoute gestion de sessions, facturation adossée à PostgreSQL et multilocation via authentification locale, OAuth GitHub ou OIDC Okta, ce qui relève du produit GPU as a service plutôt que de l'ordonnanceur.
Ce que nous en ferions
L'essayer, sur une partition de test, avec vos propres scripts. L'installation tient en une ligne de commande et deux démons, ce qui représente un après-midi plutôt qu'un projet :
curl -fsSL https://raw.githubusercontent.com/ROCm/spur/main/install.sh | bashEnsuite, pointez spurctld sur un répertoire d'état, démarrez spurd en face, et soumettez quelque chose de réel. Le test utile n'est pas de savoir si sbatch hello.sh fonctionne, il fonctionnera. C'est de savoir si les vingt scripts qui comptent le plus survivent au contact, et où précisément ils s'arrêtent. Cette liste d'échecs est la seule estimation de migration qui vaille, et elle coûte une journée.
Ce que nous ne ferions pas, c'est planifier une migration de production là-dessus. La documentation d'AMD dit elle-même que la compatibilité est en développement actif avec une parité encore en extension, et la feuille de route liste toujours le partitionnement GPU et SR-IOV, la préemption avancée et la fédération multi-grappes comme travaux à venir. C'est du côté de la comptabilité que nous attendons les arêtes les plus vives, puisque les rapports sacct et la politique de fairshare sont l'endroit où un site Slurm mature conserve des années de règles accumulées qu'aucune couche de compatibilité ne peut deviner.
La lecture stratégique est plus difficile à écarter que la lecture technique. Slurm ordonnance plus de la moitié des dix premiers et des cent premiers systèmes du TOP500, et depuis décembre 2025 il est maintenu par NVIDIA. NVIDIA a déclaré qu'il garderait Slurm open source et neutre, et rien ne suggère le contraire. Mais une seconde implémentation crédible qui accepte les mêmes fichiers de jobs change la nature de cette dépendance pour tout le monde, y compris pour les sites qui ne l'installeront jamais. Cela vaut davantage que la liste des fonctionnalités.
Sources et pour aller plus loin
- AMD ROCm Spur : un ordonnancement de jobs en Rust pensé pour l'IA, Phoronix, 7 août 2026
- Spur : ordonnancement moderne de jobs GPU pour le HPC et l'IA, blog AMD ROCm
- ROCm/spur, le dépôt source sous Apache 2.0 sur GitHub
- NVIDIA rachète SchedMD, développeur de Slurm, Evertiq, 17 décembre 2025
- NVIDIA s'enfonce dans l'infrastructure IA avec le rachat de SchedMD, Network World
- Spécification du Container Device Interface
Questions fréquentes
Peut-on remplacer Slurm par Spur dès aujourd'hui ?
Pas en production, et AMD ne prétend pas le contraire. La documentation ROCm décrit la compatibilité Slurm comme en cours de développement actif, avec une parité qui continue de s'étendre, ce qui est une façon honnête de dire que les commandes courantes fonctionnent et que la longue traîne non. Les commandes couvertes sont sbatch, srun, squeue, scancel, sinfo, sacct et scontrol, plus la reconnaissance des directives #SBATCH dans les scripts, une API REST calquée sur celle de Slurm, et une couche de compatibilité FFI C nommée libspur_compat.so pour les outils qui se lient à l'ordonnanceur plutôt que de l'appeler en ligne de commande. Cela couvre la forme générale de la soumission de jobs. Ce que cela ne dit pas, c'est comment votre site se comporte, parce qu'une installation Slurm réelle accumule dix ans de règles de comptabilité, de politiques QOS, de scripts prolog et epilog et de logique de réservation, et rien de tout cela ne figure dans la liste de compatibilité. Voyez-le comme quelque chose à monter sur une partition de test et à éprouver avec vos vrais fichiers de jobs, pas comme une migration que l'on planifie.
Qu'est-ce que le consensus Raft change par rapport à la haute disponibilité de Slurm ?
Il supprime une brique d'infrastructure. La haute disponibilité Slurm classique suppose un contrôleur de secours, un répertoire d'état accessible aux deux contrôleurs, généralement sur du stockage partagé, et une base de comptabilité MySQL ou MariaDB à côté. Cela fait trois choses à installer, sécuriser et sauvegarder avant que l'ordonnanceur ne soit redondant. Spur embarque Raft directement dans le démon contrôleur, si bien que l'état de la grappe est répliqué entre les réplicas par l'ordonnanceur lui-même, avec élection automatique du leader et sans base externe. AMD annonce une bascule en moins d'une seconde. La différence pratique se voit une mauvaise nuit : au lieu de se demander si le système de fichiers partagé répond et si la base a bien répliqué, on se demande si un quorum de contrôleurs est joignable. Moins de pièces mobiles est un vrai gain d'exploitation, même s'il faut dire que Raft a son propre mode de défaillance, la perte de quorum, et qu'un plan de contrôle à trois nœuds qui en perd deux cesse d'ordonnancer.
Pourquoi un ordonnanceur de jobs a-t-il besoin de WireGuard ?
Parce que les grappes visées par AMD ne tiennent pas toujours dans une seule salle. Spur intègre un maillage WireGuard pour construire un réseau overlay unique dédié aux communications entre jobs, ce qui vise précisément le cas où une partie de la capacité est sur site et une autre louée dans le cloud. Traditionnellement cela se règle en dehors de l'ordonnanceur, avec un VPN ou une interconnexion dédiée que l'équipe plateforme maintient séparément, l'ordonnanceur se contentant de supposer que les nœuds se joignent. L'intégrer signifie un système de moins à garder synchronisé avec la liste des nœuds. Savoir si c'est souhaitable est une vraie question d'architecture plutôt qu'un oui évident. Si vous exploitez déjà un réseau overlay mature, un ordonnanceur qui a des opinions sur vos tunnels est une chose de plus à réconcilier. Si vous assemblez de la capacité GPU venue de plusieurs endroits sans disposer de cette couche, la voir arriver avec l'ordonnanceur est commode.
Comment la partie Kubernetes s'articule-t-elle, puisque Kubernetes ordonnance déjà ?
Les deux sont censés partager les mêmes GPU plutôt que se les disputer. Spur fournit un opérateur, spur-k8s-operator, qui surveille une ressource personnalisée SpurJob et la transmet au contrôleur Spur, de sorte qu'un job batch soumis via Kubernetes atterrit dans le même pool de GPU qu'un job soumis par sbatch. Cela répond à une contrariété précise et très répandue : un site qui fait tourner de l'inférence sur Kubernetes et de l'entraînement sur Slurm finit par partitionner statiquement ses accélérateurs entre les deux, parce qu'aucun ordonnanceur ne voit les allocations de l'autre. La gestion des périphériques passe par le Container Device Interface plutôt que par des greffons propres à chaque fournisseur, ce qui permet à AMD de dire que cela vaut pour ses propres GPU et pour les accélérateurs d'autres fournisseurs sans coder ni les uns ni les autres en dur. La réserve honnête est que l'ordonnancement unifié est la chose la plus difficile de cette liste à réussir, et la partie avec le moins d'historique en production.
S'agit-il d'une réaction d'AMD au rachat de Slurm par NVIDIA ?
AMD ne le présente pas ainsi, et les arguments techniques du billet ROCm tiennent debout seuls. L'enchaînement reste difficile à ignorer. NVIDIA a finalisé le rachat de SchedMD en décembre 2025, prenant la main sur le projet qui ordonnance plus de la moitié des dix premiers et des cent premiers systèmes du TOP500. NVIDIA s'est engagé publiquement à garder Slurm open source et neutre vis-à-vis des fournisseurs, et rien n'indique à ce jour le contraire. Mais il y a une différence entre une promesse tenue et un concurrent tranquille, et la valeur stratégique d'un ordonnanceur compatible Slurm sous une licence qu'AMD maîtrise ne dépend pas d'un mauvais comportement de NVIDIA. La bonne façon de lire Spur, c'est qu'une option existe, ce qui vaut quelque chose indépendamment de savoir si quelqu'un finira par en avoir besoin.