Kann ein lokaler KI-Dienst auf die CPU ausweichen, wenn der GPU-Speicher voll ist?

Ja, aber ein zuverlässiger CPU-Failover muss geplant werden, bevor der GPU-Speicher voll ist; die meisten Inferenzprozesse können sich nicht transparent von einem unerwarteten OOM-Fehler erholen.

Ein KI-Heimserver kann auf seiner GPU schnell antworten, bis ein längerer Prompt, ein größerer Batch, eine Bildanfrage oder ein zweites Modell den verbleibenden VRAM verbraucht. Die nächste Speicherzuweisung kann fehlschlagen, obwohl System-RAM und CPU nicht ausgelastet sind. Ob die Anfrage erfolgreich abgeschlossen wird, hängt von der Laufzeitumgebung ab: Manche können Gewichte von Anfang an auf der CPU platzieren, während andere einen separaten CPU-Worker und einen Router benötigen, der sicher erneut versucht.

CPU-Offloading und CPU-Failover lösen unterschiedliche Probleme

CPU-Offloading ist eine Strategie zur Modellplatzierung. Ausgewählte Layer, Tensoren oder Pipeline-Komponenten liegen im System-RAM und werden bei Bedarf zum Beschleuniger verschoben, wodurch der für eine normale Anfrage benötigte VRAM reduziert wird. CPU-Failover ist ein Verhalten des Dienstes: Wenn der GPU-Pfad nicht verfügbar ist oder eine Anfrage ablehnt, übernimmt ein anderer Worker und führt sie mit einem CPU-kompatiblen Modell aus, ohne den Auftrag zu verlieren.

Hugging Face Accelerate bietet Methoden für CPU-Offloading, die den Modellzustand gezielt zwischen CPU-Speicher und einem Ausführungsgerät verschieben. Das ist eine geplante heterogene Ausführung und keine Notfallreaktion, nachdem ein beliebiger CUDA-Zustand fehlgeschlagen ist. Modell, Gerätezuordnung, Hooks und Speicherbudget werden vor Beginn der Inferenz vorbereitet.

Ein teilweise ausgelagertes Modell kann bereits die CPU nutzen und dennoch für jedes Token von der GPU abhängen. Wenn die GPU ausfällt, kann dieser Prozess möglicherweise nicht ab dem unterbrochenen Token auf der CPU fortgesetzt werden. Ein echtes Failover startet die Anfrage normalerweise auf einem CPU-bereiten Worker neu. Dieser Unterschied erklärt, warum eine Anwendung zwar CPU-Unterstützung angeben kann, aber dennoch einen OOM-Fehler zurückgibt, anstatt die aktuelle Anfrage abzuschließen.

VRAM kann voll werden, nachdem ein Modell erfolgreich geladen wurde

Die Modellgewichte sind nur ein Teil des Speicherbudgets. Der Key-Value-Cache wächst mit der aktiven Sequenzlänge und der Parallelität, temporäre Kernels benötigen Arbeitsbereich, Bild- oder Audio-Encoder fügen Tensoren hinzu, und ein Speicher-Allocator kann Blöcke zur Wiederverwendung reservieren. Ein Modell, das beim Start hineinpasst, kann daher bei einem langen Kontext oder mehreren gleichzeitigen Nutzern fehlschlagen.

PyTorch verwendet einen Caching-Speicher-Allocator, sodass der als reserviert gemeldete Speicher nicht mit dem Speicher identisch ist, den aktive Tensoren tatsächlich belegen. Fragmentierung und außerhalb des Frameworks vorgenommene Speicherzuweisungen können den nutzbaren Spielraum weiter reduzieren. Ein Failover-Trigger sollte abgelehnte Speicherzuweisungen und den Zustand des Workers überwachen, statt die Sicherheit aus einer einzelnen Dashboard-Zahl oder der Tatsache abzuleiten, dass das Laden des Modells erfolgreich war.

Deshalb ist auch die statische Regel „Modellgröße kleiner als VRAM“ unvollständig. Ein Dienst kann das Kontextlimit reduzieren, die Anzahl gleichzeitiger Sequenzen begrenzen oder einen Prozentsatz des VRAM ungenutzt lassen, um Laufzeitzuweisungen zu schützen. Diese Maßnahmen verhindern mehr Fehler als ein reaktiver Wechsel zur CPU, weil sie den GPU-Prozess in einem bekannten Zustand halten und eine vorhersehbare Latenz für angenommene Anfragen bewahren.

Automatische Wiederholungen sind nur bei wiederholbaren Anfragen sicher

Nach einem OOM-Fehler kann der Router den GPU-Worker als fehlerhaft markieren, ihn freigeben oder neu starten und die ursprüngliche Anfrage auf einem CPU-Worker wiederholen. Das funktioniert bei gewöhnlicher Textgenerierung, solange keine externe Nebenwirkung stattgefunden hat. Bei Streaming-Antworten, Bildpipelines mit zufälligen Seeds oder Agenten, die möglicherweise bereits ein Tool aufgerufen haben, ist es schwieriger.

Frameworks können große Modelle außerdem von Anfang an auf mehrere Geräte verteilen. Die Big-Model-Inferenz von Accelerate unterstützt Gerätezuordnungen sowie die Platzierung auf CPU oder Datenträger, wenn ein Modell ein einzelnes Gerät überschreitet. Dieser Ansatz kann eine Anfrage innerhalb eines geplanten Ausführungsgraphen am Leben halten, tauscht jedoch Geschwindigkeit gegen Kapazität und sollte nicht mit dem Weiterleiten einer fehlgeschlagenen Anfrage an einen separaten Dienst verwechselt werden.

Die Failover-Zusage gilt nicht mehr, wenn der CPU nicht genügend RAM zur Verfügung steht, die Laufzeitumgebung keine kompatiblen CPU-Kernels besitzt, die Anfrage bereits eine irreversible Aktion ausgelöst hat oder die erwartete CPU-Latenz das Client-Timeout überschreitet. In diesen Fällen sollte ein kontrollierter Kapazitätsfehler zurückgegeben oder die Anfrage in eine Warteschlange gestellt werden. Stille Wiederholungen können Nebenwirkungen duplizieren oder Nutzer deutlich länger warten lassen, als die Oberfläche verspricht.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Failover mit einem gezielten Speichertest nachweisen

Betreiben Sie einen GPU-Worker und einen CPU-Worker hinter einem Router und senden Sie anschließend eine Anfrage, die das GPU-Profil überschreitet, ohne den System-RAM zu überlasten. Erfassen Sie den ersten Fehler, die Entscheidung zur Wiederholung, den Startzeitpunkt auf der CPU, die endgültige Ausgabe und ob die Client-Verbindung bestehen bleibt. Wiederholen Sie den Test zunächst mit deaktiviertem Streaming und testen Sie anschließend Abbruch, parallelen Datenverkehr und eine Agentenanfrage mit einem simulierten Tool.

Die teilweise GPU-Ausführung ist ein nützlicher Ausgangspunkt, da Laufzeitumgebungen wie llama.cpp-Inferenz einen konfigurierbaren Anteil der Modellverarbeitung auf Beschleuniger verlagern können, während die CPU-Ausführung erhalten bleibt. Vergleichen Sie Profile mit GPU-residentem Modell, geplanter CPU/GPU-Aufteilung und unabhängigem CPU-Fallback. Ein hybrides KI-Workload-Modell hilft dabei, Kapazitäts-Fallback von routinemäßiger Cloud-Weiterleitung zu unterscheiden.

Bezeichnen Sie das Design nur dann als zuverlässig, wenn die Wiederholung genau einmal abgeschlossen wird, die Identität der Anfrage erhalten bleibt, doppelte Tool-Aktionen vermieden werden und der GPU-Worker wiederhergestellt wird, ohne andere Aufträge zu verlieren. Wenn der Abschluss auf der CPU zu langsam ist, verwenden Sie ihn als sichernden Pfad zum Erhalt der Warteschlange und nicht als interaktives Äquivalent. Das operative Ziel ist eine kontrollierte Degradierung, nicht der Anschein, CPU- und GPU-Dienste hätten dasselbe Leistungsniveau.

FAQs

Erzeugt das Leeren des GPU-Caches ein Failover?

Nein. Das Freigeben des Caches kann ungenutzte reservierte Blöcke verfügbar machen, erzeugt jedoch keine CPU-Ausführung, repariert keinen beschädigten Anfragezustand und garantiert nicht genügend zusammenhängenden Speicher für die nächste Zuweisung.

Liefert das CPU-Fallback dieselbe Antwort?

Das ist möglich, wenn dieselben Gewichte, dieselbe Präzision, derselbe Prompt, derselbe Tokenizer und derselbe Sampling-Zustand verwendet werden. Unterschiedliche Kernels, Quantisierung, Seeds oder ein neu gestarteter Streaming-Zustand können dennoch die exakte Ausgabe verändern.

Ist ein kleineres Modell besser als CPU-Failover?

Für interaktive Dienste oft. Ein kleineres GPU-Modell kann eine vorhersehbare Latenz liefern, während CPU-Failover die Verfügbarkeit bei außergewöhnlichen Anfragen schützt. Die beiden Mechanismen verfolgen unterschiedliche Dienstziele und können kombiniert werden.