Kann eine 4-GB-GPU wirklich große Sprachmodelle ausführen? AirLLMs Speicherbedarf, Inferenzgeschwindigkeit und Cloud-GPU-Kosten im Vergleich

Wer nur 4 GB GPU-Speicher hat, kann AirLLM als Versuch für große Modelle prüfen; ein erfolgreicher Start bedeutet jedoch nicht, dass die Ausgabe schnell oder für längere Aufgaben stabil genug ist. Der Artikel trennt GPU-Speicher, Arbeitsspeicher und Speicherplatz, erläutert die Geschwindigkeitsfaktoren und bietet Tabellen für den Kosten- und Szenarienvergleich.

Eignung: Geeignet für Experimente, nicht automatisch für den Alltag. Das AirLLM-Projekt nennt die Ausführung eines 70B-Modells auf einer einzelnen GPU mit 4 GB Speicher als möglichen Anwendungsfall; das ist eine Projektangabe, kein Versprechen für flüssige Ausgabe oder jede Hardware. AirLLM kann den VRAM-Bedarf durch schichtweises Laden senken. Ob sich das lohnt, hängt zusätzlich vom Arbeitsspeicher, freiem Speicherplatz, Modell und tatsächlichen Arbeitsablauf ab (Projektbeschreibung und README).

Wer nur 4 GB GPU-Speicher hat, sollte daher nicht allein fragen, ob sich ein Modell starten lässt. Entscheidend ist, ob die Ausgabe für die eigene Aufgabe schnell genug ist und ob die übrigen Ressourcen reichen. Für einzelne Tests kann AirLLM einen Versuch wert sein. Bei regelmäßigem Generieren oder längeren Eingaben sollte die lokale Laufzeit gegen die tatsächlichen Cloud-GPU-Kosten gerechnet werden.

Dieser Beitrag richtet sich an Nutzer mit einer GPU mit wenig Speicher, die ein lokales Sprachmodell ausprobieren möchten. Er hilft Entwicklerinnen und Entwicklern, AirLLMs Speicherbedarf und Geschwindigkeit realistisch einzuschätzen. Auch kleine Teams finden hier ein Kostenraster für den Vergleich mit einer Cloud-GPU.

Kann eine GPU mit 4 GB VRAM wirklich große Sprachmodelle ausführen?

Ja, unter Bedingungen. AirLLM beschreibt einen Weg, bei dem Modellschichten nacheinander geladen werden, statt alle Gewichte gleichzeitig im GPU-Speicher zu halten. Damit kann die GPU-Speicherhürde sinken. Die Rechenarbeit verschwindet dadurch aber nicht: Das System muss Modellgewichte weiterhin von einem Speichermedium bereitstellen und die einzelnen Schritte nacheinander berechnen. Die Projektangabe zu einem 70B-Modell auf einer GPU mit 4 GB ist deshalb als Machbarkeitsbeispiel zu lesen, nicht als allgemeine Zusage für eine brauchbare Geschwindigkeit.

Für die Entscheidung sind drei Begriffe auseinanderzuhalten:

• VRAM ist der Speicher der GPU. Er wird unter anderem von Modellteilen, temporären Rechendaten und weiteren CUDA-Prozessen genutzt. PyTorch weist darauf hin, dass reservierter und tatsächlich belegter CUDA-Speicher nicht dasselbe sind (PyTorch-Dokumentation zur CUDA-Speicherverwaltung).
• Arbeitsspeicher hält Daten bereit, die das Betriebssystem und der Laufzeitprozess benötigen. Eine knappe GPU-Ausstattung wird nicht automatisch durch beliebig wenig Arbeitsspeicher ausgeglichen.
• Speicherplatz wird für Modelldateien, heruntergeladene Kopien und gegebenenfalls Cache-Daten benötigt. Der genaue Umfang hängt vom konkreten Modell und seiner Ablage ab; eine allgemeingültige Mindestgröße lässt sich aus dem AirLLM-Projekt nicht ableiten.

Ein einfaches Rechenbeispiel zeigt, warum die Modellgröße wichtig bleibt: Bei einem Modell mit 70 Milliarden Parametern ergeben sich mit zwei Byte je Parameter für eine hypothetische Darstellung in FP16 rund 140 GB reine Gewichte. Das ist eine theoretische Größenordnung aus Parameterzahl und Datentyp, keine Angabe zum tatsächlich belegten Speicher eines konkreten Downloads. Zusätzlicher Laufzeitbedarf, Zwischenergebnisse und ein anderer Datentyp verändern den Bedarf. AirLLMs schichtweises Laden soll gerade vermeiden, dass sämtliche Gewichte gleichzeitig im VRAM liegen. Es macht aus diesen Gewichten aber weder kleinere Dateien noch weniger Rechenarbeit (README von AirLLM, NVIDIA CUDA Programming Guide).

Daraus folgt eine wichtige Grenze: Ein erfolgreicher Start belegt nur, dass der gewählte Lauf auf der aktuellen Umgebung initialisiert werden kann. Er belegt weder stabile Generierung bei einer langen Eingabe noch eine für interaktive Nutzung akzeptable Antwortzeit. Modellkompatibilität, Bibliotheksversionen und vorhandene Systemressourcen müssen separat geprüft werden. Die dokumentierten Projektvoraussetzungen und Abhängigkeiten sind ein sinnvoller Ausgangspunkt, ersetzen aber keinen Test mit genau dem gewünschten Modell (AirLLM-Abhängigkeiten).

Was verlangt AirLLM außer GPU-Speicher?

AirLLM senkt die VRAM-Schwelle vor allem durch die Art, wie Schichten bereitgestellt werden. Für die Planung ist deshalb nicht nur wichtig, wie viel Speicher die Grafikkarte hat, sondern auch, ob der Rechner Modellteile und Laufzeitdaten nebenbei handhaben kann. Eine offiziell ausgewiesene, für alle Modelle geltende Mindestmenge an Arbeitsspeicher oder freiem Speicherplatz sollte nicht unterstellt werden, wenn sie für die konkrete Kombination aus Modell, Bibliotheksversion und Betriebssystem nicht dokumentiert ist.

Wie viel Arbeitsspeicher und Speicherplatz sollten Sie einplanen?

Eine belastbare Antwort beginnt mit dem konkreten Modellpaket. Prüfen Sie dessen tatsächliche Dateigröße und die vom Projekt beschriebenen Ladeanforderungen. Rechnen Sie außerdem mit Platz für heruntergeladene Dateien und mögliche Cache-Kopien. Die Hugging-Face-Dokumentation erklärt, wie heruntergeladene Dateien im lokalen Cache verwaltet werden; ein Cache kann daher zusätzlichen Plattenplatz belegen und sollte in der Speicherplanung berücksichtigt werden (Dokumentation zum Modell-Cache).

Für den Arbeitsspeicher gilt: Ein Rechner kann trotz freiem GPU-Speicher an einer anderen Stelle zum Engpass werden. Betriebssystem, Python-Prozess, Bibliotheken und Daten, die während des Modelllaufs bereitgestellt werden, konkurrieren um Ressourcen. Wenn das System auslagert oder Prozesse beendet, ist „Modell geladen“ keine brauchbare Betriebszusage. Notieren Sie daher während eines realen Probelaufs sowohl GPU- als auch Arbeitsspeicherbelegung. Ein einzelner Start ohne längere Generierung reicht nicht.

Auch der Modell-Cache verdient Aufmerksamkeit. Wenn der verfügbare Speicherplatz knapp ist, können Downloads oder zwischengespeicherte Kopien den Lauf bereits vor der Inferenz verhindern. Prüfen Sie den Speicherort und die vorhandenen Dateien, bevor Sie mehrere Varianten desselben Modells laden. In Entwicklungsumgebungen mit gemeinsam genutztem Speicher sollten Sie zudem klären, wer den Cache verwaltet und ob Modellartefakte nach einem Neustart erhalten bleiben.

Hinweis aus der Praxis: Führen Sie den ersten Versuch mit dem exakten Modell und einer realistischen Eingabe durch. Ein kurzer Testprompt sagt wenig darüber aus, ob Speicherbelegung und Laufzeit bei Ihrem eigentlichen Kontext stabil bleiben.

Welche Grenzen entstehen durch die Schichten?

Schichtweises Laden tauscht geringere gleichzeitige GPU-Belegung gegen zusätzlichen Datentransfer und eine stärker sequenzielle Ausführung. Je nachdem, wo Gewichte liegen und wie schnell sie bereitgestellt werden, kann das die Laufzeit deutlich beeinflussen. Dazu kommt der Modellumfang: Ein größeres Modell bedeutet nicht nur mehr zu verwaltende Gewichte, sondern im Allgemeinen auch mehr Rechenarbeit pro Generierungsschritt. Der genaue Effekt hängt vom Modell und der Implementierung ab; ohne reproduzierbare Messung sollte daraus keine feste Tokenrate abgeleitet werden.

Auch die Eingabelänge spielt eine Rolle. Längere Kontexte können zusätzliche Speicher- und Rechenanforderungen verursachen. Die tatsächliche Auswirkung hängt vom Modell, der Implementierung und den Laufzeiteinstellungen ab. Deshalb ist die Aussage „läuft mit 4 GB“ ohne Angabe von Modell, Eingabelänge und Hardware nur eingeschränkt nützlich.

AirLLM verändert die Inferenzgeschwindigkeit durch schichtweises Laden

Die Inferenzgeschwindigkeit ist nicht eine einzelne Kennzahl. Für eine interaktive Anwendung zählen vor allem die Wartezeit bis zum ersten Token und die anschließende Ausgabegeschwindigkeit. Für einen Batch-Lauf zählt dagegen, wie lange die gesamte Aufgabe dauert. Ein System kann eine Antwort beginnen, aber so langsam weitergenerieren, dass es für den vorgesehenen Workflow unpraktisch bleibt.

Bei AirLLM sollten Sie besonders auf das Verhältnis zwischen GPU-Speicherersparnis und zusätzlichem Laden achten. Werden Modellteile schrittweise bereitgestellt, hängt die Geschwindigkeit unter anderem von der Speicherbandbreite, dem Speicherort der Gewichte, der GPU und der Implementierung ab. Auch die übrigen Prozesse auf dem Rechner können das Ergebnis verändern. Die offizielle README beschreibt das Funktionsprinzip, liefert aber keine universell übertragbare Leistungszusage für jede 4-GB-GPU.

Für einen fairen Vergleich müssen Sie die Bedingungen konstant halten:

• Dasselbe Modell und dieselbe Modellversion verwenden.
• Datentyp beziehungsweise Quantisierung nicht zwischen den Läufen ändern.
• Dieselbe Eingabe und Kontextlänge verwenden.
• Hardware, Treiber, Bibliotheken und Laufzeiteinstellungen dokumentieren.
• Start- beziehungsweise Ladezeit getrennt von der Generierungszeit erfassen.
• Mehr als einen Lauf betrachten und auffällige Hintergrundlast notieren.

Vergleichen Sie AirLLM nicht mit einer Cloud-GPU anhand einer einzelnen kurzen Antwort, wenn Ihre reale Aufgabe längere Dokumente oder wiederholte Generierung umfasst. Umgekehrt ist ein langer lokaler Lauf ohne Berücksichtigung der bereits vorhandenen Hardwarekosten nicht automatisch wirtschaftlicher. Für reproduzierbare Ergebnisse braucht es einen kleinen Test, der genau Ihren Arbeitsablauf abbildet.

Lokaler Lauf oder Cloud-GPU: Was kostet die Nutzung tatsächlich?

Eine Cloud-GPU ist nicht allein nach dem angezeigten Stundensatz zu bewerten. Relevant sind die abrechenbare Laufzeit, Leerlaufzeiten, Speicher- und Netzwerkposten sowie die Zeit, die für Einrichtung und Wiederholung anfällt. Die offiziellen Preise und Regeln können sich je nach GPU-Typ und Abrechnungsoption unterscheiden. Prüfen Sie daher vor dem Start die aktuelle Preisseite und rechnen Sie mit dem konkret ausgewählten Angebot, statt einen nicht belegten Fixpreis anzunehmen (offizielle Cloud-GPU-Preise).

Bei lokaler Ausführung unterscheiden wir zwischen Grenzkosten und Gesamtkosten. Wenn ein geeigneter Rechner bereits vorhanden ist, fallen für einen zusätzlichen Versuch nicht zwingend neue Anschaffungskosten an. Stromverbrauch, gebundene Arbeitszeit und mögliche Aufrüstungen bleiben trotzdem Teil der Entscheidung. Wird ein Gerät eigens für diese Aufgabe gekauft, müssen Anschaffung und Nutzung über den geplanten Zeitraum bewertet werden. Ein Vergleich allein zwischen Cloud-Stundensatz und Kaufpreis ist nicht ausreichend.

Für die Cloud gilt: Multiplizieren Sie den tatsächlichen Abrechnungssatz der gewählten Instanz mit der berechneten Laufzeit. Addieren Sie separat weitere Speicher- oder Netzwerkgebühren, sofern sie für das Angebot anfallen. Beziehen Sie Leerlauf ein, etwa wenn eine Instanz während Entwicklung oder Fehlersuche weiterläuft. Der Gesamtbetrag hängt damit nicht nur von der Rechenzeit ab, sondern auch davon, wie diszipliniert die Instanz nach dem Lauf beendet wird.

Die folgende Tabelle ordnet die Optionen nach Entscheidungskriterien ein. Die Bewertungen sind qualitative Einschätzungen, keine gemessenen Benchmarkwerte.

So rechnen Sie die Kosten für unterschiedliche Nutzungshäufigkeiten

Bei gelegentlichen Versuchen kann die bereits vorhandene Hardware die günstigste Wahl sein, selbst wenn der Lauf langsam ist: Es entsteht keine neue Anschaffung, sofern die Wartezeit akzeptabel bleibt. Wer dagegen wiederholt auf Ergebnisse wartet oder eine Instanz für kurze Aufgaben lange eingeschaltet lässt, sollte die reale Cloud-Abrechnung mit einer lokalen Messung vergleichen. Bei regelmäßiger, planbarer Nutzung kann eine eigene Ausstattung wirtschaftlich werden; das lässt sich aber erst mit Anschaffungskosten und tatsächlicher Auslastung seriös beurteilen.

Für eine nachvollziehbare Rechnung brauchen Sie nur wenige Eingaben: die gemessene Laufzeit Ihres Zielauftrags, die Häufigkeit der Aufträge, die tatsächlich gewählte Cloud-Instanz und deren aktuelle Abrechnungsregeln. Ergänzen Sie lokale Strom- oder Anschaffungskosten nur mit Werten, die für Ihre Umgebung bekannt sind. Rechnen Sie außerdem die Leerlaufzeit ein, wenn die Instanz nicht sofort beendet wird. Ohne diese Angaben gibt es keine belastbare allgemeine Aussage dazu, welche Variante günstiger ist.

Bei vertraulichen Eingaben ist außerdem zu prüfen, wo Daten verarbeitet und gespeichert werden und welche Löschmöglichkeiten bestehen. Bei einer Cloud-Instanz sollten Sie die Vertrags- und Datenschutzbedingungen zur Verarbeitung im Rechenzentrum lesen; bei lokalen Modellen bleiben Betriebssystem, Cache und Zugriffsrechte relevant. Die Datenschutzhinweise von ZekVPS beschreiben den Umgang mit Daten im jeweiligen Dienstkontext. Daraus folgt keine pauschale DSGVO-Bewertung einer beliebigen Cloud-GPU; maßgeblich sind stets der konkrete Anbieter und die konkrete Konfiguration.

Wann reicht AirLLM mit 4 GB für den eigenen Anwendungsfall?

AirLLM mit 4 GB ist eher vertretbar, wenn Sie die Machbarkeit prüfen, längere Wartezeiten akzeptieren und die konkrete Modellkombination kontrollieren können. Für interaktive Nutzung, viele wiederholte Anfragen oder lange Kontexte sollte die Entscheidung erst nach einem Test mit realistischen Eingaben fallen. „Kann starten“ und „ist im Alltag brauchbar“ sind zwei verschiedene Ergebnisse.

Entscheidung nach Ziel und Wartezeit

Gehen Sie schrittweise vor:

1. Zielmodell festlegen. Notieren Sie Modellname, Version, Datentyp und Quelle. Prüfen Sie, ob AirLLM die konkrete Kombination dokumentiert oder ob ein Test erforderlich ist.
2. Dateien und Cache prüfen. Ermitteln Sie die tatsächliche Größe des Modellpakets und kontrollieren Sie, wo Downloads und Cache abgelegt werden. Planen Sie freien Speicher für die benötigten Dateien ein, statt eine pauschale Mindestgröße anzunehmen.
3. Systemressourcen beobachten. Erfassen Sie während des Laufs GPU-Speicher, Arbeitsspeicher und Plattenplatz. Achten Sie auf Auslagerung, Abbrüche oder andere Prozesse, die das Ergebnis verfälschen können.
4. Eine realistische Aufgabe ausführen. Verwenden Sie den Kontext und die Eingabe, die später tatsächlich vorkommen. Erfassen Sie Ladezeit, Zeit bis zum ersten Token und Dauer bis zum vollständigen Ergebnis getrennt.
5. Wiederholen und vergleichen. Führen Sie den Test unter ähnlichen Bedingungen erneut aus. Vergleichen Sie erst danach mit einer Cloud-GPU und deren aktueller Abrechnung.
6. Monatskosten berechnen. Nutzen Sie die erwartete Auftragszahl und gemessene Laufzeiten. Berücksichtigen Sie Leerlauf und mögliche Zusatzkosten der Cloud sowie lokale Energie- oder Anschaffungskosten.

Wenn ein einzelner kurzer Prompt funktioniert, ist damit nicht bewiesen, dass ein längerer Kontext stabil läuft. Ebenso kann ein Modell zwar laden, aber beim Generieren durch knappen Arbeitsspeicher, langsamen Dateizugriff oder hohe Laufzeit unpraktisch werden. Halten Sie deshalb Ihre Testbedingungen schriftlich fest. So können Sie spätere Änderungen an Modell, Software oder Hardware von den ursprünglichen Ergebnissen unterscheiden.

Für AI-Agenten- oder App-Projekte ist außerdem wichtig, Entwicklungs- und Inferenzumgebung nicht gleichzusetzen. Eine Umgebung zum Bauen und Debuggen einer macOS-Anwendung ersetzt keine GPU-Inferenzumgebung. Wenn Ihr Vorhaben zusätzlich macOS-spezifische Entwicklung betrifft, können Sie die Einsatzgrenzen eines gemieteten Mac mini separat prüfen. Entscheidend bleibt, die jeweilige Rechenaufgabe der passenden Umgebung zuzuordnen.

Fazit: erst messen, dann mieten oder lokal bleiben

Eine GPU mit 4 GB kann mit AirLLM für bestimmte große Modelle als Einstieg dienen. Die Projektangabe zu 70B zeigt eine mögliche Speicherstrategie, nicht eine allgemeine Zusage zur Geschwindigkeit oder Stabilität. Prüfen Sie das konkrete Modell, den Arbeitsspeicher, den Speicherplatz und die erwartete Kontextlänge. Messen Sie anschließend Ladezeit und vollständige Generierung mit der Aufgabe, die tatsächlich ansteht.

Eine lokale 4-GB-Lösung kann langsam sein, zusätzliche Systemressourcen beanspruchen und bei längeren Aufgaben schwer vorhersehbare Wartezeiten verursachen. Eine Cloud-GPU bringt dagegen laufende Abrechnung, mögliche Leerlaufkosten und Fragen zu Datenübertragung und Speicherung mit sich. Wenn lokale Tests zu lange dauern oder Ihr Projekt wiederholt Rechenleistung benötigt, vergleichen Sie die gemessene Laufzeit mit den aktuellen Cloud-Konditionen. Wenn neben der Inferenz auch macOS-App-Entwicklung oder Debugging ansteht, prüfen Sie dafür eine passende Mac-Umgebung separat; ein gemieteter Mac ist dabei kein Ersatz für eine Cloud-GPU. Beginnen Sie mit einem kleinen Test unter realen Bedingungen und entscheiden Sie anhand der gemessenen Laufzeit und Gesamtkosten.