Llama-Modelle 2026: Wann lohnt sich Meta Llama lokal noch?

Meta Llama ist 2026 nicht mehr automatisch der lokale Default. Der Vergleich zeigt, wo Llama 3.x und Llama 4 noch sinnvoll sind, was RTX 5090/32 GB wirklich ändern und wann Qwen oder Mistral näherliegen.

Victor Klaue Victor Klaue IT-Projektleiter & KI-Analyst Veröffentlicht 23. Juni 2026 7 min Lesezeit
Llama-Modelle 2026: Wann lohnt sich Meta Llama lokal noch?

Llama lohnt sich lokal vor allem bei bestehenden Llama-Stacks oder einem konkreten Bedarf an Metas Modellen. Für einen neuen 32-GB-Rechner ist Scout mit 109 Milliarden Gesamtparametern dagegen kein naheliegender Standard. Stand 3. Oktober 2026 sind Scout und Maverick weiterhin die neuesten allgemeinen generativen Llama-Modelle in Metas offizieller Hugging-Face-Übersicht. Vor einer Hardwareentscheidung gehört deshalb der Vergleich mit kleineren aktuellen Alternativen dazu.

Auch die Hardware-Realität hat sich verschoben. Die RTX 4090 mit 24 GB war lange der Consumer-Anker; 2026 ist die RTX 5090 mit 32 GB GDDR7 die passendere Referenz. Das hilft kleinen und mittleren Modellen spürbar. Es macht Llama 4 Scout aber noch nicht zu einem normalen Desktop-Modell: Scout rechnet pro Token nur mit 17B aktiven Parametern, muss als 109B-MoE-Modell aber trotzdem mit seinem Speicherbedarf geplant werden.

Der nüchterne Befund: Llama lohnt sich lokal noch, wenn Kompatibilität, bestehende Llama-Stacks, lange Kontexte oder konkrete Meta-Modelle zählen. Wer heute einfach das beste lokale Modell für Text, Code oder Vision sucht, sollte Llama aber gegen Qwen, Mistral und andere aktuelle Open-Weight-Familien testen, statt aus Gewohnheit bei Llama zu starten.

Was Llama 2026 wirklich ist

Llama ist Metas Open-Weight-Modellfamilie. Open Weight ist hier der präzisere Begriff als Open Source: Die Gewichte sind verfügbar, die Nutzung läuft aber unter Metas Community-Lizenzen und nicht unter einer OSI-zertifizierten Open-Source-Lizenz. Für viele Unternehmen ist das praktisch nutzbar. Für Plattformen mit sehr grosser Reichweite, Weitervertrieb oder Konkurrenzprodukten bleibt die Lizenzprüfung Pflicht.

Für DACH ist ausserdem wichtig: Llama 4 ist multimodal, aber die Llama-4-Lizenz und die eingebundene Acceptable Use Policy gehören bei Bildinput in die Prüfung. Schweizer Organisationen fallen nicht automatisch in dieselbe EU-Lage wie Unternehmen mit Sitz in Deutschland oder Österreich. Wer in der EU Bildverständnis produktiv einsetzen will, sollte Llama 4 technisch und lizenzrechtlich prüfen und Alternativen wie Qwen-VL, Pixtral/Mistral oder gehostete APIs vergleichen. Das ist keine Rechtsberatung, aber eine praktische Beschaffungsfrage.

Stand 3. Oktober 2026 sind Scout und Maverick die neuesten allgemeinen generativen Llama-Modelle in Metas offizieller Hugging-Face-Übersicht. Frei ladbare Gewichte für Llama 4.1, Llama 4.2 oder Behemoth sind dort nicht belegt. Llama Guard 4 und Prompt Guard 2 gehören dagegen zum Safety-Ökosystem.

Für neue Text- und Agentenprojekte gehören Qwen3.8-27B und Qwen3.8-Flash-Next in die Vergleichsauswahl; Qwen3-VL bleibt ein eigener Vergleichspfad für Vision. Dabei sind 27B-Dense- und grosse MoE-Varianten keine austauschbaren Hardwareklassen. Flash-Next braucht eine separate Planung von Quantisierung, Gewichtsspeicher und Runtime. Ein neuerer Familienname allein rechtfertigt weder den Wechsel noch die Annahme gleicher Speicheranforderungen.

Produktiv relevant sind damit derzeit diese Linien:

  • Llama 3.1 vom 23. Juli 2024: Dense-Textmodelle in 8B, 70B und 405B mit 128K Kontext.
  • Llama 3.2 vom 25. September 2024: kleine Textmodelle in 1B/3B für Edge und Mobile sowie Vision-Modelle in 11B/90B.
  • Llama 3.3 70B vom 6. Dezember 2024: ein starkes 70B-Textmodell mit 128K Kontext und verbessertem Instruction-Tuning.
  • Llama 4 Scout und Maverick vom 5. April 2025: nativ multimodale MoE-Modelle mit Text- und Bildeingabe; Maverick ist auch als offizielles FP8-Artefakt verfügbar.
  • Llama Guard 4 und Prompt Guard 2 vom April 2025: aktuelle Safety-Modelle für Moderation, Jailbreak- und Prompt-Injection-Erkennung.

Llama 4 Behemoth ist in Metas Ankündigung als Lehrermodell beschrieben, aber nicht frei herunterladbar. Für lokale Hardwareplanung zählt es daher nicht.

MoE: Warum Llama 4 anders geplant werden muss

Bei einem Dense-Modell ist die Speicherrechnung grob linear: 70 Milliarden Parameter brauchen in BF16 etwa 140 GB, in 4-Bit-Quantisierung deutlich weniger. Fast alles, was im Speicher liegt, wird auch gerechnet.

Bei Mixture-of-Experts-Modellen ist das anders. Llama 4 Scout hat laut Model Card 17B aktive und 109B Gesamtparameter. Maverick hat ebenfalls 17B aktive, aber 400B Gesamtparameter. Der Router aktiviert pro Token nur einen Teil der Experten. Das spart Rechenzeit, ändert aber nicht den Grundsatz: Die Gewichte müssen für brauchbare Inferenz erreichbar sein. Meta formuliert es selbst: Scout passt mit Int4-Quantisierung auf eine H100; Maverick passt auf einen H100-Host, nicht auf eine einzelne Consumer-GPU.

Das ist keine akademische Spitzfindigkeit. Wer «17B aktiv» wie «17B Modellgrösse» behandelt, landet bei falschen Kaufentscheidungen. MoE macht Llama 4 effizienter pro Token, aber nicht klein im Speicher.

Modellvergleich: Parameter, Kontext, VRAM

Die Werte sind Richtgrössen für Modellgewichte. KV-Cache, Aktivierungen, Runtime-Overhead, längere Kontexte und Multimodalität erhöhen den realen Speicherbedarf.

Modell Architektur Parameter Kontext VRAM BF16 VRAM Q4/Int4
Llama 3.2 3B Dense, Text 3.21B 128K ~6.5 GB ~2 GB
Llama 3.1 8B Dense, Text 8B 128K ~16 GB ~5 GB
Llama 3.3 70B Dense, Text 70B 128K ~140 GB ~40 bis 45 GB
Llama 3.1 405B Dense, Text 405B 128K ~810 GB ~200 bis 230 GB
Llama 4 Scout MoE, multimodal 17B aktiv / 109B total 10M ~218 GB ~55 GB
Llama 4 Maverick MoE, multimodal 17B aktiv / 400B total 1M ~800 GB ~200 GB

Die 3.x-Modelle sind nicht alle identisch: Llama 3.2 enthält auch 11B- und 90B-Visionmodelle. Wer lokale Bildanalyse ohne Llama 4 testen will, sollte diese Modelle kennen. Für klassische Text-Assistenz, RAG und Code-Hilfe sind aber vor allem 3B, 8B und 70B relevant. Llama 4 ist die erste Llama-Linie, bei der Multimodalität und MoE gleichzeitig zum Kern der Architektur gehören.

Quantisierung: Pflicht, aber kein Zaubertrick

Ohne Quantisierung sind grössere Llama-Modelle lokal kaum interessant. Q4- und Q5-Varianten sind für Llama 3.x seit langem Alltag in llama.cpp, Ollama, LM Studio und verwandten Tools. Diese Artefakte sind aber nicht automatisch «offiziell», nur weil sie bequem verfügbar sind. Meist stammen sie aus der Community oder von spezialisierten Anbietern.

Bei Llama 4 ist diese Trennung besonders wichtig. Unsloth stellt Dynamic-GGUF-Quantisierungen bereit, darunter Scout-Varianten bis hinunter zu rund 33.8 GB Disk Size bei 1.78 Bit. Das ist beeindruckend, aber es ist ein aggressiver Community-Pfad. Eine einzelne 24-GB-GPU kann Scout damit nur mit Kompromissen betreiben: CPU-Offload, kleineres Kontextfenster, geringere Qualität oder niedrigere Geschwindigkeit. Für Produktion sollte man solche Builds erst mit eigenen Aufgaben und eigenen Qualitätskriterien prüfen.

Für die Speicherplanung bleibt die Trennung wichtig: Llama 3.1 8B in Q4/Q5 ist ein kleiner Consumer-Kandidat. Llama 3.3 70B braucht in Q4 rund 40 bis 45 GB allein für Gewichte. Scout gehört mit Int4/Q4 eher in die 80-GB-Klasse; Maverick benötigt deutlich mehr Speicher und ein passendes Multi-GPU-Konzept.

Signal der Woche abonnieren

Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.

Kostenlos als Member. Gratis abonnieren

Hardware-Matrix: Was realistisch läuft

«Läuft» ist nicht dasselbe wie «lohnt sich». Die Matrix bewertet praktische Nutzung mit brauchbarer Geschwindigkeit und nicht nur den erfolgreichen Start eines Modells.

Die RTX 5090 ändert die Consumer-Baseline: 32 GB GDDR7 und deutlich mehr Bandbreite sind für lokale KI ein echter Sprung gegenüber der 4090. Für Llama 4 ist das trotzdem keine magische Grenze. 32 GB reichen gut für kleine und mittlere Modelle, sie reichen knapp für manche aggressive 70B-Experimente und sie reichen nicht, um Scout als saubere Produktionsbasis zu behandeln.

Hardware Llama 3.1 8B Llama 3.3 70B Llama 4 Scout Llama 4 Maverick Llama 3.1 405B
RTX 3060 12 GB gut läuft nicht sinnvoll läuft nicht sinnvoll läuft nicht läuft nicht
RTX 4090 24 GB Overkill nur stark quantisiert / Offload Demo-Pfad mit aggressiven Community-Quants läuft nicht läuft nicht
RTX 5090 32 GB Overkill nur stark quantisiert / Offload Demo-Pfad, nicht Produktionsbasis läuft nicht läuft nicht
2x RTX 4090 (48 GB) Overkill sinnvoll in Q4 knapp; nur mit Kompromissen läuft nicht sinnvoll läuft nicht
2x RTX 5090 (64 GB) Overkill gut in Q4 möglich, aber knapp bei Kontext läuft nicht sinnvoll läuft nicht
Mac mini 16 GB gut läuft nicht sinnvoll läuft nicht läuft nicht läuft nicht
Mac mini / Studio 64 GB Overkill möglich in Q4, Kontext begrenzen nicht sauber sinnvoll läuft nicht läuft nicht
Mac Studio Ultra 128 GB Overkill gut in Q4 möglich in Q4 läuft nicht sinnvoll läuft nicht
H100/H200 80 GB+ (1 GPU) Overkill Overkill sinnvoll mit Int4/Q4 läuft nicht als Einzel-GPU-Default läuft nicht sinnvoll
Multi-H100/H200-Host Overkill Overkill gut sinnvoll sinnvoll

Apple Silicon braucht eine eigene Lesart. Unified Memory ist kein frei verfügbarer VRAM-Block. Betriebssystem, Apps, KV-Cache und Runtime teilen sich denselben Speicher. Ein 64-GB-Mac kann Llama 3.3 70B in Q4 je nach Tool und Kontext testen, aber Scout mit rund 55 GB Modellgewicht plus Overhead ist kein sauberer Produktionsfall. Auf 128 GB wird Scout realistischer, aber auch dort ist das 10M-Kontextfenster nicht einfach «gratis».

Bei Multi-GPU-Consumer-Systemen ist nicht nur die Summe des VRAM entscheidend. PCIe-Lanes, Tensor Parallelism, Offload-Strategie und Runtime-Support bestimmen, ob ein Setup brauchbar reagiert oder nur auf dem Papier passt. Zwei Karten in schwach angebundenen Slots sind bei MoE-Modellen schnell eine Enttäuschung.

Frameworks: Welche Runtime passt?

llama.cpp, Ollama und LM Studio sind naheliegende Einstiege für GGUF-Quantisierungen auf Macs und Consumer-GPUs. Für Serverbetrieb bietet vLLM eine OpenAI-kompatible API, Continuous Batching und Llama-4-Unterstützung. TensorRT-LLM ist ein weiterer NVIDIA-spezifischer Optimierungspfad. Die gewählte Version muss Architektur und Quantisierung des konkreten Checkpoints unterstützen.

Keine Runtime beseitigt den Gewichtsspeicher eines 400B-MoE-Modells. Offload kann knappen VRAM ausgleichen, verändert aber Latenz und Durchsatz. Safety-Modelle wie Llama Guard 4 werden zusätzlich eingeplant; sie ersetzen kein Chatmodell.

Wann Llama nicht die erste Wahl ist

Für lokale Coding- und Agentenaufgaben lohnt sich heute ein Vergleich mit Qwen3.8-27B; Qwen3.8-Flash-Next kommt nur mit passendem Speicher- und Serving-Konzept dazu. Daraus folgt keine pauschale Qualitätsrangfolge. Dieselben Aufgaben, Kontextlängen und Werkzeugverträge müssen auf dem jeweiligen System geprüft werden. Für Bildinput bleibt zusätzlich der Vergleich mit Qwen-VL oder Mistrals multimodalen Modellen relevant, insbesondere wenn Metas Lizenzbedingungen den Einsatz begrenzen.

Mistrals offene Modelle sind eine weitere Vergleichsoption. Eine europäische Anbieteradresse ersetzt dabei weder die Prüfung des konkreten Modells noch die Klärung von Lizenz und Datenverarbeitung.

Ein bestehender Llama-Stack mit geprüften Prompts und Evaluierungen kann einen Wechsel teurer machen als den Weiterbetrieb. Bei einem Neustart fehlt dieser Vorteil; dort muss Llama seinen Nutzen im direkten Aufgabentest zeigen.

Wann sich welches Llama lohnt

Llama 3.2 3B und Llama 3.1 8B bleiben Kandidaten für kleine Assistenten, Klassifikation und lokale RAG-Prototypen. Ihr Vorteil liegt in verbreiteten Quantisierungen und Runtime-Unterstützung. Bei neuen Projekten gehören aktuelle kleine Qwen-, Mistral- und Gemma-Modelle in denselben Aufgabentest.

Llama 3.3 70B ist eine Textoption für speicherreiche Workstations. Mit Q4, begrenztem Kontext und etwa 48 bis 80 GB VRAM ist ein lokaler Pfad realistisch. Wer keine Bildverarbeitung benötigt, kann damit den Mehrbedarf von Scout vermeiden.

Scout ist für Bildverständnis oder sehr lange Kontexte interessant. Das nominelle 10M-Fenster ist jedoch keine Zusage für Einzel-GPU-Betrieb. Maverick bleibt mit 400B Gesamtparametern ein Datacenter- oder Hosted-Inference-Kandidat. Beide benötigen eine modell- und einsatzbezogene Lizenzprüfung.

Fazit

Llama bleibt eine brauchbare Wahl, wenn ein vorhandener Stack oder eine konkret geprüfte Modellfähigkeit den zusätzlichen Speicher rechtfertigt. Für einen neuen lokalen Assistenten ist ein 109B- oder 400B-MoE-Modell keine sinnvolle Voreinstellung. Erst die eigene Evaluation sollte den Kauf dieser Infrastruktur auslösen.

🔗 Quellen
Victor Klaue
Victor Klaue

Ich ordne KI quellenbasiert und aus praktischer Erfahrung ein. Dabei geht es um Modelle, Agenten und Infrastruktur sowie um Sicherheit, Regulierung und gesellschaftliche Folgen. Victor Klaue ist mein Pseudonym.

Ähnliche Beiträge

veloGB10 auf DGX Spark: Qwen3.8-Flash-Next im Praxistest

veloGB10 auf DGX Spark: Qwen3.8-Flash-Next im Praxistest

Ich habe Qwen3.8-Flash-Next als EXL3-Pack auf der GB10-Engine veloGB10 getestet. Der kurze Decode lag mit 72,1 tok/s rund doppelt so hoch wie in meinem früheren vLLM-Profil, im Tool-Calling-Hardmode gab es dafür leichte Abstriche.

12. Okt. 2026 6 min
Aleph Alpha Kolibri-1 auf DGX Spark: gutes Deutsch, durchgefallen als Agent

Aleph Alpha Kolibri-1 auf DGX Spark: gutes Deutsch, durchgefallen als Agent

Ich habe Aleph Alphas Kolibri-1 im offiziellen FP8-Checkpoint auf einer 128-GB-GB10-Maschine gemessen: knapp 49 Tokens pro Sekunde, solide deutsche Texte, aber ein gescheitertes Sicherheitsgate im Werkzeugtest. Drei Blindrunden zum Selbstvergleichen inklusive.

05. Okt. 2026 17 min
Qwen3.8 Flash Next auf DGX Spark: MTP2 im Test

Qwen3.8 Flash Next auf DGX Spark: MTP2 im Test

MTP2 mit synchronem Scheduling bringt auf meiner DGX Spark 15 bis 24 Prozent mehr Decode-Durchsatz bei unveränderter Tool-Qualität. Was der KV-Aufschlag kostet und wo die Varianz die Zahl relativiert.

08. Sep. 2026 4 min