AirLLM: Ein 70B auf einer GPU mit 4 GB – wirklich? Test und limites

#Das Versprechen von AirLLM: ein 70B-Modell mit 4 GB VRAM

Ein 70B-Modell in Q4-Quantisierung benötigt etwa 40 GB VRAM, um vollständig in den Speicher geladen zu werden – also eine RTX 4090 (24 GB) plus eine zweite Grafikkarte oder ein Mac Studio mit viel Unified Memory. AirLLM behauptet, dass dasselbe Modell auf eine Karte mit 4 GB passt, selbst auf eine einfache GTX 1650 oder eine kostenlose T4 von Google Colab. Das ist kein Marketingtrick bei der Modellgröße: Tatsächlich erzeugt das vollständige 70B-Modell die Antworten, in FP16 oder mit 4/8 Bit.

Das Geheimnis lässt sich in drei Worten zusammenfassen: Das Modell wird nie vollständig in den VRAM geladen. AirLLM zerlegt das Netzwerk in Schichten (Layers), speichert sie auf dem Datenträger und lädt während der Berechnung jeweils nur eine Schicht auf die GPU. Der VRAM enthält daher immer nur die Gewichte einer Schicht sowie die aktuellen Aktivierungen – deshalb werden nur wenige Gigabyte benötigt.

#Wie Layer-Streaming funktioniert

Ein LLM vom Typ Transformer ist ein Stapel von Schichten mit identischem Aufbau (Attention + Feed-Forward), die nacheinander durchlaufen werden. Ein Llama 70B hat 80 solcher Schichten. Die klassische Inferenz lädt alle 80 Schichten auf einmal in den VRAM und hält sie während der gesamten Generierung im Speicher. AirLLM kehrt dieses Prinzip um.

Aufteilung in Dateien auf dem Datenträger

Beim ersten Laden zerlegt AirLLM die Modellgewichte in separate Dateien, eine pro Schicht, die auf der SSD gespeichert werden. Dieser Konvertierungsschritt erfolgt nur einmal pro Modell.

Lazy Loading

Um ein Token zu generieren, lädt die Engine Schicht 1 auf die GPU, führt die Berechnung durch, gibt den VRAM frei, lädt Schicht 2, führt die Berechnung durch und so weiter bis zu Schicht 80.

Konstanter VRAM-Verbrauch

Zu jeder Zeit befindet sich nur eine Schicht im VRAM. Der maximale Speicherbedarf hängt von der größten Schicht und der Kontextlänge ab, nicht von der Gesamtgröße des Modells.

Prefetch und Quantisierung der Gewichte auf der Festplatte

AirLLM lädt die nächste Schicht vor, während die aktuelle Schicht berechnet wird, und kann die Gewichte auf dem Laufwerk komprimieren (blockweise Quantisierung), um die zu lesende Datenmenge zu reduzieren.

Der Engpass ist offensichtlich: Für jedes generierte Token müssen sämtliche Modellgewichte vom Datenträger gelesen werden. Bei einem 70B-Modell bedeutet das, dass für ein einziges Token mehrere Dutzend Gigabyte von der SSD zur GPU übertragen werden. Genau hier entscheidet sich die gesamte Leistungsfähigkeit von AirLLM – und hier liegen auch seine Grenzen.

#Voraussetzungen und Installation

AirLLM ist eine Python-Bibliothek, die auf PyTorch und dem Hugging-Face-Ökosystem aufbaut. Sie wird anders als Ollama verwendet (kein Daemon, kein run-Befehl): Man importiert sie in ein Python-Skript. Folgendes wird benötigt, bevor es losgeht.

GPU

Jede NVIDIA-Karte mit mindestens 4 GB VRAM (CUDA). Apple Silicon (MPS) und CPUs werden ebenfalls unterstützt, sind aber noch langsamer.

Festplatte

Eine schnelle NVMe-SSD ist unverzichtbar, ebenso wie genügend Speicherplatz für das dekomprimierte Modell (≈40 GB für ein 70B-Modell, mehr in FP16).

System-RAM

16 GB sind ausreichend; AirLLM lädt das Modell nicht in den RAM, im Gegensatz zu einem klassischen CPU-Offload.

Python

Eine Python-3.10+-Umgebung mit korrekt installiertem PyTorch und CUDA.

pip install airllm

#Starten eines 70B auf 4 GB: der Test

Der minimale Code zum Laden und Abfragen eines Llama 70B umfasst etwa fünfzehn Zeilen. AirLLM übernimmt beim ersten Aufruf die Aufteilung in Schichten (planen Sie mehrere Minuten für die Konvertierung sowie den Download des Modells von Hugging Face ein).

from airllm import AutoModel

# Le modèle est découpé en couches au premier chargement
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3.1-70B-Instruct")

input_text = ["Explique le layer streaming en une phrase."]
input_tokens = model.tokenizer(input_text,
                               return_tensors="pt",
                               truncation=True,
                               max_length=128,
                               padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=64,
    use_cache=True,
    return_dict_in_generate=True)

output = model.tokenizer.decode(generation_output.sequences[0])
print(output)

1. 01
   1. Erstes Laden

   AirLLM lädt das Modell herunter und wandelt es anschließend auf der SSD in Dateien für die einzelnen Schichten um. Dieser Schritt dauert lange, ist aber nur einmal nötig: Bei späteren Ausführungen wird der Cache auf dem Datenträger wiederverwendet.
2. 02
   2. Einstellung der Kompression

   Der Parameter compression='4bit' (oder '8bit') reduziert die vom Datenträger gelesene Datenmenge und beschleunigt dadurch die Inferenz, allerdings auf Kosten eines leichten Qualitätsverlusts – derselbe Kompromiss wie bei der klassischen Quantisierung.
3. 03
   3. Generierung

   Jedes Token löst das vollständige Einlesen aller 80 Schichten von der SSD aus. Der Fortschrittsbalken bewegt sich Schicht für Schicht weiter: Das wirkt langsam, und das ist normal.
4. 04
   4. Messung

   Messen Sie die Gesamtzeit und teilen Sie sie durch die Anzahl der generierten Tokens, um Ihren tatsächlichen Durchsatz in Tokens pro Sekunde zu erhalten. Dies ist die einzige Zahl, die entscheidend ist, um zu beurteilen, ob das Tool für Ihren Anwendungsfall geeignet ist.

#Echter Benchmark: wie viele Tokens pro Sekunde?

Hier trifft das Versprechen auf die physische Realität. Bei einem 70B-Modell, das von einer NVMe-SSD gestreamt wird, spricht man nicht von Tokens pro Sekunde, sondern oft von Sekunden pro Token. Die Größenordnung, die Sie sich anhand der gemeldeten Konfigurationen und unserer Tests merken sollten:

70B / schnelles NVMe-Laufwerk mit PCIe 4.0

in der Größenordnung von 0,1 bis 0,5 Token pro Sekunde, also etwa 2 bis 10 Sekunden, um ein einzelnes Wort zu erzeugen. Eine Antwort mit 200 Token dauert mehrere Minuten.

70B / SATA-SSD

Noch 2- bis 5-mal langsamer: Die Bandbreite des Laufwerks ist auf etwa 500 MB/s begrenzt, der Durchsatz fällt unter 0,1 Token/s.

Vergleich: 70B-Modell im VRAM geladen (2x RTX 4090)

15 bis 30 Tokens pro Sekunde. Der Unterschied zu AirLLM beträgt einen Faktor von 30 bis 300 je nach Speichermedium.

8B-Modell in Q4 auf einer einzigen RTX 3060 mit 12 GB

40 bis 80 Tokens pro Sekunde, ganz ohne Streaming – um das Ausmaß des verlorenen Komforts zu verdeutlichen.

Die Formel ist einfach: Für jedes Token muss das gesamte Modell erneut vom Datenträger gelesen werden. Ein 70B-Modell in 4 Bit benötigt etwa 40 GB; bei einer NVMe-Lesegeschwindigkeit von 5 GB/s sind das bereits 8 Sekunden reine Ein-/Ausgabe pro Token, noch bevor die Berechnung beginnt. Keine Softwareoptimierung kann diese Hürde umgehen, solange die Gewichte auf dem Datenträger liegen. Selbst im besten Fall (kleine Modelle, sehr schneller Datenträger, aggressive Kompression) bedeutet das eine Verlangsamung um den Faktor 5 bis 30, bei großen Modellen noch deutlich mehr.

#Realistisch eingeschätzte Anwendungsfälle

Bei 0,2 Token pro Sekunde ist AirLLM zum Chatten unbrauchbar. Es gibt aber tatsächlich Szenarien, in denen die geringe Geschwindigkeit kein Problem darstellt, weil niemand vor dem Bildschirm wartet.

Batchverarbeitung (offline)

Ein Skript, das über Nacht 500 Dokumente durch ein 70B-Modell laufen lässt, kümmert sich nicht darum, wenn ein Dokument 3 Minuten dauert: Das Ergebnis liegt am Morgen vor. Dies ist der legitimste Anwendungsfall.

Punktuelle Experimente

Überprüfen, was ein bestimmtes 70B-Modell auf einige Prompts antwortet, ohne eine Cloud-GPU zu mieten oder Hardware zu kaufen, um zu entscheiden, ob sich die Investition lohnt.

Nicht dringende strukturierte Extraktion

Einen Datensatz generieren, ein Korpus annotieren, Embeddings oder Zusammenfassungen im Hintergrund erstellen, wobei der Durchsatz kaum eine Rolle spielt.

Zugriff auf ein riesiges Modell ohne Budget

Student, Forscher oder Interessierter mit nur einer kleinen Grafikkarte, der ein Modell nutzen möchte, das er sonst nicht laufen lassen könnte.

#Wenn es Marketing ist

Die Formulierung „ein 70B auf 4 GB“ ist technisch richtig, aber redaktionell irreführend, sobald damit ein normaler Einsatz suggeriert wird. Hier sind die Situationen, in denen AirLLM seine impliziten Versprechen nicht hält.

Interaktiver Chat

Mehrere Minuten auf eine Antwort warten zu müssen, bringt jedes Gespräch zum Erliegen. Für einen Chat ist ein lokales 8B- oder 14B-Modell, das sofort antwortet, unendlich nützlicher als ein 70B-Modell, das im Tempo eines Faxgeräts antwortet.

Code-Assistent in Echtzeit

Autovervollständigung und Pair-Programming erfordern Antworten innerhalb weniger Sekunden. Davon ist AirLLM Lichtjahre entfernt.

Multi-User-Server

Es ist nicht möglich, mehrere Personen zu bedienen: Jedes Token beansprucht bereits die gesamte Festplattenbandbreite für eine einzige Anfrage.

Produktivbetrieb

Kein Online-Dienst kann auf AirLLM basieren. Die Latenz und der Verschleiß der SSD (ständige umfangreiche Lesezugriffe) schließen das von vornherein aus.

#Alternativen: klassische Quantisierung zuerst

Schöpfen Sie vor dem Einsatz von Layer-Streaming alle Lösungen aus, bei denen das Modell im Speicher bleibt – sie sind fast immer vorzuziehen. Die Frage lautet nicht „Wie bringe ich ein 70B-Modell in 4 GB unter?“, sondern „Welches Modell erfüllt tatsächlich meinen Bedarf?“

Zu einer Quantisierung mit geringerer Bitbreite wechseln

Ein 70B in Q4_K_M passt auf ~40 GB, in Q2/Q3 auf viel weniger. Doch ein 70B, der zu aggressiv quantisiert ist, verliert an Qualität: Es ist oft besser, einen 32B in Q4 mit guter Qualität zu verwenden.

Ein kleineres und neueres Modell auswählen

Ein 32B-Modell (≈19 GB VRAM) oder ein 14B-Modell (≈9 GB) aus dem Jahr 2026 kann bei den meisten Aufgaben mit einem 70B-Modell aus dem Jahr 2024 mithalten und läuft dabei sofort auf einer einzigen Karte.

CPU/GPU-Offloading mit Ollama oder llama.cpp

Diese Engines laden einen Teil der Schichten in den Systemspeicher, wenn der VRAM nicht ausreicht. Das ist langsamer als ein vollständiges Laden auf der GPU, aber viel schneller als AirLLM, denn RAM ist hundertmal schneller als eine SSD.

Eine Cloud-GPU für einen gelegentlichen Bedarf mieten

Um ein echtes 70B-Modell einmalig schnell zu testen, kostet eine Stunde auf einer gemieteten GPU wenig und liefert einen normalen Durchsatz – oft wirtschaftlicher als stundenlanges Warten bei lokaler Ausführung.

#Weiterführende Informationen

AirLLM ist eine Behelfslösung: Bevor Sie darauf zurückgreifen, sollten Sie die üblichen Stellschrauben beim VRAM-Verbrauch und bei der Modellwahl beherrschen. Drei Leitfäden auf dieser Website ergänzen das Bild.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Verstehen, wie viel Qualität ein Modell in Q4 oder Q3 verliert und wie sich ein großes Modell in begrenztem VRAM unterbringen lässt, ohne auf Streaming vom Datenträger zurückzugreifen.

GPU für lokale KI auswählen

Die Abwägungen zwischen VRAM, Budget und Leistung, von der RTX 3060 mit 12 GB bis zum Mac Studio Ultra, um zu wissen, welche Modellgröße Ihre Hardware tatsächlich bewältigt.

llama.cpp vs. vLLM vs. Exllama

Inferenz-Engines und ihre Verwaltung des CPU/GPU-Offloadings: die ernstzunehmende Alternative zu AirLLM, wenn der VRAM nicht ganz ausreicht.