Homelab--Bratonein-Kontrollzentrum--Tutorial/Kapitel 18/Free Rohtext.md

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:

  ssh root@<IP-des-Containers>
  

  Ersetze <IP-des-Containers> 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:

apt update && apt upgrade -y

Container neu starten:

reboot

Danach wieder einloggen:

ssh root@<IP-des-Containers>

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:

curl -fsSL https://ollama.com/install.sh | sh

Nach Abschluss prüfe den Dienststatus:

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

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

curl http://localhost:11434/api/tags

Wenn eine leere JSON-Liste zurückkommt, ist der Server bereit:

[]

👉 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:

ollama pull mistral

Nach dem Download prüfen, ob es korrekt installiert wurde:

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:

ollama pull phi3

Anschließend erneut prüfen:

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:

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:

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:

curl http://localhost:11434/api/tags

Wenn eine JSON-Antwort erscheint, z. B.:

[{"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:

systemctl status ollama

Wenn der Status active (running) lautet,
kannst du mit ss kontrollieren, ob der Port intern aktiv ist:

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	<IP-des-Ollama-Containers>
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:

curl -k https://ollama.deinedomain.tld/api/tags

Wenn du eine JSON-Antwort erhältst, z. B.:

[{"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:

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:

{
  "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):

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:

ufw allow from <IP-des-NPM-Containers> to any port 11434
ufw deny 11434
ufw enable

Anschließend den Status prüfen:

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:

ssh root@<IP-des-Ollama-Containers>

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:

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:

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:

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:

ollama run phi3

Phi-3 eignet sich besonders für kreative Texte, Storylines oder Ideenentwürfe.

Modelle aktualisieren oder löschen

Aktualisieren:

ollama pull mistral

Entfernen:

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

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.

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:

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:

systemctl status ollama

Wenn dort inactive oder failed steht, starte ihn neu:

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

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:

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

ollama list

Wenn das Modell fehlt oder eine ungewöhnliche Größe hat, lade es neu:

ollama pull mistral

Testlauf mit Debug-Informationen

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:

systemctl status ollama

Wenn er aktiv ist, teste die direkte Verbindung aus dem NPM-Container:

curl http://<IP-des-Ollama-Containers>:11434/api/tags

Wenn keine Antwort kommt, stimmt etwas mit der Firewall oder dem Routing nicht.

Firewall-Regeln prüfen

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:

ufw allow from <IP-des-NPM-Containers> to any port 11434
ufw reload

Danach den Zugriff erneut testen.
Wenn du dich vertippt hast, kannst du falsche Regeln mit

ufw delete <Nummer>

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:

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

ping google.com

Wenn keine Antwort kommt, fehlt die Netzverbindung.
Prüfe die DNS-Einstellungen:

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:

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.

htop

Damit kannst du sehen, welches Modell gerade aktiv ist.
Beende unnötige Prozesse mit:

pkill ollama

Starte den Container anschließend neu, um Speicher freizugeben:

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.

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