Mappage mémoire des fichiers de modèle : comment les pages partagées réduisent l’utilisation de RAM en double

Les fichiers de modèles mappés en mémoire peuvent réduire l’utilisation de RAM dupliquée, car les processus référencent les mêmes pages propres adossées aux fichiers par l’intermédiaire du cache de pages du système d’exploitation.

Charger deux workers de modèles locaux ne nécessite pas toujours deux copies complètes du fichier de poids en mémoire physique. Avec le mappage mémoire, chaque processus reçoit des adresses virtuelles liées aux offsets du fichier, et les pages sont chargées à la demande. Le système d’exploitation peut fournir les mêmes pages propres depuis une seule copie physique mise en cache, tout en conservant séparément l’état d’exécution privé de chaque processus.

Le mappage mémoire relie les adresses virtuelles aux offsets du fichier

Un fichier mappé apparaît dans l’espace d’adressage d’un processus sans que l’application lise l’intégralité du fichier dans un tampon distinct du tas. L’accès à une page absente déclenche un défaut de page ; le noyau charge ou retrouve la page correspondante adossée au fichier, puis met à jour la table des pages du processus.

Le manuel Linux du mappage mémoire documente les mappages MAP_SHARED et MAP_PRIVATE ainsi que la relation entre les mises à jour des mappages et l’objet sous-jacent. Les poids de modèles en lecture seule restent généralement des données propres adossées au fichier, ce qui les rend réutilisables par le cache de pages. Cette distinction reste importante dans des conditions d’utilisation domestiques réalistes.

La pagination à la demande peut raccourcir le démarrage et limiter la mémoire résidente lorsque seule une partie du modèle est utilisée. Elle peut aussi déplacer le coût vers le premier accès ; des défauts de pages froides et la latence du stockage peuvent donc apparaître pendant l’inférence plutôt que durant une phase de chargement explicite.

Le cache de pages peut servir plusieurs processus simultanément

Deux processus peuvent mapper le même inode de modèle et les mêmes offsets dans des espaces d’adressage virtuels différents. Lorsqu’ils lisent tous deux la même page propre, le noyau peut mapper la même page physique mise en cache dans les deux tables des pages. Les mappages virtuels sont distincts ; les données résidentes sous-jacentes peuvent être partagées.

La documentation Linux consacrée aux données de mappage des pages explique comment l’espace utilisateur peut inspecter les mappages de pages et les informations sur les cadres de pages, sous réserve des restrictions d’accès. Ces interfaces aident à déterminer si des régions virtuelles apparemment distinctes font référence à des pages physiques partagées. L’état intermédiaire doit rester visible lors des diagnostics et examens ultérieurs.

C’est pourquoi additionner le RSS de chaque processus peut surestimer l’utilisation physique totale : une page partagée apparaît comme résidente dans chaque processus. La taille d’ensemble proportionnelle (PSS) répartit les pages partagées entre les mappages et est généralement plus utile pour estimer l’empreinte combinée des workers de modèles.

L’état privé et les pages modifiées se multiplient malgré tout

Les caches KV, les activations, les arènes de l’allocateur, les tampons du tokenizer et l’état des requêtes sont créés pour chaque worker ou chaque session. Une écriture via un mappage privé déclenche une copie à l’écriture, créant une page anonyme qui ne peut plus partager la copie propre adossée au fichier. Des versions différentes du fichier empêchent également la réutilisation.

Le manuel Linux de smaps classe les pages privées, partagées, propres et modifiées, ainsi que smaps manual pour chaque mappage. Ces catégories expliquent pourquoi deux workers partageant leurs poids peuvent tout de même afficher une augmentation importante de la mémoire à mesure que la concurrence et la longueur du contexte augmentent.

La limite est que le mappage réduit les poids propres dupliqués, mais pas la mémoire totale d’inférence. Les fichiers de modèles montés sur le réseau peuvent également entraîner une latence instable des défauts de page, et les chargeurs compressés ou transformés peuvent allouer une seconde représentation décompressée qui annule le partage attendu.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comparer un worker à deux workers mappés

Partez d’un cache froid, lancez un worker de modèle, exécutez un prompt fixe et relevez le temps de démarrage, les défauts de page, le RSS, le PSS et la mémoire privée modifiée. Lancez ensuite un deuxième worker identique et répétez l’opération sans modifier le fichier de modèle ni les options du chargeur.

Reliez le résultat aux compromis liés à la compression présentés dans les compromis de compression : les fichiers plus petits facilitent le stockage, tandis que les avantages du mappage dépendent de la représentation réellement utilisée en mémoire. Examinez le mappage de chaque modèle dans smaps plutôt que de vous fier au total d’un seul processus.

Le test est concluant si le deuxième worker ajoute beaucoup moins de mémoire de poids que le premier, tout en produisant la même sortie et en conservant une latence à froid acceptable. Si le PSS double presque, vérifiez l’identité du fichier, les mappages accessibles en écriture, la décompression et les copies cachées avant de conclure que mmap est inefficace.