Zum Hauptinhalt springen

Ollama Entwickler-Guide

Worum geht es?

Das ist ein praxisnaher Guide fuer Entwickler, die Ollama als local-first AI-Runtime nutzen wollen. Er erklaert, was Ollama ist, wo es stark ist, wann du es einsetzen solltest, wie du es sauber selbst hostest und welche Best Practices in echten Projekten wichtig sind.

Umfang

Dieser Guide basiert auf der offiziellen Ollama-Dokumentation, geprueft am 22. Juni 2026.

1. Was Ollama ist​

Ollama ist einer der einfachsten Wege, LLMs hinter einer lokalen CLI und HTTP-API laufen zu lassen.

In der Praxis bekommst du:

  • eine lokale Runtime fuer Modelle auf macOS, Windows und Linux
  • eine einfache CLI wie ollama run, ollama pull und ollama serve
  • eine native API unter http://localhost:11434/api
  • eine OpenAI-kompatible API unter http://localhost:11434/v1/
  • offizielle Python- und JavaScript/TypeScript-Libraries
  • einen Weg, Modelle mit Modelfiles anzupassen
  • Support fuer Streaming, Thinking, Structured Outputs, Tool Calling, Embeddings und Vision

Kurz gesagt: Wenn du mit lokalen oder selbst gehosteten Modellen bauen willst, ohne gleich einen kompletten Inferenz-Stack von Grund auf aufzubauen, ist Ollama einer der saubersten Einstiege.

2. Warum Entwickler Ollama moegen​

Die wichtigsten Vorteile​

  • Local-first Workflow: Standardmaessig laeuft alles auf deiner Maschine oder deinem eigenen Server.
  • Sehr wenig Setup-Reibung: installieren, Modell ziehen, API ansprechen.
  • OpenAI-Kompatibilitaet: viele bestehende Tools lassen sich mit einer geaenderten Base-URL an Ollama anschliessen.
  • Starke App-Features: Tool Calling, Structured Outputs, Embeddings, Vision, Streaming.
  • Gute Anpassbarkeit: Mit Modelfiles pinnst du Kontext, System-Prompts und Generation-Settings.
  • Gute Editor-Story: Die offiziellen Docs enthalten Integrationen fuer VS Code, Codex, Claude Code und mehr.
  • Gute Self-Hosting-Story: laeuft direkt auf dem Workstation-Rechner, in Docker oder auf einem internen Server.

Der eigentliche Trade-off​

Normalerweise tauschst du:

  • mehr Kontrolle
  • bessere Privatsphaere
  • weniger laufende API-Kosten

gegen:

  • deine eigenen Hardware-Grenzen
  • mehr Verantwortung bei der Modellwahl
  • weniger rohe Spitzenqualitaet als bei Frontier-Hosted-Modellen in manchen Aufgaben

3. Wofuer Ollama am besten geeignet ist​

Sehr starke Einsaetze​

Use CaseWarum Ollama gut passt
Lokaler Coding-AssistentGut fuer Editor-Integrationen, CLI-Tools und private Codebases
Interner Chat ueber FirmendokumenteGute Privatsphaere und einfache lokale APIs fuer RAG
Structured-Extraction-PipelinesJSON-Mode und schema-basierte Outputs funktionieren gut
Embeddings + semantische SucheOffizieller Embedding-Support ist direkt eingebaut
Agent-/Tool-WorkflowsTool Calling und Multi-Turn-Loops sind sauber dokumentiert
Vision-PrototypenMultimodale Modelle nutzen dieselbe Chat-API
Offline- oder kontrollierte UmgebungenNuetzlich, wenn nicht jede Anfrage an einen Hosted-Anbieter gehen soll

Gut, aber nicht immer ideal​

Use CaseWorauf du achten solltest
Produktive Customer-Facing-Chats in groesserem MassstabDu brauchst trotzdem Capacity Planning, Monitoring und Traffic-Kontrolle
Agenten mit grossem KontextMehr Kontext kostet schnell viel Speicher
Frontier-Reasoning-AufgabenEin gehostetes Frontier-Modell kann weiterhin besser sein

Meist nicht die beste Wahl​

  • wenn du fuer jede Anfrage die absolut staerkste Frontier-Modellqualitaet brauchst
  • wenn du eine voll gemanagte Multi-Tenant-AI-Plattform mit elastischer Skalierung willst
  • wenn deine Hardware schwach ist, dein Workload aber grosse Modelle + grossen Kontext + niedrige Latenz erwartet

4. Wie du den Einsatz sinnvoll denken solltest​

Der sauberste Weg mit Ollama ist:

  1. nutze es als deine lokale Standard-Runtime
  2. nimm unterschiedliche Modelle fuer unterschiedliche Jobs
  3. behandle die OpenAI-kompatible API als Kompatibilitaetsschicht, nicht als magische Vollparitaet
  4. gehe erst dann auf Docker oder einen internen Server, wenn der lokale Workflow bereits gut sitzt

Ein gesundes Mental Model​

  • Ollama ist nicht nur "Chat im Terminal"
  • es ist eine Developer-Plattform fuer lokale AI-Features
  • das staerkste Muster ist oft hybrid:
    • lokale Modelle fuer Geschwindigkeit, Privatsphaere und billige Iteration
    • gehostete Frontier-Modelle nur fuer die haertesten Aufgaben

5. Quickstart​

CLI​

Installiere Ollama und fuehre dann aus:

ollama

Laut offizieller Quickstart-Doku oeffnet das ein interaktives Menue, in dem du:

  • ein Modell starten kannst
  • Tools und Integrationen starten kannst
  • unterstuetzte Coding-Workflows findest

Erstes Modell starten​

ollama run gemma4

Erster API-Call​

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{ "role": "user", "content": "Hello!" }]
}'

Diese lokale API ist der Mittelpunkt der meisten echten Integrationen.

6. Die zwei API-Wege​

Native Ollama-API​

Base-URL:

http://localhost:11434/api

Nutze sie, wenn:

  • du Ollama-native Features direkt verwenden willst
  • du Greenfield-Tooling baust
  • du die klarste Abbildung auf die offiziellen Docs willst

OpenAI-kompatible API​

Base-URL:

http://localhost:11434/v1/

Nutze sie, wenn:

  • deine App schon OpenAI spricht
  • du SDKs oder Tools mit minimalen Aenderungen wiederverwenden willst
  • du Ollama in bestehende Editoren, Agenten oder interne Services einhaengst

Beispiel mit dem OpenAI-Python-SDK:

from openai import OpenAI

client = OpenAI(
    base_url='http://localhost:11434/v1/',
    api_key='ollama',  # vom SDK verlangt, lokal von Ollama ignoriert
)

response = client.chat.completions.create(
    model='gpt-oss:20b',
    messages=[{'role': 'user', 'content': 'Explain what Ollama is in one paragraph.'}],
)

print(response.choices[0].message.content)

Kompatibilitaets-Hinweis​

Ollama unterstuetzt grosse Teile der OpenAI-API, aber keine perfekte Eins-zu-eins-Paritaet. Die aktuellen Docs zeigen zum Beispiel Luecken wie:

  • kein tool_choice in /v1/chat/completions
  • kein stateful previous_response_id-Flow in /v1/responses
  • je nach Endpoint nur teilweise Feldunterstuetzung

Die sichere Regel lautet also: kompatibel genug fuer viele Tools, aber pruefe die Features, auf die du dich konkret verlaesst.

7. Best Practices​

1. Unterschiedliche Modelle fuer unterschiedliche Jobs​

Zwinge nicht ein einziges Modell, alles zu erledigen.

  • nimm ein allgemeines Instruct-Modell fuer Chat oder Coding
  • nimm ein dediziertes Embedding-Modell fuer Retrieval
  • nimm ein vision-faehiges Modell nur dann, wenn Bilder im Spiel sind

Die offiziellen Embedding-Docs nennen explizit Modellklassen wie:

  • embeddinggemma
  • qwen3-embedding
  • all-minilm

2. Structured Outputs fuer App-Logik bevorzugen​

Wenn Modell-Outputs in Code, Workflows oder Datenbanken fliessen, nutze:

  • format: "json" fuer einfaches JSON
  • ein volles JSON-Schema fuer stabile strukturierte Outputs

Die Docs empfehlen ausserdem die Validierung mit:

  • Pydantic in Python
  • Zod in JavaScript/TypeScript

Das ist eine der hoechsten Hebelwirkungen in echter Software.

3. Temperatur fuer deterministische Workflows niedrig halten​

Fuer Extraction, Routing, Klassifikation oder App-seitiges JSON:

  • Temperatur senken
  • fuer streng strukturierte Arbeit, wenn passend, 0 setzen

Das ist besonders wichtig, wenn du ueber mehrere Laeufe vorhersagbare Ergebnisse willst.

4. Kontext bewusst dimensionieren​

Die offiziellen Context-Length-Docs sagen aktuell, dass Ollama standardmaessig setzt:

  • 4k bei weniger als 24 GiB VRAM
  • 32k bei 24-48 GiB
  • 256k bei 48 GiB oder mehr

Ausserdem steht dort explizit, dass Web Search, Agents und Coding Tools auf mindestens 64000 Token gesetzt werden sollten.

Das heisst aber nicht: "immer maximalen Kontext". Mehr Kontext bedeutet mehr Speicherlast. Erhoehe ihn nur, wenn der Workload ihn wirklich braucht.

Du kannst ihn beim Start setzen:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

5. Modelfiles statt Verhalten ueberall neu zu tippen​

Wenn du denselben System-Prompt, Kontext oder dieselben Generation-Settings staendig wiederholst, verschiebe das in ein Modelfile.

Beispiel:

FROM gemma4
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
SYSTEM """You are a careful senior developer who answers in concise technical English."""

Dann erstellen und starten:

ollama create my-dev-model -f Modelfile
ollama run my-dev-model

Das ist sauberer, als riesige Prompts ueber viele Skripte zu verstreuen.

6. Tool Calling als expliziten Loop bauen​

Fuer ernsthaften Tool-Einsatz:

  • lass das Modell Tools anfordern
  • fuehre die Tools in deiner App aus
  • haenge die Tool-Ergebnisse an
  • lass das Modell weiterarbeiten

Die offiziellen Docs zeigen dieses Muster fuer:

  • einzelne Tool-Calls
  • parallele Tool-Calls
  • Multi-Turn-Agent-Loops
  • Streaming-Tool-Loops

Das ist die richtige Architektur. Erwarte nicht "eine Anfrage und magisches Agent-Verhalten", ausser dein Wrapper implementiert diesen Loop bereits.

7. Usage-Metriken mitloggen​

Ollama-Antworten enthalten nuetzliche Metriken wie:

  • total_duration
  • load_duration
  • prompt_eval_count
  • prompt_eval_duration
  • eval_count
  • eval_duration

Nutze sie fuer:

  • Cold Starts erkennen
  • Modelle vergleichen
  • Prompt-Aufblaehung messen
  • langsame kontextlastige Workflows sichtbar machen

8. Namen und Aliase fuer Kompatibilitaet pinnen​

Wenn ein Tool einen Modellnamen wie gpt-3.5-turbo erwartet, empfehlen die Docs ollama cp, um einen kompatiblen Alias zu erzeugen.

Das ist ein praktischer Weg, aeltere Tools gluecklich zu machen, ohne jede Konfigurationsstelle umzubauen.

9. Remote-Exposition als Infrastruktur behandeln​

Offiziell braucht lokaler Zugriff auf http://localhost:11434 keine Authentifizierung.

Das ist auf deiner Maschine okay. Es ist kein Grund, Port 11434 direkt ins Internet zu haengen.

Fuer Team- oder Server-Betrieb:

  • Ollama hinter einer internen Netzgrenze halten
  • Reverse Proxy oder Gateway davorsetzen
  • Auth ausserhalb von Ollama regeln, wenn du es remote exponierst
  • Ollama-API-Keys nur fuer direkten Zugriff auf https://ollama.com/api verwenden

8. Self-Hosting-Muster​

Muster A: lokale Workstation​

Ideal fuer:

  • Solo-Entwicklung
  • Editor-Integrationen
  • privaten Code oder private Dokus
  • schnelle Experimente

Damit sollten die meisten starten.

Muster B: Docker auf einer Dev-Box oder internem Server​

Nur CPU​

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Nvidia-GPU​

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

AMD-GPU​

docker run -d --device /dev/kfd --device /dev/dri -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:rocm

Ideal fuer:

  • stabilen internen Endpoint fuer ein kleines Team
  • CI oder gemeinsame Demo-Umgebungen
  • reproduzierbares Linux-Setup

Muster C: interner AI-Service​

Ideal fuer:

  • einen zentralen Modell-Host
  • geteilte Editor- und Tool-Integrationen
  • einen Endpoint fuer mehrere interne Apps

Empfohlene Form:

  • Ollama in Docker oder auf dedizierter Maschine
  • Modelle vorab gepullt
  • Reverse Proxy davor
  • nur internes Networking
  • Monitoring fuer API-Latenz und Speicherverbrauch

9. VS-Code-Nutzung​

Die aktuellen offiziellen Docs sagen, dass VS Code Ollama-Modelle ueber GitHub Copilot Chat nutzen kann.

Aktuell von Ollama genannte Voraussetzungen:

  • Ollama v0.18.3+
  • VS Code 1.113+
  • GitHub Copilot Chat 0.41.0+

Die Docs nennen auch ein wichtiges Detail:

  • du musst trotzdem eingeloggt sein
  • du brauchst aber keinen bezahlten Copilot-Plan
  • GitHub Copilot Free reicht fuer die Auswahl eigener/lokaler Modelle

Quick Setup:

ollama launch vscode

Danach sollte im Copilot-Chat-Panel Local ausgewaehlt sein.

Genau dadurch ist Ollama besonders interessant, wenn du willst:

  • lokalen Chat ueber deine Codebase
  • private Prompts
  • ein guenstigeres Coding-Setup
  • eine Bruecke zwischen lokaler Inferenz und vertrauter Editor-UI

10. Praktische Empfehlung​

Nutze Ollama, wenn​

  • du einen local-first AI-Stack willst
  • dir Privatsphaere oder Code-Lokalitaet wichtig ist
  • du guenstig iterieren willst, ohne laufende Token-Abrechnung
  • du einen einfachen Self-Hosting-Pfad willst
  • du RAG, Embeddings, Tools oder strukturierte Extraktion auf eigener Infrastruktur brauchst

Erzwinge Ollama nicht, wenn​

  • die Aufgabe zwingend das beste gehostete Frontier-Modell braucht
  • dein Team nicht bereit ist, GPU-Kapazitaet, Modellwahl und Latenz-Trade-offs selbst zu tragen
  • der Workload hauptsaechlich produktseitig ist und du eigentlich eine gemanagte Inferenz-Plattform brauchst

Mein praktischer Default​

Fuer die meisten Entwickler ist das staerkste Setup:

  1. lokal mit Ollama starten
  2. die App gegen die native oder OpenAI-kompatible API bauen
  3. Modelfiles und Structured Outputs hinzufuegen
  4. erst dann auf Docker oder einen internen Host gehen, wenn der Workflow bereits bewiesen ist
  5. ein gehostetes Frontier-Modell als Eskalationspfad fuer die haertesten Aufgaben behalten

Das liefert die beste Balance aus Kontrolle, Kosten und Entwicklergeschwindigkeit.

Quellen​