Pourquoi un iGPU entre-t-il en concurrence avec les applications de serveur domestique pour la mémoire ?
Un iGPU entre en concurrence avec les applications de serveur domestique car les charges de travail graphiques, médias et IA utilisent la même capacité et la même bande passante de mémoire système que le CPU.
Cette concurrence est facile à manquer car le moteur graphique apparaît comme un périphérique séparé dans les outils de surveillance, pourtant la plupart des GPU intégrés ne disposent pas d’un grand pool VRAM dédié. Les conteneurs, bases de données, cache du système de fichiers, machines virtuelles, environnements d’exécution de modèles et l’iGPU dépendent tous de la même DRAM installée et du contrôleur mémoire. Les sections ci-dessous distinguent la mémoire réservée de l’utilisation dynamique, expliquent comment les surfaces d’image et les tampons IA élargissent l’ensemble de travail, et montrent pourquoi un serveur peut avoir de la RAM libre tout en ralentissant sous la pression d’une bande passante partagée.
Le Graphisme Intégré Utilise le Pool de Mémoire Système
Un GPU discret possède normalement sa propre VRAM, tandis qu’un GPU intégré est intégré au processeur ou au package système et accède à la mémoire principale de la plateforme. Le CPU et le moteur graphique restent des ressources d’exécution séparées, mais leurs données actives occupent finalement la même DRAM physique du système.
Intel explique que la mémoire graphique intégrée provient de la RAM système plutôt que d’une banque mémoire séparée. Cela signifie qu’une image décodée, un tenseur IA, une surface de bureau ou un tampon graphique consomme une capacité qui pourrait autrement contenir des pages d’application, du cache de base de données ou des données du système de fichiers.
Le résultat n’est pas que le GPU possède de façon permanente chaque octet que Windows ou Linux rapporte comme mémoire graphique disponible. L’utilisation réelle change selon la charge de travail, la politique du pilote, les réglages du firmware et les tampons actuellement mappés par les applications.
La Mémoire Partagée Reportée Est une Limite, Pas une Réservation Constante
Les systèmes d’exploitation affichent souvent un grand nombre « mémoire GPU partagée », qui peut être confondu avec de la RAM déjà disparue du serveur. Dans de nombreuses implémentations, cette valeur est une limite supérieure ou une catégorie comptable plutôt qu’une allocation fixe maintenue en permanence.
La FAQ mémoire graphique d’Intel indique que la mémoire système partagée n’est pas une réservation continue. Le pilote graphique et le système d’exploitation allouent la mémoire selon la charge de travail actuelle du CPU et du GPU.
Cette distinction est importante lors de la planification de capacité. Un tableau de bord inactif peut montrer la plupart de la RAM libre, puis une transcodification, un modèle de vision ou plusieurs bureaux distants peuvent allouer rapidement de grandes surfaces et réduire la marge disponible pour les conteneurs.
La mémoire réservée par le firmware est différente. Un réglage BIOS ou UEFI peut réserver une petite région graphique fixe avant le démarrage du système d’exploitation, et cette portion est indisponible pour les applications normales même lorsque l’iGPU est inactif.
Les Surfaces d’Image S’agrandissent Pendant le Décodage, le Traitement et l’Encodage
Le transcodage matériel ne conserve pas seulement l’entrée compressée et la sortie compressée en mémoire. Le pipeline a aussi besoin de surfaces d’image décodées, d’images de référence, de tampons de mise à l’échelle ou de correction de tonalité, et d’assez de surfaces en file d’attente pour maintenir occupées les étapes asynchrones de décodage et d’encodage.
Intel oneVPL décrit les pools de surfaces de décodeur qui doivent contenir assez de surfaces d’image pour le composant vidéo actif. La résolution, la profondeur de bits, le format chroma, le nombre d’images de référence, les filtres et les flux concurrents modifient tous la quantité de mémoire de travail.
Une seule surface d’image 4K est bien plus grande que le paquet compressé qui l’a produite. Plusieurs transcodages simultanés peuvent donc augmenter l’utilisation mémoire visible par le graphique même lorsque les fichiers médias restent sur disque.
Le moteur média à fonction fixe peut réduire le calcul CPU, mais il ne supprime pas le besoin de stocker et déplacer ces images à travers la hiérarchie mémoire partagée.
La Pression de Capacité Peut Pousser les Applications à la Récupération et au Swap
Lorsque les allocations iGPU et les ensembles de travail des applications approchent la RAM installée, le système d’exploitation doit récupérer des pages de cache propres, compresser la mémoire, expulser des pages d’application ou déplacer des données vers le swap. Le premier ralentissement visible peut apparaître dans une base de données ou une application web non liée plutôt que dans la tâche GPU.
Le contrôle actuel d’équilibre mémoire d’Intel encadre explicitement le compromis entre les applications à forte demande de mémoire graphique et celles à forte demande de mémoire CPU. Augmenter une limite graphique peut aider une charge de travail tout en réduisant la protection pour le reste du système.
Le cache du système de fichiers est souvent la victime silencieuse. Un serveur domestique peut garder assez de mémoire anonyme pour les conteneurs tout en expulsant fréquemment des métadonnées médias, des vignettes, des pages de base de données ou des entrées de répertoire, ce qui donne l’impression d’un stockage plus lent même si l’utilisation du disque n’a pas changé.
La Contention de Bande Passante Peut Apparaître Avant que la Capacité RAM Soit Pleine
La capacité libre mesure combien de données supplémentaires peuvent tenir ; elle ne mesure pas la rapidité avec laquelle le CPU et l’iGPU peuvent déplacer les données déjà en cours d’utilisation. Les deux moteurs peuvent demander la bande passante DRAM en même temps.
Le guide d’optimisation GPU d’Intel décrit le trafic DRAM partagé entre le CPU et le GPU intégré. L’explication ZimaSpace des limites de bande passante mémoire montre pourquoi le décodage IA, les images vidéo, les caches d’application et le travail CPU peuvent ralentir les uns les autres avant que le Gestionnaire des tâches ne signale que la capacité mémoire est épuisée.
Cela crée un symptôme caractéristique : l’utilisation GPU ou CPU peut rester en dessous de 100 % tandis que le débit change fortement selon les canaux mémoire, le débit de données, le comportement de copie ou les charges de travail simultanées.
Mesurer la Capacité et la Bande Passante comme des Limites Séparées
Testez le serveur en étapes : applications seules, charge iGPU seule, puis les deux ensemble. Enregistrez la mémoire disponible, la mémoire engagée, l’activité de swap, le cache système de fichiers, la bande passante mémoire, l’utilisation du moteur iGPU et le temps de réponse de l’application qui importe.
Windows expose les segments mémoire GPU, tandis que les outils Linux peuvent exposer l’activité du moteur graphique et de la mémoire système selon le pilote. La comparaison utile n’est pas un nombre « VRAM » rapporté mais comment le système mémoire complet change quand la tâche iGPU commence.
Si le swap ou une récupération agressive du cache apparaît, ajoutez de la RAM, réduisez les surfaces simultanées, réduisez les ensembles de travail des applications ou isolez la charge de travail de l’accélérateur. Si la capacité reste confortable mais que le débit CPU et iGPU baisse ensemble, améliorez la configuration des canaux, réduisez les copies ou déplacez une charge de travail vers un appareil avec mémoire dédiée.
FAQ
L’iGPU réserve-t-il la moitié de la RAM installée ?
Habituellement non en tant qu’allocation permanente. La valeur mémoire partagée rapportée est souvent une limite d’utilisation, tandis que l’allocation réelle change dynamiquement selon la charge.
Plus de RAM peut-elle résoudre la contention iGPU ?
Elle résout la pression de capacité lorsque les applications récupèrent ou swappent. Elle n’augmente pas automatiquement la bande passante sauf si la mise à niveau modifie aussi la configuration des canaux ou la vitesse mémoire.
Le transcodage matériel évite-t-il l’utilisation de la mémoire système ?
Non. Il réduit le travail CPU général, mais les paquets compressés, surfaces décodées, filtres, images de référence et sortie encodée utilisent toujours une hiérarchie mémoire.
Produits recommandés
Centre Tech & IA
Plus à lire
État d’exécution vs état persistant dans Home Assistant : que doit survivre à un redémarrage ?
Home Assistant ne conserve pas chaque valeur en temps réel ; la configuration, les registres, certains états restaurés, l’historique et les données de déploiement...
Comment Home Assistant authentifie-t-il les sessions locales et distantes ?
Les sessions Home Assistant locales et distantes utilisent le même modèle d’identité côté serveur ; l’accès à distance modifie le chemin et la limite...
Pourquoi les requêtes d’historique de Home Assistant peuvent-elles ralentir à mesure que les données de l’enregistreur augmentent ?
L’augmentation du nombre d’enregistrements peut accroître le coût des requêtes d’historique lorsque la plage demandée concerne davantage de lignes, que les défauts de cache...
