Que se passe-t-il lorsque des services d’IA locaux se disputent la mémoire de l’accélérateur ?
Lorsque des services d’IA locaux se disputent la mémoire de l’accélérateur, chaque environnement d’exécution réduit la capacité disponible pour les autres modèles, les requêtes, les caches et les tenseurs temporaires.
Un serveur domestique peut exécuter des services de conversation, de génération d’embeddings, de génération d’images, de reconnaissance vocale, de synthèse vocale, de détection visuelle et d’analyse vidéo par l’intermédiaire de conteneurs ou de processus distincts. Leurs tableaux de bord peuvent sembler inactifs alors que les poids des modèles et les pools d’allocation restent présents sur le même GPU, NPU ou accélérateur à mémoire partagée. Une nouvelle requête a alors besoin d’espace pour l’état du prompt, les activations et les tampons de sortie, que l’empreinte mémoire statique du modèle ne révélait pas. Les sections ci-dessous expliquent comment des services distincts transforment la capacité nominale de l’accélérateur en refus d’admission et en latence instable.
Chaque service apporte davantage que les poids du modèle
Un modèle chargé occupe la mémoire dédiée à ses paramètres, mais l’inférence active nécessite également des bibliothèques d’exécution, des contextes d’exécution, des espaces de travail temporaires, des tampons d’entrée, des activations et un état propre à chaque requête.
Les recherches sur le service des grands modèles de langage identifient la mémoire de cache KV comme une limite majeure à la concurrence, car elle augmente avec le nombre de séquences actives et la longueur du contexte. Un modèle qui tient lorsqu’il est inactif peut échouer lorsque plusieurs requêtes longues deviennent actives.
Les services de vision, de diffusion, de traitement vocal et d’embeddings utilisent des profils de mémoire temporaire différents. Leurs allocations maximales peuvent se chevaucher même lorsque l’utilisation moyenne reste faible.
Des processus distincts dupliquent le contexte et la surcharge d’exécution
Exécuter chaque fonction d’IA dans son propre conteneur améliore la séparation opérationnelle, mais des processus distincts peuvent créer des contextes d’accélérateur, des bibliothèques, des pools d’allocation et des copies de composants de modèles partagés distincts.
Les systèmes multi-modèles étudient le service multi-modèles, car un placement naïf d’un modèle par service gaspille à la fois de la mémoire et de la puissance de calcul. Une colocalisation coordonnée peut utiliser la capacité plus efficacement que des environnements indépendants qui supposent chacun contrôler l’appareil.
Deux services utilisant le même tokenizer, le même encodeur de vision ou le même modèle de langage ne partagent pas automatiquement une seule copie physique. Le partage nécessite la prise en charge par l’environnement d’exécution et des limites de processus compatibles.
La pénalité liée à la duplication est particulièrement visible sur les petits accélérateurs, où quelques centaines de mégaoctets de contexte et de surcharge de bibliothèques peuvent déterminer si un autre modèle peut démarrer.
Les pools réservés peuvent masquer de la mémoire aux autres environnements d’exécution
Les frameworks conservent souvent les blocs libérés afin que les requêtes suivantes évitent une allocation et une synchronisation coûteuses sur l’appareil. Le service signale alors moins de mémoire activement allouée, mais un autre processus ne peut toujours pas utiliser l’espace physique réservé.
Des systèmes tels que le multiplexage statistique considèrent le placement et les pics de charge comme un problème global, au lieu de laisser chaque serveur de modèles réserver de la capacité pour son propre pire scénario. Des services locaux indépendants ne disposent pas de cette vision globale, sauf si un orchestrateur l’impose.
Cela explique pourquoi un accélérateur peut afficher une faible utilisation de calcul tout en refusant un nouveau modèle. La capacité est occupée par les poids, les blocs réservés ou des zones libres fragmentées, plutôt que par des noyaux actifs.
La contention modifie la latence avant de provoquer une erreur de mémoire insuffisante
Un environnement d’exécution peut réagir à une faible disponibilité mémoire en réduisant la taille des lots, en limitant le nombre de séquences simultanées admises, en recalculant l’état évincé, en déplaçant des couches vers la mémoire vive du processeur ou en déchargeant un autre modèle.
Aegaeon utilise la planification au niveau des jetons pour coordonner de nombreux modèles lorsque la demande évolue. Un serveur domestique dépourvu d’une coordination comparable expose souvent ce manque sous la forme de premiers jetons lents, de pauses, de changements de modèle ou de files d’attente imprévisibles.
L’article de ZimaSpace sur la concurrence familiale montre la même limite au niveau des requêtes : les conversations actives se disputent la mémoire et l’attention du planificateur, même lorsque les tests avec un seul utilisateur semblent rapides.
Une exception de mémoire insuffisante n’est que le mode d’échec final. L’instabilité de la latence et la baisse du débit apparaissent souvent plus tôt.
L’éviction des modèles échange une réponse instantanée contre de la capacité
Décharger un modèle inactif libère une grande zone contiguë pour un autre service. La prochaine requête adressée au service évincé doit recharger les poids et reconstruire l’état d’exécution, transformant la pression mémoire en délai de démarrage à froid.
WarmServe étudie le placement tenant compte des évictions, car les changements fréquents dégradent le délai avant le premier jeton. Garder tous les modèles en mémoire est plus rapide uniquement lorsque l’accélérateur dispose de suffisamment de mémoire pour leurs états résidents et actifs combinés.
Pour un serveur domestique, la stratégie utile dépend de la charge de travail. Le contrôle vocal peut mériter de rester en permanence en mémoire, tandis que la génération d’images occasionnelle peut accepter un rechargement.
Un seul gestionnaire de ressources peut faire respecter les véritables limites de capacité
Dans la mesure du possible, coordonnez les services au moyen d’un seul serveur d’inférence, ou définissez explicitement des limites de mémoire par service, la visibilité des appareils, les règles de résidence des modèles, les plafonds de concurrence et les priorités.
Des travaux récents sur le ballonnement de mémoire montrent pourquoi une allocation statique gaspille de la capacité lorsque la popularité des modèles et la charge de requêtes évoluent. Le partage dynamique peut améliorer l’utilisation, mais il nécessite un système unique qui observe toutes les charges concurrentes.
Mesurez, pour chaque service, les poids, la mémoire réservée, les allocations actives, le cache KV, la concurrence des requêtes, la longueur du contexte, la taille des lots et la fréquence de changement de modèle. Un total global pour l’appareil, sans attribution par service, ne peut pas expliquer la collision.
Protégez d’abord les services sensibles à la latence, planifiez les embeddings et l’indexation pendant les fenêtres de maintenance, et laissez une marge non allouée pour les pics temporaires. L’objectif n’est pas de remplir chaque octet au repos, mais de maintenir la combinaison de services prévue lorsqu’ils sont sollicités simultanément.
FAQ
Pourquoi la mémoire de l’accélérateur est-elle pleine alors que l’utilisation du GPU est faible ?
L’utilisation du calcul mesure l’exécution active, tandis que les poids des modèles, les contextes, les caches et les blocs réservés par l’allocateur peuvent occuper la mémoire entre les requêtes.
Les conteneurs peuvent-ils appliquer automatiquement des limites de mémoire GPU ?
Pas de manière fiable avec tous les environnements d’exécution. L’attribution des appareils et l’isolation des processus ne garantissent pas que plusieurs frameworks coordonnent leurs réservations internes.
Un seul serveur d’inférence partagé est-il toujours préférable ?
Non. Il peut réduire les duplications et améliorer la planification, mais l’isolation des services, la compatibilité des frameworks, la sécurité, la reprise après défaillance et la prise en charge des modèles peuvent justifier des environnements d’exécution distincts.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce qui amène un planificateur d’agent IA à répéter des étapes déjà effectuées ?
Suivez les étapes répétées du planificateur à travers la persistance de l’état, les preuves d’achèvement, l’analyse des résultats des outils, la conservation du contexte,...
Qu’est-ce qui provoque des erreurs d’autorisation uniquement dans les sous-processus des agents d’IA ?
Comparez l’identité du processus parent et du processus enfant, la vue du système de fichiers, l’environnement, les capacités, la politique de sécurité et le...
Quelles sont les causes de la saturation du processeur lorsque le transcodage matériel et l’IA vidéo s’exécutent simultanément ?
Suivez la saturation du processeur au niveau du déchargement des codecs, de la conversion des pixels, des copies d’images, du prétraitement de l’IA, de...
