Ollama im Test: der freundliche Weg zu offenen Modellen

Ollama ist eine lokale Inference-Laufzeitumgebung. Sie lädt offene Gewichtsmodelle herunter, legt sie auf der vorhandenen GPU oder CPU ab und stellt sie über eine HTTP-API auf Port 11434 bereit. Der Anbieter nennt mehr als neun Millionen Installationen pro Monat, über eine Milliarde Modell-Downloads und 182.000 GitHub-Sterne – und diese Reichweite ist erklärbar: Es ist der mit dem geringsten Aufwand erreichbare Weg, ein offenes Modell tatsächlich zum Antworten zu bringen. Der Tausch steckt in denselben Zahlen. Ollama optimiert darauf, ein Modell zum Laufen zu bringen, nicht darauf, Tokens aus einer GPU zu pressen, und wer es für einen Produktions-Inferenzserver hält, wird das merken.

Im Stack ist es ein Modellserver, kein Framework. Es ersetzt den eigenen Server von llama.cpp, die Laufzeitumgebung von LM Studio und ein von Hand gebautes Docker-Image – und konkurriert mit vLLM nur im allereisesten Sinne. Darüber liegen LangChain, LlamaIndex, die Coding-Agents und die selbst gehosteten Chat-Oberflächen; austauschbar mit alledem macht Ollama die Form seiner API, nicht das, was darin passiert. Was es nicht liefert, sind Orchestrierung, kontinuierliches Batching, Autoscaling oder Tensor-Parallelität über mehrere Knoten. Das bleibt bei vLLM oder SGLang.

Was es tatsächlich ist

Ollama ist ein Go-Server mit angebautem Modellverwalter, kein Modell. Er wird als eine Binärdatei, eine CLI und ein Docker-Image ausgeliefert, und die CLI ist die gesamte Produktoberfläche, die die meisten je berühren. Die Engines darunter sind llama.cpp für CUDA, ROCm, Vulkan und CPU sowie – seit v0.40.0 – MLX als Standard auf Apple Silicon für die unterstützten Architekturen. Alles Übrige ist Verpackung um diese Engines, und genau deshalb lohnt es sich zu wissen, wo die Grenze verläuft.

• Lizenz: MIT für die Software, ohne Nutzungseinschränkung, ohne Nutzergrenze und ohne Zusatzklausel.
• Aktuelles Release: v0.40.0, als Plattform-Binärdateien und Docker-Image. Der Takt ist schnell, die Nummern springen aber: auf v0.34.4 folgte v0.35.1 und dann direkt v0.40.0.
• APIs: eine native REST-Fläche unter /api, eine OpenAI-kompatible Fläche unter /v1 und eine Anthropic-kompatible Basis-URL – lokal wie in der Ollama Cloud gleichermassen.
• Engines: llama.cpp für CUDA, ROCm, Vulkan und CPU, dazu MLX auf Apple Silicon ab v0.40.0. Nvidia verlangt Compute Capability 5.0 oder neuer, AMD unter Linux den ROCm-v7-Treiber.
• Modellformat: GGUF für llama.cpp-Modelle, Safetensors für MLX. Seit v0.34.1 muss die GGUF-Konvertierung mit llama.cpp-Werkzeugen stattfinden, nicht in Ollama.
• Anpassung: eine Modelfile mit FROM, PARAMETER, TEMPLATE, SYSTEM, MESSAGE, LICENSE, REQUIRES und CAPABILITY – ein abgestimmtes Modell ist damit eine reviewbare Textdatei.
• Ebenfalls enthalten: strukturiertes Ausgeben gegen ein JSON-Schema, Tool-Calling, Vision, Embeddings, Websuche, experimentelle Bildgenerierung unter macOS und Entscheidungsmodelle, die Wahrscheinlichkeiten statt Text zurückgeben.

Wie es funktioniert

Im Zentrum steht ein HTTP-Server, der eine Modellbibliothek und einen VRAM-bewussten Scheduler hält. Eine Anfrage nennt ein Modell-Tag; liegen diese Gewichte nicht schon im Speicher, lädt der Server sie, und passen sie nicht neben das bereits Geladene, reiht sich die Anfrage ein, während ein untätiges Modell verdrängt wird. Geladene Modelle bleiben fünf Minuten nach der letzten Anfrage resident, die Kontextlänge richtet sich nach der VRAM-Klasse der Maschine, und parallele Anfragen an ein Modell teilen sich dessen Kontext, statt je einen eigenen zu bekommen.

Dieses Design hat eine Folge, die Leute überrascht: Das Modell ist die Einheit der Planung und die Einheit der Kosten. Ein Tag-Wechsel unter Last bedeutet ein Laden, eine VRAM-Prüfung und auf einer Maschine mit einer GPU möglicherweise das Verdrängen dessen, was gerade allen anderen geantwortet hat. Ollamas Antwort sind OLLAMA_MAX_LOADED_MODELS und OLLAMA_NUM_PARALLEL – und beide bezahlt man mit Speicher statt mit Rechenleistung.

Erste Schritte

Die Installation ist ein Shell-Skript, eine Desktop-App oder ein Docker-Image. Die API ist ein POST, und ein lokaler Server braucht weder Schlüssel noch Konfigurationsdatei. Das Snippet unten ist das Kleinste, was in der Produktion zu schreiben sich lohnt: ein streamender Aufruf mit explizitem Kontextfenster, ein zwischen den Aufrufen resident gehaltenes Modell und die Zeitmessfelder, die der Server ohnehin berechnet.

import json, urllib.request, time

URL = "http://localhost:11434/api/chat"
BODY = {
    "model": "gemma4",
    "messages": [{"role": "user", "content": "Summarise this ticket in one line."}],
    "stream": True,
    "keep_alive": "30m",              # keep the weights resident between calls
    "options": {"num_ctx": 8192, "temperature": 0},
}

request = urllib.request.Request(
    URL, data=json.dumps(BODY).encode(), headers={"Content-Type": "application/json"})

chunks = []
with urllib.request.urlopen(request) as response:
    for line in response:                       # newline-delimited JSON events
        event = json.loads(line)
        if "message" in event:
            chunks.append(event["message"].get("content", ""))
        if event.get("done"):
            seconds = event["eval_duration"] / 1e9   # nanoseconds
            print(f"{event['eval_count']} tokens in {seconds:.1f}s"
                  f" -> {event['eval_count'] / seconds:.1f} tok/s")
            print(f"prompt tokens {event['prompt_eval_count']}, cached"
                  f" {event.get('prompt_eval_cached_count', 0)},"
                  f" load {event['load_duration'] / 1e9:.1f}s")

print("".join(chunks))

Zwei Felder lohnen sich in einem Dashboard: eval_count geteilt durch eval_duration für die Generierungsgeschwindigkeit und load_duration für die Kaltstartstrafe. prompt_eval_cached_count meldet, wie viele Prompt-Token aus dem Cache kamen – das ist das einzige Gratis-Beschleunigung, die Ollama anbietet. Setzen Sie den stabilen Präfix eines Prompts zuerst und den variablen Teil zuletzt, dann wird der gemeinsame System-Prompt nicht bei jedem Aufruf neu ausgewertet.

Die Lizenz – und die Klausel, die es nicht gibt

Ollamas Software ist MIT-lizenziert, ohne Wenn und Aber. Die LICENSE-Datei im Repository ollama/ollama ist der unveränderte MIT-Text: keine Zusatzklausel, keine Nutzer-Obergrenze, keine Nutzungseinschränkung. Es gibt keine OpenAI-Klausel darin und keine Grenze von 700 Millionen monatlich aktiven Nutzern – und das sollte klar gesagt sein, weil die Behauptung weit verbreitet ist. Die Schwelle von 700 Millionen gehört zur Llama Community Licence von Meta, und die gilt für Llama-Gewichte, nicht für die Laufzeitumgebung, die sie ausliefert. Ollama verdient außerdem an bezahlten Cloud-Tarifen und wurde im Juli 2026 mit einer Finanzierungsrunde über 65 Millionen Dollar bedacht, und nichts davon setzt eine Klausel in die Quelllizenz.

Die MIT-Gewährung deckt die Server-Binärdatei. Über die damit ausgeführten Modelle sagt sie nichts, und genau dort liegt das tatsächliche Lizenzrisiko. Die Bibliothek liefert Gewichte von einem Dutzend Herausgeber unter einem Dutzend Bedingungen aus – die bindende Lizenz steht auf der Modellkarte, nicht auf der Laufzeitumgebung. Eine Modelfile hält neben den Gewichten eine LICENSE-Anweisung fest, und ollama show --modelfile gibt sie aus. Dieser String, je Modellversion, ist das Artefakt für das Compliance-Register.

• MIT auf der Laufzeitumgebung. Kommerziell nutzen, forken, in ein Produkt ausliefern. Keine Namensnennungspflicht über den Copyright-Hinweis hinaus, keine Umsatzgrenze, keine Nutzergrenze, keine Telemetrie-Pflicht.
• Die Modelllizenz ist separat. Metas Llama Community Licence verlangt oberhalb von 700 Millionen monatlich aktiven Nutzern eine separate Lizenz von Meta, andere Familien setzen eigene Umsatz- oder Nutzergrenzen. Manche Modelle werden nur nicht-kommerziell lizenziert ausgeliefert. Lesen Sie die Modellkarte.
• ollama.com selbst ist nicht MIT. Die gehostete Cloud, die Bibliothekskonten und die bezahlten Tarife fallen unter die Nutzungsbedingungen, zuletzt aktualisiert im Mai 2026: verbindliche Schiedsverfahren in San Francisco, kalifornisches Recht, eine Haftungsgrenze in Höhe der in den zwölf Monaten zuvor gezahlten Beträge und eine Klausel, die die Nutzung des Dienstes zur Entwicklung konkurrierender Produkte untersagt.

Betrieb in Produktion

Bei der Parallelität sind lokale Laufzeitumgebungen ehrlich über ihre Grenzen. Ollama verarbeitet standardmäßig eine Anfrage pro Modell, und parallele Anfragen teilen sich einen Kontext, statt unabhängig gebündelt zu werden: Die Dokumentation sagt es direkt – ein Kontext von 2.000 Tokens mit vier parallelen Anfragen verhält sich wie ein Kontext von 8.000 Tokens, und der benötigte RAM skaliert mit parallelen Anfragen mal Kontextlänge. Für interaktive Nutzung ist das ein tragfähiger Tausch, für Stapelverarbeitung ein schlechter.

Der Server hat keine Authentifizierung. Er bindet standardmäßig auf 127.0.0.1, und der OpenAI-kompatible Endpunkt verlangt einen API-Schlüsselwert, den er anschließend ignoriert – was eine präzise Aussage darüber ist, wie sehr die lokale Fläche vertraut wird. Alles, was OLLAMA_HOST auf eine routbare Adresse setzt, veröffentlicht einen unauthentifizierten Inferenz-Endpunkt. Im Januar 2026 berichteten Forscher über rund 175.000 öffentlich erreichbare Ollama-Server in 130 Ländern, die meisten durch Bindung auf 0.0.0.0 exponiert.

• Lassen Sie die Bind-Adresse auf 127.0.0.1. Es gibt keine Authentifizierung zu konfigurieren, also ist ein Reverse Proxy mit TLS und echter Zugriffsprüfung die einzige verfügbare Zugriffskontrolle.
• Setzen Sie OLLAMA_ORIGINS explizit, wenn ein Browser-Client es braucht. Loopback-Ursprünge sind standardmäßig erlaubt, also ist der Standard für lokale Werkzeuge richtig und für alles Geteilte falsch.
• Auf Maschinen, die ollama.com gar nicht erreichen dürfen, setzen Sie OLLAMA_NO_CLOUD=1 oder disable_ollama_cloud in ~/.ollama/server.json, starten neu und prüfen die Log-Zeile Ollama cloud disabled: true.
• Bedenken Sie, dass die Desktop-App sich unter macOS und Windows als Login-Element registriert: Port 11434 liefert also schon beim Start, ob danach jemand gefragt hat oder nicht.

Wo es scheitert

Die Schwächen sind real und sie liegen an einer Stelle: der Durchsatz pro GPU. Standardmäßig eine Anfrage pro Modell, kein unabhängiges Batching paralleler Anfragen, keine Parallelität über mehrere Knoten und kein Tensor-Parallel-Serving. Für einen interaktiven Endpunkt mit einer Handvoll Nutzern fällt das nicht auf. Für alles mit Warteschlange, Stapeljob oder Kostenziel schon: Dieselbe GPU liefert einen Bruchteil dessen, was vLLM mit demselben Modell liefert – und diese Lücke ist kein Konfigurationsproblem, sondern das Design.

Gegenüber LM Studio ist der Vergleich knapp und im Kern eine Verpackungsfrage: LM Studio hat eine GUI und einen Modell-Browser, Ollama hat eine CLI, ein Docker-Image und natives Headless-Format, und um die API-Form von Ollama herum ist das Open-WebUI-Ökosystem gewachsen. Gegenüber dem eigenen Server von llama.cpp ist der Unterschied der Modellverwalter und der Scheduler – für ein Team viel wert, für jemanden, der llama.cpp ohnehin schon kennt, nichts. Gegenüber vLLM ist der Unterschied der gesamte Geschäftsfall: Wenn die Frage lautet, wie man das zu planbaren Kosten ausliefert, sind vLLM oder SGLang das Werkzeug und Ollama die Entwicklungsumgebung, in der prototypisiert wird.

Das zweite Abwägungspunkt ist die Richtung. Die Ollama Cloud führt inzwischen Pro-, Max- und Team-Tarife, Preise pro Token und eine auf Unternehmen ausgerichtete Zugriffskontrolle auf Modelle. Das Projekt ist also ein kommerzieller Inferenzanbieter und zugleich eine Laufzeitumgebung. Das finanziert den Release-Takt und ist kein Vorwurf. Es bedeutet aber, dass der Schwerpunkt von „ein Modell auf der eigenen Maschine betreiben“ zu „anmelden und ein größeres nutzen“ wandert – und ein Team, das von lokaler Inferenz abhängt, sollte Version, Modell-Pins und Artefakte selbst besitzen, statt anzunehmen, die Fläche bleibe, wo sie ist.

Urteil

Ollama ist die beste Standardantwort auf die Frage, wie man ein offenes Modell betreibt, ohne jemanden einzustellen, der llama.cpp betreibt. Es ist MIT, es startet mit einem Befehl, seine API ist die Kompatibilitätsschicht, die fast jedes Agenten-Framework bereits spricht, und es verbirgt eine enorme Menge GPU-Planung hinter zwei Umgebungsvariablen. Was es nicht ist, ist eine skalierbare Inferenzplattform – und sobald eine Anfragewarteschlange auf einem Dashboard sichtbar wird, ist das das Signal zum Wechseln, nicht zum Tunen.

1. Nehmen Sie es für lokale Entwicklung, Evaluierungs-Harnesses, CI-Fixtures, On-Prem-Installationen, auf denen sich eine Handvoll Personen eine Workstation teilen, und datengebundene Workloads, deren Prompts das Gebäude nicht verlassen dürfen.
2. Nehmen Sie es für einen lokalen oder selbst gehosteten Endpunkt in einem Agenten-Framework, weil die OpenAI-kompatible Fläche einen anbieterspezifischen Client überflüssig macht.
3. Nehmen Sie es für ein Team an einem Nachmittag zu einem funktionierenden Open-Model-Prototyp zu bringen. Das ist ein echter operativer Gewinn und der Grund, warum die meisten Nutzer nie wieder gehen.
4. Lassen Sie es weg für Mehrbenutzer-Serving unter Last, Batch-Generierung oder alles, wo Tokens pro Sekunde pro GPU die Kennzahl ist, an der das Projekt gemessen wird.
5. Lassen Sie es weg für regulierte Umgebungen, die Authentifizierung, Audit-Protokollierung oder einen Scheduler unterhalb der Inferenzschicht brauchen. Stellen Sie einen Proxy davor, oder nehmen Sie eine andere Laufzeitumgebung.

Quellen

1. Ollama API documentation
2. Ollama on GitHub, with the MIT LICENSE file
3. Ollama terms of service, last updated May 2026
4. Ollama pricing, cloud plans and per-token model rates
5. Hardware support: Nvidia, AMD, Metal and Vulkan
6. OpenAI compatibility, including what is not supported