Ollama erklärt: offene KI-Modelle lokal oder hybrid betreiben, per API integrieren und mit RAG, Tool Calling und klaren Sicherheitsgrenzen nutzen.
Roland Schellhorn
Ollama macht es einfach, offene KI-Modelle auf einem eigenen Computer oder Server auszuführen und über eine einheitliche Schnittstelle in Anwendungen einzubinden. Modelle lassen sich über die Kommandozeile laden, lokal ansprechen und über eine API für Chat, Automatisierung, Suche oder Softwareentwicklung verwenden.
„Lokal“ bedeutet dabei nicht automatisch „sicher“ oder „kostenlos“. Hardware, Modelllizenz, Netzwerkfreigaben, Protokollierung und angebundene Werkzeuge bestimmen, wie kontrollierbar eine Lösung tatsächlich ist. Dieser Leitfaden zeigt deshalb neben den Funktionen auch die Architektur- und Betriebsfragen.
Die offizielle Ollama-Dokumentation beschreibt Ollama als Laufzeit, mit der offene Modelle in Desktop-Apps und Coding-Agenten verwendet oder in eigene Anwendungen eingebaut werden können. Lokale Modelle werden auf dem eigenen Gerät ausgeführt; zusätzlich können Cloud-Modelle über denselben Werkzeug- und API-Ansatz genutzt werden.
Ollama ist kein einzelnes Sprachmodell. Es verwaltet Modelle, lädt sie bei Bedarf, stellt Inference-Endpunkte bereit und vereinheitlicht die Nutzung unterschiedlicher Modellfamilien. Welche Fähigkeiten verfügbar sind, hängt vom gewählten Modell ab – etwa Text, Bildverständnis, Tool Calling, Thinking oder Embeddings.
Ollama ist für macOS, Windows und Linux erhältlich. Nach der Installation kann ein Modell aus der Bibliothek geladen und gestartet werden. Für Anwendungen läuft der lokale Dienst typischerweise unter http://localhost:11434. Die API-Einführung dokumentiert getrennte Basis-URLs für die native Ollama API sowie OpenAI- und Anthropic-kompatible Clients.
Vor der Modellauswahl solltest du Arbeitsspeicher beziehungsweise VRAM, Kontextlänge, Antwortgeschwindigkeit, Lizenz und gewünschte Fähigkeiten prüfen. Ein größeres Modell ist nicht automatisch die wirtschaftlichste Wahl: Für Klassifizierung, Extraktion oder Embeddings reichen oft kleinere spezialisierte Modelle.
Ein Modelfile beschreibt, auf welchem Basismodell eine Variante aufbaut und wie Parameter, Systemanweisung, Prompt-Vorlage, Adapter oder Lizenzinformationen gesetzt werden. Dadurch werden wiederholbare Modellkonfigurationen versionierbar.
Ein Modelfile ersetzt kein Training und macht fremde Modelle nicht automatisch kompatibel. Systemanweisungen sind außerdem keine Sicherheitsgrenze. Berechtigungen für Dateien, APIs oder Aktionen müssen außerhalb des Modells technisch durchgesetzt werden.
Die lokale Ollama API stellt unter anderem Endpunkte für Chat, Generierung, Modellverwaltung und Embeddings bereit. Zusätzlich können bestehende Werkzeuge über kompatible OpenAI- oder Anthropic-Basis-URLs angebunden werden. Das reduziert Integrationsaufwand, doch nicht jedes anbieterspezifische Feature ist zwangsläufig identisch.
Für produktive Anwendungen sollten Timeouts, Streaming, Parallelität, Modellwechsel und Fehlerfälle ausdrücklich behandelt werden. Die API ist laut Dokumentation auf Stabilität und Rückwärtskompatibilität ausgelegt, aber nicht strikt versioniert.
Mit Tool Calling kann ein unterstütztes Modell Funktionen auswählen und deren Ergebnisse in eine Antwort einbeziehen. Das ermöglicht Agenten, die beispielsweise Daten abfragen, Berechnungen durchführen oder interne Prozesse vorbereiten.
Strukturierte Ausgaben begrenzen Antworten auf ein JSON-Schema. Das erleichtert Validierung und Weiterverarbeitung, garantiert aber nicht, dass die enthaltenen Werte fachlich korrekt sind. Schema-Validierung, Berechtigungsprüfung und Geschäftsregeln bleiben Aufgabe der Anwendung.
Ollama kann mit dafür geeigneten Modellen Embeddings erzeugen. Sie bilden Texte als Zahlenvektoren ab und sind eine Grundlage für semantische Suche und Retrieval-Augmented Generation (RAG). Dabei sucht die Anwendung relevante Abschnitte aus einer eigenen Wissensbasis und gibt sie dem Sprachmodell als Kontext.
Die Qualität hängt nicht nur vom Modell ab. Dokumentaufteilung, Metadaten, Zugriffsfilter, Aktualisierung, Ranking und Quellenanzeige entscheiden darüber, ob die Antwort nützlich und nachvollziehbar ist. Besonders wichtig: Die Suche darf keine Dokumente liefern, die der anfragende Benutzer nicht sehen darf.
Ollama kann CPU- und je nach Plattform unterschiedliche GPU-Beschleunigung nutzen. Die aktuelle Hardware-Dokumentation listet unterstützte NVIDIA-, AMD-, Apple- und weitere Laufzeitpfade. Ob ein Modell vollständig in den verfügbaren Speicher passt, beeinflusst Geschwindigkeit und mögliche Kontextlänge erheblich.
Eine seriöse Dimensionierung misst reale Prompts: Zeit bis zum ersten Token, Tokens pro Sekunde, gleichzeitige Anfragen, Speicherbedarf und Qualitätsanforderungen. Quantisierung reduziert den Speicherbedarf, kann aber je nach Modell und Aufgabe Qualität kosten.
Lokale Inference bietet kurze Datenwege und direkte Kontrolle über Laufzeit und Modelle. Cloud-Modelle ermöglichen größere Modelle ohne eigene GPU und werden über Ollamas Schnittstellen ähnlich angesprochen. Ein hybrider Ansatz kann lokale Standardaufgaben mit bewusst freigegebenen Cloud-Anfragen kombinieren.
Die passende Variante hängt von Datenschutz, Latenz, Verfügbarkeit, Modellqualität und Betriebskosten ab. Wenn eine Anwendung Cloud-Modelle, Websuche oder externe Werkzeuge nutzt, verlassen Daten möglicherweise die lokale Umgebung. Das muss im Datenfluss sichtbar und konfigurierbar sein.
Ein lokaler Ollama-Dienst sollte nicht ungeschützt ins Internet gestellt werden. Für Team- oder Serverbetrieb gehören Reverse Proxy, Authentifizierung, TLS, Netzwerksegmentierung, Rate Limits und Protokollierung vor die API. Modell- und Anwendungsdaten benötigen außerdem geregelte Updates, Backups und Löschkonzepte.
BIT62 unterstützt bei Modellwahl, Hardware-Dimensionierung, API-Integration, RAG, Tool Calling, Containerbetrieb, Zugriffsschutz und Monitoring. Ziel ist keine lokale KI um jeden Preis, sondern eine nachvollziehbare Architektur, die Qualität, Datenschutz und Betrieb zusammenbringt.
Modelle auf eigener CPU, GPU und eigenem Speicher ausführen.
Größe, Fähigkeiten und Lizenz passend zur Aufgabe wählen.
Eigene Anwendungen und kompatible Werkzeuge anbinden.
Funktionen aufrufen und strukturierte Ausgaben validieren.
Private Wissensbestände semantisch suchen und belegen.
Zugriff, Netzwerk, Updates und Monitoring kontrollieren.
| Merkmal | Lokal | Cloud | Hybrid |
|---|---|---|---|
| Eigene GPU erforderlich | Ja | Nein | optional |
| Datenpfad vollständig lokal möglich | Ja | Nein | teilweise |
| Sehr große Modelle ohne eigene Hardware | eingeschränkt | Ja | Ja |
| Offline nutzbar | Ja | Nein | teilweise |
| Eigener Betriebsaufwand | hoch | niedrig | mittel |
| Flexible Aufgabenverteilung | eingeschränkt | eingeschränkt | Ja |
Modell, Kontext und Parallelität anhand echter Lastprofile dimensionieren.
API, RAG und Tools mit Authentifizierung und minimalen Rechten schützen.
Latenz, Durchsatz, Speicher und Qualität gemeinsam beobachten.
Timeouts, Streaming, Validierung und Modellwechsel in der Anwendung behandeln.
Quellen, Metadaten, Berechtigungen und Aktualisierung von Anfang an planen.
Runtime, Modelle und Abhängigkeiten getestet und reproduzierbar aktualisieren.
Qualität, Antwortzeit, Daten und Erfolgskriterien konkret festlegen.
Mit repräsentativen Beispielen und nicht nur öffentlichen Benchmarks testen.
Speicher, Kontextlänge, Parallelität und Spitzenlast realistisch prüfen.
Authentifizierung, TLS, Netzwerkgrenzen und Rate Limits ergänzen.
Antworten, strukturierte Daten, Quellen und Tool-Aufrufe automatisiert testen.
Monitoring, Updates, Backups, Lizenzen und Verantwortlichkeiten dokumentieren.
BIT62 verbindet lokale Modelle, APIs und eigene Daten zu einer überprüfbaren und wartbaren Lösung.