Pourquoi un environnement d’exécution d’IA local réserve-t-il de la mémoire après une requête ?
Un moteur d’exécution d’IA local réserve de la mémoire après une requête afin que les futurs tenseurs puissent réutiliser les blocs du périphérique sans subir à nouveau les coûts d’allocation et de synchronisation.
Le résultat visible peut ressembler à une fuite : l’utilisation du GPU tombe à zéro, la réponse est terminée, mais le processus occupe toujours la majeure partie de la mémoire de l’accélérateur. Une partie de cette empreinte peut correspondre aux poids actifs du modèle ou à l’état KV, tandis qu’une autre appartient à un allocateur de cache, à un contexte d’exécution, à une capture de graphe, à l’espace de travail d’une bibliothèque ou à une stratégie de maintien en mémoire du modèle. Les sections ci-dessous distinguent les allocations actives des réservations réutilisables et indiquent dans quels cas une mémoire persistante est normale, inutile ou le signe d’une véritable fuite.
L’allocation sur le périphérique est suffisamment coûteuse pour être mise en cache
Les tenseurs créés pendant une requête sont créés puis libérés à plusieurs reprises. Rendre chaque bloc au pilote peut entraîner des synchronisations et obliger la requête suivante à reconstruire la même disposition mémoire.
L’allocateur CUDA de PyTorch sépare les blocs mis en cache par l’allocateur des tenseurs qui restent activement alloués.
Conserver les blocs libres au sein du processus améliore la latence des requêtes répétées, mais un autre service d’IA ne peut pas utiliser ces octets tant que l’allocateur ne les a pas rendus au pilote.
La mémoire allouée, réservée et libre sur le périphérique correspond à des indicateurs différents
La mémoire allouée appartient aux tenseurs actifs. La mémoire réservée est gérée par l’allocateur d’exécution et peut inclure à la fois les allocations actives et les blocs réutilisables actuellement inutilisés.
Un moteur d’exécution peut donc afficher un écart de mémoire réservée même après la destruction des tenseurs temporaires.
Les outils du périphérique tels que nvidia-smi indiquent l’empreinte du processus visible par le pilote, et non les blocs qui sont logiquement libres au sein du framework.
L’état du modèle et du moteur d’exécution peut rester volontairement prêt
Le processus peut conserver les poids du modèle, l’état du tokenizer, les noyaux, les graphes d’exécution et les contextes de l’accélérateur afin d’éviter qu’une nouvelle requête ne déclenche un démarrage à froid.
L’explication de ZimaSpace sur la résidence des modèles montre pourquoi un service prêt consomme de la mémoire même lorsqu’aucun utilisateur ne génère actuellement de jetons.
Il s’agit d’un compromis délibéré entre capacité et latence. Du point de vue du calcul, la mémoire est inactive, mais elle reste utile en tant qu’état immédiatement disponible.
La fragmentation peut rendre les blocs réservés difficiles à réutiliser
Un pool peut contenir suffisamment d’octets inutilisés au total, tout en disposant de blocs dont les tailles ne correspondent pas à la requête suivante. Les prompts de longueur variable, les dimensions d’image, les lots et les changements de modèle peuvent créer un schéma de réservation fragmenté.
GMLake étudie la fragmentation des allocateurs causée par des tailles d’allocation irrégulières.
Dans ce cas, la mémoire conservée n’est ni activement utile ni disponible pour d’autres processus, et un redémarrage du processus peut temporairement rétablir une disposition plus propre.
Mesurez si l’empreinte se stabilise ou augmente
Exécutez plusieurs fois la même requête fixe et consignez, après chaque réponse, la mémoire allouée, réservée, du cache KV, des poids du modèle et libre sur le périphérique.
Un seuil maximal stable suggère un comportement normal de mise en cache ou de maintien en mémoire. Une empreinte qui augmente à chaque requête identique et ne réutilise jamais les anciens blocs suggère une fuite, un cache non borné, une session conservée ou une variation de la charge de travail.
Ne testez les mécanismes de libération du cache qu’après avoir confirmé l’état qu’ils suppriment. Vider les blocs inutilisés de l’allocateur ne décharge pas les poids actifs du modèle, et décharger le modèle peut dégrader le temps de réponse.
Pour un serveur domestique exécutant plusieurs services, définissez un budget mémoire et une politique d’inactivité pour chaque moteur d’exécution afin que la réservation d’un service n’empêche pas silencieusement un autre de démarrer.
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...
