Was verursacht das Laden doppelter Modellkopien durch eine lokale KI-Laufzeitumgebung?
Doppelte Modellkopien entstehen, wenn separate Prozesse, Replikate, Sitzungen oder Gerätekontexte eine geladene Gewichtszuweisung nicht gemeinsam nutzen können.
Ein Heimserver für KI kann nach dem Hinzufügen einer Weboberfläche, eines Hintergrund-Workers, eines Sprachdienstes, eines Dokumentenindexierers oder eines zweiten API-Endpunkts ungefähr doppelt so viel RAM oder VRAM anzeigen wie erwartet. Die Modelldatei auf der Festplatte kann weiterhin nur einmal vorhanden sein, während mehrere Laufzeitobjekte unabhängige Gewichte, konvertierte Tensoren, vorgepackte Kernel, Caches und Gerätekontexte vorhalten. Manche Duplikate entstehen unbeabsichtigt, andere sind bewusst erstellte Replikate für Parallelität, Isolation oder parallele Ausführung.
Eine Modelldatei kann mehrere unabhängige Laufzeitobjekte erzeugen
Das Laden über denselben Pfad bedeutet nicht, dass zwei Anwendungen auf dasselbe Modell im Speicher verweisen. Jede Laufzeitinstanz kann den Checkpoint analysieren und eigene Tensoren zuweisen.
Die Inferenzempfehlungen von Google Cloud unterscheiden Konfigurationen, die eine Modellkopie pro Prozess oder pro virtueller Maschine laden.
Steigt der Speicherverbrauch mit zunehmender Worker-Anzahl in Schritten von ungefähr einer Modellgröße, ist die Instanzreplikation die Hauptursache. Kleinere Zuwächse deuten eher auf Worker-spezifische Caches, Speicherzuweiser oder Ausführungskontexte hin.
Webserver und Job-Worker starten häufig separate Prozesse
Ein Frontend-Server, ein Warteschlangen-Consumer, ein Scheduler, ein Transkriptionsdienst und ein RAG-Worker können jeweils den Modelllader importieren, selbst wenn sie zu demselben Compose-Stack gehören.
Die Prozessisolierung gibt jedem Dienst einen eigenen Adressraum. CPU-Seiten können mithilfe von Betriebssystemmechanismen teilweise gemeinsam genutzt werden, aber gewöhnliche Framework-Objekte und GPU-Zuweisungen werden nicht automatisch zu einem gemeinsam genutzten Modelldienst.
Die Duplizierung folgt den Prozess-IDs und Dienstgrenzen. Gibt das Beenden eines Containers ungefähr eine Modellkopie frei, hat der Container Anfragen nicht lediglich an eine zentrale Laufzeit weitergeleitet.
Serving-Replikate sind absichtlich einzelne Kopien
Systeme mit automatischer Skalierung erhöhen den Durchsatz, indem sie weitere Replikate starten. Ein Replikat ist ein unabhängiger Worker, der Anfragen bedienen kann, wenn andere Worker ausgelastet sind.
Ray Serve definiert Replikate als einzelne Kopien, die in separaten Actor-Prozessen ausgeführt werden.
Ein Speicherwachstum, das mit Verkehrsspitzen oder Ereignissen der automatischen Skalierung einhergeht, ist beabsichtigte Replikation und kein Speicherleck. Die Ursache liegt im gewählten Parallelitätsmodell, selbst wenn das Herunterskalieren der zusätzlichen Replikate später Zeit benötigt.
Mehrere Inferenzsitzungen können Initialisierer und vorgepackte Gewichte duplizieren
Eine Anwendung kann innerhalb eines Prozesses mehrere Sitzungen für verschiedene Threads, Endpunkte, Profile oder Ausführungsanbieter erstellen.
ONNX Runtime dokumentiert die gemeinsame Nutzung von Speicherzuweisern, Initialisierern und vorgepackten Gewichten über mehrere Sitzungen hinweg, da separate Sitzungen andernfalls zusätzlichen Speicherbedarf verursachen.
Besitzt ein Prozess mehrere Sitzungsobjekte und steigt der Speicherverbrauch bei der Initialisierung jeder Sitzung, befindet sich der doppelte Zustand innerhalb der Anwendung und nicht containerübergreifend.
Forking garantiert keine gemeinsam genutzten Accelerator-Gewichte
Ein übergeordneter Prozess kann ein Modell laden, bevor er Worker erstellt, und durch Copy-on-Write scheinbar CPU-Seiten gemeinsam nutzen. Die Initialisierung des Accelerators und veränderlicher Laufzeitstatus machen diese Annahme jedoch komplizierter.
Die Multiprocessing-Empfehlungen von PyTorch erklären, dass Tensoren Mechanismen für gemeinsam genutzten Speicher über Prozesse hinweg verwenden können, die gemeinsame Nutzung jedoch ein ausdrücklich dafür ausgelegtes, kompatibles Design erfordert.
Ein Worker, der das Modell auf die GPU verschiebt, Gewichte ändert, einen Cache aufbaut oder nach dem Start initialisiert, kann eine neue Kopie zuweisen, selbst wenn die ursprünglichen CPU-Seiten des Checkpoints gemeinsam genutzt wurden.
Separate CUDA-Kontexte fügen prozessspezifischen Gerätezustand hinzu
Zwei Prozesse, die eine GPU verwenden, arbeiten normalerweise über getrennte CUDA-Kontexte, sofern keine spezielle Architektur für die gemeinsame Nutzung eingesetzt wird.
NVIDIA weist darauf hin, dass mehrere CUDA-Anwendungsprozesse im Allgemeinen mehrere Kontexte mit zusätzlichem Speicherbedarf erstellen.
Der Kontext-Overhead ist für sich genommen kein zweites vollständiges Modell, kann aber zusammen mit duplizierten Gewichten, Kerneln, Arbeitsbereichen und Caches auftreten. Speicherzuwächse, die kleiner als die Checkpoint-Größe sind, können daher trotzdem durch Prozessduplizierung entstehen.
Zwei Laufzeitinstanzen auf einer GPU reservieren Speicher unabhängig voneinander
Ein Dashboard kann einen Modellserver starten, während ein Automatisierungsdienst einen zweiten startet, wobei beide auf denselben Checkpoint und dasselbe Gerät verweisen.
vLLM dokumentiert, dass die GPU-Speichernutzung ein Limit pro Instanz ist, und zeigt als Beispiel zwei Instanzen, die die Kapazität einer GPU aufteilen.
Wenn jeder Endpunkt seinen eigenen Listener, seine eigenen Protokolle, seinen eigenen Scheduler und seinen eigenen KV-Cache besitzt, sind die beiden Prozesse unabhängige Inferenz-Engines. Ein gemeinsam genutztes Modellverzeichnis verhindert doppelte Downloads, nicht jedoch doppelte Laufzeitzuweisungen.
Neuladevorgänge können einen alten Prozess neben dem neuen am Leben lassen
Hot-Reload-Mechanismen, Supervisoren, Rolling Updates, fehlgeschlagene Beendigungen und Neustarts durch Health-Checks können einen Ersatzprozess starten, bevor der alte Worker sein Modell freigibt.
Diese Ursache zeigt sich als vorübergehendes oder dauerhaftes Paar nahezu identischer Prozesse mit unterschiedlichen Startzeiten. Anfragen erreichen möglicherweise nur den neueren Prozess, während der ältere weiterhin RAM oder VRAM belegt.
Der Artikel von ZimaSpace darüber, warum man den KI-Laufzeitstatus von Modelldateien trennen sollte, beschreibt die Abgrenzung: Ein gemeinsamer Checkpoint-Cache kann viele Bereitstellungen versorgen, aber die Diensttopologie bestimmt weiterhin, wie viele geladene Kopien vorhanden sind.
FAQ
Bedeutet eine einzige Modelldatei auf der Festplatte, dass sich auch nur eine Kopie im RAM befindet?
Nein. Mehrere Prozesse oder Sitzungen können dieselbe Datei unabhängig voneinander lesen und eigene Tensoren, Caches und Ausführungszustände zuweisen.
Ist jede zusätzliche Kopie ein Speicherleck?
Nein. Replikate, Tensor-Parallel-Worker, Fallback-Laufzeiten und isolierte Dienste können absichtlich zusätzlichen Zustand zuweisen. Ein Leck wächst ohne ein entsprechendes aktives Laufzeitobjekt.
Können Container automatisch dasselbe GPU-Modell gemeinsam nutzen?
Nein. Container können auf dasselbe Gerät und dieselben Dateien zugreifen, benötigen aber einen gemeinsam genutzten Serving-Prozess oder ein ausdrücklich dafür ausgelegtes Design zur Kommunikation zwischen Prozessen, um eine geladene Modellzuweisung wiederzuverwenden.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Welche Funktionen ermöglichen eine vertrauenswürdige Grenze für die KI-Verarbeitung sensibler Dateien zu Hause?
Eine Vertrauensgrenze für heimische KI kombiniert Verschlüsselung ruhender Daten, Berechtigungen nach dem Prinzip der geringsten Privilegien, Sandboxing zur Laufzeit und gezielte Datenabfragen – keine...
Warum werden häufig bearbeitete Dateien in privaten Suchergebnissen bevorzugt?
Häufig bearbeitete Dateien erhalten Ranking-Vorteile, wenn jedes Update Aktualität, Chunks, Versionen oder Interaktionssignale hinzufügt, ohne nach der Quelle zu normalisieren.
Wodurch verwechseln Smart-Home-Anwesenheitsmodelle Gäste mit Bewohnern?
Gäste können wie Bewohner erscheinen, wenn das System Aktivitätsmuster im Haushalt beobachtet, aber kein stabiles Identitätssignal für die Person besitzt, die diese Aktivitäten verursacht.
