70B-Sprachmodell auf 4GB GPU: AirLLM-Anleitung

Ja, ein 70B LLM kann mit etwa 4GB GPU-Speicher mit AirLLM ausgeführt werden—aber das Modell passt nicht in eine 4GB-Grafikkarte. AirLLM speichert den Checkpoint auf der Festplatte, lädt eine Transformer-Schicht ins VRAM, berechnet diese Schicht, gibt sie frei und wiederholt den Prozess. Die Technik tauscht Speicher gegen Speicher-I/O und Latenz ein.^[1][2]

Diese Unterscheidung ist die ganze Geschichte. Ein 70B-Modell benötigt weiterhin etwa 130GB Gewichtsspeicher bei der im ursprünglichen Demonstrationsvideo verwendeten Genauigkeit. Die 4GB-Zahl beschreibt den Spitzenwert des VRAM während eines eng konfigurierten Inferenzlaufs, nicht den gesamten Maschinenspeicher, die Downloadgröße oder die interaktive Leistung.

TL;DR

• AirLLM ermöglicht extremes Offloading. Es speichert schichtweise Splitter auf der Festplatte und verschiebt nur die aktive Schicht auf die GPU.
• Das ursprüngliche Ergebnis wurde unter 4GB auf einer 16GB Nvidia T4 gemessen. Es zeigte nicht, dass ein schneller Chatbot vollständig von einer physischen 4GB-Karte läuft.^[1]
• Festplattenkapazität und -geschwindigkeit zählen weiterhin. Der erste Lauf lädt den Checkpoint herunter und unterteilt ihn neu, und jedes generierte Token streamt Gewichte wiederholt durch das Rechengerät.
• Kurzer Kontext ist Teil des Tricks. Das ursprüngliche Beispiel verwendete eine Eingabelänge von 100 Token; ein größerer KV-Cache und Laufzeitpuffer verbrauchen mehr Speicher.^[1]
• Erwarten Sie Forschungs- oder Batch-Geschwindigkeiten, keine reaktionsschnelle Chats. Der Autor von AirLLM positioniert Low-End-Hardware explizit für Offline-Arbeiten statt für interaktive Anwendungen.^[1]
• Verwende eine API, wenn Ausgabegeschwindigkeit wichtig ist. Extremes lokales Offloading ist nützlich zum Lernen und für gelegentliche private Jobs; gehostete Inferenz ist normalerweise der einfachere Produktionsweg.

Was „ein 70B LLM auf einer 4GB GPU ausführen" wirklich bedeutet

Vier verschiedene Ressourcen sind in eine Schlagzeile komprimiert. Ihre Unterscheidung verhindert die meisten schlechten Hardwareentscheidungen.

Die ursprüngliche 2023er Anleitung verwendete einen auf Llama 2 basierenden 70B-Checkpoint mit 80 Transformer-Schichten. Eine Schicht wurde auf etwa 1,6GB geschätzt, während der KV-Cache für sein 100-Token-Beispiel etwa 30MB betrug. Der gemessene Prozess blieb auf einer Nvidia T4 unter 4GB GPU-Speicher.^[1]

Das aktuelle AirLLM-Repository erweitert die gleiche Idee auf Llama 3.x, Qwen, DeepSeek, Mixtral, Phi, Gemma und andere Familien. Seine aktuelle Referenztabelle listet einen vollgenau Llama 3.x 70B-Lauf weiterhin auf etwa 4GB VRAM auf.^[2] Behandle das als Projektanspruch und Speicherziel—nicht als Durchsatzbenchmark für jede 4GB-Karte.

Wie AirLLM-schichtweise Inferenz funktioniert

Ein Transformer führt seine Blöcke nacheinander aus. Schicht 12 verbraucht den versteckten Zustand von Schicht 11; Schicht 13 wartet auf Schicht 12. AirLLM nutzt diese Ordnung mit einer fünfteiligen Pipeline.

1. Erstelle eine leere Modellhülle. Das Meta-Device von Hugging Face Accelerate initialisiert die Architektur, ohne echten Speicher für jeden Parameter zuzuweisen.^[3]
2. Unterteile den Checkpoint nach Schicht neu. Safetensors-Dateien werden so umgeordnet, dass das Laden einer Schicht nicht das Lesen eines nicht verwandten Multi-Gigabyte-Splitters erfordert.
3. Lade eine Schicht auf das Rechengerät. Nur diese Schicht und die erforderlichen Laufzeit-Tensoren belegen die GPU in diesem Moment.
4. Berechnen, freigeben und fortfahren. Der versteckte Zustand bewegt sich nach vorne, während die Schichtgewichte das VRAM verlassen.
5. Wiederhole für jeden generierten Token. Prefetching überlappt einige Speicher-I/O mit Berechnung, kann die wiederholte Datenbewegung aber nicht eliminieren.

FlashAttention reduziert den temporären Speicher, der von Attention durch gekachelte, I/O-bewusste Berechnung verwendet wird.^[4] Es hilft der aktiven Schicht, zu passen, während Schicht-Streaming das separate Problem löst, wo inaktive Gewichte warten.

Hardware und Speicher, den du weiterhin brauchst

Die GPU ist nur eine Komponente. Bevor du einen 70B-Checkpoint herunterlädst, überprüfe den Rest der Maschine.

• Ein kompatibler Rechenpfad. Die Schlagzeilendemonstrationen zielen auf Nvidia CUDA ab. AirLLM dokumentiert auch Apple-Silicon- und CPU-Pfade, aber deren Speicher- und Leistungsmerkmale sind unterschiedlich.^[2]
• Genug Speicherplatz für den Checkpoint und die Konvertierung. Das Projekt warnt, dass Schicht-Splitting beim ersten Lauf speicherintensiv ist. Seine delete_original-Option kann den ursprünglichen Checkpoint nach der Konvertierung entfernen, wenn der Speicher eng ist.
• Schneller lokaler Speicher. NVMe macht Schicht-Streaming nicht kostenlos, aber ein langsames Laufwerk macht eine bereits I/O-gebundene Schleife wesentlich schlimmer.
• Ein kurzer anfänglicher Kontext und Output. Starten mit einem winzigen Prompt und 20–40 neue Token. Ein längerer Kontext erhöht den KV-Cache, während ein längerer Output die volle Schicht-Traversierung mehrmals wiederholt.
• Modellzugriff. Eingeschlossene Meta-Checkpoints erfordern einen Hugging Face-Token und die Annahme der Modelllizenz.

Beginne nicht mit einem 70B-Download nur um zu testen, ob die Umgebung funktioniert. Führe zuerst ein 8B oder kleineres unterstütztes Modell aus, überprüfe CUDA und Speicherpfade, dann skaliere hoch.

Wie du AirLLM mit einem 70B-Modell versuchst

Der aktuelle Projekt-Quickstart verwendet AutoModel, das die passende Implementierung aus einer Hugging Face-Repository-ID wählt.^[2] Installiere zuerst einen PyTorch-Build, der mit deinem CUDA-Treiber kompatibel ist, dann installiere AirLLM.

python -m venv .venv
source .venv/bin/activate
pip install airllm

Halte Geheimnisse in Umgebungsvariablen statt im Quellcode:

export HF_TOKEN="your_hugging_face_token"

Dann führe eine absichtlich kleine Generierung aus:

import os

from airllm import AutoModel

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"
MAX_LENGTH = 128

model = AutoModel.from_pretrained(
    MODEL_ID,
    hf_token=os.environ["HF_TOKEN"],
    layer_shards_saving_path="/data/airllm-shards",
)

prompt = ["Explain layer-wise inference in three short sentences."]
tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)

result = model.generate(
    tokens["input_ids"].cuda(),
    max_new_tokens=32,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(result.sequences[0]))

Dies ist eine minimale Anpassung des Repository-Quickstarts, keine universelle Umgebungs-Sperrdatei. AirLLM, Transformers, PyTorch, CUDA und der Remote-Code eines Modells können versionsspezifische Einschränkungen haben, daher überprüfe die aktuellen Repository-Issues, bevor du es auf einer Produktionsmaschine installierst.

Was beim ersten Lauf passiert

Der erste Start ist nicht repräsentativ für spätere Starts. AirLLM muss das Modell herunterladen, seine Architektur überprüfen, den Checkpoint in Schicht-Splitter aufteilen und diese Splitter im konfigurierten Pfad schreiben. Das Unterbrechen dieser Konvertierung oder das Ausführen von Speicherplatz kann zu einem unvollständigen Safetensors-Header führen; die FAQ des Projekts empfiehlt, den unvollständigen Cache zu löschen und nach Speicherplatz erneut auszuführen. ^[2]

Überwache vier Signale separat:

nvidia-smi -l 1          # GPU-Speicher und Auslastung
free -h                  # Systemspeicher
df -h /data              # verfügbarer Speicherplatz
iostat -xz 1             # Speichersättigung, falls sysstat installiert ist

Eine niedrige VRAM-Zahl ist nicht allein ein Erfolg. Notiere Zeit bis zum ersten Token, Sekunden pro Output-Token, Datenträger-Lesevolumen und ob wiederholte Läufe abgeschlossene Splitter wiederverwenden.

Warum AirLLM langsam ist, selbst wenn es passt

Normales GPU-Inferencing lädt Gewichte einmal und verwendet sie für viele Token und Anfragen wieder. Extremes Schicht-Offloading kehrt diese Vorteil um. Jeder neue Token muss den vollständigen Stack des Modells durchlaufen, während Gewichte in kleinen Teilen vom Speicher zur GPU fließen.

AirLLM hat Prefetching hinzugefügt, um das Laden mit der Berechnung zu überlappen und bietet 4-Bit- oder 8-Bit-blockweise Gewichtskomprimierung, um Speicherkehr zu reduzieren. Das Repository meldet bis zu dreifache Verbesserung durch Komprimierung, aber die tatsächliche Leistung hängt vom Modell, Speicher, GPU, Kontext und Softwareversionen ab.^[2]

Dies macht die Methode für Folgendes glaubwürdiger:

• einmalige Bewertung eines Modells, das sonst nicht geladen werden kann;
• Offline-Dokumentklassifizierung oder -extraktion;
• Batch-Verarbeitung mit niedrigem Volumen, wo Latenz sekundär ist;
• Studium von Speicherplanung und Modellarchitektur.

Es ist eine schlechte Standardoption für Live-Chat, Agentenschleifen, hohe Nebenläufigkeit oder eine API mit einem Latenzziels.

AirLLM vs. Quantisierung vs. API

Wähle AirLLM, wenn das Experiment der Punkt ist. Wähle ein kleineres quantisiertes Modell, wenn lokale Interaktivität der Punkt ist. Wähle eine API, wenn das 70B-Modell und die nutzbare Antwortzeit beide Anforderungen sind.

Die gleiche Unterscheidung gilt für viel größere Ansprüche. Unsere Kimi K3 auf einer 4GB-GPU-Analyse erklärt, warum dünne Experten die Streaming-Einheit ändern, aber den Checkpoint nicht auslöschen. Für ein aktuelles Long-Context-API-Beispiel siehe den MiniMax M3 API-Leitfaden oder durchsuche den Live-Modellkatalog.

Eine praktische Entscheidungs-Checkliste

Bevor du ein 70B LLM auf einer 4GB GPU versuchst, beantworte diese Fragen:

1. Ist das Ziel, Ausführung zu beweisen, oder ein responsives Produkt zu bauen?
2. Kann die Festplatte das ursprüngliche Modell und seine schichtweise aufgeteilt Kopie während der Konvertierung halten?
3. Wird die Checkpoint-Architektur explizit durch die aktuelle AirLLM-Version unterstützt?
4. Kann die Arbeitslast lange Zeit-bis-zum-ersten-Token und niedrigen Durchsatz tolerieren?
5. Erlaubt die Modelllizenz die beabsichtigte Verwendung?
6. Hast du dieselbe Software-Stack mit einem kleinen Checkpoint zuerst getestet?

Wenn die Antwort auf Fragen zwei bis vier nein ist, ist die 4GB-Schlagzeile kein nützlicher Bereitstellungsplan.

FAQ

Kann ein 70B LLM wirklich auf einer 4GB GPU laufen?

Ja, durch extremes Schicht-Streaming. Nur ein kleiner Teil des Modells befindet sich gleichzeitig im VRAM; der vollständige Checkpoint bleibt auf der Festplatte. Das ist nicht das gleiche wie ein 70B-Modell in 4GB laden.

Hat der ursprüngliche AirLLM-Test eine echte 4GB-Grafikkarte verwendet?

Der 2023-Artikel sagt, dass das Team auf einer 16GB Nvidia T4 testete und weniger als 4GB GPU-Speichernutzung gemessen hat.^[1] Das aktuelle Repository listet Llama 3.x 70B separat auf etwa 4GB VRAM auf.

Wie viel Speicherplatz benötigt ein 70B-Modell?

Das hängt von der Checkpoint-Präzision und dem Format ab. Der ursprüngliche Durchgang beschrieb grob 130GB Parameter, und Schicht-Konvertierung kann vorübergehend sowohl die ursprünglichen als auch die konvertierten Kopien erfordern. Überprüfe die Repository-Dateien, bevor du herunterlädst und lasse Platz für unterbrochene oder teilweise Konvertierungen.

Ist AirLLM schnell genug für einen Chatbot?

Normalerweise nicht auf Low-End-Hardware. Der ursprüngliche Autor warnt, dass ein T4-Setup langsam ist und besser für Offline-Arbeiten geeignet ist.^[1]

Trainiert AirLLM ein 70B-Modell in 4GB?

Nein. Das Training muss Aktivierungen und Gradienten für Backpropagation beibehalten oder neu berechnen. AirLLMs schichtweise Technik befasst sich mit Inferenza, nicht mit vollem Training.^[1]

Ist ein 4-Bit 70B-Modell klein genug für 4GB VRAM?

Nein. Siebzig Milliarden Parameter bei vier Bits benötigen theoretisch 35GB nur für rohe Gewichte, vor Quantisierungs-Metadaten und Laufzeitspeicher. Quantisierung hilft, schließt aber diese Lücke nicht.

Das ehrliche Urteil über 70B-Inferenz mit 4GB VRAM

AirLLM verwandelt eine harte Speicherdecke in ein Planungsproblem. Das ist ein echtes technisches Ergebnis: ein 70B LLM kann mit etwa 4GB VRAM ausgeführt werden, wenn die Laufzeit Schicht-Splitter von viel größerem Speicher streamt. Der Preis ist wiederholtes I/O, langsame Erzeugung, ein großer Checkpoint und ein zerbrechlicher Software-Stack.

Verwende es zum Studium extremen Inferencias oder zum Fertigstellen von Offline-Jobs mit niedrigem Volumen. Für eine interaktive Anwendung verwende ein kleineres lokales Modell oder rufe ein gehostetes Modell durch den reAPI-Schnellstart auf. Die nützliche Lektion ist nicht, dass 70B ein 4GB-Modell geworden ist. Es ist, dass VRAM nicht länger jedes Gewicht zur gleichen Zeit halten muss.

Referenzen

1. Gavin Li. Unbelievable! Run 70B LLM Inference on a Single 4GB GPU with This New Technique. November 30, 2023. huggingface.co/blog/lyogavin/airllm
2. AirLLM. AirLLM repository, current quickstart, supported models, configuration, and FAQ. Retrieved August 2, 2026. github.com/lyogavin/airllm
3. Hugging Face Accelerate. Big Model Inference and the meta device. huggingface.co/docs/accelerate/usage_guides/big_modeling
4. Dao et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022. arxiv.org/abs/2205.14135