--- title: "AirLLM mit 4 GB VRAM: Layer-wise Inference" canonical: https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/ language: de description: "Kann AirLLM 70B bis 2,8T mit 4 GB VRAM ausführen? So funktionieren Layer-Streaming, Speicher- und Speed-Kosten sowie ein sinnvoller Pilot." image: "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 20. Aug. 2026 Zuletzt geprüft 20. August 2026 [**Weiter**](/de/blog/moneyprinterturbo-review-2026/) # AirLLM mit 4 GB VRAM: So funktioniert Layer-wise Inference TL;DR AirLLM senkt den maximalen GPU-Speicher, indem immer nur die aktuelle Schicht oder bei unterstützten Sparse-Modellen die gerouteten Experten geladen werden. Das Repository nennt rund 4 GB VRAM für 70B, 8 GB für Llama 3.1 405B, 12 GB für DeepSeek-V3 und 3,72 GB für Kimi K3. Das sind Ausführungs- und Peak-Memory-Angaben, keine Garantie für produktiven Durchsatz. Der vollständige Checkpoint bleibt auf dem Datenträger, jeder generierte Token kann erneute Weight-Transfers auslösen, und Kontext sowie Runtime-Puffer brauchen weiterhin Speicher. Für die großen Headlines fehlt ein reproduzierbarer Tokens-pro-Sekunde-Benchmark. Kimi K3 wird außerdem bereits mit nativen MXFP4-Weights ausgeliefert, weshalb "ohne Quantisierung" dieses Beispiel falsch beschreibt. AirLLM eignet sich für Forschung, Offline-Evaluierung und Zugänglichkeitstests. Für Kundensysteme müssen Time to First Token, Decode-Speed, Speicherplatz, Parallelität, Qualität und Gesamtkosten gegen ein kleineres quantisiertes Modell oder eine API gemessen werden. **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](/de/blog/llmfit-local-llm-hardware-guide/). | Claim | Was die Evidenz trägt | Was offen bleibt | | --- | --- | --- | | 70B mit 4 GB VRAM | Eine Schicht liegt im GPU-Speicher | Interaktive Geschwindigkeit | | Llama 3.1 405B mit 8 GB | Codepfad und Notebook sind öffentlich | Reproduzierbarer Full-Precision-Benchmark | | DeepSeek-V3 mit rund 12 GB | Support und Peak-Memory-Angabe | Latenz, Parallelität und Reliability | | Kimi K3 2,8T mit 3,72 GB | Maintainer-Messung auf einer RTX 6000 Ada | Der 1,6-TB-Checkpoint bleibt auf Storage | | Keine Quantisierung nötig | AirLLM kann manche Weights ohne eigene Kompression streamen | Kimi K3 wird nativ als MXFP4 ausgeliefert | ## 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](https://github.com/lyogavin/airllm) 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](https://github.com/MoonshotAI/Kimi-K3) 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](https://github.com/deepseek-ai/DeepSeek-V3) 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](https://github.com/lyogavin/airllm/issues/295) 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? | Anforderung | Besserer Default | Grund | | --- | --- | --- | | Riesigen Checkpoint einmal untersuchen | AirLLM-Pilot | Zugriff ist wichtiger als Antwortzeit | | Privater lokaler Chat | Kleineres quantisiertes Modell | Residente Weights liefern meist bessere Latenz | | Multi-User-API | vLLM, SGLang oder Managed API | Batching und Scheduling sind Kernfunktionen | | Offline-Batch | Beide Varianten messen | Ein Layer-Load kann viele Sequenzen bedienen | | Produktion | Kleinstes Modell, das den Eval besteht | Akzeptierte Aufgaben zählen mehr als Parameter | Disk-Offload schafft Kapazität, danach muss Systemdesign Geschwindigkeit zurückholen. Das [PRIMA.CPP-Paper](https://arxiv.org/abs/2504.08791) 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](/de/blog/local-models-vs-apis-break-even-eu-2026/). Für API-Bedingungen und Datenstandort besitzt unser [Kimi-K3-Produktionscheck](/de/blog/kimi-k3-eu-api-production-review/) den Intent. Eine NVMe-Alternative mit veröffentlichten Speed-Daten analysiert unser [Colibri-Hardware-Review](/de/blog/colibri-glm-5-2-consumer-hardware/). ## 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. ## Häufige Fragen ### Kann AirLLM 70B mit 4 GB VRAM ausführen? Ja, unterstützte Checkpoints können durch schichtweises Laden einen niedrigen VRAM-Peak erreichen. Das vollständige Modell bleibt auf Storage, und die Zahl garantiert keine interaktive Geschwindigkeit. ### Wie funktioniert AirLLM? AirLLM teilt den Checkpoint in Layer-Shards, lädt die aktuelle Schicht, verarbeitet Activations und gibt die Weights wieder frei. Sparse-Modelle können einzelne Experten streamen. ### Verwendet AirLLM Quantisierung? AirLLM bietet optionale 4-Bit- und 8-Bit-Kompression. Kimi K3 verwendet schon native MXFP4-Weights, daher ist sein Beispiel nicht unquantisiert. ### Wie schnell ist AirLLM? Für die großen Headlines fehlt eine reproduzierbare Upstream-Tabelle. Miss Cold Start, Time to First Token und Decode-Speed auf dem exakten Modell. ### Ist AirLLM produktionsreif? Behandle AirLLM als Forschungs- und Zugriffs-Tool, solange eigene Tests Latenz, Durchsatz, Qualität und Reliability nicht belegen. ## Fazit AirLLM kann einen Checkpoint ausführen, obwohl er nicht in den GPU-Speicher passt. Die 4-GB-, 8-GB-, 12-GB- und 3,72-GB-Zahlen beschreiben gemeldete Peak-Werte. Sie verkleinern weder den Checkpoint noch machen sie Storage schnell. Prüfe das Weight-Format, plane Platz für Original und Shards, miss jede Generation-Phase und vergleiche Kosten pro akzeptierter Aufgabe mit einem kleineren residenten Modell oder einer API. Das größte startende Modell ist selten das beste Produkt. ## Das könnte dich auch interessieren.. [**Welches lokale LLM passt auf deine Hardware?** Grenze passende Modelle ein, bevor du extremes Layer-Streaming testest.](/de/blog/llmfit-local-llm-hardware-guide/) [**Lokale Modelle versus APIs** Berechne Self-Hosting nach Messung von Latenz, Auslastung und Engineering.](/de/blog/local-models-vs-apis-break-even-eu-2026/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Qwen3.8-27B: Computer-Use-Agenten selbst hosten, ohne Screenshots zu exportieren](/de/blog/qwen3-8-27b-self-hosted-computer-use-agents/) - [Der vLLM- und Triton-Stack von Netflix: 7 Produktionslektionen](/de/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js im Browser: Wann lokale KI in dein Produkt gehört](/de/blog/transformers-js-browser-ai-guide/) - [LiteLLM selbst hosten: Production-Guide 2026](/de/blog/self-host-litellm-production-2026/) - [KI-fähiges Unternehmenswiki: Architektur und Aufbau](/de/blog/ai-ready-company-wiki/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 20. Aug. 2026 Zuletzt geprüft 20. August 2026 [**Weiter**](/de/blog/moneyprinterturbo-review-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/#webpage", "@type": "WebPage", "dateModified": "2026-08-20", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-20", "url": "https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "AirLLM senkt den maximalen GPU-Speicher, indem immer nur die aktuelle Schicht oder bei unterstützten Sparse-Modellen die gerouteten Experten geladen werden. Das Repository nennt rund 4 GB VRAM für 70B, 8 GB für Llama 3.1 405B, 12 GB für DeepSeek-V3 und 3,72 GB für Kimi K3. Das sind Ausführungs- und Peak-Memory-Angaben, keine Garantie für produktiven Durchsatz. Der vollständige Checkpoint bleibt auf dem Datenträger, jeder generierte Token kann erneute Weight-Transfers auslösen, und Kontext sowie Runtime-Puffer brauchen weiterhin Speicher. Für die großen Headlines fehlt ein reproduzierbarer Tokens-pro-Sekunde-Benchmark. Kimi K3 wird außerdem bereits mit nativen MXFP4-Weights ausgeliefert, weshalb \"ohne Quantisierung\" dieses Beispiel falsch beschreibt. AirLLM eignet sich für Forschung, Offline-Evaluierung und Zugänglichkeitstests. Für Kundensysteme müssen Time to First Token, Decode-Speed, Speicherplatz, Parallelität, Qualität und Gesamtkosten gegen ein kleineres quantisiertes Modell oder eine API gemessen werden.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur AirLLM mit 4 GB VRAM: So funktioniert Layer-wise Inference TL;DR AirLLM senkt den maximalen GPU-Speicher, indem immer nur die aktuelle Schicht oder bei unterstützten Sparse-Modellen die gerouteten Experten geladen werden. Das Repository nennt rund 4 GB VRAM für 70B, 8 GB für Llama 3.1 405B, 12 GB für DeepSeek-V3 und 3,72 GB für Kimi K3. Das sind Ausführungs- und Peak-Memory-Angaben, keine Garantie für produktiven Durchsatz. Der vollständige Checkpoint bleibt auf dem Datenträger, jeder generierte Token kann erneute Weight-Transfers auslösen, und Kontext sowie Runtime-Puffer brauchen weiterhin Speicher. Für die großen Headlines fehlt ein reproduzierbarer Tokens-pro-Sekunde-Benchmark. Kimi K3 wird außerdem bereits mit nativen MXFP4-Weights ausgeliefert, weshalb \"ohne Quantisierung\" dieses Beispiel falsch beschreibt. AirLLM eignet sich für Forschung, Offline-Evaluierung und Zugänglichkeitstests. Für Kundensysteme müssen Time to First Token, Decode-Speed, Speicherplatz, Parallelität, Qualität und Gesamtkosten gegen ein kleineres quantisiertes Modell oder eine API gemessen werden. 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. AirLLM-Claims und ihre belastbare Interpretation ClaimWas die Evidenz trägtWas offen bleibt 70B mit 4 GB VRAMEine Schicht liegt im GPU-SpeicherInteraktive Geschwindigkeit Llama 3.1 405B mit 8 GBCodepfad und Notebook sind öffentlichReproduzierbarer Full-Precision-Benchmark DeepSeek-V3 mit rund 12 GBSupport und Peak-Memory-AngabeLatenz, Parallelität und Reliability Kimi K3 2,8T mit 3,72 GBMaintainer-Messung auf einer RTX 6000 AdaDer 1,6-TB-Checkpoint bleibt auf Storage Keine Quantisierung nötigAirLLM kann manche Weights ohne eigene Kompression streamenKimi K3 wird nativ als MXFP4 ausgeliefert 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? Checkpoint aufteilen. AirLLM erzeugt Dateien pro Schicht. Original und umgewandelte Kopie können gleichzeitig Platz benötigen. Runtime-State behalten. Activations, Attention-Daten, KV-Cache und Puffer brauchen weiterhin RAM oder VRAM. Aktuelle Schicht laden. Der Transformer-Block wird zum Compute Device übertragen, ausgeführt und wieder freigegeben. 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "offizielle AirLLM-Repository", "url": "https://github.com/lyogavin/airllm" }, { "@type": "WebPage", "name": "offizielle Kimi-K3-Repository", "url": "https://github.com/MoonshotAI/Kimi-K3" }, { "@type": "WebPage", "name": "offizielle DeepSeek-V3-Repository", "url": "https://github.com/deepseek-ai/DeepSeek-V3" }, { "@type": "WebPage", "name": "Evidenz-Audit im Repository", "url": "https://github.com/lyogavin/airllm/issues/295" }, { "@type": "WebPage", "name": "PRIMA.CPP-Paper", "url": "https://arxiv.org/abs/2504.08791" } ], "dateModified": "2026-08-20", "datePublished": "2026-08-20", "description": "AirLLM senkt den maximalen GPU-Speicher, indem immer nur die aktuelle Schicht oder bei unterstützten Sparse-Modellen die gerouteten Experten geladen werden. Das Repository nennt rund 4 GB VRAM für 70B, 8 GB für Llama 3.1 405B, 12 GB für DeepSeek-V3 und 3,72 GB für Kimi K3. Das sind Ausführungs- und Peak-Memory-Angaben, keine Garantie für produktiven Durchsatz. Der vollständige Checkpoint bleibt auf dem Datenträger, jeder generierte Token kann erneute Weight-Transfers auslösen, und Kontext sowie Runtime-Puffer brauchen weiterhin Speicher. Für die großen Headlines fehlt ein reproduzierbarer Tokens-pro-Sekunde-Benchmark. Kimi K3 wird außerdem bereits mit nativen MXFP4-Weights ausgeliefert, weshalb \"ohne Quantisierung\" dieses Beispiel falsch beschreibt. AirLLM eignet sich für Forschung, Offline-Evaluierung und Zugänglichkeitstests. Für Kundensysteme müssen Time to First Token, Decode-Speed, Speicherplatz, Parallelität, Qualität und Gesamtkosten gegen ein kleineres quantisiertes Modell oder eine API gemessen werden.", "headline": "AirLLM mit 4 GB VRAM: So funktioniert Layer-wise Inference", "image": "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.svg", "inLanguage": "de", "keywords": "AirLLM, Lokale LLMs, GPU-Inferenz", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/", "wordCount": 1457 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/airllm-layer-wise-inference-low-vram/", "name": "AirLLM mit 4 GB VRAM: Layer-wise Inference | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja, unterstützte Checkpoints können durch schichtweises Laden einen niedrigen VRAM-Peak erreichen. Das vollständige Modell bleibt auf Storage, und die Zahl garantiert keine interaktive Geschwindigkeit." }, "name": "Kann AirLLM 70B mit 4 GB VRAM ausführen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AirLLM teilt den Checkpoint in Layer-Shards, lädt die aktuelle Schicht, verarbeitet Activations und gibt die Weights wieder frei. Sparse-Modelle können einzelne Experten streamen." }, "name": "Wie funktioniert AirLLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AirLLM bietet optionale 4-Bit- und 8-Bit-Kompression. Kimi K3 verwendet schon native MXFP4-Weights, daher ist sein Beispiel nicht unquantisiert." }, "name": "Verwendet AirLLM Quantisierung?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Für die großen Headlines fehlt eine reproduzierbare Upstream-Tabelle. Miss Cold Start, Time to First Token und Decode-Speed auf dem exakten Modell." }, "name": "Wie schnell ist AirLLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Behandle AirLLM als Forschungs- und Zugriffs-Tool, solange eigene Tests Latenz, Durchsatz, Qualität und Reliability nicht belegen." }, "name": "Ist AirLLM produktionsreif?" } ] } ```