Warum starten containerisierte KI-Modelle neu, obwohl der Host freien Speicher meldet?

Containerisierte KI-Modelle können trotz freiem Host-Speicher neu starten, weil ihre cgroup-, Beschleuniger- oder Supervisor-Limits enger gefasst sind als die RAM-Ansicht des gesamten Systems.

Ein Home-Server-Dashboard kann mehrere Gigabyte freien Speicher anzeigen, während ein Inferenz-Container verschwindet und mit einer neuen Prozess-ID zurückkehrt. Der Container kann seine eigene Speicherobergrenze erreichen, während der Rückgewinnung eine Gesundheitsprüfung nicht bestehen, den GPU-Speicher erschöpfen oder nach einem Zuordnungsfehler beendet werden. Eine Neustartrichtlinie macht aus diesem lokalen Fehler dann einen scheinbar spontanen Modellneustart.

Der Container hat eine andere Speichergrenze als der Host

Linux-Control-Groups erfassen und begrenzen den Speicher für eine ausgewählte Prozessgruppe. Ein Container kann memory.max oder ein Laufzeitlimit erreichen, während dem Kernel weiterhin unabhängiger Host-RAM zur Verfügung steht. Daher beschreibt die systemweite Anzeige des freien Speichers nicht die Zuordnungsgrenze, die für diesen Dienst gilt.

Eine detaillierte Erklärung der cgroup-Speicherabrechnung unterscheidet anonymen Speicher, zugeordnete Dateien und den Cache, der einer Control-Group zugerechnet wird. Diese Abrechnung zeigt, warum aus dem Datenträger geladene Gewichte, temporäre Modellpuffer und der Seiten-Cache das Budget eines Containers aufbrauchen können, selbst wenn eine einfache RSS-Ansicht des Prozesses kleiner aussieht.

Limits können außerdem verschachtelt sein: Ein Modell-Container kann sich innerhalb eines Compose-Dienstes, eines systemd-Slices, einer virtuellen Maschine oder einer Orchestrierungsgruppe befinden. Die jeweils engste aktive Grenze kann eine Rückgewinnung oder eine Beendigung wegen Speichermangels auslösen, bevor sich der physische Host einer globalen Erschöpfung nähert.

Speicherdruck kann Gesundheitsprüfungen vor einer OOM-Beendigung ausbremsen

Wenn sich das Limit nähert, kann der Kernel den Cache zurückgewinnen, Speicher scannen und Zuordnungen drosseln. Das Modell kann weiterhin aktiv sein, aber zu langsam auf eine Gesundheitsprüfung reagieren, sodass der Supervisor es beendet und ersetzt, ohne eine OOM-Beendigung auf Containerebene zu protokollieren.

Das Framework für Pressure Stall Information misst die Zeit, die verloren geht, weil Aufgaben auf Speicher-, CPU- oder I/O-Druck warten, anstatt sich nur auf die Auslastung zu stützen. Pressure Stall Information erklärt, warum freie Bytes und die Reaktionsfähigkeit eines Dienstes während einer aggressiven Rückgewinnung voneinander abweichen können.

Das Laden von KI-Modellen erzeugt Spitzen mit schwankender Auslastung: Bei der Deserialisierung können komprimierte und expandierte Gewichte vorübergehend gleichzeitig im Speicher liegen, bei der Quantisierung kann zusätzlicher Arbeitsspeicher für temporäre Berechnungen reserviert werden, und parallele Worker können Puffer duplizieren. Der konstante Speicherbedarf nach dem Laden unterschätzt daher die kurze Spitze, die zeitlich mit der fehlgeschlagenen Prüfung zusammenfällt.

GPU-Fehler und Neustartrichtlinien können einen Host-OOM vortäuschen

Messwerte des Host-RAMs schließen dedizierten VRAM normalerweise aus. Ein Modell kann bei der GPU-Zuordnung scheitern, weil Gewichte, KV-Cache, Kernel und eine weitere Arbeitslast den Beschleuniger belegen. Es wird dann möglicherweise mit einem Anwendungsfehler beendet, während der Host weiterhin reichlich Systemspeicher meldet.

Richtlinien zur Ressourcenverwaltung unterscheiden Speicherlimits für Container von einem systemweiten Speichermangel und erklären, dass Limits von Laufzeitumgebung und Kernel durchgesetzt werden, nicht durch die Anzeige des freien Speichers im Dashboard. Der Neustart wird dann von der Neustartrichtlinie der Arbeitslast gesteuert und nicht von der Speichermessung selbst.

Die Annahme, dass jede neue Container-ID ein OOM-Ereignis beweist, bildet die falsche Fehlergrenze. Image-Aktualisierungen, Watchdog-Zeitüberschreitungen, manuelle Neubereitstellungen, Geräte-Resets und Anwendungsabstürze erzeugen dasselbe sichtbare Symptom. Beendigungsgrund, Kernel-Log, cgroup-Ereignisse und GPU-Fehler müssen übereinstimmen, bevor Speicher als Ursache festgelegt wird.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Beendigungsgrund mit jeder Speichergrenze abgleichen

Reproduzieren Sie das Laden eines Modells einmal und erfassen Sie dabei container memory.current, memory.max, memory.events, den RSS und die zugeordneten Dateien des Prozesses, MemAvailable des Hosts, die Pressure-Stall-Summen, den GPU-Speicher, die Latenz der Gesundheitsprüfung, den Exit-Code des Prozesses und die Anzahl der Neustarts durch den Supervisor auf einer gemeinsamen Zeitachse.

Verwenden Sie konkurrierende Container-Arbeitslasten als Kontext und wiederholen Sie den Test anschließend mit demselben Modell unter einem höheren Container-Limit, deaktivierter Neustartrichtlinie und ohne konkurrierende Arbeitslast auf dem Beschleuniger. Ändern Sie pro Durchlauf nur eine Grenze, damit ein erfolgreicher Neustart den ursprünglichen Fehler nicht verdeckt.

Ordnen Sie das Ereignis als cgroup-OOM, globalen OOM, GPU-Zuordnungsfehler, Beendigung durch die Gesundheitsprüfung oder Anwendungsende ein, bevor Sie Limits ändern. Wenn die Spitze legitim ist, lassen Sie ausreichend Spielraum; wenn eine Prüfung ein Modell beendet, das während der Rückgewinnung weiterhin gesund ist, passen Sie das Timing der Prüfung an, ohne echte Hänger zu verschleiern.