Kapitel 18/Premium Rohtext.mde hinzugefügt
This commit is contained in:
Thomas committed
1 parent
dfc1ce2b92
commit
39c9a5e9df
1 file changed
+506
@@ -0,0 +1,506 @@
|
||||
# Kapitel 18 – Premium: Ollama im UCC
|
||||
|
||||
Ollama ist im UCC weit mehr als nur eine lokale KI-Engine.
|
||||
In der Free-Version wurde die Basis gelegt – ein Container, der Sprachmodelle lokal bereitstellt.
|
||||
In diesem Premium-Kapitel wird Ollama zu einer **vollwertigen, interaktiven KI-Plattform**,
|
||||
die GPU-Beschleunigung nutzt, eine eigene GUI bereitstellt, über Python gesteuert werden kann
|
||||
und sich dynamisch an die CPU-Leistung des Systems anpasst.
|
||||
|
||||
Ziel ist eine Umgebung, in der **lokale KI-Prozesse, GPU-Compute und Steuerung per API oder Interface**
|
||||
ineinandergreifen – stabil, performant und komplett offline betreibbar.
|
||||
Ollama dient hier als zentraler Baustein für Automatisierungen, Assistenz-Funktionen und Content-Workflows.
|
||||
|
||||
👉 **Screenshot geeignet:** Architekturübersicht mit Ollama LXC, GPU-Passthrough, GUI-Frontend und Python-Anbindung
|
||||
|
||||
> [!NOTE]
|
||||
> Dieses Kapitel setzt eine funktionierende Free-Installation von Ollama voraus.
|
||||
> Stelle sicher, dass dein LXC-Container läuft, über HTTPS erreichbar ist
|
||||
> und mindestens ein Modell (z. B. `llama3`, `mistral`) erfolgreich geladen wurde.
|
||||
|
||||
> [!TIP]
|
||||
> Falls dein System keine dedizierte GPU besitzt, kann dieses Kapitel trotzdem durchgeführt werden.
|
||||
> CPU-Optimierungen und GUI-Einrichtung funktionieren unabhängig vom GPU-Passthrough.
|
||||
|
||||
---
|
||||
|
||||
## GPU-Durchreichen in Proxmox
|
||||
|
||||
Damit Ollama Modelle wie `llama3`, `gemma` oder `mistral` mit maximaler Leistung ausführen kann,
|
||||
muss der LXC-Container direkten Zugriff auf die Grafikkarte erhalten.
|
||||
In diesem Abschnitt richten wir das GPU-Passthrough korrekt ein – vollständig über die Proxmox-GUI,
|
||||
aber **erst nachdem** die GPU auf Host-Ebene gemappt und für Container freigegeben wurde.
|
||||
|
||||
👉 **Screenshot geeignet:** Proxmox Host-Übersicht mit markierter GPU unter "Hardware → PCI-Geräte"
|
||||
|
||||
> [!NOTE]
|
||||
> Proxmox kann GPUs an Container nur durchreichen, wenn die Geräte im Hostsystem
|
||||
> bereits als `/dev/nvidia*` (NVIDIA) oder `/dev/dri/*` (Intel/AMD) verfügbar sind.
|
||||
> Fehlen diese Einträge, liegt das Problem **nicht** am Container, sondern am Host-Treiber.
|
||||
|
||||
### Schritt 1 – GPU-Verfügbarkeit auf dem Host prüfen
|
||||
|
||||
Öffne auf dem Proxmox-Host eine Shell:
|
||||
|
||||
```bash
|
||||
lspci | egrep "NVIDIA|AMD|Intel"
|
||||
```
|
||||
|
||||
Beispielausgabe (NVIDIA):
|
||||
```
|
||||
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070] (rev a1)
|
||||
01:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1)
|
||||
```
|
||||
|
||||
Danach prüfen, ob die Gerätedateien existieren:
|
||||
|
||||
```bash
|
||||
ls /dev/nvidia* /dev/dri/* 2>/dev/null
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Terminalausgabe mit sichtbaren `/dev/nvidia0`, `/dev/nvidiactl`, `/dev/dri/renderD128`
|
||||
|
||||
> [!TIP]
|
||||
> Wenn hier nichts erscheint, installiere zuerst die offiziellen GPU-Treiber im Host
|
||||
> (z. B. `apt install nvidia-driver` oder `apt install firmware-amd-graphics`).
|
||||
|
||||
### Schritt 2 – GPU als Device freigeben
|
||||
|
||||
1. Öffne im Proxmox-Webinterface den **Host** (nicht den Container).
|
||||
2. Gehe auf **Hardware → PCI-Geräte**.
|
||||
3. Suche deine GPU in der Liste (z. B. „NVIDIA Corporation GA104 [GeForce RTX 3070]“).
|
||||
4. Notiere die PCI-ID (z. B. `0000:01:00.0`).
|
||||
5. Stelle sicher, dass das Gerät **nicht bereits einer VM** zugeordnet ist.
|
||||
|
||||
👉 **Screenshot geeignet:** Proxmox Host-Hardwareliste mit markierter GPU und sichtbarer PCI-ID
|
||||
|
||||
> [!NOTE]
|
||||
> Für Container wird die GPU **nicht direkt** über „Hardware → GPU hinzufügen“ eingebunden,
|
||||
> sondern über die **Gerätedateien** (`/dev/nvidia*`).
|
||||
> Diese werden per GUI in den Container gemountet.
|
||||
|
||||
### Schritt 3 – Gerät per GUI an den Container anbinden
|
||||
|
||||
1. Öffne im linken Menü deinen **Ollama-Container**.
|
||||
2. Wähle **Ressourcen → Optionen → Geräte** (je nach Version auch unter *Reiter „Hardware“*).
|
||||
3. Klicke auf **Hinzufügen → Gerät → Allgemein (Custom)**.
|
||||
4. Wähle den Typ **Gerätedatei (bind mount)**.
|
||||
5. Füge nacheinander folgende Pfade hinzu (je nach GPU-Typ verfügbar):
|
||||
|
||||
```
|
||||
/dev/nvidia0
|
||||
/dev/nvidiactl
|
||||
/dev/nvidia-uvm
|
||||
/dev/dri/renderD128
|
||||
```
|
||||
|
||||
6. Aktiviere die Option **Nur Lesen deaktivieren** (d. h. Lese-/Schreibzugriff erlauben).
|
||||
7. Bestätige mit **Hinzufügen**.
|
||||
|
||||
👉 **Screenshot geeignet:** Dialogfenster „Gerät hinzufügen“ mit eingetragenem `/dev/nvidia0`
|
||||
|
||||
> [!TIP]
|
||||
> Bei Intel- oder AMD-GPUs reicht meist `/dev/dri/renderD128`.
|
||||
> NVIDIA benötigt in der Regel alle vier Gerätedateien.
|
||||
|
||||
### Schritt 4 – Container starten und GPU-Test
|
||||
|
||||
1. Starte den Container im Proxmox-Webinterface neu.
|
||||
2. Öffne die **Konsole** des Containers.
|
||||
3. Prüfe die GPU-Erkennung:
|
||||
```bash
|
||||
nvidia-smi
|
||||
```
|
||||
oder (bei AMD/Intel):
|
||||
```bash
|
||||
ls /dev/dri/
|
||||
```
|
||||
4. Wenn die GPU erkannt wird, sollte `nvidia-smi` das Modell, den Treiber und den Status anzeigen.
|
||||
|
||||
👉 **Screenshot geeignet:** Konsolenansicht mit erfolgreicher `nvidia-smi`-Ausgabe im Ollama-LXC
|
||||
|
||||
> [!NOTE]
|
||||
> Sollte keine GPU erscheinen, überprüfe im Host die Gruppenrechte:
|
||||
> ```bash
|
||||
> chmod 666 /dev/nvidia*
|
||||
> ```
|
||||
> Danach Container erneut starten.
|
||||
|
||||
### Schritt 5 – Test mit Ollama
|
||||
|
||||
Im Container:
|
||||
```bash
|
||||
ollama run llama3
|
||||
```
|
||||
|
||||
Wenn alles korrekt ist, erscheint:
|
||||
```
|
||||
GPU acceleration enabled: NVIDIA RTX 3070
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Terminalausgabe mit Hinweis „GPU acceleration enabled“
|
||||
|
||||
> [!TIP]
|
||||
> GPU-Beschleunigung bleibt nach Neustarts aktiv.
|
||||
> Nur bei Kernel- oder Treiberupdates sollte das Mapping kurz überprüft werden.
|
||||
|
||||
---
|
||||
|
||||
## GUI für Ollama
|
||||
|
||||
Die lokale GUI erweitert Ollama um eine komfortable Weboberfläche,
|
||||
mit der Modelle, Sessions und Chats übersichtlich verwaltet werden können – **direkt im selben LXC** wie Ollama selbst.
|
||||
Sie kommuniziert intern mit der Ollama-API (`http://localhost:11434`) und ist nach außen nur über den separaten Proxy-LXC (Nginx Proxy Manager) erreichbar.
|
||||
Dadurch bleibt der Container isoliert, während die Oberfläche sicher im internen Netz verfügbar ist.
|
||||
|
||||
👉 **Screenshot geeignet:** Architekturübersicht mit Ollama-LXC ↔ Proxy-LXC ↔ Client-Browser
|
||||
|
||||
> [!NOTE]
|
||||
> Diese GUI läuft vollständig lokal und benötigt keinen Internetzugang.
|
||||
> Modellverwaltung, Eingaben und Antworten bleiben im Container – keine externen API-Aufrufe.
|
||||
|
||||
### Installation im Ollama-LXC
|
||||
|
||||
1. Öffne im Proxmox-Webinterface die **Konsole** des Ollama-Containers.
|
||||
2. Aktualisiere die Paketquellen und installiere die benötigten Werkzeuge:
|
||||
|
||||
```bash
|
||||
apt update && apt install -y curl unzip
|
||||
```
|
||||
|
||||
3. Lade die aktuelle Version der Ollama-Weboberfläche herunter:
|
||||
|
||||
```bash
|
||||
curl -L -o ollama-gui.zip https://github.com/ollama-webui/ollama-webui/releases/latest/download/webui.zip
|
||||
unzip ollama-gui.zip -d /opt/ollama-webui
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Terminalausgabe mit entpackten Dateien unter `/opt/ollama-webui`
|
||||
|
||||
4. Starte die GUI testweise:
|
||||
|
||||
```bash
|
||||
cd /opt/ollama-webui
|
||||
nohup ./ollama-webui --api http://localhost:11434 --port 3000 &
|
||||
```
|
||||
|
||||
Danach ist sie intern erreichbar unter:
|
||||
|
||||
```
|
||||
http://<LXC-IP>:3000
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Browserfenster mit lokal aufgerufenem GUI-Dashboard (`http://192.168.xxx.xxx:3000`)
|
||||
|
||||
> [!TIP]
|
||||
> Die GUI sollte ausschließlich intern erreichbar bleiben.
|
||||
> Eine öffentliche Freigabe ohne Reverse Proxy ist aus Sicherheitsgründen nicht empfohlen.
|
||||
|
||||
### Autostart konfigurieren
|
||||
|
||||
Damit die GUI nach jedem Neustart automatisch startet:
|
||||
|
||||
```bash
|
||||
nano /etc/systemd/system/ollama-gui.service
|
||||
```
|
||||
|
||||
Inhalt:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Ollama Web GUI
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
ExecStart=/opt/ollama-webui/ollama-webui --api http://localhost:11434 --port 3000
|
||||
WorkingDirectory=/opt/ollama-webui
|
||||
Restart=always
|
||||
User=root
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Speichern und aktivieren:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl enable ollama-gui
|
||||
systemctl start ollama-gui
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Terminalausgabe `systemctl status ollama-gui` mit Status „active (running)“
|
||||
|
||||
> [!NOTE]
|
||||
> Der Dienst läuft im Hintergrund und startet automatisch, sobald das Netzwerk verfügbar ist.
|
||||
|
||||
### Zugriff über externen Nginx Proxy Manager (NPM-LXC)
|
||||
|
||||
Der Zugriff erfolgt über den zentralen **Nginx Proxy Manager**, der in einem eigenen LXC betrieben wird.
|
||||
Dieser leitet die Anfragen intern an den Ollama-LXC weiter.
|
||||
So bleibt der Container vollständig abgeschottet, und die GUI kann sicher unter einer eigenen Subdomain aufgerufen werden.
|
||||
|
||||
1. Öffne im NPM-Container die Weboberfläche (`https://npm.<deine-domain.tld>`).
|
||||
2. Gehe zu **Hosts → Add Proxy Host**.
|
||||
3. Trage folgende Werte ein:
|
||||
|
||||
| Feld | Wert |
|
||||
|------|------|
|
||||
| **Domain** | `ollama.<deine-domain.tld>` |
|
||||
| **Forward Hostname / IP** | IP-Adresse des Ollama-LXC (z. B. `192.168.100.42`) |
|
||||
| **Forward Port** | `3000` |
|
||||
| **Scheme** | `http` |
|
||||
| **Block Common Exploits** | aktiviert |
|
||||
| **SSL (Let's Encrypt)** | aktiviert, *Force SSL* anhaken |
|
||||
|
||||
4. Unter *Access Lists* optional Zugriffsbeschränkungen einrichten
|
||||
(z. B. nur lokale IP-Bereiche oder Benutzer-Authentifizierung aktivieren).
|
||||
5. Speichern und den Proxy-Host aktivieren.
|
||||
|
||||
👉 **Screenshot geeignet:** NPM-Konfigurationsfenster mit eingetragener Ziel-IP und aktiviertem SSL
|
||||
|
||||
> [!TIP]
|
||||
> Wenn du eine interne Subdomain nutzt (z. B. `ollama.ucc.local`),
|
||||
> kann das Zertifikat über dein internes CA-System oder manuell hinterlegt werden.
|
||||
> Für öffentliche Domains ist Let’s Encrypt die empfohlene Lösung.
|
||||
|
||||
### Ergebnis
|
||||
|
||||
Die Ollama-GUI ist jetzt über deinen zentralen Proxy erreichbar –
|
||||
sicher, verschlüsselt und getrennt vom restlichen System.
|
||||
Sie zeigt verfügbare Modelle, laufende Sessions und GPU-Status an
|
||||
und kann als Basis für weitere lokale Tools (z. B. n8n oder Stream-Automationen) dienen.
|
||||
|
||||
👉 **Screenshot geeignet:** Browseransicht mit aktiver GUI über `https://ollama.<deine-domain.tld>` und sichtbarem Modellstatus
|
||||
|
||||
---
|
||||
|
||||
## Internetzugang für Ollama LXC
|
||||
|
||||
Damit Ollama aktuelle Informationen nutzen kann,
|
||||
bekommt es im Container eine kleine **Internet-Bridge**.
|
||||
Sie verbindet Ollama mit dem Internet – aber sicher und kontrolliert.
|
||||
Egal welches Modell du in Ollama verwendest (z. B. Llama 3, Mistral oder Phi 3):
|
||||
die Bridge erkennt es automatisch und funktioniert mit allen.
|
||||
|
||||
👉 **Screenshot geeignet:** einfache Darstellung „Ollama ↔ Internet-Bridge ↔ Internet“
|
||||
|
||||
> [!NOTE]
|
||||
> Ollama selbst bleibt komplett offline.
|
||||
> Nur die Bridge holt gezielt Webseiten und liefert den Text an Ollama zurück.
|
||||
|
||||
### Schritt 1 – Bridge installieren
|
||||
|
||||
1. Öffne in **Proxmox** den Container, in dem Ollama läuft.
|
||||
2. Klicke auf **Konsole**.
|
||||
3. Gib diese Befehle ein:
|
||||
|
||||
```bash
|
||||
apt update
|
||||
apt install -y python3-pip
|
||||
pip3 install ollama requests beautifulsoup4
|
||||
mkdir -p /opt/ollama-bridge
|
||||
nano /opt/ollama-bridge/internetbridge.py
|
||||
```
|
||||
|
||||
### Schritt 2 – Bridge-Programm einfügen
|
||||
|
||||
Kopiere diesen Code in die Datei:
|
||||
|
||||
```python
|
||||
from ollama import chat
|
||||
import requests
|
||||
from bs4 import BeautifulSoup
|
||||
import subprocess
|
||||
|
||||
# Modell automatisch erkennen
|
||||
def aktuelles_modell():
|
||||
"""Ermittelt automatisch das erste installierte Ollama-Modell."""
|
||||
result = subprocess.run(["ollama", "list"], capture_output=True, text=True)
|
||||
for line in result.stdout.splitlines():
|
||||
if line and not line.startswith("NAME"):
|
||||
return line.split()[0]
|
||||
return "llama3"
|
||||
|
||||
modell = aktuelles_modell()
|
||||
print(f"[Bridge] Verwende Modell: {modell}")
|
||||
|
||||
def internet_bruecke(url: str) -> str:
|
||||
"""Holt Text einer Webseite und gibt ihn an Ollama weiter."""
|
||||
r = requests.get(url, timeout=10, headers={"User-Agent": "UCC-Bridge"})
|
||||
soup = BeautifulSoup(r.text, "html.parser")
|
||||
text = " ".join(soup.stripped_strings)
|
||||
return text[:1500]
|
||||
|
||||
nachricht = [
|
||||
{"role": "system", "content": "Wenn du neue Informationen brauchst, nutze das Tool internet_bruecke."},
|
||||
{"role": "user", "content": "Was steht aktuell in der Proxmox-Dokumentation über GPU-Passthrough?"}
|
||||
]
|
||||
|
||||
antwort = chat(model=modell, messages=nachricht, tools=[internet_bruecke])
|
||||
print(antwort["message"]["content"])
|
||||
```
|
||||
|
||||
Speichern mit
|
||||
`STRG + O`, `Enter`, `STRG + X`.
|
||||
|
||||
### Schritt 3 – Automatisch starten
|
||||
|
||||
1. Erstelle eine kleine Startdatei:
|
||||
|
||||
```bash
|
||||
nano /etc/systemd/system/ollama-internetbridge.service
|
||||
```
|
||||
|
||||
2. Füge ein:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Ollama Internet-Bridge
|
||||
After=network.target ollama.service
|
||||
|
||||
[Service]
|
||||
ExecStart=/usr/bin/python3 /opt/ollama-bridge/internetbridge.py
|
||||
Restart=always
|
||||
User=root
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
3. Aktivieren:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl enable --now ollama-internetbridge
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** `systemctl status ollama-internetbridge` → grünes „active (running)“
|
||||
|
||||
### Ergebnis
|
||||
|
||||
Die Internet-Bridge erkennt dein installiertes Modell automatisch,
|
||||
registriert das benötigte Tool und hält die Verbindung aktiv.
|
||||
Ollama kann dadurch auf Webseiten zugreifen, Informationen lesen
|
||||
und sie direkt in seine Antworten einbauen – alles lokal, sicher und unabhängig.
|
||||
|
||||
👉 **Screenshot geeignet:** vereinfachte Darstellung „Ollama ↔ Bridge ↔ Webseite ↔ Ollama“
|
||||
|
||||
---
|
||||
|
||||
## CPU-Optimierung für Ollama LXC
|
||||
|
||||
Ollama braucht viel Rechenleistung – besonders bei größeren Modellen wie Llama 3 oder Mistral.
|
||||
Damit dein System dabei ruhig und stabil bleibt, kannst du in **Proxmox** genau festlegen,
|
||||
wie viel CPU-Leistung der Container bekommt und wie dein Host damit umgeht.
|
||||
So bleibt alles kühl, leise und zuverlässig – auch bei langen Sessions.
|
||||
|
||||
👉 **Screenshot geeignet:** Reiter „Ressourcen“ im Proxmox-Interface mit markierter CPU-Zuweisung
|
||||
|
||||
> [!NOTE]
|
||||
> Die folgenden Schritte funktionieren für alle Setups:
|
||||
> • CPU-only-Systeme
|
||||
> • Kombination aus CPU + GPU
|
||||
> • GPU-only (CPU dient dann nur zur Steuerung)
|
||||
|
||||
### Schritt 1 – CPU-Kerne festlegen
|
||||
|
||||
1. Öffne in **Proxmox** deinen Ollama-Container.
|
||||
2. Gehe zu **Optionen → Ressourcen**.
|
||||
3. Unter **CPU** stellst du die gewünschte Kernzahl ein, z. B. **4 Kerne**.
|
||||
4. Aktiviere **CPU-Pinning**, damit Ollama immer dieselben Kerne nutzt.
|
||||
|
||||
👉 **Screenshot geeignet:** CPU-Einstellungen mit aktivem Pinning (z. B. Kerne 0–3)
|
||||
|
||||
> [!TIP]
|
||||
> Für kleine Modelle reichen meist 2 bis 4 Kerne.
|
||||
> Mehr Kerne lohnen sich nur, wenn dein Modell sie tatsächlich verwendet.
|
||||
|
||||
### Schritt 2 – CPU-Leistung im Container begrenzen
|
||||
|
||||
Damit dein Host nicht dauerhaft auf 100 % läuft:
|
||||
|
||||
1. Öffne den Reiter **Ressourcen → Erweitert**.
|
||||
2. Setze das **CPU-Limit** auf etwa **80 %**.
|
||||
3. Trage bei **CPU Units** einen Wert zwischen **1000 und 2000** ein.
|
||||
So bekommt Ollama Leistung, aber andere Container bleiben flüssig.
|
||||
|
||||
👉 **Screenshot geeignet:** Ansicht mit CPU-Limit bei 80 %
|
||||
|
||||
> [!NOTE]
|
||||
> Diese Begrenzung schützt die CPU, hält die Temperatur niedrig
|
||||
> und sorgt für gleichmäßige Leistung ohne Lüftergebrüll.
|
||||
|
||||
### Schritt 3 – CPU-Takt auf dem Host regeln
|
||||
|
||||
Die folgenden Befehle werden **nicht im Container**,
|
||||
sondern auf dem **Proxmox-Host selbst** ausgeführt – also auf dem physischen Rechner,
|
||||
auf dem alle Container laufen.
|
||||
|
||||
1. Öffne im Proxmox-Interface oben den Punkt **Shell** (nicht Konsole des Containers).
|
||||
2. Gib dort ein:
|
||||
|
||||
```bash
|
||||
apt install -y cpufrequtils
|
||||
cpufreq-set -g schedutil
|
||||
```
|
||||
|
||||
Dadurch verwaltet der Host die CPU-Taktfrequenz automatisch:
|
||||
hohe Leistung bei Bedarf, sparsamer Betrieb im Leerlauf.
|
||||
|
||||
👉 **Screenshot geeignet:** Host-Shell mit erfolgreicher `cpufreq-set`-Ausgabe
|
||||
|
||||
> [!TIP]
|
||||
> „schedutil“ ist der dynamische Standardmodus.
|
||||
> Er verhindert, dass die CPU dauerhaft auf Max-Takt läuft,
|
||||
> ohne Ollama spürbar auszubremsen.
|
||||
|
||||
### Schritt 4 – Auslastung überwachen
|
||||
|
||||
Behalte die Werte im Blick:
|
||||
* Im **Proxmox-Reiter „Ressourcen“**, oder
|
||||
* über **Netdata** (falls im UCC installiert).
|
||||
|
||||
Dort siehst du: CPU-Temperatur, Taktfrequenz und Auslastung pro Kern.
|
||||
|
||||
> [!TIP]
|
||||
> Wenn einzelne Kerne dauerhaft auf 100 % liegen,
|
||||
> reduziere gleichzeitige Anfragen oder gib dem Container 1–2 Kerne mehr.
|
||||
|
||||
### Ergebnis
|
||||
|
||||
Dein System läuft jetzt ruhig, effizient und sicher.
|
||||
Ollama bekommt genug Rechenleistung, ohne dass dein Host überhitzt oder andere Dienste leiden.
|
||||
Ideal für lange KI-Sessions, Streaming-Setups oder parallele Container-Workflows.
|
||||
|
||||
👉 **Screenshot geeignet:** Vergleichsgrafik „CPU-Last vor / nach Optimierung“
|
||||
|
||||
---
|
||||
|
||||
## Abschluss – Ollama (Premium)
|
||||
|
||||
Mit diesem Premium-Kapitel hast du Ollama vollständig in dein UCC integriert –
|
||||
stabil, sicher und für den Dauerbetrieb optimiert.
|
||||
Das System kombiniert Leistung, Datenschutz und Flexibilität – ganz ohne Cloud-Zwang.
|
||||
|
||||
### Zusammenfassung
|
||||
|
||||
| Bereich | Umsetzung |
|
||||
|----------|------------|
|
||||
| **GUI für Ollama** | Lokale Weboberfläche zur Modellsteuerung im selben LXC |
|
||||
| **GPU-Durchreichung** | Einbindung über Proxmox für beschleunigte Berechnungen |
|
||||
| **Internetzugang** | Kontrollierte Python-Bridge, die Webseiten abruft und Texte an Ollama übergibt |
|
||||
| **CPU-Optimierung** | Leistungsbegrenzung, Pinning und Temperaturregelung für stabilen Dauerbetrieb |
|
||||
|
||||
👉 **Screenshot geeignet:** Architekturübersicht „Ollama LXC mit GUI, GPU, Bridge und Optimierung“
|
||||
|
||||
### Fazit
|
||||
|
||||
* Ollama läuft vollständig in deiner eigenen Infrastruktur.
|
||||
* Alle Modelle, Eingaben und Verläufe bleiben privat.
|
||||
* Die Internet-Bridge liefert bei Bedarf aktuelle Informationen – kontrolliert und sicher.
|
||||
* Durch CPU-Optimierung und GPU-Durchreichung nutzt du dein System effizient, ohne es zu überlasten.
|
||||
* Alles bleibt wartungsarm, nachvollziehbar und zukunftssicher.
|
||||
|
||||
Damit ist das Premium-Kapitel **Ollama** abgeschlossen.
|
||||
Dein UCC verfügt nun über eine vollständig integrierte, selbstverwaltete KI-Umgebung,
|
||||
die lokal, performant und datensouverän arbeitet.
|
||||
Reference in new issue
Block a user