Run:ai : orchestrer les charges de travail IA en entreprise

En bref

Run:ai est une plateforme d’orchestration GPU construite sur Kubernetes, rachetée par NVIDIA après une acquisition approuvée par la Commission européenne fin 2024.

Son architecture repose sur deux briques : un cluster qui ordonnance les tâches, un control plane qui centralise pilotage et supervision.

Le scheduler applique des quotas par projet et par département pour partager les GPU sans qu’une équipe monopolise tout.

En cas de pénurie de ressources, la plateforme consolide, rééquilibre, puis préempte, dans cet ordre précis.

Deux modes de déploiement existent, cloud ou self-hosted, avec des règles claires sur ce qui remonte au fournisseur.

Un dirigeant nous a posé la question la semaine dernière : « run:ai, c’est un logiciel qui fait tourner mes calculs IA plus vite ? » Non. Run:ai ne calcule rien. Elle organise le trafic autour des GPU, un peu comme un régulateur qui décide qui passe en premier sur une route à une seule voie. Depuis son rachat par NVIDIA, cette plateforme d’orchestration GPU devient une pièce d’infrastructure pour les entreprises qui font tourner plusieurs projets IA en parallèle sur un parc de cartes graphiques limité. Voici ce qu’elle fait réellement, et pour qui elle a du sens.

Run:ai : définition et positionnement depuis le rachat par NVIDIA

Commençons par ce que run:ai n’est pas. Ce n’est pas un modèle d’IA, ni un outil d’entraînement, ni une puce. C’est un logiciel d’orchestration et d’optimisation des ressources GPU, construit sur Kubernetes, le système open source qui organise le déploiement d’applications sur des serveurs répartis. Sa mission : éviter que les cartes graphiques d’une entreprise restent inactives pendant qu’une équipe attend son tour, et empêcher qu’une seule équipe accapare tout le parc au détriment des autres.

Un logiciel d’orchestration, pas un outil de calcul

Dans nos missions clients, on voit régulièrement des entreprises acheter des GPU coûteux pour les laisser tourner à moitié vides. Un data scientist lance un entraînement le lundi, bloque quatre cartes, puis part en réunion pendant trois heures sans rien faire tourner dessus. Pendant ce temps, une autre équipe attend. Run:ai s’attaque précisément à ce gaspillage. Elle ne remplace pas les GPU, elle les répartit entre les projets qui en ont besoin, au moment où ils en ont besoin.

Pourquoi NVIDIA a racheté Run:ai

La Commission européenne a validé en décembre 2024 l’acquisition de Run:ai par NVIDIA, avec prise de contrôle exclusif. Le calcul de NVIDIA est simple : vendre des GPU, c’est une chose ; garantir que ces GPU tournent à plein régime chez le client en est une autre. En intégrant une couche d’orchestration à son écosystème, NVIDIA rend son matériel plus attractif pour les grandes structures qui déploient de l’IA à grande échelle. Pour une PME ou une ETI, ce rachat change surtout la trajectoire produit : Run:ai n’est plus un acteur indépendant, elle avance désormais au rythme de la feuille de route NVIDIA.

Comment fonctionne Run:ai : cluster et control plane Kubernetes

L’architecture technique de Run:ai tient sur deux jambes : le cluster et le control plane. Ce sont deux composants distincts, installés autour d’un cluster Kubernetes existant, qui ne font pas le même travail.

Le rôle du cluster d’ordonnancement

Le cluster, c’est la partie qui vit au plus près des GPU. Il reçoit les demandes de calcul (entraîner un modèle, lancer une inférence, exécuter un notebook) et décide où et quand les exécuter. C’est là que l’ordonnanceur Kubernetes pour l’IA entre en jeu : il place les tâches sur les bonnes machines, en tenant compte de la charge déjà présente et des priorités définies en amont.

Le control plane et son tableau de bord

Le control plane, lui, centralise. C’est depuis cette interface qu’un administrateur soumet des workloads, consulte les métriques d’usage, et suit qui utilise quoi. Concrètement, un responsable infrastructure ouvre un tableau de bord et voit d’un coup d’œil quelle équipe consomme quelle part du parc GPU, sans avoir à interroger chaque serveur individuellement. Cette séparation entre exécution (cluster) et pilotage (control plane) permet à la plateforme de fonctionner aussi bien sur un data center que sur une infrastructure cloud.

Le scheduler de Run:ai : quotas, fairness et priorisation des équipes

Le cœur intelligent de run:ai, c’est son scheduler. C’est lui qui tranche, en permanence, la question la plus sensible d’une infrastructure IA partagée : qui a le droit d’utiliser quel GPU, et pendant combien de temps.

Files par projet et par département

Le scheduler organise les demandes en files hiérarchiques autour de deux niveaux : le projet et le département, chacun rattaché à un « node pool » (un groupe de machines). Chaque niveau reçoit un quota « déservi » (deserved quota) exprimé en nombre de GPU, de CPU ou de mémoire. Imaginez une entreprise avec trois équipes : R&D, production, et expérimentation. Chacune a droit à sa part garantie de GPU. Personne ne se bat pour la ressource tant que tout le monde reste dans son quota.

Allocation in-quota puis over-quota

Le mécanisme se corse quand une équipe veut dépasser son quota. Le scheduler autorise cette gourmandise, mais avec une règle claire : les demandes « in-quota » (dans la limite fixée) passent toujours avant les demandes « over-quota » (au-delà de la limite). Une équipe peut donc emprunter temporairement des ressources inutilisées par une autre, à condition de les rendre dès que le propriétaire légitime en a besoin. Ce principe de fairness évite deux écueils : le gaspillage de GPU qui dorment, et la frustration d’une équipe prioritaire qui ne trouve jamais de place.

Run:ai face à la pénurie de GPU : consolidation, reclaim, préemption

Que se passe-t-il quand la demande dépasse franchement la capacité disponible ? C’est le scénario que redoutent tous les responsables infrastructure. La réponse tient en trois temps, appliqués dans un ordre précis.

Étape 1 : la consolidation des ressources

Avant de retirer quoi que ce soit à quiconque, le scheduler range d’abord mieux l’existant. Cette technique, le bin packing, regroupe les tâches déjà en cours pour libérer des créneaux entiers plutôt que de laisser des fragments de capacité épars sur plusieurs machines. C’est un peu comme réorganiser un parking mal rempli pour faire rentrer une voiture supplémentaire sans en déplacer d’autres au-dehors.

Étape 2 et 3 : rééquilibrage puis préemption

Si la consolidation ne suffit pas, le scheduler passe au rééquilibrage : il reprend des ressources aux files qui dépassaient leur quota déservi (donc en position « over-deserved »), pour les redonner à celles qui sont sous leur quota. La préemption n’intervient qu’en dernier recours, si tout le reste a échoué : elle interrompt une tâche en cours, mais toujours à l’intérieur d’une même file, jamais en piochant arbitrairement chez un autre projet. Cette hiérarchie protège les équipes. Une tâche prioritaire ne se voit jamais coupée par une simple demande gourmande venue d’ailleurs, sans passer par ces étapes de vérification.

Ce mécanisme rassure souvent les clients qui craignent de perdre des heures de calcul sans préavis. La réalité est plus nuancée : la plateforme épuise d’abord les solutions douces avant d’en venir à l’arbitrage forcé.

Cas d’usage de Run:ai en entreprise et gestion des données

Sur le terrain, deux questions reviennent systématiquement chez nos clients : où installer Run:ai, et que devient-on quand on l’installe.

Cloud vs self-hosted : deux modes de déploiement

Run:ai se déploie en mode cloud (géré par le fournisseur) ou en mode self-hosted (hébergé chez le client, sur son propre cluster Kubernetes). Le choix dépend surtout de la politique de gouvernance des données et des contraintes réglementaires de l’entreprise. Une PME sans exigence de souveraineté particulière ira naturellement vers le cloud, plus simple à mettre en route. Une ETI soumise à des contraintes sectorielles strictes préférera garder la main sur son infrastructure.

Ce que Run:ai transmet (et ne transmet pas)

En mode self-hosted, la communication vers le control plane est décrite comme « outbound-only » (elle part toujours de l’installation client vers le fournisseur, jamais l’inverse) et chiffrée en SSL. Seules des métadonnées et des métriques opérationnelles sont synchronisées, sans transit d’artefacts de modèles ni de jeux de données appartenant au client. C’est un point à vérifier avant tout déploiement, en particulier dans les secteurs réglementés.

Franchement, on le dit à chaque client : cette promesse-là reste une promesse fabricant. Elle est claire sur le papier, mais elle doit être confrontée à vos propres exigences de conformité, pas prise pour argent comptant.

Dans les workflows que nous concevons chez nos clients, Run:ai se situe en amont : elle organise l’accès aux GPU, mais ne remplace pas les briques d’automatisation métier qui viennent ensuite chaîner les traitements. Pour ces tâches d’orchestration applicative (déclencher un pipeline, connecter une API, notifier une équipe), des outils comme Make ou n8n restent complémentaires, à un autre niveau de la chaîne IA.

Ce qu’il faut retenir

Run:ai n’entraîne aucun modèle. Elle organise le partage des GPU entre projets, via un scheduler qui applique quotas, fairness et priorités. Depuis son rachat par NVIDIA, la plateforme continue d’évoluer au rythme de son nouveau propriétaire. Pour une entreprise qui envisage un déploiement en 2026, la bonne pratique reste la même : vérifier la version documentée au moment du projet, et confronter les promesses de gestion des données aux propres exigences de conformité de l’organisation.

FAQ

Run:ai remplace-t-il un outil d’automatisation comme Make ou n8n ?

Non. Run:ai gère l’accès aux ressources GPU pour des charges de calcul IA. Les outils d’automatisation orchestrent des workflows métier (API, notifications, déclencheurs). Les deux couches se complètent, elles ne se substituent pas l’une à l’autre.

Faut-il déjà avoir Kubernetes en place pour utiliser Run:ai ?

Oui, la plateforme s’installe autour d’un cluster Kubernetes existant, avec ses deux composants (cluster et control plane) déployés sur cette base. Sans cluster Kubernetes préalable, l’adoption de Run:ai demande d’abord ce socle technique.

Une petite équipe peut-elle dépasser son quota GPU si personne d’autre n’en a besoin ?

Oui, c’est justement le principe de l’allocation « over-quota » : une équipe peut utiliser des ressources non réclamées par d’autres, tant qu’elle reste prête à les restituer si le propriétaire légitime en a besoin.

Le mode cloud de Run:ai a-t-il accès à mes données d’entraînement ?

En mode self-hosted, seules des métadonnées et des métriques opérationnelles remontent vers le control plane, sans artefacts de modèles ni datasets clients. Ce point mérite néanmoins d’être vérifié précisément selon le mode de déploiement choisi et vos exigences de conformité internes.