Le noyau Linux considère toujours le GPU comme un périphérique — et la refonte du système d'exploitation pour les serveurs d'IA

Mise à jour : août 2026.

Le système d'exploitation a été conçu pour remplir une seule fonction : faire le lien entre le matériel coûteux et la multitude de programmes gourmands, puis répartir les ressources de manière à ce que personne ne les accapare toutes. Depuis quarante ans, le noyau Linux s'acquitte très bien de cette tâche avec les processeurs, la mémoire, les disques et le réseau. Mais en 2026, l’élément le plus coûteux d’un serveur n’est plus le processeur : ce sont les huit cartes graphiques dissimulées sous le capot, qui représentent la majeure partie de la facture. Et comme on peut s’y attendre pour l’élément le plus coûteux, le noyau ne s’en occupe pratiquement pas.

Il existe quatre piliers abstraits — le GPU n'en fait pas partie

Énumérez les éléments qui permettent à un utilisateur de « posséder » véritablement une ressource. Pour le CPU : il existe le concept de processus, un ordonnanceur à répartition équitable du temps, des cgroups qui comptent chaque cycle, et surtout, le droit de préemption — l’interruption du compteur de temps, les processus à faible priorité sont immédiatement évincés du cœur, sans qu’il soit nécessaire de demander la permission. Pour la mémoire : il y a les pages mémoire, la mémoire virtuelle qui permet de demander plus de mémoire que la machine n’en dispose, et l’espace d’échange pour assurer une transition en douceur en cas de pénurie. Pour le disque et le réseau : il y a les inodes, les sockets, les files d’attente et les politiques.

Avec le GPU, il n’y a pratiquement rien dans cette liste. Du point de vue du noyau, le GPU n’est qu’un fichier de périphérique : le processus ouvre /dev/nvidia*, appelle quelques commandes ioctl propriétaires, puis tout se passe au sein du pilote et du micrologiciel. Le noyau ne sait pas combien de « tâches » de calcul sont en file d’attente, lesquelles sont sur le point de se terminer, ni lesquelles monopolisent toute la bande passante. Il n’y a pas de paramètre gpu.weight permettant de dire « deux parts pour cette tâche, une part pour celle-là ». Il n’y a pas de swap pour la VRAM : une fois la mémoire GPU épuisée, la tâche est terminée, point final. Et il n’y a pas de préemption : une tâche d’entraînement de trois jours monopolisera huit GPU pendant trois jours, même si des tâches plus urgentes font la queue derrière.

Les conséquences architecturales sont considérables : comme le noyau ne dispose d’aucun emplacement pour stocker les politiques, toutes les décisions sont renvoyées vers le haut — vers Kubernetes, vers le planificateur du cluster. Ce niveau voit les pods et les étiquettes, mais ne peut pas voir à l’intérieur du GPU. Il se contente de compter : « Cette machine a 8 cartes, 8 cartes ont été attribuées, c’est tout. »

Le point économique : quelle est la valeur d'un point de pourcentage de taux d'occupation ?

Lorsque les ressources ne sont allouées qu’au niveau du cluster, personne ne récupère les ressources inutilisées. Un rapport sur l’optimisation de Kubernetes publié début 2026, qui a analysé plus de vingt mille clusters, a révélé un chiffre stupéfiant : le taux d’utilisation moyen des GPU avoisine les 5 %. D’autres études FinOps sont plus prudentes, évoquant généralement un taux de 20 à 40 % pour les clusters bien entretenus. Quel que soit le chiffre retenu, la conclusion est la même : la plupart du temps, les puces électroniques les plus chères de la planète restent inactives — elles attendent des données, attendent la synchronisation, ou simplement parce qu’un pod les a réservées puis les a laissées de côté.

Le prix de location d’un GPU de classe centre de données à la demande sur les grands clouds avoisine la dizaine de dollars de l’heure ; les contrats à long terme sont bien moins chers, mais en contrepartie, il faut payer même en cas de non-utilisation. Quoi qu'il en soit : un GPU inactif coûte plusieurs dollars de l'heure, tandis qu'un CPU inactif ne coûte que quelques centimes. Cet écart de deux ordres de grandeur renverse complètement l’ordre des priorités techniques. Si l’on n’utilise que 20 % de la capacité, chaque heure de calcul réellement utile coûte cinq fois le prix affiché ; passer de 20 % à 40 % ne signifie pas « doubler la vitesse », mais réduire de moitié le coût pour une même quantité de travail — sans avoir à acheter de nouvelles cartes graphiques, sans avoir à attendre la livraison d’une nouvelle usine, sans avoir à demander davantage d’électricité.

Alors que la mémoire HBM et la capacité d'emballage constituent le goulot d'étranglement de l'ensemble du secteur, le moyen le plus économique d'augmenter la puissance de calcul ne consiste pas à acheter davantage de matériel, mais à récupérer celle qui est gaspillée — c'est pourquoi des éléments aussi arides que les cgroups, les planificateurs ou les points de contrôle deviennent soudainement les postes les plus coûteux d'un cluster d'IA.

Début de la mise à jour : cgroup pour la VRAM, planification des écritures via BPF

Le premier pilier est en place : depuis Linux 6.14, le noyau dispose d’un cgroup dmem — un contrôleur de mémoire de périphérique — permettant de limiter la mémoire vidéo selon une arborescence de cgroups, initialement intégré au pilote graphique Intel Xe. Cela peut paraître modeste, mais c’est la première fois que la mémoire d’un périphérique d’accélération est gérée par le même mécanisme du noyau que celui utilisé pour la RAM. L’idée d’un « cgroup pour le DRM » avait été rejetée à plusieurs reprises pendant près d’une décennie ; elle a pu aboutir aujourd’hui parce que certains ont dû en payer le prix fort en raison de son absence.

Du côté de la planification, l'impulsion est venue d'une direction à laquelle peu de gens s'attendaient. sched_ext — un framework permettant d’écrire des planificateurs de CPU en BPF puis de les charger à chaud dans le noyau — est passé du statut de sujet controversé à celui de pratique courante : de nombreuses distributions de premier plan l’activent par défaut, et SteamOS utilise même un planificateur BPF par défaut lors des sessions de jeu. En ce qui concerne les serveurs d’IA, la feuille de route est particulièrement intéressante : l’équipe de développement a inscrit la « prise en charge des GPU » sur sa liste de tâches. La raison est très concrète : savoir quel thread du processeur alimente quel GPU est une information cruciale ; si un thread est mal affecté à un cœur appartenant à une zone NUMA différente, le GPU reste inactif.

La couche de coordination a franchi une étape importante : la fonctionnalité Dynamic Resource Allocation (DRA) de Kubernetes est désormais disponible en version officielle v1.35, remplaçant définitivement l’ancien mécanisme de plugin de périphérique qui ne savait compter que des nombres entiers. Le DRA permet à une charge de travail de décrire ses besoins — type de périphérique, capacité mémoire, type de liaison NVLink, tranche MIG — puis de laisser le planificateur se charger de l’appariement. Lors de la KubeCon Europe 2026, NVIDIA a cédé son pilote DRA à la CNCF, ce qui signifie que ce modèle de ressources n’est plus l’apanage d’un seul fabricant. L’abstraction au niveau du noyau n’existe pas encore ; l’écosystème se construit actuellement au niveau supérieur et procède à sa normalisation.

Une nouvelle forme d'usurpation de contrôle : prendre une capture d'écran du GPU, puis continuer à s'exécuter

Parmi les quatre éléments manquants, la préemption est la plus difficile à mettre en œuvre, mais c’est aussi celle qui a connu les progrès les plus intéressants. Pour interrompre une tâche afin de lui céder la place, il faut pouvoir enregistrer l’intégralité de son état : la mémoire CPU, les fichiers ouverts, ainsi que le contenu de la VRAM et le contexte CUDA — threads, événements, mappage mémoire. Cette pièce du puzzle est désormais en place : NVIDIA propose cuda-checkpoint, un outil qui verrouille les appels CUDA, transfère la mémoire du périphérique vers le processeur, puis libère le GPU ; en l’associant à CRIU — un outil de capture d’état des processus dans l’espace utilisateur de Linux —, on obtient un instantané unifié du CPU et du GPU, permettant une restauration exacte aux anciennes adresses, même sur une autre machine.

Cela revêt une importance bien plus grande qu’il n’y paraît, car cela transforme le GPU d’une ressource « prêtée à perpétuité » en une ressource récupérable. Ce n’est qu’avec un point de contrôle que l’on peut oser exécuter des tâches à faible priorité pour combler les créneaux vides, car on peut alors les évacuer en cas de besoin sans perdre de progression ; ce n’est qu’ainsi que l’on peut oser migrer des tâches pour récupérer les fragments de capacité ; ce n’est qu’ainsi que l’on peut oser vendre la capacité inutilisée sous forme de « spot ». L’ensemble du calcul économique présenté ci-dessus repose sur cette capacité.

La couche de mémoire s'est divisée en quatre

Parallèlement, le deuxième pilier de l’architecture est également remis en cause : l’hypothèse selon laquelle la mémoire est un bloc uniforme, où l’accès est identique quel que soit l’endroit. Dans les serveurs d'IA actuels, la mémoire se présente comme une échelle à quatre échelons dont les latences varient de plusieurs milliers de fois : la mémoire HBM intégrée au GPU, la DRAM locale du CPU, la mémoire étendue via CXL, puis le NVMe.

La nouveauté, c’est que le noyau a commencé à gérer lui-même cette échelle plutôt que de s’en remettre à l’application. Depuis la version 6.9, la politique de « weighted interleave » permet de répartir la mémoire entre les nœuds selon un poids proportionnel à la bande passante, plutôt que de la répartir naïvement de manière égale — avec CXL, une répartition égale revient à se tirer une balle dans le pied, car le nœud le plus lent ralentit l'ensemble du système. Par la suite, DAMON — le système de suivi de l’activité mémoire directement au sein du noyau — a été étendu pour non seulement observer, mais aussi agir : il transfère les pages actives vers les niveaux rapides, déplace les pages inactives vers les niveaux lents, et, dans les mises à jour 2026, effectue une répartition dynamique vers plusieurs nœuds cibles dotés de pondérations spécifiques. C’est là que la mémoire virtuelle entre dans l’ère des niveaux multiples : l’idée reste la même (« le noyau sait quelle page doit se trouver où »), à la seule différence qu’il faut désormais choisir entre quatre types de mémoire dont le prix au Go varie d’un facteur de dix.

Lorsque l'agent exécute lui-même du code : le bac à sable devient une nouvelle frontière

Il y a quelques années, il existait une charge de travail qui n'existait pas encore à une échelle significative : du code généré par un modèle, s'exécutant automatiquement, que personne ne lisait au préalable. Chaque session était un processus court, qui apparaissait et disparaissait en quelques secondes, et qui n'était absolument pas fiable.

Les conteneurs ne suffisent pas pour cela, pour une raison très simple : tous les conteneurs d'une même machine partagent un seul noyau, ce qui signifie que la surface d'attaque correspond à l'ensemble de l'interface des appels système de ce noyau. En 2026, le consensus du secteur s’est clairement orienté vers les microVM : chaque session d’agent s’exécute dans une machine virtuelle distincte dotée de son propre noyau Linux, sous KVM. Firecracker démarre en un dixième de seconde environ, pour un coût de quelques Mio de mémoire par machine virtuelle ; Kata Containers intègre ce concept dans une « classe d’exécution » directement intégrée à Kubernetes. L’autre voie est celle de gVisor — un noyau Linux réécrit dans l’espace utilisateur, qui intercepte les appels système avant qu’ils n’atteignent le véritable noyau. La balance penche désormais d’un côté, car deux forces s’opposent : l’écart de temps de démarrage entre les conteneurs et les micro-machines virtuelles s’est réduit au point de ne plus constituer un argument valable, tandis que le coût d’une sortie du bac à sable a explosé — la machine contient désormais des clés API, des données clients et les autorisations nécessaires pour exécuter d’autres agents.

Machine partagée : l'utilisateur doit prouver qu'il ne lit pas les données sans autorisation

Le dernier point découle du partage de ressources. Lorsque le modèle et les données s’exécutent sur la machine d’un tiers, la question n’est plus de savoir si « le voisin peut les lire », mais si « le propriétaire peut les lire ». Le calcul confidentiel répond à cette question en encapsulant l’ensemble de la machine virtuelle dans une zone chiffrée par le processeur — AMD SEV-SNP ou Intel TDX — afin que la couche de virtualisation du fournisseur ne puisse pas lire la mémoire du client. La nouveauté pour 2025–2026 consiste à intégrer le GPU dans cette zone de confiance : le mode confidentiel sur les GPU de centre de données à partir de la génération H100 crypte à la fois la mémoire du périphérique et les liaisons PCIe et NVLink, puis émet un certificat permettant au locataire de vérifier par lui-même que le processeur, le GPU et le bus qui les relie sont bien scellés. Le coût en termes de performances pour l’inférence est actuellement annoncé à quelques pour cent — bien inférieur aux prévisions initiales —, ce qui fait qu’il passe d’une « option réservée aux grandes entreprises » à une configuration par défaut pour les charges de travail sensibles.

Prévisions

• Les cgroups pour GPU suivront la même voie que les cgroups pour CPU. Une fois la mémoire des périphériques verrouillée, la prochaine étape consistera à attribuer une sorte de « pondération » au temps de calcul. Ce sera un processus lent et controversé, car chaque fabricant cache son ordonnanceur dans son micrologiciel — mais l’argent est du côté de ceux qui l’intègrent.
• Le « checkpoint » GPU devient une infrastructure de base, ce n’est plus une astuce. Dans les 12 à 18 prochains mois, l’arrêt, la migration et la reprise d’un job GPU seront des fonctionnalités par défaut des plateformes de clusters, ouvrant la voie à un véritable marché « spot ».
• Le « remplissage » devient un indicateur de compétitivité public. Les fournisseurs annonceront le prix « par heure utile » plutôt que le prix affiché par carte.
• La hiérarchisation de la mémoire contrôlée par le noyau deviendra la norme. L’entrelacement pondéré et la hiérarchisation basés sur DAMON quitteront le domaine des « réglages manuels pour experts » pour intégrer les configurations par défaut des distributions serveurs à mesure que le CXL se généralisera.
• Les MicroVM par session deviendront la norme pour le code généré par des modèles. Les conteneurs resteront d’actualité pour les charges internes fiables, mais le « code étranger partageant le même noyau » sera considéré comme une erreur de configuration, à l’instar de l’exécution de services sous les droits root qui a déjà été remise en question.
• Risque inverse : si le rythme des investissements dans l’IA ralentit et que les GPU deviennent soudainement abondants, cette pression à l’optimisation s’estompera rapidement — historiquement, l’infrastructure n’est optimisée correctement que lorsque les ressources sont rares.

Dans l’ensemble, il ne s’agit pas de « Linux doté de fonctionnalités d’IA ». C’est une vieille histoire qui se répète : un type de matériel si coûteux qu’il serait dommage de le gaspiller, ce qui oblige le système d’exploitation à développer davantage d’abstractions pour le répartir équitablement et l’exploiter pleinement. La mémoire virtuelle, la planification en temps partagé et les cgroups sont tous nés selon cette même logique. Cette fois-ci, le protagoniste est le GPU, et nous en sommes au milieu de l’histoire.