Speicherzuordnung von Modelldateien: Wie gemeinsam genutzte Seiten den doppelten RAM-Verbrauch reduzieren

Memory-abgebildete Modelldateien können die doppelte RAM-Nutzung reduzieren, da Prozesse über den Seiten-Cache des Betriebssystems auf dieselben unveränderten, dateigestützten Seiten zugreifen.

Das Laden von zwei lokalen Modell-Workern erfordert nicht immer zwei vollständige Kopien der Gewichtedatei im physischen Speicher. Beim Memory-Mapping erhält jeder Prozess virtuelle Adressen, die mit Datei-Offsets verknüpft sind, und Seiten werden bei Bedarf geladen. Das Betriebssystem kann identische, unveränderte Seiten aus einer einzigen zwischengespeicherten physischen Kopie bereitstellen, während der private Laufzeitstatus jedes Prozesses getrennt bleibt.

Memory-Mapping verknüpft virtuelle Adressen mit Datei-Offsets

Eine gemappte Datei erscheint im Adressraum eines Prozesses, ohne dass eine Anwendung die gesamte Datei in einen separaten Heap-Puffer einlesen muss. Der Zugriff auf eine fehlende Seite löst einen Seitenfehler aus; der Kernel lädt die entsprechende dateigestützte Seite oder findet sie und aktualisiert die Seitentabelle des Prozesses.

Das Handbuch zum Memory-Mapping von Linux dokumentiert MAP_SHARED- und MAP_PRIVATE-Mappings sowie den Zusammenhang zwischen gemappten Änderungen und dem zugrunde liegenden Objekt. Schreibgeschützte Modellgewichte bleiben üblicherweise unveränderte dateigestützte Daten und können daher vom Page-Cache-Reuse profitieren. Diese Unterscheidung bleibt unter realistischen Bedingungen im Heimgebrauch wichtig.

Demand Paging kann den Start verkürzen und den residenten Speicher begrenzen, wenn nur ein Teil eines Modells verwendet wird. Gleichzeitig können dadurch Kosten auf den ersten Zugriff verlagert werden, sodass Fehler beim Zugriff auf nicht im Cache befindliche Seiten und Speicherlatenzen während der Inferenz statt während einer expliziten Ladephase auftreten.

Der Page-Cache kann mehrere Prozesse gleichzeitig bedienen

Zwei Prozesse können dieselbe Modell-Inode und dieselben Offsets in unterschiedliche virtuelle Adressräume mappen. Wenn beide dieselbe unveränderte Seite lesen, kann der Kernel dieselbe zwischengespeicherte physische Seite in beide Seitentabellen eintragen. Die virtuellen Mappings sind getrennt; die zugrunde liegenden residenten Daten können gemeinsam genutzt werden.

Die Linux-Dokumentation zu Page-Mapping-Daten erklärt, wie Userspace Page-Mappings und Informationen zu Seitenrahmen untersuchen kann, vorbehaltlich Zugriffsbeschränkungen. Diese Schnittstellen helfen zu zeigen, ob scheinbar getrennte virtuelle Bereiche auf gemeinsam genutzte physische Seiten verweisen. Der Zwischenzustand sollte bei späterer Diagnose und Überprüfung weiterhin sichtbar bleiben.

Deshalb kann das Addieren des RSS-Werts pro Prozess den gesamten physischen Speicherverbrauch überschätzen: Eine gemeinsam genutzte Seite erscheint in jedem Prozess als resident. Die Proportional Set Size verteilt gemeinsam genutzte Seiten auf die Mappings und ist meist besser geeignet, den kombinierten Speicherbedarf von Modell-Workern zu schätzen.

Privater Status und veränderte Seiten vervielfachen sich weiterhin

KV-Caches, Aktivierungen, Allokator-Arenen, Tokenizer-Puffer und Anfragezustände werden pro Worker oder Sitzung erstellt. Ein Schreibzugriff über ein privates Mapping löst Copy-on-Write aus und erstellt eine anonyme Seite, die die unveränderte dateigestützte Kopie nicht mehr gemeinsam nutzen kann. Auch unterschiedliche Dateiversionen verhindern die Wiederverwendung.

Das smaps-Handbuch von Linux klassifiziert private, gemeinsam genutzte, unveränderte und veränderte Bereiche sowie smaps manual für jedes Mapping. Diese Kategorien erklären, warum zwei Worker, die ihre Gewichte gemeinsam nutzen, bei steigender Parallelität und Kontextlänge dennoch einen beträchtlichen zusätzlichen Speicherbedarf aufweisen können.

Die Grenze besteht darin, dass Mapping doppelte unveränderte Gewichte reduziert, nicht jedoch den gesamten Inferenzspeicherbedarf. Über das Netzwerk eingebundene Modelldateien können außerdem zu instabilen Latenzen bei Seitenfehlern führen, und komprimierende oder transformierende Loader können eine zweite entpackte Repräsentation anlegen, wodurch die erwartete gemeinsame Nutzung entfällt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Einen Worker mit zwei gemappten Workern vergleichen

Beginnen Sie mit einem leeren Cache, starten Sie einen Modell-Worker, führen Sie einen festen Prompt aus und erfassen Sie Startzeit, Seitenfehler, RSS, PSS und privaten veränderten Speicher. Starten Sie anschließend einen zweiten identischen Worker und wiederholen Sie den Vorgang, ohne die Modelldatei oder die Loader-Flags zu ändern.

Setzen Sie das Ergebnis in Beziehung zu den Kompromissen bei der Komprimierung in Kompromissen bei der Komprimierung: Kleinere Dateien sparen Speicherplatz, während der Nutzen des Mappings davon abhängt, welche Repräsentation tatsächlich im Speicher verwendet wird. Untersuchen Sie jedes Modell-Mapping in smaps, statt sich auf die Gesamtsumme eines einzelnen Prozesses zu verlassen.

Der Test gilt als bestanden, wenn der zweite Worker deutlich weniger Gewichtespeicher als der erste zusätzlich benötigt und dabei dieselbe Ausgabe sowie eine akzeptable Kaltstartlatenz liefert. Wenn sich die PSS nahezu verdoppelt, prüfen Sie Date iidentität, beschreibbare Mappings, Dekomprimierung und verborgene Kopien, bevor Sie davon ausgehen, dass mmap unwirksam ist.