AirLLM mit 4 GB VRAM: So funktioniert Layer-wise Inference

Ja, AirLLM kann ein Modell ausführen, das deutlich größer als der VRAM der GPU ist. Das Modell passt dadurch nicht auf die GPU. Der Checkpoint bleibt auf dem Datenträger. AirLLM lädt die benötigte Schicht oder ausgewählte Experten, rechnet, gibt den Speicher frei und wiederholt den Ablauf. Weniger Speicherbelegung wird mit mehr Datentransfer bezahlt.

Ein 4-GB-Peak verrät weder Speicherplatz noch Setup-Zeit, Latenz, lange Context-Limits oder Parallelität. Dieser Check wurde am 20. August 2026 durchgeführt und besitzt einen engen Suchintent: Wie funktioniert AirLLM mit wenig VRAM, und wann ergibt ein kommerzieller Pilot Sinn? Wenn du ein normales Modell für vorhandene Hardware suchst, starte mit unserem Hardware-Guide für lokale LLMs.

Was ist AirLLM?

AirLLM ist eine Apache-2.0-lizenzierte Python-Bibliothek, die unterstützte Transformer-Checkpoints in kleinere Shards zerlegt und bei Bedarf lädt. Das offizielle AirLLM-Repository nennt Llama, Qwen, DeepSeek, Mistral, Phi, Gemma, Kimi K3 und weitere Familien unter einer AutoModel-Schnittstelle. Optional gibt es blockweise 4-Bit- oder 8-Bit-Kompression, CPU-Ausführung, Apple-Silicon-Support und begrenztes Prefetching.

Der Nutzen ist Zugriff. Ein Team kann einen Checkpoint untersuchen, der beim normalen Laden wegen fehlendem VRAM scheitert. Der Preis sind wiederholte Transfers. Ein üblicher GPU-Server hält Weights resident und verwendet sie für viele Token erneut. AirLLM holt sie wiederholt aus einer langsameren Speicherschicht, weil Kapazität vor Durchsatz steht.

Wie reduziert Layer-wise Inference den VRAM?

1. Checkpoint aufteilen. AirLLM erzeugt Dateien pro Schicht. Original und umgewandelte Kopie können gleichzeitig Platz benötigen.
2. Runtime-State behalten. Activations, Attention-Daten, KV-Cache und Puffer brauchen weiterhin RAM oder VRAM.
3. Aktuelle Schicht laden. Der Transformer-Block wird zum Compute Device übertragen, ausgeführt und wieder freigegeben.
4. Für jeden Token wiederholen. Autoregressiver Decode durchläuft das Modell erneut. Ohne Cache kehrt der Storage-Traffic zurück.

Der VRAM-Peak folgt der größten Schicht plus Activations und Arbeitsbereich, nicht allen Parametern. Der Platz auf Disk folgt weiterhin dem vollständigen Checkpoint. Langer Context, große Batches und mehrere Requests erhöhen den Runtime-Speicher zusätzlich.

Warum meldet Kimi K3 weniger VRAM als ein dichtes 70B-Modell?

Kimi K3 ist kein dichtes Modell. Das offizielle Kimi-K3-Repository dokumentiert 93 Schichten, 896 geroutete Experten, 16 ausgewählte Experten pro Token und 104 Milliarden aktive Parameter. AirLLM lädt bei K3 nur geroutete Experten. Dieser Working Set kann kleiner als eine dichte 70B-Schicht sein, obwohl die gesamte Expertenbibliothek viel größer ist.

Die Peak-Zahl sagt nichts über den Download. Der veröffentlichte Checkpoint hat rund 1,6 TB. Moonshot empfiehlt für Produktion vLLM, SGLang und TokenSpeed. AirLLM ist ein experimenteller Zugangspfad, nicht das Standardrezept des Modellanbieters.

„Ohne Quantisierung“ braucht eine Korrektur

AirLLM verlangt nicht für jeden Checkpoint eine eigene Quantisierung. Kimi K3 wurde jedoch mit Quantization-aware Training erstellt und mit MXFP4-Weights sowie MXFP8-Activations veröffentlicht. Der virale Satz verwechselt zusätzliche Runtime-Kompression mit dem Format der heruntergeladenen Weights.

Auch Modellgrößen brauchen Kontext. Das offizielle DeepSeek-V3-Repository nennt 671 Milliarden Parameter im Hauptmodell, 37 Milliarden aktive Parameter pro Token und weitere 14 Milliarden im Multi-Token-Prediction-Modul. „671B mit 12 GB“ beschreibt Peak VRAM, nicht 671 Milliarden residente Weights.

Was versteckt sich hinter 4 GB VRAM?

• Disk: Original und Layer-Shards können gleichzeitig existieren. Bei Kimi K3 hat schon der Quell-Checkpoint rund 1,6 TB.
• I/O: Kalte Schichten und Experten durchqueren Storage, RAM und eventuell PCIe. Prefetching macht NVMe nicht zu GPU-Speicher.
• Speed: Das README veröffentlicht keine reproduzierbare Tokens-pro-Sekunde-Tabelle für die großen Headlines.
• Context: KV-Cache, Activations und Batching-Kosten bleiben erhalten.

Ein öffentlicher Evidenz-Audit im Repository hält fest, dass dem 405B-Notebook Timing- und Memory-Ausgaben fehlen und es ein vorquantisiertes 4-Bit-Modell verwendet. Geschwindigkeit bleibt unbekannt, bis Checkpoint, Revision, Prompt, Context, Hardware und Output-Länge feststehen.

AirLLM oder ein Modell, das wirklich passt?

Disk-Offload schafft Kapazität, danach muss Systemdesign Geschwindigkeit zurückholen. Das PRIMA.CPP-Paper nutzt Memory Mapping, Pipelining, Prefetching und Device-aware Layer Placement für 30B- bis 70B-Modelle. Das ist kein AirLLM-Benchmark. Es zeigt, dass zwischen „läuft“ und „läuft sinnvoll“ ein Architekturproblem liegt.

Wann ist ein kommerzieller Pilot sinnvoll?

Teste AirLLM für seltenen Offline-Zugriff, Modellforschung, große Batch-Experimente oder Lehre mit knapper Hardware. Verzichte, wenn Kunden interaktive Antworten erwarten, mehrere Nutzer gleichzeitig zugreifen, regulierte Daten ohne Security Review verarbeitet werden oder ein quantisiertes 7B- bis 70B-Modell denselben Task-Eval bereits besteht.

Benchmark-Plan für die Entscheidung

1. Modell-ID, Revision, Weight-Format, AirLLM-Commit und alle Runtime-Versionen pinnen.
2. Peak VRAM, RAM, Swap, Original, Shards und temporären Platz messen.
3. Download, Split, Cold Start, Prefill, Time to First Token und Decode getrennt berichten.
4. Echte Context-Länge, Tools, Sprachen, Batch und Parallelität testen.
5. Qualität und Kosten pro akzeptierter Aufgabe gegen ein Hosted Baseline vergleichen.

Nutze danach unser Break-even-Modell für lokale LLMs und APIs. Für API-Bedingungen und Datenstandort besitzt unser Kimi-K3-Produktionscheck den Intent. Eine NVMe-Alternative mit veröffentlichten Speed-Daten analysiert unser Colibri-Hardware-Review.

Quellen und Grenzen

AirLLM liefert Features und Peak-Claims. Moonshot dokumentiert K3-Architektur und MXFP4. DeepSeek liefert die V3-Parameterzahlen. Der öffentliche Audit dokumentiert die 405B-Evidenzlücke. PRIMA.CPP liefert unabhängigen Kontext, validiert aber keine AirLLM-Zahl. Wavect hat die Terabyte-Checkpoints nicht heruntergeladen und die Peaks nicht reproduziert.