API-Zugriff: Ollama spricht OpenAI

Das Schöne an Ollama: Es bietet eine OpenAI-kompatible API. Wenn du also schon Code hast, der mit der OpenAI-API spricht, brauchst du nur die Base-URL umzustellen und kannst das Modell wechseln.

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.3:8b",
    "messages": [
      {"role": "user", "content": "Antworte mit OK"}
    ]
  }'

Das ist exakt dieselbe Struktur wie bei OpenAI – nur ohne Authorization-Header (lokal, brauchst keinen Key) und mit anderem Modellnamen. Tools wie n8n, LangChain oder LlamaIndex unterstützen Ollama als drop-in.

Welches Modell für welchen Zweck

Hier eine ehrliche Einschätzung aus eigenen Tests, Stand April 2026:

Test zwei Modelle parallel gegen deine echten Aufgaben. Benchmarks sagen wenig. Nur deine Use Cases entscheiden.

Performance-Reality-Check

Die unbequeme Wahrheit: Lokale Modelle sind langsamer als die Cloud-Modelle. Nicht in der Modell-Qualität, sondern in der Verarbeitungs-Geschwindigkeit. Während GPT-4o auf einem Azure-Server ungefähr 100 Tokens pro Sekunde liefert, ist Llama 3.3 70B auf einer RTX 4090 bei ungefähr 15 bis 25 Tokens pro Sekunde.

Was das bedeutet: Eine Antwort, die in der Cloud zwei Sekunden dauert, dauert lokal acht bis zwölf Sekunden. Für asynchrone Agenten (E-Mail-Auswertung, Dokumentenklassifikation) ist das egal. Für Echtzeit-Chat mit Kunden ist es spürbar.

Wenn Geschwindigkeit kritisch ist, brauchst du entweder besseres Hardware (mehrere GPUs parallel, Inference-optimierte Karten wie A100/H100) oder du kombinierst lokal und Cloud: lokal für sensible Daten, Cloud für unkritische schnelle Antworten.

Was die DSGVO-Doku sagt (und warum sie kürzer ist)

Der große Vorteil von Ollama für die DSFA: Die Auftragsverarbeitungs-Sektion entfällt. Es gibt keinen externen Auftragsverarbeiter. Du verarbeitest die Daten selbst, in deinen eigenen Räumen, auf deiner eigenen Infrastruktur.

Was du mehr dokumentieren musst als bei Cloud: Die technischen und organisatorischen Maßnahmen (TOMs) für deinen Server. Wer hat physischen Zugriff? Wie wird gepatcht? Wie sind die Backups? Das ist normale IT-Sicherheit, gilt für jeden Server, ist nicht KI-spezifisch – aber muss in der DSFA stehen.

Wann du lokal NICHT einsetzen solltest

Drei Situationen, in denen wir bei kiba von lokal abraten:

Wenn niemand bei euch Linux/Server-Betrieb beherrscht. Ollama ist nicht "klick und es läuft". Es läuft erstmal. Sechs Monate später, wenn ein Treiber-Update kaputt geht oder der Server neu starten muss, brauchst du jemanden, der weiß, was er tut. Wenn das niemand ist und ihr keinen externen Dienstleister habt, ist Cloud trotz schwächerer DSGVO-Position der praktikablere Weg.

Wenn euer Volumen unter 100.000 Tokens täglich liegt. Bei den Token-Preisen 2026 sind das in der Cloud weniger als 50 Euro im Monat. Eine 4.000-Euro-Hardware-Investition amortisiert sich da nie. Cloud ist günstiger, wenn das Volumen klein ist.

Wenn ihr maximale Modell-Qualität braucht. Lokale Modelle 2026 sind gut, aber GPT-4o, Claude Opus 4 und Gemini 2.5 Pro sind noch einen Tick stärker. Wenn dein Use Case das beste Reasoning braucht – komplexe Vertragsanalyse, mehrstufige Planungsaufgaben – geht lokal, aber du verschenkst Qualität.

Erster lokaler Agent

Wenn das Setup steht, ist der erste Agent nicht anders als in der Cloud. Du nutzt n8n, LangChain oder ein eigenes Skript, zeigst auf http://localhost:11434/v1 statt auf OpenAI, und der Workflow ist identisch.

Den konkreten Bauplan für einen ersten Agenten – mit Trigger, Schritten, Outputs – schreiben wir im nächsten Artikel der Serie. Da nutzen wir n8n als Orchestrator und können sowohl lokal als auch Cloud als Backend reinhängen.