Was verursacht den schleichenden Anstieg des Arbeitsspeichers eines lokalen Modellservers zwischen Anfragen?

Der Speicher eines lokalen Modellservers wächst normalerweise allmählich, weil Caches und Allocatoren wiederverwendbare Blöcke behalten. Unbegrenzte Referenzen oder Lecks im nativen Code können jedoch ein echtes Wachstum verursachen.

Nach jeder Anfrage an den Home-Server kann ein Dashboard einen Anstieg des RAM- oder VRAM-Verbrauchs anzeigen, ohne dass der ursprüngliche Ausgangswert wieder erreicht wird. Die Laufzeit kann KV-Blöcke, Präfixeinträge, Kernel, Graphen, Arbeitsbereiche und freigegebene Tensorblöcke zur Wiederverwendung behalten. Unterschiedliche Prompt-Längen können Pools fragmentieren, während Protokolle, Sitzungen, Bildpuffer oder Erweiterungen Objekte unbegrenzt referenzieren. Daher erfordern diese Mechanismen unterschiedliche Nachweise und Begrenzungen.

Caching-Allocatoren reservieren freigegebene Blöcke zur Wiederverwendung

GPU-Frameworks vermeiden kostspielige Gerätezuweisungen, indem sie freigegebene Blöcke in einem prozesseigenen Pool behalten. Anwendungstensoren können bereits verschwunden sein, während der Treiber den reservierten Pool weiterhin als vom Modellserver verwendet meldet. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Eine Analyse von Allocatoren erklärt, wie zwischengespeicherte GPU-Speicherblöcke CUDA-Blöcke aufrundet, aufteilt, zusammenführt und cached. Das typische Muster besteht darin, dass der Speicher für zugewiesene Tensoren nach einer Anfrage sinkt, während der reservierte Speicher hoch bleibt und bei späteren Anfragen wiederverwendet wird.

Dieses Plateau ist nicht automatisch ein Leck. Problematisch wird es, wenn der Pool eine andere Dienstkomponente an einer Zuweisung hindert oder bei wiederholten Anfragen mit identischer Form nach dem Aufwärmen weiter wächst. Das Zwischenergebnis muss prüfbar bleiben, bevor die Automatisierung fortgesetzt wird.

Serving-Caches und Anfrageformen erweitern den vorgesehenen Arbeitssatz

KV-Caches wachsen mit dem aktiven Kontext, Präfix-Caches behalten wiederverwendbare Prompts, und kompilierte Graphen oder Kernel decken beobachtete Batch-Formen ab. Neue Kontextlängen, Modalitäten und Parallelitätsprofile können zwischen Anfragen weitere Einträge hinzufügen. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Untersuchungen zur LLM-Speicherfragmentierung identifizieren eine Fragmentierung zwischen Aktivierungs- und KV-Cache-Speicherbereichen beim LLM-Serving. Diese Beobachtung erklärt, warum die Gesamtkapazität steigen kann, obwohl keine einzelne aktive Anfrage groß ist. Die praktische Folge zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Erfassen Sie die Anzahl der Cache-Einträge und die Klassen der Anfrageformen. Ein Wachstum, das endet, sobald sich die Arbeitslastverteilung stabilisiert, ist ein begrenztes Aufwärmen. Ein Wachstum proportional zur Gesamtzahl der Anfragen oder zu eindeutigen Sitzungs-IDs deutet dagegen auf eine fehlende Ausmusterung hin. Diese Abhängigkeit sollte in der endgültigen Oberfläche ausdrücklich erkennbar bleiben.

Beibehaltene CPU-Objekte und native Puffer verursachen echtes schleichendes Wachstum

Anfrageverläufe, Streaming-Warteschlangen, Metriklabels, Tokenizer-Ausgaben, hochgeladene Bilder, angeheftete Host-Puffer und Zuweisungen von Erweiterungen können nach Abschluss weiterhin referenziert werden. GPU-Snapshots können stabil aussehen, während der RSS-Wert des Prozesses weiter steigt. Das Ergebnis muss daher anhand der ursprünglichen Belege überprüft werden.

Eine praktische Untersuchung des Verhältnisses zwischen zugewiesenem und reserviertem Speicher trennt Signale für zugewiesenen, reservierten und prozessbezogenen Speicher. Diese mehrschichtige Betrachtung verhindert, dass ein Aufbewahrungsproblem auf CPU-Seite fälschlicherweise dem GPU-Allocator zugeschrieben wird. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Die Fehlergrenze ist ein einmaliger Anstieg, auf den ein stabiler Höchststand folgt. Bezeichnen Sie es erst dann als Leck, wenn kontrollierte, identische Anfragen nach Berücksichtigung von Cache-Limits, Garbage Collection und erwarteten Pools weiterhin zu einem Anstieg des beibehaltenen Speichers führen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Erstellen Sie eine Speicheraufbewahrungskurve pro Anfrage

Wiederholen Sie Hunderte identischer Anfragen und anschließend Anfragen mit gemischten Längen und Modalitäten. Erfassen Sie dabei zugewiesene und reservierte GPU-Bytes, KV- und Präfixeinträge, den Graph-Cache, angehefteten Speicher, den Prozess-RSS, Objektanzahlen, Anfrage-Sitzungen, Neustarts von Workern und Allocator-Snapshots.

Verwenden Sie Speicherreservierung nach der Anfrage, um die beabsichtigte Reservierung nach einer Anfrage zu unterscheiden. Wiederholen Sie den Test mit jeweils einzeln deaktiviertem optionalem Cache, einzeln deaktivierter Erweiterung, deaktiviertem Upload-Pfad und deaktiviertem Metriklabel, während Modell und Parallelität unverändert bleiben. Das Zwischenergebnis muss prüfbar bleiben, bevor die Automatisierung fortgesetzt wird.

Akzeptieren Sie ein begrenztes Aufwärmen, das innerhalb des festgelegten Speicherbudgets ein Plateau erreicht. Fügen Sie eine Ausmusterung hinzu, wenn die Cache-Kardinalität ohne Nutzen wächst, normalisieren Sie Anfrageformen, wenn Fragmentierung dominiert, und isolieren Sie ein echtes Leck erst, wenn Stacktraces beibehaltene Zuweisungen eindeutig einem Verantwortlichen zuordnen.