Qu’est-ce que la résidence d’un modèle et quand un service d’IA local doit-il conserver les poids chargés ?

La résidence d'un modèle consiste à conserver ses poids dans la mémoire de l'hôte ou de l'accélérateur entre les requêtes, afin que l'inférence suivante évite une partie ou la totalité du chargement.

Un assistant domestique utilisé toutes les quelques minutes fonctionne très différemment selon qu'un modèle de huit gigaoctets reste dans la mémoire du GPU ou qu'il soit lu depuis le stockage à chaque fois. La résidence peut exister à plusieurs niveaux : cache du système de fichiers, pages hôtes mappées, RAM épinglée ou VRAM prête pour les noyaux. Garder les poids à chaud réduit le délai de démarrage, mais réserve une mémoire rare et peut empêcher l'exécution d'autres modèles ou charges de travail.

La résidence décrit l'emplacement de l'état réutilisable du modèle

Un modèle froid n'existe que sur le stockage et doit être lu, alloué, transformé et copié avant l'inférence. Les poids résidents sur l'hôte évitent les lectures depuis le stockage, tandis que les poids résidents sur l'accélérateur évitent également le transfert de l'hôte vers le périphérique et le chemin d'initialisation de l'environnement d'exécution. Cette distinction reste visible lors des tests ultérieurs en environnement domestique.

L'analyse du streaming de modèles de NVIDIA sépare le chemin de chargement du modèle du transfert et du travail d'initialisation, montrant pourquoi l'emplacement des poids domine de nombreux démarrages à froid. Un processus à chaud peut encore nécessiter l'initialisation du tokenizer, du graphe, de l'adaptateur ou du cache. Le résultat intermédiaire doit rester vérifiable avant que l'automatisation ne prenne le relais.

La résidence n'est pas synonyme de requête active. Un modèle peut rester chargé sans cache KV ni données utilisateur, prêt à répondre tout en consommant de la mémoire et certaines ressources en arrière-plan. Cette limite doit être mesurée séparément dans des conditions d'exploitation réalistes.

La chaleur existe à travers une hiérarchie de mémoire

Le système d'exploitation peut conserver les pages du modèle dans son cache de pages même après la fermeture d'un processus, le mappage mémoire peut charger les pages à la demande, et un processus de service peut conserver les tenseurs en RAM ou en VRAM. Chaque niveau plus chaud réduit généralement la latence tout en consommant une ressource plus limitée.

ServerlessLLM étudie le chargement de modèles par niveaux entre le stockage, la mémoire de l'hôte et la mémoire du GPU, et planifie le chargement afin de réduire le coût des démarrages à froid. Cette hiérarchie explique pourquoi un modèle apparemment déchargé peut redémarrer rapidement jusqu'à ce que la pression sur le cache évince ses pages.

La quantification réduit le nombre d'octets nécessaires à la résidence et peut permettre à plusieurs modèles spécialisés de coexister. Elle peut également modifier les noyaux d'exécution et la qualité ; les économies de mémoire ne doivent donc pas être considérées comme une augmentation gratuite de la capacité. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La politique d'éviction transforme la pression mémoire en délai de démarrage

Un service peut conserver en mémoire les modèles fréquemment utilisés et évincer les modèles moins sollicités selon leur ancienneté d'utilisation, la demande prévue, la priorité ou le coût de chargement. Le routage multi-modèle nécessite des règles d'admission afin que les tâches en arrière-plan ne remplacent pas le modèle vocal qui doit répondre immédiatement.

FlexGen démontre le déchargement des poids entre le GPU, le CPU et le stockage pour l'inférence sous contrainte. Bien que cette approche vise le débit, elle rend le compromis fondamental explicite : déplacer les poids entre les niveaux permet d'économiser une mémoire rare, mais ajoute un coût de transfert et de planification.

La limite de défaillance correspond à une pression mémoire qui déclenche la pagination, les redémarrages pour dépassement de mémoire ou le phénomène d'éviction incessante. Conserver trop de poids chargés peut ralentir et rendre chaque modèle moins fiable qu'un réchauffement volontaire d'un ensemble de travail plus réduit. Cette dépendance doit rester explicite dans l'interface finale.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Définissez la résidence à partir de la distance de réutilisation et de la marge mémoire

Mesurez le temps de démarrage à froid, à chaud sur l'hôte et à chaud sur l'accélérateur pour chaque modèle, puis consignez l'intervalle entre les requêtes, le volume de données chargé, l'empreinte VRAM et RAM, la consommation au repos, le nombre d'évictions et la demande des charges de travail concurrentes. Le résultat doit donc être vérifié par rapport aux éléments probants d'origine.

Comparez le mécanisme de démarrage avec le démarrage par mappage mémoire. Rejouez une semaine d'arrivées selon différentes fenêtres de maintien en vie et priorités, en incluant les pics, les longues périodes d'inactivité et les requêtes simultanées de modèles. Cette distinction reste visible lors des tests ultérieurs en environnement domestique.

Conservez un modèle en mémoire lorsque la latence de chargement évitée et la fréquence de réutilisation justifient la mémoire qui lui est réservée. Évincez-le lorsque la capacité réservée provoque des files d'attente ou une éviction incessante, et préservez une marge de secours pour le cache KV et les allocations temporaires.