Geheugentoewijzing van modelbestanden: hoe gedeelde pagina’s dubbel RAM-gebruik verminderen

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Modelbestanden die via geheugenmapping worden gebruikt, kunnen dubbel RAM-gebruik verminderen, omdat processen via de paginacache van het besturingssysteem naar dezelfde schone, door bestanden ondersteunde pagina’s verwijzen.

Het laden van twee lokale modelworkers vereist niet altijd twee volledige kopieën van het gewichtsbestand in het fysieke geheugen. Met geheugenmapping krijgt elk proces virtuele adressen die aan bestandsposities zijn gekoppeld, waarna pagina’s op aanvraag worden geladen. Het besturingssysteem kan identieke schone pagina’s vanuit één fysieke kopie in de cache beschikbaar stellen, terwijl de private runtime-status van elk proces afzonderlijk blijft.

Geheugenmapping koppelt virtuele adressen aan bestandsposities

Een gemapt bestand verschijnt binnen de adresruimte van een proces zonder dat een toepassing het volledige bestand naar een afzonderlijke heapbuffer hoeft te lezen. Toegang tot een ontbrekende pagina veroorzaakt een fout; de kernel laadt de bijbehorende door bestanden ondersteunde pagina of zoekt die op en werkt de paginatabel van het proces bij.

De handleiding voor geheugenmapping van Linux documenteert MAP_SHARED- en MAP_PRIVATE-mappings en de relatie tussen gemapte updates en het onderliggende object. Alleen-lezen-modelgewichten blijven doorgaans schone, door bestanden ondersteunde gegevens, waardoor ze in aanmerking komen voor hergebruik via de paginacache. Dit onderscheid blijft belangrijk onder realistische omstandigheden in een huishouden.

Demand paging kan het opstarten versnellen en het resident geheugen beperken wanneer slechts een deel van een model wordt gebruikt. De kosten kunnen daardoor ook naar de eerste toegang verschuiven, waardoor fouten door koude pagina’s en opslaglatentie tijdens inferentie kunnen optreden in plaats van tijdens een expliciete laadfase.

De paginacache kan meerdere processen tegelijk bedienen

Twee processen kunnen dezelfde model-inode en bestandsposities naar verschillende virtuele adresruimten mappen. Wanneer beide dezelfde schone pagina lezen, kan de kernel dezelfde fysieke pagina uit de cache naar beide paginatabellen mappen. De virtuele mappings zijn afzonderlijk; de onderliggende residente gegevens kunnen worden gedeeld.

De Linux-documentatie voor paginamappinggegevens legt uit hoe userspace paginamappings en informatie over paginaframes kan inspecteren, onder voorbehoud van toegangsbeperkingen. Deze interfaces helpen aantonen of ogenschijnlijk afzonderlijke virtuele regio’s verwijzen naar gedeelde fysieke pagina’s. De tussenstatus moet zichtbaar blijven tijdens latere diagnose en beoordeling.

Daarom kan het optellen van RSS per proces het totale fysieke gebruik overschatten: een gedeelde pagina lijkt in elk proces resident te zijn. De proportionele setgrootte verdeelt gedeelde pagina’s over de mappings en is doorgaans nuttiger bij het schatten van de gecombineerde voetafdruk van modelworkers.

Private status en gewijzigde pagina’s blijven zich vermenigvuldigen

KV-caches, activaties, allocatorarena’s, tokenizerbuffers en requeststatus worden per worker of per sessie aangemaakt. Schrijven via een private mapping activeert copy-on-write, waardoor een anonieme pagina wordt aangemaakt die de schone, door bestanden ondersteunde kopie niet langer kan delen. Verschillende bestandsversies verhinderen hergebruik eveneens.

De smaps-handleiding van Linux classificeert private, gedeelde, schone en gewijzigde gegevens en smaps-handleiding voor elke mapping. Deze categorieën verklaren waarom twee workers die gewichten delen toch een aanzienlijke extra geheugentoename kunnen laten zien wanneer de gelijktijdigheid en contextlengte toenemen.

De grens is dat mapping dubbele schone gewichten vermindert, maar niet het totale inferentiegeheugen. Modelbestanden op netwerkgemounte opslag kunnen ook instabiele foutlatentie veroorzaken, en gecomprimeerde of getransformeerde loaders kunnen een tweede uitgepakte representatie toewijzen, waardoor het verwachte delen teniet wordt gedaan.

Vergelijk één worker met twee gemapte workers

Begin met een koude cache, start één modelworker, voer een vaste prompt uit en noteer de opstarttijd, pagina-fouten, RSS, PSS en private gewijzigde geheugen. Start vervolgens een tweede identieke worker en herhaal de test zonder het modelbestand of de loaderopties te wijzigen.

Breng het resultaat in verband met de compressieafwegingen in compressieafwegingen: kleinere bestanden helpen voor opslag, terwijl de voordelen van mapping afhangen van de daadwerkelijk gebruikte geheugenrepresentatie. Inspecteer elke modelmapping in smaps in plaats van te vertrouwen op één procestotaal.

De test slaagt als de tweede worker veel minder gewichtsgeheugen toevoegt dan de eerste, terwijl dezelfde uitvoer en een acceptabele koude latentie worden geproduceerd. Als PSS bijna verdubbelt, controleer dan de bestandsidentiteit, schrijfbare mappings, decompressie en verborgen kopieën voordat je concludeert dat mmap niet effectief is.

Tech & AI HUB

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.