Qu’est-ce qui amène un environnement d’exécution d’IA local à charger plusieurs copies d’un même modèle ?
Des copies du modèle apparaissent lorsque des processus, réplicas, sessions ou contextes d’appareil distincts ne peuvent pas partager une même allocation de poids chargée.
Un serveur IA domestique peut afficher environ deux fois la quantité de RAM ou de VRAM attendue après l’ajout d’une interface web, d’un worker en arrière-plan, d’un service vocal, d’un indexeur de documents ou d’un second point de terminaison d’API. Le fichier du modèle sur le disque peut rester unique, tandis que plusieurs objets d’exécution contiennent leurs propres poids, tenseurs convertis, noyaux pré empaquetés, caches et contextes d’appareil. Certaines duplications sont accidentelles ; d’autres sont des réplicas délibérés créés pour la concurrence, l’isolation ou l’exécution parallèle.
Un seul fichier de modèle peut produire plusieurs objets d’exécution indépendants
Charger le modèle depuis le même chemin ne signifie pas que deux applications font référence à un seul modèle en mémoire. Chaque instance d’exécution peut analyser le point de contrôle et allouer ses propres tenseurs.
Les recommandations de Google Cloud en matière d’inférence distinguent les configurations qui chargent une copie du modèle par processus ou par machine virtuelle.
Si la mémoire augmente par paliers correspondant à la taille du modèle lorsque le nombre de workers augmente, la cause principale est la réplication des instances. Des hausses plus modestes indiquent plus probablement des caches, allocateurs ou contextes d’exécution propres à chaque worker.
Les serveurs web et les workers de tâches lancent souvent des processus distincts
Un serveur frontend, un consommateur de file d’attente, un ordonnanceur, un service de transcription et un worker RAG peuvent chacun importer le chargeur du modèle, même s’ils appartiennent à une seule stack Compose.
L’isolation des processus donne à chaque service son propre espace d’adressage. Les pages CPU peuvent parfois être partagées grâce aux mécanismes du système d’exploitation, mais les objets courants des frameworks et les allocations GPU ne constituent pas automatiquement un service de modèle partagé.
La duplication suit les identifiants de processus et les limites entre services. Si l’arrêt d’un conteneur libère approximativement une copie du modèle, le conteneur ne se contentait pas de transférer les requêtes vers un runtime central.
Les réplicas de service sont des copies individuelles par conception
Les systèmes d’autoscaling augmentent le débit en lançant davantage de réplicas. Un réplica est un worker indépendant capable de traiter des requêtes lorsque les autres workers sont occupés.
Ray Serve définit les réplicas comme des copies individuelles exécutées dans des processus acteurs distincts.
Une hausse de la mémoire qui suit les pics de trafic ou les événements de l’autoscaler correspond à une réplication intentionnelle, et non à une fuite. La cause vient du modèle de concurrence choisi, même si la réduction du nombre de réplicas supplémentaires peut ensuite prendre du temps.
Plusieurs sessions d’inférence peuvent dupliquer les initialiseurs et les poids pré empaquetés
Une application peut créer plusieurs sessions au sein d’un même processus pour différents threads, points de terminaison, profils ou fournisseurs d’exécution.
ONNX Runtime documente le partage des allocateurs, initialiseurs et poids pré empaquetés entre les sessions, car des sessions distinctes ajoutent autrement une surcharge mémoire.
Si un processus possède plusieurs objets de session et que la mémoire augmente lors de l’initialisation de chaque session, l’état dupliqué se trouve dans l’application plutôt qu’entre les conteneurs.
Le forking ne garantit pas le partage des poids sur l’accélérateur
Un processus parent peut charger un modèle avant de créer des workers et sembler partager des pages CPU grâce à la copie sur écriture. L’initialisation de l’accélérateur et l’état d’exécution mutable compliquent cette hypothèse.
Les recommandations de PyTorch concernant le multiprocessing expliquent que les tenseurs peuvent utiliser des mécanismes de mémoire partagée entre les processus, mais que le partage nécessite une conception compatible et explicite.
Un worker qui déplace le modèle vers le GPU, modifie les poids, crée un cache ou s’initialise après le spawn peut allouer une nouvelle copie, même si les pages CPU du point de contrôle d’origine étaient partagées.
Des contextes CUDA distincts ajoutent un état propre à chaque processus sur l’appareil
Deux processus utilisant un même GPU fonctionnent normalement avec des contextes CUDA distincts, sauf lorsqu’une architecture spéciale de partage est utilisée.
NVIDIA indique que plusieurs processus d’application CUDA créent généralement plusieurs contextes avec une surcharge mémoire.
La surcharge liée aux contextes ne constitue pas à elle seule un second modèle complet, mais elle peut accompagner la duplication des poids, des noyaux, des espaces de travail et des caches. Une augmentation inférieure à la taille du point de contrôle peut donc tout de même provenir de la duplication des processus.
Deux instances d’exécution sur un même GPU réservent leur mémoire indépendamment
Un tableau de bord peut démarrer un serveur de modèle tandis qu’un service d’automatisation en démarre un autre, tous deux utilisant le même point de contrôle et le même appareil.
vLLM documente que l’utilisation de la mémoire GPU est une limite propre à chaque instance et donne l’exemple de deux instances se partageant la capacité d’un seul GPU.
Si chaque point de terminaison possède son propre écouteur, ses journaux, son ordonnanceur et son cache KV, les deux processus sont des moteurs d’inférence indépendants. Un répertoire de modèles partagé empêche les téléchargements en double, mais pas les allocations d’exécution dupliquées.
Les rechargements peuvent laisser un ancien processus actif à côté du nouveau
Les mécanismes de rechargement à chaud, superviseurs, mises à jour progressives, arrêts défaillants et redémarrages déclenchés par les vérifications d’état peuvent lancer un processus de remplacement avant que l’ancien worker ne libère son modèle.
Cette cause se manifeste par une paire temporaire ou persistante de processus presque identiques, dont les heures de démarrage diffèrent. Les requêtes peuvent être dirigées uniquement vers le processus le plus récent, tandis que l’ancien continue d’occuper de la RAM ou de la VRAM.
L’article de ZimaSpace expliquant pourquoi il faut séparer l’état d’exécution IA des fichiers de modèles établit la distinction : un seul cache de points de contrôle peut servir plusieurs déploiements, mais la topologie des services détermine toujours le nombre de copies chargées.
FAQ
Un seul fichier de modèle sur le disque signifie-t-il qu’il n’existe qu’une seule copie en RAM ?
Non. Plusieurs processus ou sessions peuvent lire indépendamment le même fichier et allouer leurs propres tenseurs, caches et états d’exécution.
Toute copie supplémentaire est-elle une fuite mémoire ?
Non. Les réplicas, workers de parallélisme tensoriel, runtimes de secours et services isolés peuvent allouer intentionnellement un état supplémentaire. Une fuite augmente sans qu’un objet d’exécution actif correspondant ne l’explique.
Les conteneurs peuvent-ils partager automatiquement un modèle GPU ?
Non. Les conteneurs peuvent accéder au même appareil et aux mêmes fichiers, mais ils ont besoin d’un processus de service partagé ou d’une conception interprocessus explicite pour réutiliser une même allocation de modèle chargé.
Produits recommandés
Centre Tech & IA
Plus à lire
Quelles fonctionnalités permettent de créer une frontière de confiance pour l’IA domestique autour des fichiers sensibles ?
Une frontière de confiance pour l’IA à domicile combine le chiffrement des données au repos, des autorisations selon le principe du moindre privilège, un...
Pourquoi les résultats de recherche privés privilégient-ils les fichiers fréquemment modifiés ?
Les fichiers fréquemment modifiés bénéficient d’un meilleur classement lorsque chaque mise à jour ajoute des signaux de fraîcheur, des segments, des versions ou des...
Qu’est-ce qui pousse les modèles de détection de présence pour maison intelligente à confondre les invités avec les résidents ?
Les invités peuvent être pris pour des résidents lorsque le système observe des habitudes d’activité du foyer, mais ne dispose d’aucun signal d’identité stable...
