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 s’accapare tout. 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 situé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 gère pratiquement rien de tout cela.

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 de processeur, des cgroups qui comptent chaque cycle, et surtout, le droit de préemption — l’interruption de l’horloge, les processus à faible priorité sont immédiatement expulsés du cœur, sans qu’il soit nécessaire de demander l’autorisation. Pour la mémoire : il y a les pages mémoire, la mémoire virtuelle qui permet de demander plus de mémoire que l’ordinateur n’en dispose, et l’espace d’échange pour assurer une transition en douceur lorsque la mémoire vient à manquer. 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 gpu.weight pour dire « deux parts pour cette tâche, une part pour celle-là ». Il n’y a pas de swap pour la VRAM : dès que la mémoire du GPU est épuisée, la tâche est interrompue, un point c’est tout. 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 coin économique : combien vaut chaque point de pourcentage de taux d'occupation ?

Lorsque les ressources ne sont allouées qu’au niveau du cluster, personne ne récupère ce qui reste. 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 se montrent 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 de silicium les plus chères de la planète restent inactives — en attente de données, en attente de 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 les dix dollars de l’heure ; les contrats à long terme sont bien moins chers, mais en contrepartie, il faut payer même lorsque l’on ne l’utilise pas. Quoi qu’il en soit : un GPU inactif coûte plusieurs dollars par 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 n’est pas d’acheter davantage de matériel, mais de récupérer ce qui est actuellement gaspillé — 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 en place : cgroup pour la VRAM, planification des écritures via BPF

Le premier pilier est en place : depuis Linux 6.14, le noyau intègre le cgroup dmem — un contrôleur de mémoire de périphérique — qui permet de limiter la mémoire vidéo selon une arborescence de cgroups, initialement reliée 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 finalement abouti aujourd’hui car certains ont dû payer le prix fort pour 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 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 CPU alimente quel GPU est une information cruciale ; si un thread est mal affecté à un cœur appartenant à une autre zone NUMA, le GPU se retrouve en manque de données.

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 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’appartient plus à une seule entreprise. L’abstraction au niveau du noyau n’existe pas encore ; l’écosystème se construit actuellement à un niveau supérieur et travaille à sa normalisation.

Une nouvelle forme d'usurpation : prendre une photo du GPU, puis continuer à fonctionner

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 du processeur, 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 de 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 à jamais » 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 de faible priorité pour combler les créneaux disponibles, car on peut alors les évacuer en cas de besoin sans perdre de progrès ; 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 principe fondamental de l'informatique est également remis en cause : celui selon lequel la mémoire est un espace plat, où l'accès est identique quel que soit l'endroit. Dans les serveurs d’IA actuels, la mémoire se présente comme un escalier à quatre marches dont les délais de latence 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 procéder à une répartition uniforme naïve — avec CXL, une répartition uniforme 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 « chaudes » vers les niveaux rapides, déplace les pages « froides » vers les niveaux lents, et, dans les mises à jour de 2026, répartit dynamiquement la mémoire sur plusieurs nœuds cibles dotés de poids 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 sandbox devient une nouvelle frontière

Il y a quelques années, il existait une charge de travail qui n’avait alors pas encore atteint une ampleur 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 puis disparaissait en quelques secondes, et qui n’était absolument pas fiable.

Les conteneurs ne suffisent pas dans ce cas, pour une raison très simple : tous les conteneurs d’une même machine partagent un seul noyau, ce qui fait 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 droits nécessaires pour exécuter d’autres agents.

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

Le dernier point découle du partage de ressources. Lorsque les modèles 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, le bus PCIe et le NVLink, puis émet une attestation permettant au locataire de vérifier 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 passer cette fonctionnalité du statut d’« option réservée aux banques » à celui de paramètre 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 joue en faveur de cette approche.
• Le checkpoint GPU devient une infrastructure de base, ce n’est plus une astuce. Au cours des 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 serveur à 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 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 de manière rigoureuse 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 par tranches de temps et les cgroups ont tous vu le jour selon cette même logique. Cette fois-ci, le protagoniste est le GPU, et nous en sommes au milieu de l’histoire.