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 mission : faire le pont entre le matériel coûteux et la multitude de programmes gourmands, puis répartir les ressources de manière à ce que personne ne monopolise tout. Depuis quarante ans, le noyau Linux s’acquitte très bien de cette tâche avec le processeur, 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 avec cet é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 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 des pages mémoire, une mémoire virtuelle permettant de demander plus de mémoire que la machine n’en dispose, et une zone de swap pour assurer une transition en douceur en cas d’épuisement. Pour le disque et le réseau : il y a des inodes, des sockets, des files d’attente et des 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, lesquelles accaparent 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 point économique : quelle est la valeur d’un point de pourcentage de taux d’occupation ?

Lorsque les ressources sont allouées de manière fragmentée, 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 : un taux d’utilisation moyen des GPU avoisinant 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 — en attente de données, en attente de synchronisation, ou simplement parce qu’un pod les a réservées puis abandonnées.

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 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 charge de travail — sans avoir à acheter de nouvelles cartes graphiques, sans avoir à attendre la mise en service d’une nouvelle usine, sans avoir à demander davantage d’électricité.

Alors que la mémoire HBM et la capacité de conditionnement 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 soudain 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 finalement abouti 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 source à 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 du processeur 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 stable (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’est plus l’apanage d’un seul fabricant. L’abstraction au niveau du noyau n’existe pas encore ; l’écosystème se construit actuellement à un 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 à 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 disponible : NVIDIA fournit `cuda-checkpoint`, un outil qui verrouille les appels CUDA, transfère la mémoire du périphérique vers le processeur central, 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 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 pilier de la théorie des cœurs est également remis en cause : l’hypothèse selon laquelle 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 des niveaux d’accès à la 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 2026, effectue une répartition dynamique vers 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 doit 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, une charge de travail n’existait pas encore à une échelle significative : du code généré par un modèle, exécuté 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 pour cela, pour une raison très simple : tous les conteneurs d’une même machine partagent un même 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-VM 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 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 un certificat 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 du périphérique 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. 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 préréglées des distributions de 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 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 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.