Warum kann die Fragmentierung des GPU-Speichers ein lokales KI-Modell blockieren?
Die Fragmentierung des GPU-Speichers kann ein lokales KI-Modell daran hindern zu starten, wenn die freie Kapazität in Bereiche aufgeteilt ist, die das nächste Allokationsmuster der Laufzeitumgebung nicht erfüllen können.
Der Fehler tritt häufig nach dem Wechseln von Modellen, dem Ändern der Kontextlängen, dem gemeinsamen Ausführen von Bild- und Sprach-Workloads oder beim Bearbeiten von Anfragen auf, deren temporäre Tensoren wachsen und schrumpfen. Die Überwachung kann zwar ungenutzten VRAM anzeigen, doch der Allokator kann einen großen Arbeitsbereich, Modell-Shard oder eine Erweiterung des KV-Caches trotzdem nicht platzieren, ohne vorhandene Blöcke freizugeben oder neu zu organisieren. Die folgenden Abschnitte unterscheiden einen echten Kapazitätsmangel von einer Fragmentierung des Allokators und erklären, warum ein Neustart der Laufzeitumgebung vorübergehend dazu führen kann, dass dasselbe Modell wieder passt.
Der gesamte freie VRAM entspricht nicht dem nutzbaren Allokationsraum
Ein Speichermonitor meldet die Gesamtkapazität, doch ein Allokator muss Anfragen über die von ihm verwalteten Blöcke und virtuellen Zuordnungen erfüllen. Mehrere kleine freie Bereiche können sich zwar zu mehr als der angeforderten Größe summieren, unter einer Regel für zusammenhängende Allokationen aber trotzdem unbrauchbar sein.
Eine Analyse zum LLM-Betrieb beschreibt diese Abweichung beim freien Speicher, wenn KV-Caches und variable Tensoren Lücken hinterlassen, die kleiner als die nächste Anfrage sind. Der sichtbare OOM-Fehler betrifft daher sowohl die Speicheranordnung als auch die Gesamtzahl der Bytes.
Treiber und Frameworks können freien Gerätespeicher, reservierten, allokierten und inaktiven Speicher außerdem unterschiedlich melden. Vergleichen Sie die Ansicht des Laufzeit-Allokators mit der geräteweiten Nutzung, anstatt einer einzelnen Kennzahl zu vertrauen.
Unterschiedliche Tensorgrößen erzeugen im Laufe der Zeit Lücken
KI-Workloads allokieren und geben wiederholt Tensoren unterschiedlicher Größe frei – für Prompts, Batches, Bilddimensionen, Attention-Arbeitsbereiche und temporäre Konvertierungen. Ein Caching-Allokator behält Blöcke zur Wiederverwendung, da ihre wiederholte Rückgabe an den Treiber kostspielig ist.
Die Forschung zu GMLake zeigt, dass unregelmäßige Allokationen Poolspeicher, der auf dem Aufteilen von Blöcken basiert, beeinträchtigen und bei großen Modellen erhebliche Fragmentierung verursachen können. Die Wiederverwendung exakt gleicher Größen ist effizient; das wiederholte Aufteilen und Zusammenführen nicht zueinander passender Größen ist schwieriger.
Ein Home-Server, auf dem Modelle gewechselt werden, ist besonders anfällig, da Sprach-, Diffusions-, Bildverarbeitungs- und Sprachverarbeitungs-Laufzeiten sehr unterschiedliche Blockformen von derselben GPU anfordern.
Fragmentierung kann sich ohne Speicherleck aufbauen. Jede Allokation kann letztlich an den Pool zurückgegeben werden, doch dessen Struktur kann weiterhin schlecht zum nächsten Workload passen.
Ein wachsender KV-Cache macht die Fragmentierung bei der Inferenz dynamisch
LLM-Gewichte bleiben nach dem Laden relativ stabil, während der KV-Cache mit der Zahl aktiver Benutzer, der Prompt-Länge und den generierten Tokens wächst. Anfragen werden außerdem zu unterschiedlichen Zeitpunkten beendet und geben ungleichmäßig verteilte Bereiche frei.
PagedAttention wurde entwickelt, um die Fragmentierung des KV-Caches zu verringern, indem der Status einer Anfrage in kleineren Blöcken gespeichert wird, anstatt für eine unbekannte endgültige Sequenzlänge einen großen zusammenhängenden Bereich zu reservieren.
Dieses Problem unterscheidet sich von der Fragmentierung im allgemeinen Tensor-Allokator des Frameworks, beide können jedoch gleichzeitig auftreten. Ein ausgelagerter KV-Manager kann Arbeitsbereiche des Modells oder Allokationen eines anderen Prozesses nicht automatisch kompaktieren.
Die Diskussion von ZimaSpace über gleichzeitige Kontexte zeigt, warum ein Modell, das für eine Person passt, eine Speicherschwelle überschreiten kann, wenn mehrere Gespräche gleichzeitig wachsen.
Reservierter Speicher kann den Fehler wie ein Leck aussehen lassen
Framework-Allokatoren behalten häufig freigegebene Blöcke, um spätere Anfragen zu beschleunigen. Gerätetools zählen diese Blöcke als vom Prozess verwendet, selbst wenn das aktuelle Modell nicht in allen von ihnen aktive Tensoren hält.
Ein praxisorientierter OOM-Leitfaden unterscheidet reservierten Speicher vom Bedarf des aktiven Modells und Caches. Eine große Differenz kann auf wiederverwendbare Allokatorblöcke, Fragmentierung oder einen Workload hindeuten, dessen Spitzenbedarf höher war als der aktuelle Zustand.
Das Leeren eines Caches kann einige Blöcke an den Treiber zurückgeben, aber es kann keine aktiven Gewichte, einen aktiven KV-Status, den Kontext eines anderen Prozesses oder einen für die nächste Operation benötigten Arbeitsbereich freigeben.
Stabile Allokationsformen und Paging verringern wiederkehrende Fehler
Reproduzieren Sie den Fehler mit einem Modell, einem festen Kontextlimit, einer festen Batch-Größe und ohne konkurrierende KI-Dienste. Protokollieren Sie den allokierten und reservierten Speicher auf Prozessebene, den freien Speicher auf Geräteebene, die größte Anfrage sowie die Workload-Sequenz, die dem OOM-Fehler vorausging.
vAttention verwendet Zuordnungen des virtuellen Speichers, um zusammenhängenden virtuellen KV-Speicher vom physischen Speicher zu trennen. Ähnliche Paging- und segmentierte Allokationsverfahren verringern die Abhängigkeit von einem einzigen physisch zusammenhängenden Bereich.
Für einen Home-Server gehören dazu in der Praxis ein VRAM-Puffer, weniger häufige Modellwechsel, stabile Obergrenzen für Kontext und Batch-Größe, die Koordination der Dienste über eine einzige Laufzeitumgebung sowie der Neustart eines fragmentierten Prozesses während der Wartung statt erst nach dem Fehlschlagen einer Benutzeranfrage.
Wenn das Modell nach einem sauberen Neustart weiterhin nicht passt, liegt wahrscheinlich eher ein tatsächlicher Kapazitätsmangel als eine angesammelte Fragmentierung vor. Verkleinern Sie das Modell, den Quantisierungsbedarf, den Kontext oder die Batch-Größe oder reduzieren Sie konkurrierende Allokationen.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Warum werden Smart-Home-Prognosen nach saisonalen Änderungen der Routinen ungenauer?
Saisonale Routinen verändern das Verhältnis zwischen Zeit, Sensoren, Belegung und gewünschten Aktionen, wodurch ein auf früheren Gewohnheiten trainiertes Modell veraltet.
Warum verpasst ein Heim-NVR kurze Ereignisse, wenn die Objektverfolgung aktiviert ist?
Das Tracking benötigt ausreichend Erkennungen, um eine Trajektorie zu starten und zu bestätigen. Daher kann ein kurzzeitig auftauchendes Objekt verschwinden, bevor der NVR ein...
Warum ändern sich KI-Fotobezeichnungen nach einem Modell-Upgrade?
Ein Modell-Upgrade verändert die zur Zuweisung von Labels verwendete Repräsentation und Rangfolge, sodass dasselbe Foto unterschiedliche semantische Grenzen oder Konfidenzschwellen überschreiten kann.
