Sie haben eine Grafikkarte mit 4GB VRAM — vielleicht eine GTX 1650 oder einen Laptop-MX-Chip — und möchten Llama 3.1 70B selbst ausführen. Das klingt unmöglich: Standard-FP16-Inferenz braucht rund 140GB Grafikspeicher, also mindestens zwei A100. Das Open-Source-Projekt AirLLM nutzt Schicht-Inferenz (layer-wise inference), um den VRAM-Peak unter 4GB zu drücken: Gewichte liegen auf der SSD, die GPU lädt jeweils nur eine Transformer-Schicht, rechnet und entlädt wieder. Im August 2026 haben wir AirLLM v3.x erneut getestet — mit Installation, Geschwindigkeitszahlen und einer Einordnung, wann ein Cloud-Mac die sinnvollere Alternative ist.
Warum 4GB überhaupt an 70B herankommen
Der Engpass bei LLM-Inferenz ist nicht die Gesamtparameterzahl, sondern wie viele Schichten gleichzeitig auf der GPU liegen müssen. Llama 3.1 70B hat etwa 80 Transformer-Schichten; jede Schicht wiegt in FP16 rund 1,7GB. Das volle Modell braucht ~140GB VRAM. Nur eine Schicht gleichzeitig zu laden senkt den Peak auf eine Schicht plus Aktivierungspuffer — praktisch etwa 3,5–4,2GB.
AirLLM, von Gavin Li unter Apache 2.0 gepflegt, unterstützt Llama 3.x, Qwen3, Mistral, DeepSeek-V3 und mehr. MoE-Modelle wie Kimi K3 können auf Expert-Ebene gestreamt werden; laut Dokumentation läuft das schon ab 3,72GB VRAM. Wenn API-Kosten neben lokalen Experimenten eine Rolle spielen, lesen Sie unseren Kimi-K3- vs. GPT-5.5-API-Kostenvergleich — lokale Validierung und Cloud-Inferenz ergänzen sich oft.
Schicht-Inferenz und Prefetching
Klassische Inferenz: volles Modell in den VRAM → Forward Pass → Ausgabe. AirLLM arbeitet anders:
- Erster Lauf — Checkpoint von HuggingFace herunterladen und in 80+ Layer-Shard-Dateien im lokalen Cache aufteilen
- Schichtweise Berechnung — Layer N per Memory-Mapping auf die GPU laden, ausführen, Aktivierungen zurück in CPU oder Unified Memory schreiben, VRAM freigeben
- Prefetch-Überlappung — mit
prefetching=Truelädt ein Hintergrundthread Layer N+1, während die GPU Layer N rechnet; I/O und Compute überlappen teilweise - Optionale Quantisierung —
compression='4bit'nutzt Block-Quantisierung; laut Projekt etwa dreifach schnellere Inferenz bei minimalem Genauigkeitsverlust
Installation und Konfiguration
Die Schritte unten gelten für Ubuntu 22.04 + CUDA 12.x + Python 3.10. Auf macOS mit Apple Silicon zuerst das MLX-Backend installieren; der Ablauf ist ähnlich.
# 1. Abhängigkeiten installieren (CUDA-Umgebung) pip install airllm torch --upgrade # 2. Optional: 4-Bit-Kompression + Prefetch + eigener Cache-Pfad from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-3.1-70B-Instruct", compression='4bit', layer_shards_saving_path="/data/airllm-cache", prefetching=True, delete_original=True, # Original-Checkpoint nach Shard-Split entfernen ) # 3. Generieren (erster Lauf: Download + Split, 30–60 Min.) output = model.generate("Erkläre Schicht-Inferenz in drei Sätzen.", max_new_tokens=128) print(output)
Benchmarks: Geschwindigkeit und Ressourcen
Wir haben Llama 3.1 70B Instruct (4-Bit-Kompression) auf einer GTX 1650 (4GB) mit 2TB-NVMe erneut getestet. Erster Shard-Split: etwa 47 Minuten; danach bei der Inferenz:
| Kennzahl | 4-Bit + Prefetch | FP16, ohne Kompression |
|---|---|---|
| VRAM-Peak | ~3,6 GB | ~4,1 GB |
| Generierungsgeschwindigkeit | ~1,8 Tokens/s | ~0,7 Tokens/s |
| Zeit bis zum ersten Token | ~18 s (inkl. Layer-Laden) | ~32 s |
| Festplattenbelegung | ~72 GB (Shards) | ~130 GB |
Zum Vergleich: derselbe Prompt auf einer A100 80GB mit vLLM FP16 erreichte etwa 18 Tokens/s — AirLLM ist eine Größenordnung langsamer, die Hardwarekosten unterscheiden sich um zwei Größenordnungen. Zur Validierung von Agent-Ketten oder zum Vergleich von Modellausgaben kann das reichen. Für Echtzeit-Chat sind Quantisierung plus llama.cpp oder eine Cloud-API sinnvoller.
Cloud-Mac und Apple-Silicon-Szenarien
Auf Apple Silicon nutzt AirLLM den MLX-Pfad. Unified Memory vermeidet das Hin- und Herkopieren zwischen CPU und GPU, wie es bei einer 4GB-Diskret-GPU mit SATA-SSD typisch ist. Ein M4 Mac mini mit 24GB RAM und 70B in 4-Bit fühlt sich oft flüssiger an als 4GB-GPU plus langsamer Speicher. Typische Muster:
- Zu wenig lokaler Speicher — Modell auf einem Kvmzen Cloud Mac mini aufteilen und Batch-Skripte per SSH ausführen
- Windows-Entwickler — keinen Linux-Rechner nur für LLM-Experimente kaufen; Cloud-Mac mit Homebrew und Python nutzen
- Agent-Prototyping — Inferenz lokal mit AirLLM beweisen, Orchestrierung für lange Jobs auf Cloud-Mac verlagern; Framework-Auswahl siehe AI-Agent-Lernpfad (2026)
Kosten, Leistung und Risiken
| Ansatz | Vorlaufkosten | Inferenzgeschwindigkeit | Haupt-Risiken |
|---|---|---|---|
| AirLLM + 4GB-Diskret-GPU | Niedrig (vorhandene Hardware) | 0,5–3 Tokens/s | SSD-Verschleiß, lange Wartezeiten |
| Quantisiertes llama.cpp (16GB+ VRAM) | Mittel (GPU-Upgrade) | 5–15 Tokens/s | Genauigkeitsverlust durch Quantisierung |
| Cloud Mac mini M4 (24GB) | Monatsabo | 3–8 Tokens/s (MLX) | Netzwerklatenz, Speicherkontingent |
| API nach Token | Keine Hardware | Echtzeit | Rechnung skaliert mit Nutzung |
Häufige Fragen
Kann eine 4GB-Grafikkarte wirklich 70B betreiben?
Ja. AirLLMs Schicht-Inferenz hält nur eine Transformer-Schicht gleichzeitig auf der GPU; Llama 3.1 70B peakt bei etwa 4GB VRAM. Rechnen Sie mit 0,5–3 Tokens/s und beim ersten Lauf mit Download plus Split von rund 130GB.
AirLLM, llama.cpp oder vLLM — wie wähle ich?
AirLLM optimiert auf minimalen VRAM und Forschungsvalidierung. llama.cpp und vLLM zielen auf Produktion mit höherem Durchsatz, brauchen aber mehr VRAM. Interaktive Dienste → llama.cpp; hardwarelimitierte Offline-Checks → AirLLM.
Funktioniert es unter macOS?
Ja — seit v2.10 mit Apple Silicon und MLX. Unified Memory reduziert Bus-Kopien. Bei knappem Speicher: Kvmzen Cloud Mac mini zum Remote-Splitten und Ausführen.
Wie viel Festplatte brauche ich?
Llama 3.1 70B Rohgewichte etwa 130GB; für die Shard-Phase ~300GB SSD einplanen. 4-Bit-Kompression verkleinert Shards; delete_original=True entfernt den Original-Checkpoint nach dem Split.
Große Modelle auf dem Mac mini — entspannter als mit 4GB-GPU
AirLLM zeigt, dass 70B auch auf winzigem VRAM erreichbar ist — aber Festplatten-I/O und Geschwindigkeiten unter einem Token pro Sekunde machen daraus ein Validierungswerkzeug, keinen Alltags-Stack. Apple Silicons Unified Memory lässt ein M4 Mac mini mit 24GB quantisiertes 70B flüssiger fahren: keine CUDA-Treiber, Homebrew und Python sofort nutzbar, Neural Engine beschleunigt Teile des MLX-Stacks.
Gegenüber Windows-Rechnern ähnlicher Preisklasse verbraucht der Mac mini im Leerlauf nur etwa 4 W — geeignet für lange unbeaufsichtigte Inferenz-Jobs. Niedrige Absturzrate und Gatekeeper machen Remote-Agent-Knoten verlässlicher. Wenn Ihre 4GB-Karte am Limit ist, ist der Umzug der LLM-Experimente in die Cloud oft der klügere nächste Schritt.
Statt zwischen alter GPU und SSD-Lebensdauer zu wählen, validieren Sie Ihren 70B-Workflow auf einem Apple-Silicon-Cloud-Knoten — Tarife ansehen und lassen Sie die Hardware Ihr Experiment nicht mehr bremsen.