Ollama

Ollama ist ein lokaler Model-Runner mit CLI, App und API, der lokale LLMs einfach installierbar macht. Technisch ist es ein Convenience-Layer über llama.cpp ([HW-04]): Es nimmt GGUF, das Modell-Management, die Konfiguration und die OpenAI-kompatible API ab, ohne dass du dich um Backends oder Build-Flags kümmern musst.

Im Lehrgang gehört dieser Begriff zur Phase lokale AI, Datenkontrolle, Modellgrenzen und Automatisierung. Er ist nicht als isolierte Definition gedacht, sondern als Baustein, den du später in echten Fällen wiedererkennst. Wenn du ganz neu einsteigst, musst du zuerst drei Dinge können: den Zweck in eigenen Worten erklären, die Grenze des Begriffs nennen und sagen, woran du in der Praxis erkennst, dass er gerade relevant ist.

Merksatz: Ollama beantwortet nicht jede Frage, aber es sortiert einen wichtigen Ausschnitt der Arbeit so, dass du nicht blind ausprobierst.

Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.

Als Anfänger arbeitest du mit einer einfachen Prüfliste:

Welche Aufgabe soll das Modell wirklich lösen?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.
Welche Daten dürfen lokal, intern oder extern verarbeitet werden?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.
Woran misst du, ob die Antwort gut genug, schnell genug und verlässlich genug ist?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du startest ein lokales Modell per CLI und bindest es später über eine lokale API in ein Tool oder Script ein.

Das Ziel ist nicht, sofort Experte zu sein. Das Ziel ist, den Normalfall sauber zu erkennen, keine riskanten Annahmen zu treffen und die nächste sinnvolle Handlung begründen zu können.

Miniübung für den Lehrgang: Formuliere einen echten Fall in zwei Sätzen, markiere die wichtigste Information und schreibe eine Rückfrage auf, die fehlende Fakten klärt. Dadurch lernst du, Ollama nicht nur zu definieren, sondern im Arbeitsfluss anzuwenden.

Auf Level 2 wird Ollama in einen Ablauf eingebettet. Du unterscheidest Eingaben, Entscheidungspunkte, Ergebnis und Dokumentation. Genau dadurch wird aus Nachschlagen echtes Lernen: Du erkennst, was vorher geklärt sein muss, was sich aus dem Begriff ergibt und welche anderen Begriffe anschliessen.

Was Ollama konkret bietet (Stand 2026-07-20, [HW-04]):

Bibliothek / Library: Ein kuratierter Katalog fertiger Modelle (z.B. ollama pull qwen3, ollama run phi4), das Modelfile-Format für eigene Varianten.
Model-Management: Pull, Run, List, Remove über eine einheitliche CLI — kein manuelles Herunterladen von GGUF-Dateien nötig.
OpenAI-kompatible API: /v1/chat/completions out-of-the-box, damit Tools wie LangChain, OpenWebUI oder eigene Scripts direkt angeschlossen werden.
Engine: Baut auf llama.cpp auf. Damit erbt Ollama GGUF-Support, CPU/CUDA/Metal/Vulkan und die Q4_K_M/Q5_K_M/Q8_0-Quants (siehe Quantisierung lokaler Modelle und llama.cpp).

Wichtige Grenze: Ollama ist auf einzelne Nutzer oder kleine Nebenläufigkeit ausgelegt. Praktische Erfahrungswerte und das Repo-Feedback zeigen, dass es ab etwa 5 gleichzeitigen Nutzern spürbar abbricht (Warteschlange, Latenzspitzen, kein echtes Batching) ([HW-04]). Für Mehrnutzer-Produktion ist vLLM mit PagedAttention die übliche Wahl (siehe Lokale AI Grundlagen).

Arbeite mit diesem Schema:

Eingang: Welche Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung startet den Vorgang?
Der Eingang ist der konkrete Auslöser: eine Beobachtung, Anfrage, Messung, Datei, Fehlermeldung oder Entscheidung. Schreibe zuerst den Rohbefund auf und trenne ihn von deiner Vermutung.
Prüfung: Welche Fakten müssen belegt werden, bevor du handelst?
Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.
Aktion: Was ist der kleinste sinnvolle Schritt, der das Problem klärt oder voranbringt?
Die Aktion ist der kleinste reversible Schritt, der Klarheit bringt: eine Messung, ein kontrollierter Test, eine Rückfrage, ein Backup, eine Dokumentation oder eine sichere Änderung mit beobachtbarem Ergebnis.
Nachweis: Was dokumentierst du, damit andere Menschen später verstehen, was passiert ist?
Der Nachweis hält fest, was entschieden und beobachtet wurde: Ausgangslage, Prüfschritte, Ergebnis, Zeit, Beteiligte, offene Risiken und der nächste sinnvolle Schritt. So kann jemand anderes den Fall nachvollziehen.

Vorher solltest du Lokale AI Grundlagen verstanden haben.

Für die Praxis bedeutet das: Du trennst Beobachtung von Interpretation. Eine Beobachtung ist zum Beispiel ein Messwert, eine Fehlermeldung, ein Zählerstand, ein Logeintrag oder ein reproduzierbarer Schritt. Eine Interpretation ist deine Vermutung, warum das passiert. Gute Arbeit entsteht, wenn beide Ebenen nicht vermischt werden.

Verwandte Begriffe für die Vertiefung: Lokale AI Grundlagen, llama.cpp.

Auf Expertenniveau geht es nicht mehr um das Wiederholen einer Definition. Du bewertest Randfälle, Grenzen, Verantwortlichkeiten und Folgewirkungen. Bei Ollama heißt das: Du kannst zwischen Normalfall, Ausnahmefall und Risiko unterscheiden. Du erkennst, wann ein Fall noch in deinen Aufgabenbereich gehört und wann Spezialisten, rechtliche Klärung, Security, Engineering oder eine formale Freigabe nötig sind.

Die wichtigsten Praxisfallen sind:

Ein Modell wird nach Hype ausgewählt, nicht nach Datenlage, Hardware, Lizenz, Latenz und Qualitätsmessung.
Ollama als Produktionsserver missverstanden — es bricht ab ~5 gleichzeitigen Nutzern ab ([HW-04]); für echte Nebenläufigkeit ist vLLM der richtige Pfad.
Token/s ohne vollständigen Kontext (CPU/GPU, Quant, Kontext, Batch, Runtime, Quelle) sind wertlos; Herstellers-Benchmarks (LocalAI Master, Spheron, mustafa.net u.a.) sind Eigenmessungen und teils spekulativ.
RAG wird als Wahrheitssystem missverstanden, obwohl Retrieval, Kontext und Modellantwort getrennt validiert werden müssen.
Lokale Verarbeitung wird automatisch als datenschutzsicher betrachtet, obwohl Logs, Plugins, Downloads und Benutzerrechte weiter relevant sind (siehe Datenschutz bei lokaler AI).
Benchmarks ersetzen keine eigenen Testfälle aus der echten Arbeit.

Goldstandard: Du kannst den Begriff einem Laien erklären, einen realistischen Fall damit bearbeiten, Grenzen sauber benennen, Nachweise dokumentieren und erklären, welche Entscheidung du warum getroffen hast.

Quick-Check