Pourquoi la fragmentation de la mémoire du GPU peut-elle bloquer un modèle d’IA local ?
La fragmentation de la mémoire GPU peut empêcher l’exécution d’un modèle d’IA local lorsque la capacité libre est répartie en régions qui ne peuvent pas répondre au prochain schéma d’allocation du runtime.
La panne survient souvent après un changement de modèle, une modification de la longueur du contexte, l’exécution simultanée de charges de travail d’image et de langage, ou le traitement de requêtes dont les tenseurs temporaires augmentent et diminuent. La surveillance peut indiquer qu’il reste de la VRAM inutilisée, mais l’allocateur ne parvient toujours pas à placer un espace de travail volumineux, un fragment de modèle ou une extension du cache KV sans libérer ou réorganiser les blocs existants. Les sections ci-dessous distinguent une véritable insuffisance de capacité de la fragmentation de l’allocateur et expliquent pourquoi le redémarrage du runtime peut permettre temporairement au même modèle de tenir à nouveau.
La VRAM totale libre n’est pas synonyme d’espace d’allocation utilisable
Un outil de surveillance de la mémoire indique la capacité globale, mais un allocateur doit satisfaire les demandes au moyen des blocs et des mappages virtuels qu’il gère. Plusieurs petites régions libres peuvent représenter ensemble plus que la taille demandée tout en restant inutilisables avec une règle d’allocation contiguë.
Une analyse des opérations LLM décrit cette discordance de mémoire libre lorsque les caches KV et les tenseurs de taille variable laissent des trous plus petits que la prochaine demande. L’erreur OOM visible concerne donc aussi bien la disposition que le nombre total d’octets.
Les pilotes et les frameworks peuvent également signaler différemment la mémoire libre sur le périphérique, réservée, allouée et inactive. Comparez la vue de l’allocateur du runtime à l’utilisation au niveau du périphérique au lieu de vous fier à un seul chiffre global.
Les changements de taille des tenseurs créent des trous au fil du temps
Les charges de travail d’IA allouent et libèrent régulièrement des tenseurs de tailles différentes pour les prompts, les lots, les dimensions d’image, les espaces de travail d’attention et les conversions temporaires. Un allocateur avec mise en cache conserve les blocs pour les réutiliser, car les restituer systématiquement au pilote coûte cher.
Les travaux de recherche de GMLake montrent que les allocations irrégulières peuvent dégrader les pools de mémoire reposant sur le découpage et créer une fragmentation importante dans les grands modèles. La réutilisation de tailles identiques est efficace ; le découpage et la fusion répétés de tailles incompatibles sont plus complexes.
Un serveur domestique qui change fréquemment de modèle est particulièrement vulnérable, car les runtimes de langage, de diffusion, de vision et de parole demandent des formes de blocs très différentes sur le même GPU.
La fragmentation peut s’accumuler sans fuite mémoire. Chaque allocation peut finir par être libérée dans le pool, mais la structure de ce pool peut rester mal adaptée à la charge de travail suivante.
La croissance du cache KV rend la fragmentation de l’inférence dynamique
Les poids d’un LLM restent relativement stables après le chargement, tandis que le cache KV augmente avec le nombre d’utilisateurs actifs, la longueur des prompts et le nombre de jetons générés. Les requêtes se terminent également à des moments différents, libérant des régions de tailles inégales.
PagedAttention a été conçu pour réduire la fragmentation du cache KV en stockant l’état des requêtes dans de petits blocs plutôt qu’en réservant une seule grande région contiguë pour une longueur finale de séquence inconnue.
Ce problème diffère de la fragmentation de l’allocateur général de tenseurs du framework, mais les deux peuvent coexister. Un gestionnaire KV paginé ne peut pas automatiquement compacter les espaces de travail du modèle ni les allocations détenues par un autre processus.
La présentation par ZimaSpace des contextes simultanés montre pourquoi un modèle qui tient pour un seul utilisateur peut franchir un seuil de mémoire lorsque plusieurs conversations s’allongent simultanément.
La mémoire réservée peut donner l’impression d’une fuite
Les allocateurs des frameworks conservent souvent les blocs libérés afin d’accélérer les requêtes suivantes. Les outils du périphérique comptabilisent ces blocs comme utilisés par le processus, même si le modèle actuel ne contient pas de tenseurs actifs dans chacun d’eux.
Un guide pratique sur les erreurs OOM distingue la mémoire réservée des besoins du modèle actif et du cache. Un écart important peut indiquer des blocs réutilisables de l’allocateur, de la fragmentation ou une charge de travail dont le pic a été supérieur à l’état actuel.
Vider un cache peut restituer certains blocs au pilote, mais cela ne peut pas libérer les poids actifs, l’état KV en cours d’utilisation, le contexte d’un autre processus ni l’espace de travail requis par l’opération suivante.
Des formes d’allocation stables et la pagination réduisent les échecs récurrents
Reproduisez l’échec avec un seul modèle, une limite de contexte fixe, une taille de lot fixe et aucun service d’IA concurrent. Consignez la mémoire allouée et réservée au niveau du processus, la mémoire libre au niveau du périphérique, la taille de la plus grande demande et la séquence de charges de travail précédant l’erreur OOM.
vAttention utilise le mappage de mémoire virtuelle pour séparer l’espace KV virtuel contigu de l’allocation physique. Des approches similaires, fondées sur la pagination et l’allocation segmentée, réduisent la dépendance à une seule région physiquement contiguë.
Pour un serveur domestique, les mesures pratiques consistent notamment à conserver une marge de VRAM, à limiter les changements de modèle, à utiliser des plafonds stables pour le contexte et les lots, à coordonner les services au moyen d’un seul runtime et à redémarrer un processus fragmenté pendant la maintenance plutôt qu’après l’échec d’une requête utilisateur.
Si un redémarrage propre ne permet toujours pas au modèle de tenir, le problème principal est probablement une capacité réellement insuffisante plutôt qu’une fragmentation accumulée. Réduisez la taille du modèle, son empreinte de quantification, le contexte, la taille des lots ou les allocations concurrentes.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi les prédictions de la maison connectée deviennent-elles moins précises après des changements de routine saisonniers ?
Les habitudes saisonnières modifient la relation entre le temps, les capteurs, l’occupation et les actions souhaitées, ce qui rend obsolète un modèle entraîné à...
Pourquoi un NVR domestique manque-t-il des événements brefs lorsque le suivi des objets est activé ?
Le suivi nécessite suffisamment de détections pour commencer et confirmer une trajectoire ; un objet peut donc disparaître brièvement avant que le NVR ne...
Pourquoi les étiquettes des photos générées par l’IA changent-elles après la mise à niveau d’un modèle ?
Une mise à niveau du modèle modifie la représentation et le classement utilisés pour attribuer les étiquettes, de sorte qu’une même photo peut franchir...
