Welches Ollama-Modell? Auswahl nach Hardware und Zweck

Artikel-Übersicht

Die Ollama-Registry enthält hunderte Einträge, relevant ist ein knappes Dutzend. Dieser Artikel bringt die drei Größen zusammen, die zusammengehören und in keiner Übersicht gemeinsam auftauchen: Parameterzahl, Quantisierungsstufe und verfügbarer Speicher. Er beginnt mit der kurzen Antwort — drei konkreten Empfehlungen nach Speicherklasse, für alle, die nur diesen Abschnitt lesen wollen. Danach kommt die Faustformel für den Speicherbedarf, die Erklärung, was passiert, wenn ein Modell nicht passt, und eine knappe Einordnung der Quantisierungsstufen. Das Kernstück ist eine Modelltabelle mit Speicherbedarf bei Q4, Kontextfenster, Stärke und Schwäche. Es folgen Empfehlungen nach Anwendungsfall: Code schreiben, deutschsprachige Texte, Embeddings für RAG und Werkzeugaufrufe. Ein eigener Abschnitt sagt, was Ollama nicht kann — Bildgenerierung etwa —, ein weiterer, wie du Speicher zurückgewinnst. Zum Schluss die ehrliche Grenze: ab wann lokal nicht mehr reicht.

Wenn du Ollama noch nicht installiert hast, findest du den Weg dorthin in Ollama installieren: macOS, Linux, Windows und Docker. Was Ollama überhaupt ist, steht im Überblicksartikel.

Die kurze Antwort

Für 8 GB verfügbaren Speicher: ein Modell der 7- bis 8-Milliarden-Klasse in Q4, etwa Llama 3.1 8B oder Qwen 3 in vergleichbarer Größe. Das ist die Untergrenze für ernsthafte Nutzung.

Für 16 GB: dieselbe Klasse, aber mit längerem Kontext und höherer Quantisierungsqualität — oder ein Modell der 12- bis 14-Milliarden-Klasse. Der Sprung in der Antwortqualität ist spürbar.

Für 24 GB und mehr: Modelle bis etwa 32 Milliarden Parameter. Ab hier wird der Abstand zu kleineren gehosteten Modellen deutlich kleiner.

Für 64 GB und mehr: die 70-Milliarden-Klasse. Das ist Serverhardware oder ein gut ausgestatteter Mac, und es ist die erste Größenordnung, in der lokale Modelle mit gehosteten Angeboten ernsthaft konkurrieren.

Und die Empfehlung, die quer dazu steht: Nimm nicht das größte Modell, das gerade noch lädt. Ein kleineres Modell, das flüssig antwortet, ist im Alltag fast immer nützlicher als ein größeres, das an der Speichergrenze kratzt und bei jeder längeren Eingabe auf den Prozessor zurückfällt.

Die eine Zahl, auf die es ankommt

Nicht die Rechenleistung entscheidet, sondern der Speicher, auf den der Rechenbeschleuniger direkt zugreifen kann. Bei einer NVIDIA-Karte ist das der Videospeicher, bei Apple Silicon der gemeinsame Arbeitsspeicher.

Die Faustformel für Q4-quantisierte Modelle:

Speicherbedarf ≈ Parameter in Milliarden × 0,55 GB + Kontextanteil

Ein 8-Milliarden-Modell braucht demnach rund 4,5 GB für die Gewichte. Mit einem Kontextfenster von 8.000 Token landet man bei etwa 6 GB, mit 32.000 Token deutlich darüber. Ein 70-Milliarden-Modell liegt bei rund 40 GB — plus Kontext.

Der Kontextanteil wird regelmäßig unterschätzt. Der Zwischenspeicher für die Aufmerksamkeitsberechnung wächst linear mit der Kontextlänge, und bei großen Fenstern kann er den Bedarf der Gewichte erreichen. Wer den Kontext auf das Maximum stellt, das ein Modell könnte, hat oft weniger davon als gedacht. Die Zusammenhänge stehen im Artikel über das Kontextfenster bei LLMs.

Zur Orientierung, was in welche Speicherklasse passt:

Verfügbarer Speicher	Sinnvolle Modellgröße bei Q4	Kontext realistisch
8 GB	7–8 Mrd.	4.000–8.000 Token
12 GB	8–12 Mrd.	8.000–16.000 Token
16 GB	12–14 Mrd.	8.000–32.000 Token
24 GB	24–32 Mrd.	16.000–32.000 Token
48 GB	32–70 Mrd. (stark quantisiert)	32.000+
64 GB+	70 Mrd.	32.000+

Was passiert, wenn das Modell nicht passt

Ollama bricht nicht ab, sondern verteilt: Ein Teil der Modellschichten liegt im Grafikspeicher, der Rest im Hauptspeicher, und der Prozessor rechnet mit. Das ist ein sinnvolles Verhalten — es fühlt sich nur an wie ein Defekt, weil die Ausgabegeschwindigkeit um den Faktor zehn bis dreißig einbricht.

Erkennen kannst du es an der Ausgabe von ollama ps, die anzeigt, wie das Modell aufgeteilt ist. Wer plötzlich zäh gewordene Antworten bemerkt, ohne etwas am Modell geändert zu haben, hat meist den Kontext hochgesetzt.

Quantisierung in drei Sätzen

Quantisierung reduziert die Genauigkeit, mit der die Modellgewichte gespeichert werden — statt 16 Bit je Parameter sind es bei Q4 etwa vier bis fünf. Das schrumpft den Speicherbedarf auf ungefähr ein Viertel, kostet aber ein wenig Qualität. Q4_K_M ist der Standardkompromiss und für die meisten Zwecke die richtige Wahl; Q8 lohnt, wenn Speicher übrig ist, Q2 selten.

Mehr braucht es für die Modellauswahl nicht. Wie die Verfahren im Einzelnen arbeiten, worin sich GGUF, GPTQ und AWQ unterscheiden und wann welche Stufe messbar schadet, steht vollständig im Artikel über LLM-Quantisierung.

Die Modelltabelle

Modell	Parameter	Speicher bei Q4	Kontext	Stärke	Schwäche
Llama 3.x	8 Mrd.	~5 GB	mittel	solider Allrounder, breites Ökosystem	auf Deutsch schwächer als auf Englisch
Llama 3.x	70 Mrd.	~40 GB	mittel	deutlich stärker, nahe an kleinen Cloud-Modellen	Serverhardware nötig
Qwen 3	4–8 Mrd.	3–5 GB	lang	stark mehrsprachig, gutes Deutsch	Prompt-Vorlage beachten
Qwen 3	14–32 Mrd.	9–20 GB	lang	bestes Verhältnis in der Mittelklasse	braucht 16–24 GB
Gemma	4 Mrd.	~3 GB	mittel	gute Qualität je Parameter	begrenzte Tiefe
Gemma	27 Mrd.	~17 GB	mittel	starker Allrounder	Speicherbedarf
Mistral	7 Mrd.	~4,5 GB	mittel	schnell, sehr genügsam	älter als die Konkurrenz
Coder-Modell (z. B. Qwen-Coder)	7–32 Mrd.	5–20 GB	lang	Codeergänzung und -erklärung	schwächer im Fließtext
Vision-Modell	7–12 Mrd.	6–9 GB	mittel	liest Bilder, Formulare, Tabellen	langsamer, Bildvorverarbeitung
`nomic-embed-text`	klein	< 1 GB	—	Embeddings für Suche und RAG	erzeugt keine Texte
Kleinstmodell (1–3 Mrd.)	1–3 Mrd.	1–2,5 GB	kurz	läuft auf schwacher Hardware	spürbar begrenzt

Stand 09/2026. Modellnamen, Versionsbezeichnungen und verfügbare Größen ändern sich im Quartalstakt — prüfe die Registry, bevor du dich festlegst. Die Speicherangaben sind Näherungen für Q4 ohne großzügigen Kontext.

Die Modelle bekommst du mit:

ollama pull qwen3
ollama pull nomic-embed-text

Empfehlung nach Anwendungsfall

Code schreiben und erklären

Ein spezialisiertes Coder-Modell schlägt einen gleich großen Allrounder bei Codeaufgaben deutlich. Der Unterschied zeigt sich weniger beim Erzeugen kleiner Funktionen — das können beide — als beim Verstehen längerer Zusammenhänge und beim Einhalten von Konventionen.

Unter 7 Milliarden Parametern wird es schwierig: Die Vorschläge werden syntaktisch korrekt, aber inhaltlich beliebig. Ab 14 Milliarden ist der Nutzen im Alltag spürbar.

Deutschsprachige Texte

Hier lohnt eine ehrliche Aussage, die englischsprachige Vergleiche nie treffen: Die meisten Modelle sind auf Deutsch messbar schwächer als auf Englisch. Das betrifft nicht nur die Formulierung, sondern auch das Faktenwissen — deutschsprachige Trainingsdaten sind schlicht seltener.

Praktisch heißt das: Modelle mit ausdrücklich mehrsprachigem Training schneiden auf Deutsch besser ab als reine englische Modelle derselben Größe. Und für hochwertige deutsche Texte braucht es eher eine Klasse mehr, als man für Englisch veranschlagen würde. Wer ein 8-Milliarden-Modell für englische Zusammenfassungen gut findet, sollte für deutsche 14 Milliarden aufwärts testen.

Ein zweiter Punkt, der oft übersehen wird: Manche Modelle antworten auf deutsche Eingaben zuverlässiger, wenn die Systemanweisung ebenfalls deutsch formuliert ist. Das ist keine Regel, aber ein billiger Test.

Embeddings für RAG

Embedding-Modelle erzeugen keine Antworten, sondern Vektoren. Sie sind die Grundlage semantischer Suche und damit von Retrieval-Augmented Generation.

Wichtig ist die Trennung: Du brauchst zwei Modelle — eines für die Einbettung, eines für die Antwort. Beide laufen parallel in Ollama, das Embedding-Modell ist mit unter einem Gigabyte klein genug, dass es kaum ins Gewicht fällt.

Wie Embeddings funktionieren, steht in Embeddings verständlich erklärt; welche Datenbank dazu passt, im Vektordatenbanken-Vergleich.

Ein Hinweis, der später teuer wird, wenn man ihn übergeht: Ein Wechsel des Embedding-Modells erzwingt eine Neuberechnung des gesamten Bestands. Die Vektoren verschiedener Modelle sind nicht vergleichbar. Diese Entscheidung bindet stärker als die Wahl der Datenbank.

Werkzeugaufrufe und strukturierte Ausgaben

Nicht jedes Modell beherrscht Tool Calling zuverlässig. Kleinere Modelle erzeugen Aufrufe in falschem Format oder erfinden Parameter — was in einem Dialog auffällt, in einem automatisierten Ablauf aber stillschweigend zu falschen Ergebnissen führt.

Wenn du auf verlässliche Werkzeugaufrufe angewiesen bist, brauchst du ein Modell mit ausgewiesener Unterstützung und mindestens 14 Milliarden Parametern. Für erzwungene JSON-Ausgaben ist die Lage entspannter, weil Ollama ein Schema durchsetzen kann; die Details stehen in Structured Output und JSON-Mode bei LLMs.

Was Ollama nicht kann

Bilder erzeugen. Danach wird regelmäßig gesucht, und die Antwort ist ein klares Nein. Ollama führt Sprachmodelle aus; Bildgenerierung braucht Diffusionsmodelle und eine andere Laufzeitumgebung. Vision-Modelle in Ollama können Bilder lesen, nicht erzeugen.

Mehrere Nutzer gleichzeitig gut bedienen. Ollama verarbeitet Anfragen im Wesentlichen nacheinander. Für einen Dienst mit mehreren Nutzern ist vLLM das richtige Werkzeug.

Modelle zur Laufzeit anpassen. Ein Modelfile kann Systemprompt und Parameter setzen, aber nicht die Gewichte ändern. Wer ein Modell auf eigene Daten anpassen will, braucht Fine-Tuning und lädt das Ergebnis anschließend in Ollama.

Wie schnell ist das eigentlich?

Die Speicherfrage entscheidet, ob ein Modell läuft. Wie es sich anfühlt, entscheidet die Ausgabegeschwindigkeit, gemessen in Token pro Sekunde. Als grobe Orientierung: Etwa 20 Token pro Sekunde entsprechen ungefähr flüssiger Lesegeschwindigkeit. Darunter wartet man sichtbar, darüber ist die Ausgabe schneller, als man liest.

Drei Faktoren bestimmen den Wert:

Die Speicherbandbreite des Beschleunigers, nicht seine Rechenleistung. Sprachmodelle sind bei der Textausgabe fast durchgängig durch den Speicherzugriff begrenzt.
Die Modellgröße. Doppelt so viele Parameter heißt grob halb so schnell.
Ob das Modell vollständig im Grafikspeicher liegt. Fällt ein Teil auf den Prozessor zurück, bricht der Wert um eine Größenordnung ein.

Messen kannst du das selbst — Ollama gibt die Werte nach jeder Antwort aus:

ollama run llama3.1 --verbose

Die Ausgabe nennt unter anderem eval rate in Token pro Sekunde. Wer zwei Modelle vergleichen will, stellt beiden dieselbe Frage und schaut auf diesen Wert.

Modelle verwalten: Speicher zurückgewinnen

Nach einigen Wochen Ausprobieren belegt der Modellordner zweistellige Gigabytebeträge. Die Übersicht:

ollama list

Entfernen:

ollama rm gemma:27b

Ein Detail, das überrascht: Modelle können sich Ebenen teilen. Das Löschen eines Modells gibt deshalb nicht immer den vollen erwarteten Platz frei, weil Teile davon noch von einem anderen benutzt werden. Wer wirklich aufräumen will, entfernt alle nicht genutzten Modelle und prüft anschließend die Ordnergröße.

Wann lokal nicht mehr reicht

Drei Grenzen, an denen der Wechsel zu einem gehosteten Modell die richtige Entscheidung ist:

Die Modellklasse. Was auf einem Arbeitsplatzrechner läuft, ist nicht das, was in einem Rechenzentrum läuft. Bei Aufgaben, die mehrschrittiges Schließen verlangen — komplexe Analysen, längere Herleitungen —, ist der Unterschied deutlich. Was Reasoning-Modelle dabei anders machen, steht in Reasoning-Modelle erklärt.

Der Durchsatz. Ab wenigen gleichzeitigen Nutzern wird Ollama zum Engpass.

Die Kontextlänge. Sehr lange Dokumente vollständig in den Kontext zu legen, ist lokal eine Speicherfrage, die schnell unbeantwortbar wird. Meist ist RAG ohnehin die bessere Lösung als ein immer längerer Kontext.

Wer an diesen Punkten steht, findet die Alternativen im Vergleich der führenden LLM-Anbieter — und eine Übersicht darüber, was der Betrieb kostet, in LLM-Kosten optimieren.

Häufige Fragen

Welches ist das beste Ollama-Modell? Es gibt keines. Für 8 GB Speicher ist ein 7- bis 8-Milliarden-Modell richtig, für 24 GB eines mit 24 bis 32 Milliarden. Für Code lohnt ein spezialisiertes Coder-Modell, für deutsche Texte eher eine Klasse größer als für englische.

Welche Hardware brauche ich für Ollama? Rechne mit etwa 0,55 GB Speicher je Milliarde Parameter bei Q4-Quantisierung, plus Reserve für den Kontext. Apple Silicon ist im Vorteil, weil der Speicher zwischen Prozessor und Grafikeinheit geteilt wird.

Wie viel VRAM braucht ein 8B-Modell? Rund 5 GB für die Gewichte in Q4. Mit einem Kontextfenster von 8.000 Token sind etwa 6 GB realistisch.

Was bedeutet Q4 bei einem Modellnamen? Die Quantisierungsstufe — die Genauigkeit, mit der die Gewichte gespeichert sind. Q4 belegt ungefähr ein Viertel des Speichers gegenüber der vollen Genauigkeit und ist für die meisten Zwecke der richtige Kompromiss.

Warum ist mein Modell so langsam? Meist passt es nicht vollständig in den Grafikspeicher und ein Teil der Berechnung läuft auf dem Prozessor. ollama ps zeigt die Aufteilung.

Kann Ollama Bilder erzeugen? Nein. Vision-Modelle können Bilder lesen und beschreiben, aber keine erzeugen.

Zusammenfassung und praktische Tipps

Speicher entscheidet, nicht Rechenleistung. Faustformel: Parameter in Milliarden × 0,55 GB bei Q4, plus Kontextanteil.
Ein flüssiges kleineres Modell schlägt ein stockendes großes. Wer an der Speichergrenze arbeitet, verliert mehr, als er gewinnt.
Q4_K_M ist der Standardkompromiss — alles Weitere zur Quantisierung im eigenen Artikel.
Für deutsche Texte eine Klasse größer rechnen als für englische.
Embeddings brauchen ein eigenes, kleines Modell — und ein späterer Wechsel erzwingt die Neuberechnung des gesamten Bestands.
Werkzeugaufrufe brauchen Größe. Unter 14 Milliarden Parametern ist die Zuverlässigkeit für Automatisierung zu gering.

Mein Rat: Rechne einmal aus, wie viel Speicher dir tatsächlich zur Verfügung steht, und nimm dann das größte Modell, das mit dem Kontext, den du wirklich brauchst, noch vollständig hineinpasst. Diese eine Rechnung erspart dir mehr Frust als jeder Modellvergleich — denn ein Modell, das zur Hälfte auf dem Prozessor läuft, fühlt sich defekt an, ohne es zu sein.

Ressourcen

Ollama – Modellbibliothek – alle Modelle mit Größen, Tags und Kontextfenstern
Hugging Face – GGUF-Modelle – Quelle für Modelle außerhalb der Registry
Ollama – Modelfile-Referenz – eigene Modellvarianten bauen