# Kapitel 18 – Ollama (Lokale KI-Inferenz) ## Einleitung Künstliche Intelligenz ist längst kein Zukunftsthema mehr – sie ist ein Werkzeug. Für viele Aufgaben im Homelab, in der Automatisierung oder Content-Produktion kann eine lokal laufende KI enorme Vorteile bringen: Antworten in Echtzeit, volle Kontrolle über Daten und keine Abhängigkeit von Cloud-Diensten. **Ollama** ist eine Open-Source-Plattform, die genau das ermöglicht. Sie erlaubt es, Sprachmodelle (z. B. Llama 3, Mistral, Phi oder Gemma) direkt auf deinem eigenen System auszuführen – entweder CPU-basiert oder mit GPU-Beschleunigung. Damit erhältst du eine **lokale Chat- und Inferenz-Engine**, die du in Tools wie n8n, Affine, deinem Kontrollzentrum oder eigenen Apps einsetzen kannst. Kein API-Key, keine Kosten, kein Tracking – volle Datensouveränität. 👉 **Screenshot geeignet:** UCC-Dashboard mit markiertem „Ollama“-Container, sichtbar neben n8n und Nextcloud > [!NOTE] > Ollama ist kein einzelnes KI-Modell, sondern eine Laufzeitumgebung. > Sie stellt einen lokalen API-Server bereit, über den du beliebige Modelle laden, verwalten und abfragen kannst. > Die Modelle selbst sind eigenständige Dateien und können unabhängig voneinander installiert oder entfernt werden. Nach diesem Kapitel hast du eine vollständig funktionsfähige lokale KI-Umgebung, die du direkt über die Kommandozeile, per HTTP-Request oder in anderen UCC-Diensten ansprechen kannst. --- ## Voraussetzungen & Ressourcen Ollama lässt sich auch auf schwächerer Hardware stabil betreiben – entscheidend ist die richtige Modellauswahl. Da dein Host ein älterer Office-PC ist, liegt der Fokus auf effizientem Ressourceneinsatz statt maximaler Leistung. ### Container-Ressourcen * **CPU:** 4 vCPU Ollama nutzt Multithreading, daher sind vier virtuelle Kerne sinnvoll. Weniger funktioniert, verlängert aber die Antwortzeiten. * **RAM:** 8 GB Für leichte Modelle wie Phi-3 Mini, Gemma 2B oder Mistral 7B in Q4-Quantisierung ausreichend. Wichtig ist, dass nie mehrere große Modelle gleichzeitig geladen werden. * **Speicherplatz:** 50 GB Modelle liegen als `.gguf`-Dateien lokal im Container. Plane je nach Modellgröße zwischen 4 und 15 GB ein, plus 10 GB Reserve für temporäre Daten. * **Netzwerk:** Statische IP oder DHCP-Reservierung Damit andere Container (z. B. n8n oder Affine) die API zuverlässig erreichen. * **Betriebssystem:** Debian 12 (Bookworm) Stabil, ressourcenschonend und optimal für den Einsatz auf älterer Hardware. 👉 **Screenshot geeignet:** Proxmox-Maske beim Erstellen des Ollama-Containers (4 vCPU | 8 GB RAM | 50 GB Storage | Debian 12) ### Technische Voraussetzungen Vor der Einrichtung sollte dein UCC folgendes erfüllen: * **Proxmox VE** ist betriebsbereit und kann Container erstellen. * **Nginx Proxy Manager (NPM)** ist installiert und erreichbar. * **DNS-Eintrag** für `ollama.deinedomain.tld` zeigt auf deinen Server. * **Internetverbindung** ist stabil – Modelle werden online geladen. * **SSH-Zugriff** auf den Container funktioniert: ```bash ssh root@ ``` Ersetze `` durch die tatsächliche Adresse des Ollama-LXC. > [!IMPORTANT] > GPU-Unterstützung ist hier nicht vorgesehen. > Ollama läuft vollständig CPU-basiert und kann trotzdem stabile Ergebnisse liefern, > solange Modelle mit moderater Parameterzahl (bis 7B) verwendet werden. --- ### Schritt 1 – Container vorbereiten und System aktualisieren Starte den frisch erstellten Ollama-Container in Proxmox und öffne die Konsole (Web-Shell oder SSH). Systempakete aktualisieren: ```bash apt update && apt upgrade -y ``` Container neu starten: ```bash reboot ``` Danach wieder einloggen: ```bash ssh root@ ``` > [!NOTE] > Ein aktuelles System verhindert Installationsfehler und Abbrüche beim Laden der Modelle. 👉 **Screenshot geeignet:** Proxmox-Konsole nach erfolgreichem `apt upgrade` ### Schritt 2 – Ollama installieren Ollama stellt ein offizielles Installationsskript bereit, das automatisch alle Abhängigkeiten einrichtet und den Dienst als systemd-Service konfiguriert. Führe im Container folgenden Befehl aus: ```bash curl -fsSL https://ollama.com/install.sh | sh ``` Nach Abschluss prüfe den Dienststatus: ```bash systemctl status ollama ``` Die Ausgabe sollte `active (running)` anzeigen. > [!NOTE] > Der Dienst startet automatisch beim Booten des Containers und lauscht auf Port `11434`. > Sollte die Ausgabe `inactive` oder `failed` lauten, kontrolliere mit > ```bash > journalctl -u ollama -xe > ``` > ob Pakete oder Abhängigkeiten fehlgeschlagen sind. 👉 **Screenshot geeignet:** Terminalausgabe von `systemctl status ollama` mit aktivem Dienst ### Schritt 3 – Erste Funktionsprüfung & Modelle installieren Nach der erfolgreichen Installation läuft der Ollama-Dienst bereits im Hintergrund. Jetzt prüfst du, ob die API reagiert und lädst anschließend die beiden benötigten Modelle. #### Installation prüfen ```bash curl http://localhost:11434/api/tags ``` Wenn eine leere JSON-Liste zurückkommt, ist der Server bereit: ```json [] ``` 👉 **Screenshot geeignet:** Terminalausgabe von `curl /api/tags` mit leerer JSON-Liste #### Modell 1 – Mistral 7B Dieses Modell übernimmt die strukturierten Aufgaben innerhalb deines UCC – z. B. präzise Auswertungen, systemnahe Antworten oder die Verarbeitung von Nachrichten, die über WAHA eingehen. Modell herunterladen: ```bash ollama pull mistral ``` Nach dem Download prüfen, ob es korrekt installiert wurde: ```bash ollama list ``` In der Ausgabe sollte `mistral` erscheinen. 👉 **Screenshot geeignet:** Terminalausgabe von `ollama list` mit sichtbarem Eintrag `mistral` #### Modell 2 – Phi-3 Mini Phi-3 ist kompakt und läuft stabil auch auf schwächerer Hardware. Es eignet sich ideal für natürlich klingende, kreative Texte und ergänzt Mistral in allen inhaltlich offeneren Aufgaben. Modell laden: ```bash ollama pull phi3 ``` Anschließend erneut prüfen: ```bash ollama list ``` Beide Modelle sollten nun angezeigt werden: `mistral` und `phi3`. 👉 **Screenshot geeignet:** Terminalausgabe von `ollama list` mit sichtbaren Modellen `mistral` und `phi3` ### Schritt 4 – Funktionstest und erste Abfrage Nach der Installation und dem Laden beider Modelle folgt nun der Praxistest. Damit stellst du sicher, dass Ollama korrekt arbeitet und die Modelle einsatzbereit sind. #### Test mit Mistral Starte Mistral direkt über die Konsole: ```bash ollama run mistral ``` Nach dem Start erscheint die Eingabeaufforderung (`>>>`). Gib eine einfache Testfrage ein, die sich ohne Internetzugriff beantworten lässt: ``` Erkläre mir, was ein Container ist. ``` Mistral sollte in wenigen Sekunden eine sachliche und technisch korrekte Antwort liefern. Beende den Lauf anschließend mit `CTRL + C`. 👉 **Screenshot geeignet:** Terminal mit sichtbarer Mistral-Antwort auf Testfrage #### Test mit Phi-3 Starte danach das zweite Modell: ```bash ollama run phi3 ``` Diese Variante ist sprachlich freier und eignet sich besser für kreative Texte. Verwende deshalb eine etwas erzählerische Testfrage: ``` Beschreibe eine Fantasiewelt mit einem eigenen Kontrollzentrum. ``` Phi-3 reagiert meist mit lebendigen, bildhaften Formulierungen. Auch hier die Sitzung mit `CTRL + C` beenden. 👉 **Screenshot geeignet:** Terminal mit Phi-3-Antwort auf Testfrage > [!NOTE] > Ollama-Modelle haben **keinen Internetzugriff** und kennen weder „Bratonien“ noch dein reales System. > Sie antworten ausschließlich auf Basis des Prompt-Inhalts. > Damit sie künftig deine eigene Welt verstehen, werden wir im Premium-Kapitel zeigen, > wie du Kontextwissen und interne Dokumente lokal einbindest. ### Schritt 5 – API-Zugriff aktivieren Ollama stellt lokal eine HTTP-API bereit, über die du Anfragen aus anderen Systemen senden kannst – etwa von n8n, Affine oder deinem Kontrollzentrum. Die API läuft standardmäßig auf Port `11434`. #### Erreichbarkeit prüfen Führe im Container folgenden Befehl aus: ```bash curl http://localhost:11434/api/tags ``` Wenn eine JSON-Antwort erscheint, z. B.: ```json [{"name": "mistral"}, {"name": "phi3"}] ``` dann ist die API aktiv und betriebsbereit. 👉 **Screenshot geeignet:** Terminalausgabe von `curl /api/tags` mit sichtbaren Modellen #### Zugriff über das Netzwerk Damit andere Container im UCC (z. B. n8n oder Affine) auf die API zugreifen können, muss der Nginx Proxy Manager (NPM) den internen Port **11434** weiterleiten. Dazu braucht Ollama **keine öffentliche Bindung** – der Dienst bleibt intern und sicher. Prüfe zunächst, ob der Dienst korrekt läuft: ```bash systemctl status ollama ``` Wenn der Status `active (running)` lautet, kannst du mit `ss` kontrollieren, ob der Port intern aktiv ist: ```bash ss -tulpen | grep 11434 ``` Wird hier `127.0.0.1:11434` angezeigt, ist alles korrekt – Ollama lauscht lokal, und NPM greift intern über die Container-IP zu. > [!NOTE] > Du musst **keine** Änderung in der Ollama-Konfiguration vornehmen > (z. B. `--host 0.0.0.0`). > Der Dienst bleibt bewusst auf `localhost` beschränkt, > um keine ungeschützten Ports ins interne Netz zu öffnen. #### Proxy-Host in NPM anlegen 1. Öffne das **Nginx Proxy Manager Dashboard**. 2. Wähle **Add Proxy Host**. 3. Trage folgende Werte ein: | Feld | Wert | |------|------| | **Domain Names** | `ollama.deinedomain.tld` | | **Scheme** | `http` | | **Forward Hostname / IP** | `` | | **Forward Port** | `11434` | | **Block Common Exploits** | aktivieren | | **Websockets Support** | aktivieren | Wechsle anschließend in den Reiter **SSL** und aktiviere: - **Request a new SSL Certificate** - **Force SSL** - **HTTP/2 Support** - **HSTS Enabled** > [!NOTE] > Achte darauf, dass `ollama.deinedomain.tld` bereits im DNS > auf deinen Server zeigt und dass interne Firewalls (z. B. Proxmox oder UFW) > Verbindungen zwischen NPM und Ollama zulassen. > Eine Freigabe des Ports **11434** nach außen ist nicht erforderlich. 👉 **Screenshot geeignet:** NPM-Dashboard mit geöffnetem Proxy-Host `ollama.deinedomain.tld` #### Verbindung testen Öffne im Browser: ``` https://ollama.deinedomain.tld/api/tags ``` Wenn du dieselbe JSON-Ausgabe erhältst wie zuvor, ist die API über HTTPS erreichbar. Ab diesem Punkt können n8n, Affine oder andere UCC-Dienste Ollama direkt über Requests ansprechen. > [!TIP] > Im Premium-Kapitel lernst du, wie Ollama über **llm-axe** zusätzlich aktuelle Webdaten beziehen kann, > um Antworten mit externen Informationen zu erweitern – bei weiterhin vollständiger lokaler Kontrolle. ### Schritt 6 – API-Nutzung aus einem anderen Container Nachdem die Ollama-API über den Nginx Proxy Manager eingerichtet wurde, kann sie jetzt von jedem anderen Container im UCC-Netzwerk angesprochen werden. Dieser Schritt zeigt, wie du die Verbindung praktisch nutzt – ohne zusätzliche Tools oder Oberflächen. #### Zugriff aus einem anderen LXC prüfen Wechsle in die Konsole eines anderen Containers, z. B. deines n8n-LXC oder eines beliebigen Debian-Containers im selben Netz, und führe folgenden Befehl aus: ```bash curl -k https://ollama.deinedomain.tld/api/tags ``` Wenn du eine JSON-Antwort erhältst, z. B.: ```json [{"name":"mistral"},{"name":"phi3"}] ``` dann ist die Verbindung erfolgreich und die API von außen erreichbar. 👉 **Screenshot geeignet:** Terminalausgabe im anderen Container mit erfolgreicher JSON-Antwort > [!NOTE] > Die Option `-k` ignoriert Zertifikatswarnungen. > Bei gültigem Let’s-Encrypt-Zertifikat kann sie entfallen. #### Erste API-Abfrage an ein Modell Um die API praktisch zu testen, sende eine kurze Anfrage an das Mistral-Modell: ```bash curl -X POST https://ollama.deinedomain.tld/api/generate \ -H "Content-Type: application/json" \ -d '{ "model": "mistral", "prompt": "Erkläre in einem Satz, was ein Homelab ist." }' ``` Wenn alles funktioniert, antwortet Ollama mit einem JSON-Block, der den generierten Text enthält: ```json { "model": "mistral", "created_at": "2025-10-22T17:32:00Z", "response": "Ein Homelab ist eine private IT-Umgebung zum Lernen, Testen und Automatisieren." } ``` 👉 **Screenshot geeignet:** Terminalausgabe mit erfolgreicher API-Antwort #### Verwendung im Alltag Über diese Schnittstelle kannst du Ollama ab jetzt aus beliebigen Skripten, Shell-Befehlen oder Tools im UCC aufrufen – z. B. zur Textgenerierung, Zusammenfassung von Logs oder automatisierten Statusmeldungen. Der Aufruf bleibt dabei vollständig lokal und erfordert keine Cloud-Verbindung. > [!TIP] > Diese API bildet die technische Grundlage für spätere Erweiterungen – > etwa automatisierte Workflows oder grafische Oberflächen. > Für den Moment genügt sie, um Ollama sicher aus jedem Container im UCC zu steuern. ### Schritt 7 – Zugriff absichern Damit die Ollama-API nicht von außen erreichbar ist, muss der Zugriff konsequent über den Nginx Proxy Manager (NPM) und die interne Firewall geschützt werden. Dieser Schritt ist zwingend erforderlich, um unbefugten Zugriff auf dein System zu verhindern. #### Zugriff über NPM absichern Öffne das Dashboard des **Nginx Proxy Manager** und bearbeite den Proxy-Host `ollama.deinedomain.tld`. Wechsle in den Reiter **Access List** und lege eine neue Zugriffsregel an: 1. **Add Access List** → Name: `ollama-intern` 2. Unter *Access* aktiviere - **Authorization:** „HTTP Basic Authentication“ - Lege einen sicheren Benutzernamen und ein starkes Passwort fest. 3. Unter *Access Control* wähle - **Allow IP Addresses:** den internen Adressbereich deines UCC (z. B. `192.168.100.0/24`) - Alle anderen Zugriffe werden automatisch blockiert. Speichern und im Proxy-Host diese Access-List aktivieren. > [!NOTE] > Damit ist Ollama ausschließlich intern erreichbar > und erfordert bei jedem Aufruf Benutzername und Passwort. 👉 **Screenshot geeignet:** NPM-Dashboard mit aktivierter Access-List „ollama-intern“ #### Zugriff testen Von einem erlaubten Container (z. B. n8n-LXC): ```bash curl -u benutzername:passwort -k https://ollama.deinedomain.tld/api/tags ``` Wenn du die korrekten Zugangsdaten angibst, antwortet die API wie gewohnt mit der Modellliste. Ohne Authentifizierung oder von einer nicht freigegebenen IP erscheint die Meldung `403 Forbidden`. 👉 **Screenshot geeignet:** Terminalausgabe mit erfolgreicher Authentifizierung #### Firewall-Regeln im Ollama-LXC setzen Der API-Port 11434 muss zusätzlich auf Systemebene abgesichert werden. Erlaubt wird ausschließlich der Zugriff vom NPM-Container. Führe im Ollama-LXC folgende Befehle aus: ```bash ufw allow from to any port 11434 ufw deny 11434 ufw enable ``` Anschließend den Status prüfen: ```bash ufw status numbered ``` Die Ausgabe sollte zeigen, dass **nur die NPM-IP** Zugriff auf Port 11434 hat. 👉 **Screenshot geeignet:** Terminalausgabe von `ufw status numbered` mit aktiver Regel > [!IMPORTANT] > Ohne diese Firewall-Regeln bleibt der Port im internen Netz offen. > Das wäre ein kritisches Sicherheitsrisiko – führe diesen Schritt daher immer durch. #### Ergebnis Die Ollama-API ist jetzt: - nur über den internen Proxy erreichbar, - durch HTTP-Authentifizierung geschützt, - über die Firewall auf NPM-IP beschränkt, - und damit vollständig abgeschottet gegen direkten Zugriff. Das System ist damit sicher, stabil und bereit für alle weiteren Integrationen innerhalb deines UCC. ### Schritt 8 – Nutzung über die lokale CLI Neben der API kannst du Ollama auch direkt im Container verwenden. Das ist der schnellste Weg, um Modelle zu testen, einfache Texte zu generieren oder Systemfunktionen zu prüfen – ohne dass eine Netzwerkverbindung oder Proxy nötig ist. Alle Befehle in diesem Schritt führst du **innerhalb des Ollama-Containers** aus, entweder über die Proxmox-Konsole oder per SSH: ```bash ssh root@ ``` Nach dem Login steht dir die Ollama-CLI zur Verfügung. #### Verfügbare Modelle anzeigen Um zu prüfen, welche Modelle auf deinem System vorhanden sind: ```bash ollama list ``` Beispielausgabe: ``` NAME ID SIZE MODIFIED mistral 5d43f1d3bdfd 4.1GB 3 days ago phi3 e2412cd927a8 2.8GB 2 days ago ``` 👉 **Screenshot geeignet:** Terminalausgabe mit sichtbaren Modellen #### Interaktive Sitzung starten Um direkt mit einem Modell zu interagieren, starte es über: ```bash ollama run mistral ``` Sobald die Eingabeaufforderung (`>>>`) erscheint, kannst du Fragen stellen: ``` >>> Was ist ein Homelab? Ein Homelab ist eine private IT-Umgebung, in der Systeme, Server und Netzwerke zu Lern- oder Testzwecken betrieben werden. ``` Beende die Sitzung mit `CTRL + C`. 👉 **Screenshot geeignet:** Terminal mit laufender Mistral-Sitzung und Antwort #### Einmalige Abfrage (non-interaktiv) Für einfache Einzelfragen kannst du den Prompt direkt mitgeben: ```bash ollama run mistral "Erkläre kurz den Unterschied zwischen Container und virtueller Maschine." ``` Das Modell gibt eine einmalige Antwort zurück und beendet sich automatisch. #### Modelle wechseln Du kannst jederzeit ein anderes Modell verwenden: ```bash ollama run phi3 ``` Phi-3 eignet sich besonders für kreative Texte, Storylines oder Ideenentwürfe. #### Modelle aktualisieren oder löschen Aktualisieren: ```bash ollama pull mistral ``` Entfernen: ```bash ollama rm phi3 ``` > [!NOTE] > Der Befehl `pull` benötigt eine aktive Internetverbindung, um das Modell neu zu laden. > In Offline-Umgebungen bleiben vorhandene Modelle funktionsfähig. #### Beispiel: praktische Nutzung ```bash ollama run mistral "Schreibe eine kurze Streamankündigung für Bratonien_TV." ``` Erwartete Antwort: ``` "🎬 Der Stream ist live! Willkommen zu einem neuen Abend voller Chaos, Magie und Möhrenpower." ``` 👉 **Screenshot geeignet:** Terminalausgabe mit generierter Beispielantwort #### Ergebnis Ollama ist jetzt vollständig nutzbar: - Du kannst Modelle direkt über die CLI starten. - Anfragen funktionieren ohne Internetverbindung. - Alle Aktionen laufen lokal im Container. ## Troubleshooting & Tipps Ollama läuft im Normalbetrieb sehr stabil. Trotzdem kann es – besonders auf älterer Hardware oder bei ersten Installationen – zu Problemen kommen. In diesem Abschnitt lernst du, wie du typische Fehler erkennst, Ursachen findest und dein System stabil hältst. ### Ollama startet nicht Wenn Ollama sich nicht starten lässt oder direkt wieder beendet wird, liegt das meist an zu wenig Arbeitsspeicher oder beschädigten Dateien. #### Arbeitsspeicher prüfen Ollama lädt komplette Modelle in den RAM. Ist zu wenig Speicher frei, startet der Dienst gar nicht erst oder bricht beim Laden ab. ```bash free -h ``` In der Zeile **Mem:** siehst du, wie viel Arbeitsspeicher belegt ist und wie viel noch frei ist. Wenn weniger als 2 GB frei sind, reicht das nicht aus, um ein Modell zu laden. Starte den Container neu, um Arbeitsspeicher freizugeben: ```bash reboot ``` > [!NOTE] > Bei 8 GB Gesamtspeicher sollte Ollama mindestens 6 GB reserviert bekommen. > Andernfalls kann das Modell nicht stabil geladen werden. #### Dienststatus prüfen Wenn genug Speicher vorhanden ist, prüfe, ob der Dienst aktiv ist: ```bash systemctl status ollama ``` Wenn dort **inactive** oder **failed** steht, starte ihn neu: ```bash systemctl restart ollama ``` Zeigt der Status anschließend **active (running)**, läuft der Dienst korrekt. Wenn er erneut fehlschlägt, schaue dir die Logdateien an. #### Logdateien prüfen ```bash journalctl -u ollama -xe ``` Die Ausgabe zeigt, warum der Dienst nicht startet. Häufige Ursachen sind: - beschädigte oder unvollständige Modelldateien - kein freier Speicherplatz auf der Systempartition - fehlende Berechtigungen Wenn ein Modell beschädigt ist, entferne es und lade es neu: ```bash ollama rm mistral ollama pull mistral ``` > [!TIP] > Wenn Ollama nach einem Neustart automatisch wieder startet, ist alles korrekt konfiguriert. > Sollte der Dienst dauerhaft ausfallen, prüfe die Datei `/etc/systemd/system/ollama.service`. > Achte darauf, dass dort `Restart=always` gesetzt ist. ### Modelle reagieren nicht oder brechen ab Wenn ein Modell zwar startet, aber nicht antwortet oder mitten im Text abbricht, liegt das meist an Speicherproblemen oder unvollständigen Downloads. #### Modellverfügbarkeit prüfen ```bash ollama list ``` Wenn das Modell fehlt oder eine ungewöhnliche Größe hat, lade es neu: ```bash ollama pull mistral ``` #### Testlauf mit Debug-Informationen ```bash ollama run mistral -v ``` Der Parameter `-v` zeigt dir den Fortschritt beim Laden. Wenn der Prozess bei „Loading model…“ stehen bleibt, hat Ollama nicht genug RAM oder die Datei ist defekt. > [!NOTE] > Beende alle laufenden Sitzungen mit `CTRL + C`, bevor du ein neues Modell startest. > Mehrere aktive Prozesse können den Speicher blockieren. ### API antwortet nicht Wenn du über den Browser oder per `curl` keine Antwort erhältst, kann die Verbindung zwischen Ollama und dem Nginx Proxy Manager (NPM) unterbrochen sein. #### Verbindung prüfen Prüfe zunächst, ob der Ollama-Dienst läuft: ```bash systemctl status ollama ``` Wenn er aktiv ist, teste die direkte Verbindung aus dem NPM-Container: ```bash curl http://:11434/api/tags ``` Wenn keine Antwort kommt, stimmt etwas mit der Firewall oder dem Routing nicht. #### Firewall-Regeln prüfen ```bash ufw status numbered ``` Achte darauf, dass die IP-Adresse des NPM-Containers für Port 11434 freigegeben ist. Wenn keine entsprechende Regel vorhanden ist, füge sie hinzu: ```bash ufw allow from to any port 11434 ufw reload ``` Danach den Zugriff erneut testen. Wenn du dich vertippt hast, kannst du falsche Regeln mit ```bash ufw delete ``` entfernen. Die Nummer siehst du in der Ausgabe von `ufw status numbered`. > [!TIP] > Wenn der Browser trotz korrekter Firewall keine Verbindung aufbaut, starte den NPM-Container neu: > ```bash > docker restart npm-app > ``` ### Modelle laden nicht oder brechen beim Download ab Wenn `ollama pull` mit Fehlermeldungen stoppt oder sehr langsam lädt, liegt das meist an DNS-Problemen oder instabiler Verbindung. #### Internetverbindung prüfen ```bash ping google.com ``` Wenn keine Antwort kommt, fehlt die Netzverbindung. Prüfe die DNS-Einstellungen: ```bash cat /etc/resolv.conf ``` Falls die Datei leer ist oder fehlerhafte Einträge enthält, setze die Nameserver neu (z. B. `1.1.1.1` oder `8.8.8.8`). #### Download neu starten Wenn ein Modell unvollständig heruntergeladen wurde, entferne es und lade es neu: ```bash ollama rm mistral ollama pull mistral ``` > [!NOTE] > Wenn die Verbindung regelmäßig abbricht, liegt das Problem meist am Hostnetzwerk oder einer Proxy-Instanz. > Teste den Download direkt im Hostsystem – wenn er dort stabil ist, prüfe die Container-Netzwerkkonfiguration. ### Hohe CPU- oder RAM-Auslastung Wenn Ollama dauerhaft hohe CPU-Last oder Speicherverbrauch zeigt, liegt das meist an zu vielen gleichzeitig laufenden Prozessen. ```bash htop ``` Damit kannst du sehen, welches Modell gerade aktiv ist. Beende unnötige Prozesse mit: ```bash pkill ollama ``` Starte den Container anschließend neu, um Speicher freizugeben: ```bash reboot ``` Wenn die Auslastung danach weiter hoch bleibt, erhöhe die CPU-Zuteilung oder reduziere die Anzahl gleichzeitig geladener Modelle. > [!TIP] > Eine dedizierte CPU-Zuweisung in Proxmox (z. B. 2 Kerne fest, keine Lastverteilung) sorgt für stabileres Verhalten. ### Logdateien und Statusüberwachung Ollama protokolliert alle Ereignisse über das Systemjournal. Das ist hilfreich, um Startverhalten und API-Aufrufe nachzuvollziehen. ```bash journalctl -u ollama -f ``` Damit siehst du in Echtzeit, welche Anfragen ankommen und ob Fehler auftreten. > [!TIP] > Wenn Ollama längere Zeit stabil läuft, ändere an der Grundkonfiguration nichts. > Teste neue Modelle oder Versionen immer zuerst in einem separaten Container. > Das verhindert Konflikte und sichert dir ein zuverlässiges Hauptsystem. --- ## Ergebnis Mit diesem Kapitel hast du ein voll funktionsfähiges, lokales KI-System in dein UCC integriert. Ollama läuft stabil, ist abgesichert und kann sowohl über die Konsole als auch über die interne API genutzt werden. Alle Vorgänge bleiben vollständig innerhalb deiner eigenen Infrastruktur – keine Cloud, keine externen Server, keine Abhängigkeiten. ### Dein aktueller Stand - **Ollama-Container** ist eingerichtet und betriebsbereit - **API-Zugriff** funktioniert sicher über den internen Proxy - **Modelle Mistral und Phi-3** sind geladen und getestet - **Firewall- und Zugriffsschutz** sind aktiv - **CLI-Nutzung** erlaubt direkte Arbeit im Container - **Fehlerdiagnose und Logs** sind bekannt und überprüft Damit steht dir nun ein autarkes, datensicheres KI-System zur Verfügung, das sich in deine bestehende UCC-Umgebung nahtlos einfügt. Du kannst Ollama direkt für eigene Projekte verwenden oder als Grundlage für zukünftige Erweiterungen nutzen. > [!TIP] > In den erweiterten Kapiteln werden diese Grundlagen ausgebaut: > Dort geht es um komfortablere Bedienung, Automatisierungen und erweiterte Einsatzmöglichkeiten – > die Basis bleibt jedoch immer dein hier aufgebautes, lokales System. 👉 **Screenshot geeignet:** Proxmox-Interface mit aktivem Ollama-Container, daneben NPM- und n8n-Container sichtbar