Ollama: lokale Sprachmodelle auf dem eigenen Rechner betreiben

Artikel-Übersicht

In diesem Leitfaden bekommst du ein vollständiges Bild davon, was Ollama ist und wofür es sich lohnt. Wir starten mit der Einordnung: Ollama ist keine KI, sondern eine Laufzeitumgebung, die Sprachmodelle lokal lädt und über eine HTTP-Schnittstelle bereitstellt — das Verhältnis ist ungefähr das von Docker zu einer Anwendung. Danach schauen wir uns an, wie das technisch funktioniert: Modelldateien im GGUF-Format, eine Registry, ein lokaler Server auf Port 11434. Du bekommst die Installation in Kurzform für macOS, Linux, Windows und Docker, eine Modelltabelle, die Parameterzahl, Quantisierungsstufe und Speicherbedarf zusammenbringt, und eine belastbare Faustregel für die Hardwarefrage. Ein eigener Abschnitt gilt der API, weil dort der eigentliche Nutzen liegt: der OpenAI-kompatible Endpunkt, die Frage nach dem API-Schlüssel und die Anbindung an Entwicklungswerkzeuge wie Claude Code. Dazu kommen die grafischen Oberflächen, ein ehrlicher Vergleich mit LM Studio, llama.cpp und vLLM, der Betriebsalltag mit Aktualisierungen und Speicherverwaltung — und zum Schluss die Grenzen: Kontextlänge, Durchsatz bei parallelen Anfragen und der Punkt, an dem Ollama das falsche Werkzeug ist.

Warum lokal?

Die meisten Menschen begegnen Sprachmodellen über eine Webseite oder eine API in der Cloud. Das funktioniert gut, ist bequem und für viele Anwendungsfälle die richtige Wahl. Trotzdem gibt es vier Gründe, ein Modell auf der eigenen Maschine laufen zu lassen.

Der erste ist Datenschutz. Was du lokal eingibst, verlässt den Rechner nicht. Für Verträge, Personalunterlagen, Quellcode unter Verschwiegenheitspflicht oder Patientendaten ist das kein weiches Argument, sondern häufig die Bedingung dafür, dass ein Sprachmodell überhaupt eingesetzt werden darf. In der Schweiz kommt hinzu, dass mit dem revidierten Datenschutzgesetz eine eigene Rechtslage gilt und „die Daten verlassen das Haus nicht" gegenüber Kunden und Aufsicht das stärkste Argument ist, das man haben kann. In Deutschland und Österreich greift die DSGVO mit denselben praktischen Folgen: Wer personenbezogene Daten in ein gehostetes Modell gibt, braucht dafür eine Grundlage und einen Vertrag zur Auftragsverarbeitung. Lokal entfällt beides.

Der zweite ist Kostenberechenbarkeit. Ein lokales Modell kostet Strom und einmalig Hardware, aber nichts pro Anfrage. Wer Modelle in Schleifen aufruft — für Klassifikation über tausende Datensätze, für automatisierte Codeanalyse, für Experimente — merkt den Unterschied schnell.

Der dritte ist Unabhängigkeit. Ein Modell, das lokal liegt, wird nicht abgeschaltet, nicht verteuert und nicht ohne Vorwarnung durch eine neue Version ersetzt, die sich anders verhält. Für reproduzierbare Auswertungen ist das ein handfester Vorteil.

Der vierte ist schlicht Neugier. Man versteht Sprachmodelle deutlich besser, wenn man einmal gesehen hat, wie viel Speicher ein Modell mit acht Milliarden Parametern tatsächlich belegt und wie sich die Antwortgeschwindigkeit ändert, wenn man von der Grafikkarte auf den Prozessor zurückfällt.

Und der ehrliche Gegenpunkt gleich hinterher: Ein Modell, das auf deinem Laptop läuft, ist nicht so gut wie die größten gehosteten Modelle. Es ist kleiner, es hat ein kürzeres Kontextfenster, und es antwortet langsamer. Für viele Aufgaben reicht das trotzdem — aber wer erwartet, dass ein 8-Milliarden-Modell auf einem Notebook dieselben Ergebnisse liefert wie ein Spitzenmodell aus der Cloud, wird enttäuscht. Einen Überblick über die gehosteten Anbieter findest du im Vergleich der führenden LLM-Anbieter.

Was ist Ollama?

Ollama ist eine Laufzeitumgebung, die Sprachmodelle lokal auf dem eigenen Rechner ausführt und sie über eine HTTP-API bereitstellt. Es ist selbst kein Modell, sondern der Betreiber davon.

Diese Unterscheidung klingt pedantisch, ist aber der häufigste Grund für Missverständnisse. Wer fragt „wie gut ist Ollama", stellt dieselbe Frage wie „wie gut ist Docker" — die Antwort hängt davon ab, was man hineinlädt. Ollama kümmert sich um vier Dinge: Es lädt Modelle aus einer Registry herunter, hält sie im Speicher, führt die Berechnung aus und beantwortet Anfragen über eine Schnittstelle. Welche Qualität dabei herauskommt, entscheidet das Modell.

Der praktische Nutzen liegt in der Bequemlichkeit. Vor Ollama bedeutete „ein Sprachmodell lokal ausführen": das passende Format finden, eine Inferenz-Bibliothek übersetzen, Speicheraufteilung zwischen Grafikkarte und Hauptspeicher konfigurieren, einen Server drumherum bauen. Ollama macht daraus einen Befehl.

ollama run llama3.1

Das lädt das Modell beim ersten Aufruf herunter, startet es und öffnet einen Dialog. Alles Weitere — Quantisierungsformat, Speicheraufteilung, Vorlage für den Prompt — steckt in einer Konfiguration, die mit dem Modell mitgeliefert wird.

Wie Ollama funktioniert

Unter der Oberfläche besteht Ollama aus drei Teilen, und wer sie kennt, versteht die meisten Fehlermeldungen von selbst.

Die Modelldateien liegen im GGUF-Format vor. GGUF ist ein Containerformat, das die Modellgewichte zusammen mit den nötigen Metadaten in einer einzigen Datei bündelt — Tokenizer, Architekturparameter, Prompt-Vorlage. Entscheidend ist, dass die Gewichte darin quantisiert sind, also mit reduzierter Genauigkeit gespeichert. Statt 16 Bit je Parameter sind es typischerweise vier oder fünf. Genau deshalb passt ein Modell mit acht Milliarden Parametern in etwa fünf Gigabyte statt in sechzehn. Was hinter den Bezeichnungen wie Q4_K_M steckt und welche Stufe wann sinnvoll ist, habe ich in einem eigenen Artikel über LLM-Quantisierung mit GGUF, GPTQ und AWQ ausführlich beschrieben.

Das Modelfile ist die Bauanweisung. Es verweist auf eine GGUF-Datei und ergänzt sie um Parameter: Systemprompt, Temperatur, Kontextlänge, Stoppzeichen. Wer ein Modell anpassen will, ohne es neu zu trainieren, schreibt ein eigenes Modelfile — das ist der leichteste Eingriff, den Ollama erlaubt.

Der Server läuft im Hintergrund und lauscht standardmäßig auf Port 11434. Jeder Befehl, den du im Terminal eingibst, ist in Wahrheit ein HTTP-Aufruf an diesen Server. Das ist der Grund, warum du Ollama auch aus einem Programm heraus ansprechen kannst, ohne etwas Zusätzliches zu installieren — und warum ein Ollama, das auf 0.0.0.0 lauscht, ohne weitere Absicherung im Netz erreichbar ist. Dazu später mehr.

Der Ablauf einer Anfrage sieht damit so aus: Dein Client schickt eine HTTP-Anfrage an Port 11434. Der Server prüft, ob das angeforderte Modell bereits im Speicher liegt. Ist es nicht geladen, lädt er es — das dauert je nach Modellgröße und Datenträger einige Sekunden. Dann berechnet er die Antwort und streamt sie zurück. Nach einer konfigurierbaren Leerlaufzeit gibt er den Speicher wieder frei.

Installation in Kurzform

Ollama läuft auf macOS, Linux und Windows sowie in einem Container. Hier die Kurzfassung; die ausführliche Anleitung mit GPU-Durchreichung, systemd-Einbindung und Fehlerbehandlung folgt in einem eigenen Artikel.

macOS — entweder die Installer-App von der Projektseite oder über Homebrew:

brew install ollama

Linux — das offizielle Installationsskript legt einen systemd-Dienst und einen eigenen Benutzer an:

curl -fsSL https://ollama.com/install.sh | sh

Wer kein Skript aus dem Netz in eine Shell leiten möchte — ein berechtigter Einwand —, kann das Binärpaket auch manuell entpacken und den Dienst selbst einrichten.

Windows — nativer Installer von der Projektseite. Alternativ läuft Ollama unter WSL2 wie unter Linux; das ist der Weg, wenn du ohnehin in einer Linux-Umgebung entwickelst.

Docker — der Weg, den ich für Server empfehle, weil er den Rest des Systems sauber lässt:

services:
  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped

volumes:
  ollama:

Das Volume ist nicht optional. Ohne es liegen die heruntergeladenen Modelle im Container, und nach jedem Neustart lädst du zweistellige Gigabytebeträge erneut. Für die Nutzung einer NVIDIA-Grafikkarte im Container brauchst du zusätzlich das NVIDIA Container Toolkit auf dem Wirtssystem.

Ob es läuft, prüfst du mit:

ollama list

Welches Modell für welchen Zweck

Die Registry enthält hunderte Einträge. Relevant ist ein knappes Dutzend. Die folgende Tabelle gibt eine Orientierung — die Speicherangaben beziehen sich auf die verbreitete Quantisierungsstufe Q4 und schließen den Bedarf für ein moderates Kontextfenster ein.

Modellfamilie	Parameter	Speicher bei Q4	Stärke	Schwäche
Llama 3.x	8 Mrd.	~6 GB	solider Allrounder, gutes Ökosystem	auf Deutsch schwächer als auf Englisch
Llama 3.x	70 Mrd.	~42 GB	deutlich stärker, nahe an kleineren Cloud-Modellen	braucht Serverhardware
Qwen 3	4–32 Mrd.	3–20 GB	stark bei Code und mehrsprachig	Prompt-Vorlage beachten
Gemma	4–27 Mrd.	3–17 GB	gute Qualität je Parameter	teils kürzeres Kontextfenster
Mistral / Mixtral	7 Mrd. / MoE	5 GB / ~26 GB	schnell, MoE-Variante sehr leistungsfähig	MoE braucht viel Speicher
Coder-Modelle (z. B. Qwen-Coder)	7–32 Mrd.	5–20 GB	Codeergänzung und -erklärung	schwächer im Fließtext
Vision-Modelle	7–12 Mrd.	6–9 GB	Bilder und Dokumente lesen	langsamer, Bildvorverarbeitung nötig
nomic-embed-text	klein	< 1 GB	Embeddings für Suche und RAG	erzeugt keine Texte
Kleinstmodelle (1–3 Mrd.)	1–3 Mrd.	1–2,5 GB	läuft auf schwacher Hardware	spürbar begrenzt

Stand 09/2026. Modellnamen und Versionsbezeichnungen ändern sich im Quartalstakt — prüfe die aktuelle Registry, bevor du dich festlegst.

Zwei Zeilen verdienen eine Anmerkung. Die Embedding-Modelle erzeugen keine Antworten, sondern Vektoren; sie sind der Baustein für semantische Suche und für Retrieval-Augmented Generation. Wie das genau funktioniert, steht im Artikel über Embeddings und die Auswahl der passenden Datenbank im Vektordatenbanken-Vergleich. Und die Vision-Modelle sind der Grund, warum lokale Dokumentverarbeitung inzwischen realistisch ist — sie lesen Formulare und Tabellen deutlich besser als klassische Texterkennung. Für Sprache statt Bild gilt dasselbe Prinzip; wie eine vollständige Sprachpipeline aufgebaut ist, steht in Voice-Agent selbst bauen: Whisper, LLM und TTS.

Wer ein Modell nicht nur nutzen, sondern auf eigene Daten anpassen will, findet den Weg dorthin im Artikel über Fine-Tuning mit Python und Ollama.

Was an Hardware nötig ist

Die bestimmende Größe ist Speicher, nicht Rechenleistung. Genauer: der Speicher, auf den der Rechenbeschleuniger direkt zugreifen kann.

Die Faustregel für Q4-quantisierte Modelle lautet: etwa 0,55 GB je Milliarde Parameter, plus Speicher für den Kontext. Ein 8-Milliarden-Modell braucht also rund 4,5 GB für die Gewichte; mit einem Kontextfenster von 8.000 Token landet man bei etwa 6 GB. Für ein 70-Milliarden-Modell sind es rund 40 GB — das ist keine Notebook-Größenordnung mehr.

Der Kontextanteil wird regelmäßig unterschätzt. Der sogenannte KV-Cache wächst linear mit der Kontextlänge, und bei großen Kontextfenstern kann er den Speicherbedarf der Gewichte erreichen oder übersteigen. Warum lange Kontexte teuer sind und was man dagegen tut, habe ich im Artikel über das Kontextfenster beschrieben.

Bei den Geräteklassen gilt grob:

• Apple Silicon ist für lokale Modelle ungewöhnlich gut geeignet, weil Prozessor und Grafikeinheit sich denselben Speicher teilen. Ein Mac mit 32 GB kann Modelle ausführen, für die auf einem PC eine Grafikkarte mit 24 GB nötig wäre.
• NVIDIA-Grafikkarten sind die schnellste Option, aber der Videospeicher ist die harte Grenze. Passt das Modell nicht hinein, verlagert Ollama Schichten in den Hauptspeicher — und die Geschwindigkeit bricht um den Faktor zehn bis dreißig ein.
• Nur Prozessor funktioniert, ist aber für interaktive Nutzung meist zu langsam. Für Stapelverarbeitung im Hintergrund kann es trotzdem reichen.

Der wichtigste praktische Rat: Nimm nicht das größte Modell, das gerade noch lädt. Ein kleineres Modell mit höherer Quantisierungsqualität und schneller Antwort ist im Alltag fast immer die bessere Wahl als ein größeres, das an der Speichergrenze kratzt.

Die API: Ollama als lokaler Dienst

Hier liegt der eigentliche Nutzen, und hier hört die Hersteller-Dokumentation meist auf.

Ollama stellt zwei native Endpunkte bereit. /api/generate nimmt einen einzelnen Prompt entgegen, /api/chat eine Nachrichtenfolge mit Rollen. Beide streamen die Antwort standardmäßig zurück.

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "Erkläre Quantisierung in zwei Sätzen."}],
  "stream": false
}'

Wichtiger ist für die meisten Vorhaben der OpenAI-kompatible Endpunkt unter /v1. Er bildet die verbreitete Schnittstelle nach, sodass Bibliotheken und Werkzeuge, die für gehostete Modelle geschrieben wurden, ohne Änderung mit Ollama sprechen können:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # wird nicht geprüft, darf aber nicht leer sein
)

antwort = client.chat.completions.create(
    model="llama3.1",
    messages=[{"role": "user", "content": "Was ist ein Bounded Context?"}],
)
print(antwort.choices[0].message.content)

Das führt direkt zur häufigsten Frage: Ollama braucht keinen API-Schlüssel. Die Bibliotheken verlangen oft, dass das Feld gesetzt ist, aber der Wert wird nicht geprüft. Das ist bequem — und es ist genau die Stelle, an der man aufpassen muss. Wer Ollama an eine Netzwerkadresse bindet, die von außen erreichbar ist, stellt einen unauthentifizierten Dienst ins Netz. Für den Betrieb auf einem Server gehört ein vorgelagerter Reverse Proxy mit Authentifizierung davor, oder die Bindung bleibt auf 127.0.0.1 beschränkt.

Wenn du strukturierte Ausgaben brauchst — JSON statt Fließtext —, unterstützt Ollama Schemazwang. Die Details dazu und warum das für automatisierte Weiterverarbeitung entscheidend ist, stehen im Artikel über Structured Output und JSON-Mode.

Ollama mit Entwicklungswerkzeugen verbinden

Ein Anwendungsfall, nach dem auffällig oft gesucht wird und für den es wenig Brauchbares gibt: ein Coding-Werkzeug auf ein lokales Modell umbiegen.

Die meisten Assistenten erwarten eine OpenAI-kompatible Schnittstelle. Damit reicht in der Regel, zwei Umgebungsvariablen zu setzen — die Basis-URL auf den lokalen Ollama-Endpunkt und einen beliebigen Platzhalter als Schlüssel:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

Ob das im Einzelfall funktioniert, hängt an zwei Bedingungen. Erstens muss das Werkzeug tatsächlich über den kompatiblen Endpunkt sprechen und nicht über eine anbietereigene Schnittstelle. Zweitens — und das ist die härtere Hürde — muss das lokale Modell Werkzeugaufrufe zuverlässig beherrschen. Agentische Assistenten arbeiten damit ununterbrochen: Datei lesen, Suche ausführen, Ergebnis bewerten. Kleinere Modelle scheitern hier reproduzierbar, indem sie Aufrufe in falschem Format erzeugen oder Parameter erfinden.

Meine ehrliche Einschätzung nach einigen Anläufen: Für Codeergänzung und Erklärungen funktionieren lokale Modelle gut. Für vollständig agentisches Arbeiten über mehrere Schritte hinweg reichen sie in der Größenordnung, die auf einem Arbeitsplatzrechner läuft, meist noch nicht. Wer es versuchen will, nimmt ein Modell mit ausgewiesener Tool-Calling-Unterstützung und mindestens 14 Milliarden Parametern.

Oberflächen

Ollama selbst bringt keine grafische Oberfläche mit. Für den Alltag lohnt sich eine, besonders wenn mehrere Personen darauf zugreifen sollen.

Open WebUI ist die verbreitetste Wahl und funktioniert wie eine selbst gehostete Chat-Oberfläche: Modellauswahl, Gesprächsverlauf, Benutzerverwaltung, Dokumenten-Upload. Wie du beides zusammen aufsetzt, habe ich in Lokale ChatGPT-Alternative mit Open WebUI und Ollama beschrieben.

Daneben gibt es schlankere Alternativen — Desktop-Anwendungen, die sich direkt mit dem lokalen Server verbinden, und Erweiterungen für Entwicklungsumgebungen. Welche passt, hängt davon ab, ob du eine Einzelplatzlösung oder einen gemeinsamen Dienst brauchst.

Ollama, LM Studio oder vLLM?

Die drei Werkzeuge lösen ähnliche, aber nicht dieselben Probleme.

Werkzeug	Zielgruppe	Oberfläche	API	Mehrbenutzer	Wofür geeignet
Ollama	Entwickler, Einzelplatz	nein (extern)	ja, auch OpenAI-kompatibel	eingeschränkt	Entwicklung, Experimente, kleine Dienste
LM Studio	Einsteiger	ja, eingebaut	ja	nein	Ausprobieren ohne Terminal
llama.cpp	Bastler, Systemnähe	nein	rudimentär	nein	maximale Kontrolle, exotische Hardware
vLLM	Betrieb	nein	ja	ja, ausgelegt darauf	produktiver Mehrbenutzerbetrieb
Jan	Einzelplatz	ja	ja	nein	Desktop-Nutzung mit Datenschutzfokus

Die wichtigste Aussage dieser Tabelle ist die letzte Spalte der vorletzten Zeile: vLLM ist die richtige Wahl, sobald mehrere Nutzer gleichzeitig anfragen. Ollama ist ein Einzelplatzwerkzeug mit Server-Anstrich. Es verarbeitet Anfragen im Wesentlichen nacheinander; vLLM bündelt sie und hält den Beschleuniger dadurch deutlich besser ausgelastet. Wer einen internen Dienst für ein Team baut, sollte den Wechsel früh einplanen statt Ollama in eine Rolle zu drängen, für die es nicht gebaut ist.

Für alles davor — Entwicklung, Prototypen, persönliche Nutzung, einzelne Hintergrundprozesse — ist Ollama die pragmatischere Wahl, weil es weniger Konfiguration verlangt und Modelle bequemer verwaltet.

Betrieb im Alltag

Vier Dinge, die nach der ersten Woche relevant werden.

Modelle aktualisieren. Ein erneutes ollama pull holt eine neuere Fassung, falls vorhanden. Das ist keine Kleinigkeit: Modelle werden nachgeschärft, und die Ausgabe kann sich zwischen zwei Fassungen desselben Namens ändern. Wenn du auf reproduzierbare Ergebnisse angewiesen bist, notiere dir den Digest.

Speicher zurückgewinnen. Modelle summieren sich schnell auf zweistellige Gigabytebeträge. ollama list zeigt, was liegt, ollama rm <modell> entfernt es. Ein Hinweis, der überrascht: Weil sich Modelle Ebenen teilen können, gibt das Löschen eines einzelnen Modells nicht immer den vollen erwarteten Platz frei.

Ollama aktualisieren. Die Laufzeitumgebung selbst entwickelt sich schnell. Neue Fassungen bringen Unterstützung für neue Modellarchitekturen — wenn ein frisch veröffentlichtes Modell nicht lädt, ist eine veraltete Ollama-Version die häufigste Ursache.

Modelle im Speicher halten. Standardmäßig gibt Ollama den Speicher nach einigen Minuten Leerlauf frei. Für einen Dienst, der sporadisch angefragt wird, bedeutet das bei jeder Anfrage eine Ladeverzögerung. Über einen Parameter lässt sich die Haltezeit verlängern.

Wo Ollama an Grenzen stößt

Diesen Abschnitt halte ich bewusst nüchtern, weil er in den meisten Anleitungen fehlt.

Der Durchsatz bei parallelen Anfragen ist die härteste Grenze. In einem internen Aufbau mit einem 8-Milliarden-Modell auf einer Grafikkarte mit 24 GB blieb die Antwortzeit bei zwei gleichzeitigen Nutzern noch akzeptabel; ab etwa vier parallelen Anfragen stieg die Zeit bis zum ersten Token so weit an, dass die Nutzung sich unbrauchbar anfühlte, obwohl der Speicher nicht ausgeschöpft war. Die Konsequenz war kein größerer Rechner, sondern ein anderes Werkzeug: vLLM mit derselben Hardware bediente dieselbe Nutzerzahl ohne spürbare Verzögerung. Wer plant, mehr als zwei bis drei Personen gleichzeitig zu bedienen, sollte diesen Schritt von Anfang an einkalkulieren.

Die Kontextlänge ist die zweite Grenze. Ollama setzt das Kontextfenster standardmäßig kürzer, als das Modell könnte — aus gutem Grund, denn der Speicherbedarf steigt mit. Wer lange Dokumente verarbeiten will, muss den Wert bewusst erhöhen und dafür Speicher einplanen. Ab einer gewissen Größe ist Retrieval-Augmented Generation die bessere Antwort als ein immer längerer Kontext.

Die Modellklasse ist die dritte. Was auf einem Arbeitsplatzrechner läuft, ist nicht das, was in einem Rechenzentrum läuft. Für Zusammenfassungen, Klassifikation, Codeergänzung und einfache Fragen reicht es. Für Aufgaben, die mehrschrittiges Schließen verlangen, merkt man den Unterschied deutlich — dazu passt der Artikel über Reasoning-Modelle.

Und die Skalierung über eine Maschine hinaus gibt es schlicht nicht. Ollama ist nicht dafür gebaut, mehrere Knoten zu koordinieren.

Lokal, gemietet oder gehostet?

Zwischen „läuft auf meinem Rechner" und „läuft bei einem Anbieter" gibt es inzwischen eine Zwischenstufe, und sie sorgt regelmäßig für Verwirrung: Ollama bietet selbst einen Cloud-Dienst an, über den sich größere Modelle ausführen lassen, als lokal passen würden — mit derselben Bedienung und derselben API.

Das ist praktisch, hebt aber genau den Vorteil auf, um dessentwillen die meisten Menschen zu Ollama greifen. Sobald die Berechnung woanders stattfindet, verlassen die Daten den Rechner. Wer aus Datenschutzgründen lokal arbeitet, hat damit dieselbe Prüfpflicht wie bei jedem anderen gehosteten Anbieter: Wo steht der Server, was passiert mit den Eingaben, gibt es einen Vertrag zur Auftragsverarbeitung.

Für die Entscheidung hilft eine einfache Dreiteilung:

Betriebsart	Daten bleiben lokal	Modellgröße	Kosten	Wann sinnvoll
lokal	ja	begrenzt durch Speicher	Strom, einmalig Hardware	Datenschutz, Experimente, konstante Grundlast
gemietete Hardware	vertraglich regelbar	frei wählbar	pro Stunde	konstante Last, große Modelle, eigene Kontrolle
gehostete API	nein	am größten	pro Token	schwankende Last, beste Modellqualität

Die Faustregel aus der Praxis: Bei geringer und schwankender Nutzung ist eine gehostete API günstiger, als man denkt. Ab einer konstanten Grundlast kippt die Rechnung zugunsten eigener oder gemieteter Hardware — und wenn Datenschutz das Ausschlusskriterium ist, stellt sich die Kostenfrage ohnehin nicht.

Häufige Fragen

Was ist Ollama genau? Eine Laufzeitumgebung, die Sprachmodelle lokal ausführt und über eine HTTP-API auf Port 11434 bereitstellt. Es ist kein Modell und keine Oberfläche, sondern der Unterbau für beides.

Wie starte ich Ollama? Nach der Installation läuft der Dienst meist automatisch im Hintergrund. ollama run <modell> startet einen Dialog im Terminal und lädt das Modell beim ersten Aufruf herunter.

Welches ist das beste Ollama-Modell? Das hängt von Speicher und Zweck ab. Für 8 GB verfügbaren Speicher ist ein 7- bis 8-Milliarden-Modell die richtige Größe, für 24 GB eines mit 14 bis 32 Milliarden Parametern. Für Code lohnt ein spezialisiertes Coder-Modell, für Suche und RAG zusätzlich ein Embedding-Modell.

Welche Hardware brauche ich für Ollama? Als Faustregel etwa 0,55 GB Speicher je Milliarde Parameter bei Q4-Quantisierung, plus Reserve für den Kontext. Apple Silicon mit gemeinsamem Speicher ist im Vorteil, weil dort mehr Speicher für das Modell zur Verfügung steht als bei den meisten Grafikkarten.

Ollama oder LM Studio? LM Studio, wenn du eine fertige Oberfläche willst und nicht im Terminal arbeitest. Ollama, wenn du aus eigenen Programmen darauf zugreifen oder es auf einem Server betreiben willst.

Braucht Ollama einen API-Schlüssel? Nein. Bibliotheken verlangen oft ein nicht leeres Feld, der Wert wird aber nicht geprüft. Das bedeutet zugleich, dass ein von außen erreichbarer Ollama-Server ungeschützt ist.

Zusammenfassung und praktische Tipps

• Ollama ist die Laufzeitumgebung, nicht das Modell. Wie gut die Ergebnisse sind, entscheidet, was du hineinlädst.
• Speicher ist die bestimmende Größe. Rechne mit etwa 0,55 GB je Milliarde Parameter bei Q4 plus Reserve für den Kontext — und nimm lieber ein kleineres Modell, das flüssig antwortet.
• Die API ist der eigentliche Nutzen. Über den OpenAI-kompatiblen Endpunkt sprechen die meisten Werkzeuge ohne Anpassung mit deinem lokalen Modell.
• Kein Schlüssel heißt keine Authentifizierung. Wer den Dienst ins Netz stellt, muss selbst für Zugriffsschutz sorgen.
• Ab mehreren gleichzeitigen Nutzern ist vLLM das richtige Werkzeug. Ollama ist ein Einzelplatzwerkzeug mit Server-Anstrich.
• Lokale Modelle sind nicht die stärksten Modelle — aber für Datenschutz, Kostenberechenbarkeit und Unabhängigkeit oft die einzige Option, die überhaupt in Frage kommt.

Mein Rat für den Einstieg: Fang mit einem 7- bis 8-Milliarden-Modell an, auch wenn mehr Speicher da ist. Du lernst in der ersten Woche mehr über Kontextlängen, Ladezeiten und Antwortqualität als über Modellgrößen — und die Erkenntnisse übertragen sich später auf jedes größere Modell. Wenn du danach merkst, dass die Qualität nicht reicht, ist der Wechsel ein einziger Befehl.

Ressourcen

• Ollama – Projektseite – Installer, Registry und Dokumentation
• Ollama – GitHub – Quellcode, API-Referenz und Fehlermeldungen
• Ollama – Modellbibliothek – alle verfügbaren Modelle mit Größen und Tags
• vLLM – die Alternative für Mehrbenutzerbetrieb
• LM Studio – Desktop-Anwendung mit eingebauter Oberfläche