Llama lokal installieren - Llama 3.2, 3.3 und Code-Llama auf eigener Hardware

Llama ist das mit Abstand wichtigste offene Sprachmodell der letzten Jahre. Meta hat mit den Releases von Llama 2, Llama 3, Llama 3.1, Llama 3.2 und schließlich Llama 3.3 eine Modellfamilie etabliert, die heute auf Millionen lokalen Rechnern läuft, in Embedded-Geräten steckt, in Forschungslaboren als Baseline dient und in unzähligen Unternehmen die Basis für interne Assistenten bildet. Wer 2026 ein lokales LLM aufsetzen will, kommt an Llama nicht vorbei. Diese Anleitung führt dich Schritt für Schritt durch Modellauswahl, Hardware-Anforderungen, Installation per Ollama oder llama.cpp, das Verständnis der Quantisierungs-Stufen und die typischen Fallstricke. Am Ende läuft auf deinem Rechner ein Modell, das bei vielen Aufgaben nahe an GPT-4 herankommt und dabei deine Daten lokal lässt.

Llama-Modelle im Überblick

Die Llama-Familie ist seit 2024 in mehrere Subfamilien zerfallen, was Einsteiger schnell verwirrt. Llama 3.2 ist die Generation, die Meta im Herbst 2024 veröffentlicht hat. Sie umfasst zwei Edge-Modelle (1B und 3B Parameter) sowie zwei Vision-Modelle (11B und 90B), die Bilder verarbeiten können. Die Edge-Modelle sind explizit dafür gemacht, auf Smartphones, Raspberry-Pi-Boards oder schwachen Laptops zu laufen. Die 3B-Variante ist bemerkenswert: Sie liefert für Standard-Aufgaben (Zusammenfassen, Umformulieren, einfache Recherche) erstaunlich gute Ergebnisse bei einem Footprint von nur 2 GB.

Llama 3.3 ist der aktuelle Flaggschiff-Release. Meta hat mit dieser Generation die 70B-Architektur überarbeitet und liefert ein Modell, das in vielen Benchmarks an GPT-4o herankommt. Besonders deutlich sind die Sprünge bei Tool-Use, Function Calling und mehrsprachiger Performance. Llama 3.3 spricht Deutsch, Französisch, Spanisch, Italienisch, Portugiesisch, Hindi und Thai erstklassig. Für deutschsprachige Unternehmen ist das ein riesiger Schritt nach vorn, denn die Vorgänger waren zwar brauchbar, aber stilistisch oft holprig. Es gibt kein Llama 3.3 in 8B oder 13B - Meta hat sich bewusst auf 70B konzentriert, weil die Distillation in kleinere Modelle parallel über Llama 3.2 läuft.

Code-Llama ist die ältere, dafür spezialisierte Coding-Variante. Sie kommt in 7B-, 13B- und 34B-Größen und wurde auf öffentlich verfügbarem Code feingetunt. Für reine Programmieraufgaben ist Code-Llama 13B in vielen Fällen besser als Llama 3.2 3B oder sogar 8B-Modelle, weil das Trainingsmaterial einfach passender war. Wer einen lokalen Pair-Programmer in VS Code, Zed oder Neovim haben möchte, ist mit Code-Llama gut bedient. Inzwischen gibt es auch DeepSeek-Coder, Qwen-Coder und StarCoder als Alternativen, aber Code-Llama bleibt der Klassiker.

Die Lizenz von Llama ist nicht ganz so frei wie Apache 2.0 oder MIT, aber für die allermeisten Anwender unproblematisch. Meta erlaubt kommerzielle Nutzung, fordert allerdings zwei Dinge: Erstens darfst du das Modell nicht für Anwendungen mit mehr als 700 Millionen monatlich aktiven Nutzern verwenden ohne Sonderlizenz von Meta. Das betrifft praktisch nur die Top-20-Tech-Konzerne weltweit. Zweitens muss in nutzerseitiger Dokumentation klar erkennbar sein, dass Llama im Hintergrund läuft (Acceptable Use Policy). Für interne Tools, B2B-Produkte und mittelständische Anwendungen ist das kein Problem.

Im Vergleich zu Gemma (Google), Phi (Microsoft) und Mistral (Mistral AI) hat Llama mehrere Vorteile. Erstens ist die Community deutlich größer, was sich in besseren Tools, mehr Quantisierungen und mehr Finetunings niederschlägt. Zweitens ist die Multilinguale Performance besser als bei Gemma und Phi, die stark auf Englisch optimiert sind. Drittens ist Llama 3.3 70B eines der wenigen frei verfügbaren Modelle in der Klasse oberhalb von 30B, wo der Qualitätssprung gegenüber kleineren Varianten massiv ist. Mistral Large ist proprietär, Mixtral 8x22B ist verfügbar aber komplexer im Setup, und Gemma stoppt bei 27B. Damit bleibt Llama 3.3 für viele Use-Cases die einzige realistische Option, wenn lokale Top-Qualität gefordert ist.

Ein häufig übersehener Aspekt: Llama 3.2 11B Vision ist eines der besten frei verfügbaren multimodalen Modelle. Wer Bilder beschreiben, Diagramme analysieren oder Screenshots auswerten lassen möchte und dabei nicht auf OpenAI oder Anthropic angewiesen sein will, findet hier eine solide Lösung. Die 90B-Vision-Variante ist nochmal deutlich besser, braucht aber eine Workstation oder einen Server, weil sie um die 50 GB belegt.

Welche Llama-Variante für welche Hardware?

Die richtige Modellauswahl hängt zu 90 Prozent von deiner Hardware ab. Wer ein MacBook Air mit 16 GB hat, sollte gar nicht erst versuchen, Llama 3.3 70B zu starten, das frustriert nur. Umgekehrt verschenkt jemand mit einer RTX 4090 sein Potenzial, wenn er sich mit Llama 3.2 1B begnügt. Die folgende Tabelle zeigt die typischen Größen samt RAM-Bedarf und Empfehlung. Beachte, dass diese Werte für Q4-Quantisierung gelten, was 2026 die Standard-Qualitätsstufe für Consumer-Hardware ist.

Modell	Quantisierung	RAM-Bedarf	Empfohlen für
Llama 3.2 1B	Q4	1,5 GB	Edge, Raspberry Pi, schwache Laptops
Llama 3.2 3B	Q4	3 GB	Mainstream-Laptops, schnelle Antworten
Llama 3.2 11B Vision	Q4	8 GB	Bilderkennung, Mac mit 16+ GB
Llama 3.3 70B	Q4_K_M	40-45 GB	Workstation, M3 Max 64 GB, Server
Code-Llama 13B	Q4	9 GB	Coding-Assistent, Pair-Programming

Für die meisten Anwender ist Llama 3.2 3B der süße Spot. Auf einem MacBook M2 Air mit 16 GB liefert das Modell zwischen 35 und 50 Tokens pro Sekunde, was sich beim Tippen wie GPT-3.5 anfühlt. Für E-Mail-Drafts, Übersetzungen, einfache Zusammenfassungen und Brainstorming reicht die Qualität locker. Wer auf einem alten Intel-MacBook arbeitet, sollte direkt zu 1B greifen, weil 3B sonst zwar startet, aber unangenehm langsam läuft.

Llama 3.3 70B ist der Sprung in die Profi-Liga. Realistisch brauchst du dafür entweder einen Mac mit 64 GB Unified Memory (M2 Max, M3 Max, M3 Ultra, M4 Max) oder eine PC-Workstation mit zwei GPUs oder mindestens 64 GB DDR5-RAM. Auf einem MacBook M3 Max 64 GB läuft Q4_K_M mit etwa 8 bis 12 Tokens pro Sekunde, was zum Lesen ausreichend ist. Auf einem M3 Ultra oder einem System mit dedizierter A6000 wird es richtig flüssig. Wichtig: 32 GB sind theoretisch möglich, aber dann musst du andere Anwendungen schließen, sonst killt macOS den Llama-Prozess wegen Speicherdruck.

Code-Llama 13B braucht etwa 9 GB Q4 und passt damit sogar auf eine RTX 4060 mit 16 GB VRAM komfortabel hinein. Auf NVIDIA-Hardware schlagen Coding-Modelle oft mit 70 bis 100 Tokens pro Sekunde durch, was für eine Pair-Programming-Erfahrung absolut ausreicht. Wer Code-Llama in einer IDE-Integration laufen lassen will (Continue.dev, Twinny, Aider, Avante), bekommt damit die volle GitHub-Copilot-Erfahrung lokal und ohne Abo.

Die Vision-Variante Llama 3.2 11B ist eine eigene Liga. Sie braucht etwas mehr Setup-Aufwand, weil nicht jede Frontend-Software Bildinputs sauber durchreicht, dafür kannst du damit Screenshots interpretieren, OCR auf Dokumenten machen, Diagramme erklären lassen und Bildbeschreibungen für Accessibility-Zwecke generieren. Auf einem Mac mit 24 GB läuft das Modell entspannt mit 15 bis 25 Tokens pro Sekunde. Bedenke, dass die effektive RAM-Belegung mit Bildkontext höher ist als bei reinen Text-Prompts.

Installation mit Ollama (empfohlen)

Ollama ist 2026 der unumstrittene Standard für lokale LLMs. Das Tool kümmert sich um Modellverwaltung, Quantisierung, Server-Lifecycle und API-Endpunkt. Installation auf macOS und Linux ist ein Einzeiler, auf Windows läuft seit Mitte 2025 ein nativer Build. Nach der Installation hast du einen lokalen REST-API-Server auf Port 11434, der zu großen Teilen kompatibel mit der OpenAI-API spricht. Das ist Gold wert, weil viele bestehende Tools (Open WebUI, LangChain, LlamaIndex, AnythingLLM, Continue, Aider) ohne Code-Änderung darauf andocken.

Das Pullen der Modelle funktioniert wie bei Docker. Ein einziger Befehl lädt Modell plus Tokenizer, prüft Hashes und legt alles unter ~/.ollama/models ab. Wer mehrere Modelle parallel testen will, kann das problemlos tun, weil Ollama die Modelle nur bei Bedarf in den RAM lädt und nach kurzer Inaktivität wieder freigibt. Für Llama 3.3 70B solltest du eine schnelle Internetverbindung einplanen, der Download von rund 40 GB dauert auch über Glasfaser meist eine Stunde oder länger.

ollama pull llama3.2:3b           # 2 GB Download
ollama pull llama3.3:70b-q4_K_M   # 40 GB Download, mehrere Stunden
ollama run llama3.3:70b-q4_K_M

Nach dem Pull kannst du Modelle direkt im Terminal chatten oder als API ansprechen. Für ein hübscheres Frontend empfiehlt sich Open WebUI, das du als Docker-Container mit einer einzigen Zeile startest. Dort hast du dann eine ChatGPT-ähnliche Oberfläche, die direkt auf deinen Ollama-Server zugreift. Wenn du mehrere Modelle parallel ausprobieren willst, ist die Modelle-Auswahl oben in Open WebUI besonders nützlich. Wichtig zu wissen: Ollama benutzt im Hintergrund llama.cpp, ist also keine eigene Inference-Engine, sondern eine Convenience-Schicht.

Installation mit llama.cpp (Profi-Variante)

llama.cpp ist die zugrundeliegende C++-Implementierung von Georgi Gerganov, die seit 2023 existiert und sich als Industriestandard für Inference auf CPU und Consumer-GPUs etabliert hat. Während Ollama bequem ist, brauchst du llama.cpp direkt, sobald du tiefer eingreifen willst: eigene Quantisierungen erstellen, Modelle aus FP16 in GGUF konvertieren, Patches für spezielle Hardware einspielen, Server-Modus mit Sliding-Window-Attention betreiben, oder Multi-GPU-Splitting feinkonfigurieren. Auch Forschungs-Setups laufen meist direkt auf llama.cpp, weil dort neue Quantisierungs-Verfahren als erstes implementiert werden.

Die Kompilierung ist auf macOS und Linux unkompliziert. Wichtig ist, das richtige Backend einzuschalten: GGML_METAL=1 für Apple Silicon, GGML_CUDA=1 für NVIDIA-Karten, GGML_VULKAN=1 für AMD-GPUs, GGML_SYCL=1 für Intel Arc. Wer das vergisst, landet im CPU-Fallback und wundert sich, warum Llama plötzlich zehnmal langsamer läuft als unter Ollama. Auf Apple Silicon ist die Kompilierung mit Metal-Backend ein One-Liner, weil das gesamte Toolchain-Setup über Xcode Command Line Tools mitkommt.

Modelle für llama.cpp lädst du am besten direkt von Hugging Face als GGUF-Files. Das GGUF-Format ist der Nachfolger des alten GGML-Formats und enthält Modellgewichte, Tokenizer-Konfiguration und Metadaten in einer einzigen Datei. Beliebte Quellen sind die Repositories von TheBloke (für ältere Quantisierungen), bartowski und mradermacher. Letztere produzieren regelmäßig frische Quantisierungen für neue Modelle, oft schon Stunden nach dem offiziellen Release.

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make GGML_METAL=1   # Mac
# oder make GGML_CUDA=1   # NVIDIA GPU
./llama-cli -m models/llama-3.3-70b-q4_k_m.gguf -p "Erkläre Embeddings"

Wann lohnt sich llama.cpp statt Ollama? Erstens, wenn du eigene Modelle hast (Finetunings, Merges, exotische Architekturen), die nicht im Ollama-Registry stehen. Zweitens, wenn du den HTTP-Server llama-server direkt nutzen willst, der OpenAI-kompatibel ist und mehr Kontrolle über Sampling-Parameter erlaubt. Drittens, wenn du dich für die Quantisierung interessierst und selbst Q5- oder K-Quantisierungen ausprobieren möchtest. Viertens, wenn du Embedded-Setups baust und einen statisch kompilierten Binary brauchst, der ohne Daemon-Prozess läuft. Für 90 Prozent aller Anwender ist Ollama die richtige Wahl, aber wer einmal in die llama.cpp-Welt eintaucht, schätzt die Kontrolle.

Ein wichtiger Vorteil von llama.cpp ist der Server-Modus. Mit llama-server -m model.gguf -c 8192 --host 0.0.0.0 --port 8080 startest du einen HTTP-Endpoint, der OpenAI-kompatibel ist und sich in Custom-Apps integrieren lässt. Über Parameter kannst du Kontextfenster, Temperatur, Top-P, Top-K, Mirostat, Repeat-Penalty und Grammar-Constraints feinjustieren. Letzteres ist mächtig: Du kannst dem Modell ein BNF-Grammar mitgeben, das die Output-Struktur strikt erzwingt (zum Beispiel valides JSON oder eine spezifische DSL). Das spart in vielen Pipelines Code für Output-Parsing.

Quantisierung verstehen

Quantisierung ist der wichtigste Begriff, wenn man lokale Modelle ernsthaft betreiben will, und gleichzeitig der am häufigsten missverstandene. Im Original-Format speichert ein Modell jedes Gewicht als 16-Bit-Floating-Point-Zahl (FP16). Llama 3.3 70B hat 70 Milliarden Gewichte, was bei FP16 rund 140 GB ergibt. Diese Größe passt in keine Consumer-Hardware. Quantisierung reduziert die Bitzahl pro Gewicht und damit die Modellgröße, mit minimalem Qualitätsverlust.

Die Notation Q4, Q5, Q6 bezieht sich auf die durchschnittliche Bitzahl pro Gewicht. Q4 bedeutet 4 Bits, was die Größe gegenüber FP16 viertelt. Q5 sind 5 Bits, Q6 sind 6 Bits, Q8 entspricht praktisch dem Original. Innerhalb dieser Stufen gibt es Subvarianten: Q4_0 ist die einfachste, Q4_K_M ist eine “K-Quantization” mit Mixed-Precision innerhalb des Modells, was in benchmarks deutlich bessere Ergebnisse liefert. Heutzutage ist Q4_K_M der De-facto-Standard für Consumer-Hardware.

Q5_K_M ist näher am Original und in vielen Benchmarks praktisch nicht von FP16 zu unterscheiden, kostet aber rund 25 Prozent mehr RAM. Q6_K und Q8_0 sind nur sinnvoll, wenn du wirklich auf jeden Promille Qualität abzielst, etwa bei Forschungsbenchmarks oder bei sehr fachlichen Texten. Für die allermeisten Anwendungen ist der Unterschied zwischen Q4_K_M und Q6_K unspürbar. Bei Q3_K_M wird es bereits kritisch: Das Modell hat hier sichtbare Schwächen bei längeren Argumentationsketten und mathematischen Aufgaben. Q2 ist nur als letzter Ausweg gedacht, etwa um ein 70B-Modell auf 24 GB RAM zu zwingen.

Eine wichtige Faustregel: Lieber ein kleineres Modell mit höherer Quantisierung als ein großes Modell mit aggressiver Quantisierung. Llama 3.2 11B in Q5_K_M schlägt in vielen Benchmarks Llama 3.3 70B in Q2_K, weil die Q2-Stufe so viel Information vernichtet, dass die Architektur-Vorteile verpuffen. Praktisch heißt das: Wenn du wählen musst zwischen “Llama 3.3 70B Q2 läuft gerade so” und “Llama 3.2 11B Q5 läuft entspannt”, nimm das kleinere Modell. Es wird dich seltener enttäuschen.

Die Perplexity-Metrik ist der wichtigste Indikator für Quantisierungsqualität. Perplexity misst, wie gut das Modell echtes Textcorpus vorhersagt. FP16 dient als Referenz, jede Quantisierung wird daran gemessen. Q4_K_M liegt typischerweise 1 bis 2 Prozent über FP16, was praktisch nicht spürbar ist. Q5_K_M liegt bei 0,5 Prozent. Q3_K_M liegt bei 5 bis 8 Prozent. Q2_K kann je nach Modell 15 bis 20 Prozent draufschlagen. Wenn du dir unsicher bist, schau auf Hugging Face nach den Perplexity-Werten der jeweiligen GGUF-Datei, viele Quantisierer dokumentieren das.

Eine spannende Entwicklung der letzten Monate sind die Importance-Matrix-Quantisierungen, kurz IQ2, IQ3, IQ4. Diese benutzen ein Datenset, um zu bestimmen, welche Gewichte besonders wichtig sind, und vergeben dort mehr Bits als an unwichtigen Stellen. IQ3_M kann Q4_K_M qualitativ erreichen, während es 25 Prozent kleiner ist. Für Anwender, die ein 70B-Modell auf einem 32-GB-Mac laufen lassen wollen, sind IQ-Quantisierungen oft die Rettung. Sie sind allerdings rechenintensiver in der Erstellung und werden nicht für jedes Modell veröffentlicht.

Performance-Erwartungen

Performance bei lokalen LLMs ist hardwareabhängig, und viele Erwartungen werden hier enttäuscht. Wer von ChatGPT kommt, ist instant-Antworten gewohnt. Lokal läuft das anders, abhängig von Modellgröße und Quantisierung können Wartezeiten von wenigen Sekunden bis zu einer Minute auftreten. Die wichtigste Metrik ist Tokens pro Sekunde (T/s). Ein Wert über 30 fühlt sich beim Lesen flüssig an, 10 bis 20 sind okay zum Mitlesen, unter 5 wird die Erfahrung frustrierend.

Hardware	Modell	Tokens/s
MacBook M3 Pro 18 GB	Llama 3.2 3B Q4	30-50
MacBook M3 Max 64 GB	Llama 3.3 70B Q4	8-12
RTX 4070 12 GB	Llama 3.2 7B Q4	80-120
RTX 4090 24 GB	Llama 3.3 70B Q4 (CPU+GPU)	6-10

Apple Silicon profitiert massiv von Unified Memory. Auf einem M3 Max 64 GB hast du quasi 64 GB schnelles GPU-RAM, was große Modelle erst praktikabel macht. Der Nachteil: Die rohe Compute-Leistung pro Sekunde liegt unter NVIDIA, deshalb sind die Token-Raten bei kleineren Modellen niedriger. Bei großen Modellen, wo Memory-Bandwidth limitiert, schlägt Apple Silicon dafür oft NVIDIA-Setups, die das Modell teilweise in den langsamen System-RAM auslagern müssen.

NVIDIA-GPUs sind das schnellste Setup für Modelle, die komplett in VRAM passen. Eine RTX 4070 mit 12 GB läuft Llama 3.2 7B Q4 mit 100+ Tokens pro Sekunde, was sich anfühlt wie ein Top-Tier-Cloud-Service. Sobald das Modell aber nicht mehr ins VRAM passt und Layer in den System-RAM ausgelagert werden müssen (Offloading), bricht die Performance dramatisch ein, oft auf 5 bis 10 Tokens pro Sekunde. Deshalb ist VRAM-Größe für ernstes lokales Inferencing wichtiger als rohe TFlops. Eine RTX 4090 mit 24 GB schafft Llama 3.3 70B nicht ohne Offloading und sitzt damit in einer unbequemen Lücke.

AMD- und Intel-GPUs sind seit 2025 brauchbar, hängen aber NVIDIA in Reife und Treibern hinterher. Eine Radeon RX 7900 XTX mit 24 GB läuft Llama 3.2 7B Q4 mit etwa 60 bis 80 Tokens pro Sekunde, ist also langsamer als eine RTX 4070. Intel Arc B580 mit 12 GB ist eine spannende Budget-Option, läuft aber primär über Vulkan oder SYCL, was nicht alle Frontends sauber unterstützen.

CPU-Inferencing ist der Worst Case und nur dann sinnvoll, wenn keine GPU verfügbar ist. Auf einem aktuellen Ryzen 7 7700X mit 64 GB DDR5 läuft Llama 3.2 3B Q4 mit etwa 8 bis 12 Tokens pro Sekunde, Llama 3.3 70B Q4 mit etwa 1 bis 2 Tokens pro Sekunde. Letzteres ist zu langsam für interaktive Chats, aber für Batch-Verarbeitung über Nacht (zum Beispiel 1000 Dokumente zusammenfassen) durchaus brauchbar.

Praxis-Beispiel: Deutscher Recherche-Assistent

Ein konkretes Beispiel macht den Wert lokaler Llama-Modelle greifbar. Stell dir vor, du arbeitest in einer mittelständischen Beratungsfirma und brauchst regelmäßig deutschsprachige Recherche-Zusammenfassungen, willst aber keine Mandantendaten an US-Cloudanbieter schicken. Ein lokal laufender Llama 3.3 70B Q4 auf einem Mac Studio M3 Ultra mit 96 GB löst das Problem elegant. Du erstellst dafür ein eigenes Modelfile in Ollama, das System-Prompt, Output-Format und Sampling-Parameter festlegt.

Das Modelfile ist ein einfaches Textfile, das Llama 3.3 als Basis nimmt und mit deinem Custom-Prompt kombiniert. Du kannst es per ollama create recherche-de -f Modelfile aufbauen und anschließend wie ein eigenes Modell ansprechen. Praktisch ist, dass du verschiedene Modelfiles für verschiedene Use-Cases parallel pflegen kannst: einen Recherche-Assistenten, einen E-Mail-Beantworter, einen Code-Reviewer, einen Übersetzer.

FROM llama3.3:70b-q4_K_M

PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1

SYSTEM """Du bist ein deutscher Recherche-Assistent für Unternehmensberatung.
Antworte präzise, faktenbasiert und auf Deutsch.
Strukturiere komplexe Antworten mit Überschriften und Aufzählungen.
Bei Unsicherheit gib das offen zu, statt zu raten.
Quellen oder Annahmen explizit benennen.
Keine Marketing-Floskeln, keine Disclaimer am Anfang oder Ende.
Wenn der Nutzer englisch fragt, übersetze die Frage und antworte auf Deutsch."""

In der Praxis sieht eine Conversation dann so aus: Du fragst, “Welche regulatorischen Anforderungen gelten 2026 für KI-Anwendungen in deutschen Banken?”. Das Modell strukturiert die Antwort entlang BaFin-Anforderungen, MaRisk, EU AI Act und DORA. Es erklärt jeden Punkt in 2 bis 3 Sätzen und schlägt am Ende vor, was du im Detail noch recherchieren solltest. Auf einem M3 Ultra läuft das mit etwa 12 Tokens pro Sekunde, eine vollständige Antwort von 600 Tokens dauert also rund 50 Sekunden. Das ist langsamer als ChatGPT, aber für interne Recherche absolut akzeptabel und vor allem datenschutzkonform.

Spannend wird es, wenn du das Modelfile mit einer lokalen RAG-Pipeline kombinierst. Tools wie AnythingLLM, Open WebUI mit RAG-Plugin oder LlamaIndex erlauben dir, eigene Dokumente (PDFs, Word, Markdown) zu indizieren und im Kontext mitzuschicken. So entsteht ein Recherche-Assistent, der nicht nur generelles Weltwissen hat, sondern auch deine internen Wikis, Verträge, Studien und Reports kennt. Auf einem 64-GB-Setup läuft das Ganze kombiniert mit moderater Performance, und sensible Dokumente verlassen niemals dein Netzwerk.

Ein häufiger Anfängerfehler: Den Temperature-Parameter zu hoch setzen. Für faktenbasierte Recherche willst du eher 0.2 bis 0.4, nicht 0.7 oder höher. Höhere Werte machen das Modell kreativer, aber auch erfindungsfreudiger, was bei Compliance-Themen genau das Gegenteil von hilfreich ist. Der Repeat-Penalty 1.1 verhindert, dass das Modell in Schleifen verfällt, ohne den Stil zu sehr zu verzerren. Bei kreativen Aufgaben (Werbetexte, Storytelling) drehst du Temperature dann hoch, das ist aber ein anderes Modelfile.

Wer das Setup im Team nutzen will, baut den Ollama-Server auf einer dedizierten Workstation auf und konfiguriert ihn so, dass er im Firmennetz erreichbar ist. Der OLLAMA_HOST=0.0.0.0:11434 macht den Server netzwerkweit sichtbar. Mit einer kleinen Open-WebUI-Instanz davor haben fünf bis zehn Mitarbeiter ihren eigenen Llama-Zugang ohne dass jemand Cloud-Zugänge braucht. Das spart pro Person etwa 240 Euro pro Jahr an Cloud-LLM-Abos und lässt Daten lokal.

Häufige Fehler

In der Praxis tauchen immer wieder dieselben Probleme auf. Wer diese Liste vorher liest, spart sich Stunden Frustration und unnötige Reinstallationen.

• Zu großes Modell für die Hardware wählen. Llama 3.3 70B auf einem 16-GB-Mac startet nicht oder swappt so massiv, dass das System unbrauchbar wird. Realistisch bleiben und im Zweifel kleiner anfangen, dann hocharbeiten.

• Q2-Quantisierung benutzen. Sieht auf dem Papier verlockend aus, weil ein 70B-Modell plötzlich auf 24 GB passt, liefert aber Output-Qualität, die schlechter ist als ein 13B-Modell in Q5. Lieber das kleinere Modell mit besserer Quantisierung.

• GPU-Backend nicht aktivieren. Wer llama.cpp ohne METAL oder CUDA kompiliert, läuft im CPU-Fallback und wundert sich über Token-Raten unter 5/s. Vor dem Bauen immer prüfen, dass das richtige Backend-Flag gesetzt ist.

• Kontextfenster-Limit ignorieren. Llama 3.3 unterstützt offiziell 128k Token Kontext, aber dein RAM nicht. Pro 1k Token Kontext kommen je nach Modell 100 bis 500 MB obendrauf. Wer den Kontext auf 32k stellt, sollte sich nicht wundern, wenn das Modell out-of-memory geht.

• Temperature zu hoch lassen. Default ist oft 0.8, was für Faktenarbeit zu kreativ ist. Bei Recherche, Code, Übersetzungen und Zusammenfassungen lieber 0.2 bis 0.4 nutzen.

• Modell direkt für Vector-Embeddings benutzen. Llama ist ein Generative-Modell, kein Embedding-Modell. Wer RAG bauen will, braucht ein dediziertes Embedding-Modell (BGE, GTE, Snowflake-Arctic, Nomic-Embed). Dieselbe Llama-Pipeline für beides zu nutzen ist ein Anti-Pattern.

Nächster Schritt

Wenn du Llama erfolgreich aufgesetzt hast und mehr Möglichkeiten erkunden willst, gibt es drei naheliegende Vertiefungen. Mistral und Mixtral sind die wichtigsten Konkurrenz-Modelle und haben Stärken bei Kürze und Tool-Use, schau dir Mistral lokal installieren an. Wenn du noch unsicher bist, ob deine Hardware ausreicht oder du eine neue Maschine kaufen willst, hilft der Hardware-Guide bei der Entscheidung zwischen Mac, NVIDIA-PC oder spezialisierter Inference-Box. Und wer Llama im Unternehmenseinsatz nutzen möchte, sollte unbedingt den Beitrag Sicherheit und DSGVO lesen, dort geht es um Logging, Netzwerk-Isolation, Audit-Trails und die Frage, wann genau ein lokales Modell DSGVO-konform ist und welche Restrisiken bleiben.