Tiefer tauchen mit KI – Teil 2: Die Software-Hürden

Während wir uns in Teil 1 dieses Doppel-Beitrags ausführlich der Hardware gewidmet haben, kommt nun der Software-Teil. Dabei sollte man sich bewusst sein: Dies ist ebenfalls kein Spaziergang. Ein LLM bzw. eine KI zu betreiben, ist zum einen gierig auf Ressourcen und bringt zum anderen einen gewissen Konfigurationsaufwand mit sich.

Die wichtigsten Punkte im Überblick:

• Betriebssystem
• Art der Installation
• Hardware-Überwachung
• Wahl des Interfaces
• Wahl des Sprachmodells

Aufgrund der benötigten Aktualität der GPU-Treiber und anderer Software kommen nur Systeme in Frage, die einen engen Release-Zyklus haben. Dabei rangieren Arch-basierte Distributionen ganz weit vorne. Diese sind wohlgemerkt auch in großen Teilen zu Fuß zu konfigurieren, eher für fortgeschrittene Linux-Nutzer gedacht und erschweren im Sinne von keinzugriff.de den Einstieg in das Thema. Fedora auf RHEL-Basis ist ebenfalls eine gute Wahl laut Recherche.

Und da habt ihr mich auch schon erwischt: Ich habe von Arch und RHEL/Fedora so gar keine Ahnung. Ich befasse mich von Haus aus so gut wie nur mit Debian-basierten Systemen (Debian selbst, Ubuntu/Kubuntu und Pop!_OS).

Pop!_OS installieren

Debian selbst setzt mehr auf Stabilität als auf Aktualität – was die Anforderung nicht deckt. Ubuntu ist zwar völlig ausreichend, allerdings setzt Ubuntu immer noch auf das Snap-System, welches aus Sicht des Datenschutzes direkt unten durch ist. So lande ich im Kontext dieser Seite bei Pop!_OS.

Die ISO-Datei zu Pop!_OS findest du im Netz. Hier gibt es verschiedene Versionen, je nachdem, welche GPU in deinem Rechner werkelt. Die rund 1,8 GB passen dann auf einen kleinen USB-Stick (min. 8 GB), mit Balena Etcher darauf getoastet, und fertig.

Hast du noch das Secure Boot aktiviert, wird dir Pop!_OS beim Start erst einmal eine Fehlermeldung servieren – im BIOS/UEFI abschalten in diesem Fall. Die Installation läuft mit den üblichen Abfragen und ist sonst nichts Besonderes.

Pop!_OS hat den neuesten Treiber für deine GPU an Bord und sollte die Karte auch in der Regel finden. Daneben handelt es sich um ein Desktop-System, welches auf Knopfdruck automatisch Fenster kacheln kann. Der Store ist hier der COSMIC Store und beinhaltet Flatpaks, welche alle Abhängigkeiten mit sich bringen. Wenn du hier eine Anwendung nicht findest, gibt es die im CLI mit:

sudo apt install <paketname>

Es empfiehlt sich, die gewohnten Werkzeuge erst einmal hinzuzufügen, bevor es ans Eingemachte geht: Filemanager, NFS-Mounts, eventuell auch erst noch ein RAID-Array mit Btrfs erstellen usw. Ich würde die individuelle Bedienbarkeit erst einmal anpassen und für mich selbst herstellen.

Art der Installation

In vielen Workshops wird die Installation unter Docker empfohlen. Das mag zwar der einfachere Weg sein, allerdings möchte ich jede noch so kleine Ressource verfügbar haben – auch den geringen Docker-Overhead hierbei wegsparen. Wer das anders angehen möchte, dem steht Docker natürlich zur Verfügung. Auf dem KI-Rechner hier läuft jedenfalls kein Docker; diese Instanzen laufen ausschließlich auf VMs unter Proxmox bei mir. Weiterhin müsste man die GPU an Docker durchreichen, was ich mir ebenfalls sehr gerne ersparen möchte.

Neben den eigentlichen Sprachmodellen benötigt es ein Framework (Ollama) oder eine eigenständige Desktop-Anwendung (LM Studio), welche dann die Arbeit mit den Sprachmodellen erst möglich macht. Beide ließen sich lokal installieren, Ollama auch unter Docker. Ollama benötigt zusätzlich ein Interface; Open WebUI ist hier das empfohlene:

• LM Studio: Desktop-App – LLM herunterladen in der App – arbeiten (nur lokal).
• Ollama: LLM per CLI laden/entladen, per Open WebUI darauf zugreifen (lokal oder Docker).

Das solltest du bei deinem Ansatz der Installationsart berücksichtigen. Mehr zu den Interfaces und Sprachmodellen weiter unten.

Hardware-Überwachung

Im Hardware-Teil zu diesem Zweiteiler wurde klar, dass es durchaus ein thermisches Problem geben könnte in zu kleinen Gehäusen oder bei unzureichender Luftdurchströmung. Da sich diese vorab nur schwer einschätzen oder gar ausrechnen lässt, ist ein wenig Monitoring angebracht. Das bringt denn auch mit sich, dass wir die nötigen Lüfter besser steuern können – und zum Beispiel über BIOS/UEFI die Drehzahlen mittels smarter Steuerung heruntersetzen können. Dein Gehör wird es dir danken auf Dauer.

Während Psensor hier eigentlich eine ganz gute Figur gemacht hat bisher, vermisse ich dabei die GPU. Im Linux-Umfeld war diese für mich bislang zu vernachlässigen – aber das ändert sich mit diesem Anwendungsfall natürlich. Im COSMIC Store findest du hierzu das Mission Center. Kurz installiert, an der unteren Taskleiste fixiert, und fertig ist die Überwachung: RAM, CPU, GPU – Last in %, Leistungsaufnahme in W, Temperatur, Speichernutzung – alles unter einem Dach ohne viel Konfigurieren zu müssen.

Ob das Mission Center oder eine andere Software hierzu – wichtig ist meiner Meinung nach nur, dass RAM/CPU/GPU vernünftig und in Echtzeit gemonitort werden. Hast du später ein gutes Gefühl für die Belüftung deiner Hardware bekommen und eine Idee, welche Lasten deine KI-Workflows wirklich erzeugen, dann kann dieser Part auch wieder beerdigt werden. Ich würde mir aber die Zeit für diesen Input nehmen und das Zusammenspiel beobachten und bewerten für eine optimale Steuerung.

Wahl des Interfaces / Tools

Oben hast du nun schon von Ollama und LM Studio gehört, es gibt natürlich noch weitere:

Da hier auch Docker-Container in VMs auf dem Proxmox-Host laufen, die ebenfalls in das entsprechende Tool eingebaut werden sollen – womit ich mir die Abfrage der einzelnen Container erspare und dazu noch einen Verlauf speichere im Tool – fällt für diesen Beitrag die Wahl auf Ollama, als Interface dann Open WebUI. Damit schaffe ich mir zugleich die Möglichkeit, dass andere Dienste im LAN direkt Ollama als Server abfragen können per API – wer weiß, was noch kommt in der Zukunft.

Open WebUI installieren

Python 3.11+ und pip müssen vorhanden sein, dies prüfst du mit:

python3 --version pip3 --version

Fehlt eines der beiden, kannst du diese mit sudo apt install python3-pip nachinstallieren. Ich würde mir nun eine Verzeichnisstruktur festlegen, wo alles, was mit LLM/KI zu tun hat, an einen Unterbaum gehängt wird. Ich habe mir hierzu einen Mountpoint für ein RAID10 Btrfs-Verbund unter /mnt/raid/llm angelegt.

Wechsle dorthin und erstelle z. B. open-webui als Verzeichnis. Die im Netz auffindbare Installationsanleitung mit pip3 install open-webui wird unter Pop!_OS oft nicht funktionieren, da der direkte Einsatz von pip verhindert wird, um Paketkonflikte zu vermeiden.

Stattdessen kommen wir hier zu einer virtuellen Umgebung zur isolierten Installation:

1. Virtuelle Umgebung erstellen: python3 -m venv open-webui-venv
2. Umgebung aktivieren: source open-webui-venv/bin/activate
3. OpenWebUI installieren: pip install open-webui

Zum Starten von Open WebUI habe ich mir ein kleines Script schreiben lassen (von einem LLM):

#!/bin/bash

# Virtuelle Umgebung aktivieren
source /mnt/raid/llm/open-webui/open-webui-venv/bin/activate

# Konfiguration
VENV_PATH="/mnt/raid/llm/open-webui/open-webui-venv"
LOG_FILE="/mnt/raid/llm/open-webui/open-webui.log"
PORT=3000

# Prüfen, ob der Dienst schon läuft
if pgrep -f "open-webui serve" > /dev/null; then
    echo "⚠️ OpenWebUI läuft bereits. Beende den alten Prozess..."
    pkill -f "open-webui serve"
    sleep 2
fi

# Virtuelle Umgebung aktivieren (Pfad in PATH setzen)
export PATH="$VENV_PATH/bin:$PATH"

# Dienst starten im Hintergrund
# nohup sorgt dafür, dass der Prozess weiterläuft, auch wenn du das Terminal schließt
nohup open-webui serve --host 0.0.0.0 --port $PORT > "$LOG_FILE" 2>&1 &

echo "✅ OpenWebUI wurde gestartet."
echo "🌐 Zugriff: http://localhost:$PORT"
echo "📝 Logs: tail -f $LOG_FILE"

#!/bin/bash

# Virtuelle Umgebung aktivieren
source /mnt/raid/llm/open-webui/open-webui-venv/bin/activate

# Konfiguration
VENV_PATH="/mnt/raid/llm/open-webui/open-webui-venv"
LOG_FILE="/mnt/raid/llm/open-webui/open-webui.log"
PORT=3000

# Prüfen, ob der Dienst schon läuft
if pgrep -f "open-webui serve" > /dev/null; then
    echo "⚠️ OpenWebUI läuft bereits. Beende den alten Prozess..."
    pkill -f "open-webui serve"
    sleep 2
fi

# Virtuelle Umgebung aktivieren (Pfad in PATH setzen)
export PATH="$VENV_PATH/bin:$PATH"

# Dienst starten im Hintergrund
# nohup sorgt dafür, dass der Prozess weiterläuft, auch wenn du das Terminal schließt
nohup open-webui serve --host 0.0.0.0 --port $PORT > "$LOG_FILE" 2>&1 &

echo "✅ OpenWebUI wurde gestartet."
echo "🌐 Zugriff: http://localhost:$PORT"
echo "📝 Logs: tail -f $LOG_FILE"

Pfade anpassen natürlich! Ich habe das Ganze dann ins /home/benutzer-Verzeichnis gelegt und xyz.sh genannt, ausführbar machen nicht vergessen (chmod +x xyz.sh). Man könnte das Ganze jetzt auch über einen Daemon automatisch laden lassen beim Systemstart – das setzt aber voraus, dass man auch immer Open WebUI auf Port 3000 verfügbar haben möchte – was bei mir nicht der Fall ist.

Aufruf erfolgt nun mit http://localhost:3000. Eine animierte Startseite lädt nun mit „-> Los geht’s“ zum Anlegen des Admin-Accounts an. Name, Email, Passwort, fertig (endlich!). Zumindest die Oberfläche ohne Hirn ist jetzt fertig.

Ollama hinzufügen

Das geht ganz einfach mit einem Script:

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

Optional: Abweichender Speicherort für Modelle Wenn du deine KI-Bestandteile unter einem eigenen Verzeichnisbaum gesammelt haben möchtest wie oben unter z. B. /mnt/raid/llm, dann ist jetzt der richtige Zeitpunkt, ein Verzeichnis für models hinzuzufügen (unter llm in diesem Fall). Mit einem Symlink verweist du dann vom vorgesehenen Speicherort der Modelle hierhin.

Der Standard-Speicherort ist entweder ~/.ollama/models oder /usr/share/ollama/.ollama/models. Den jeweiligen Ordner models löscht du – zwingend vor Download des ersten Modells überhaupt.

Dann erstellst du den Symlink wie folgt:

ln -s /mnt/raid/llm/models /home/[benutzername]/.ollama/models (oder: ln -s <ziel> <herkunft>)

Arbeitsvorbereitung mit Ollama Ob Ollama funktioniert, kannst du testen, indem du einfach mit ollama -v die installierte Version abrufst. Etwas mehr Informationen erhältst du, wenn du den Dienst selbst abfragst:

sudo systemctl status ollama

Und Ollama ist auf einem eigenen Port im Browser erreichbar: http://[IP]:11434 – gibt dann zwar nur Ollama is running zurück, reicht ja aber auch.

Vor Download des ersten Modells sollte man die Anbieter der Modelle einmal verinnerlicht haben:

Diese Übersicht zeigt, wie zu erwarten, dass die US-Dienste allesamt zu BigTech gehören, nur Amazon und X fehlen hier aktuell noch. Daneben hat China extrem aufgeholt und stellt zusammen mit Mistral aus Frankreich eine gute Alternative zu den US-Diensten dar. Die letzten beiden Modelle dieser Liste lassen einen aufhorchen – die VAE mischen hier ebenfalls.

An BLOOM waren mehr als 1.000 Forscher aus 70 Ländern beteiligt, hier findet sich denn auch Deutschland wieder mit Beteiligung der TU München und des Max-Planck-Instituts. Und es ist das einzige Modell in dieser Liste, welches Open Source ist. Allerdings ist BLOOM veraltet und wurde im Jahr 2023 trainiert. Dazu benötigt es Unmengen an VRAM (bei 176B Parametern in Q4 rund 100 GB VRAM). Das hat man üblicherweise nicht im eigenen KI-Rechner zu bieten.

Es ist letztlich deine Entscheidung, welches Modell du einsetzen wirst. Für diesen Blog werden wir auf US-Anbieter jedoch nur bedingt zurückgreifen – ich habe mich hier zu Testzwecken und Vergleichen auf Llama 3.2 beschränkt. Ansonsten sind aktuell Qwen und Mistral die Modelle meiner Wahl, weitere werden dazu kommen, wie DeepSeek.

Ein Modell lädst du ganz einfach mit diesem Befehl herunter:

ollama pull <modellname>

Den genauen Modellnamen findest du entweder auf der Webseite ollama.com/library (Immer aktuell, Filter nach Name, Größe, Zweck, Stichwort möglich) oder mit dem Befehl:

ollama search <begriff> z. B. ollama search qwen ollama search german ollama search code

Ohne Parameter ist die search-Funktion allerdings ungenau – hier werden dann oft nur die Top-Ergebnisse aus tausenden von Modellen angezeigt. Die Webseite hingegen ist übersichtlicher.

Du findest dort die offiziellen Modelle, Community-Modelle mit von Nutzern hochgeladenen Finetunes sowie unterschiedliche Tags: Mit ollama pull qwen2.5 wird standardmäßig die latest Version gezogen. Um eine spezifische Größe zu laden, muss ein Tag verwendet werden, wie z. B. ollama pull qwen2.5:32b.

Wenn nun die ersten Downloads abgeschlossen sind, kannst du mit ollama list eine Aufstellung der lokal verfügbaren Modelle ausgeben lassen:

NAME                   ID              SIZE      MODIFIED
qwen3.6:35b-a3b        07d35212591f    23 GB     8 hours ago
qwen2.5:14b            7cdf5a0187d5    9.0 GB    8 hours ago
mistral-nemo:latest    e7e06d107c6c    7.1 GB    9 hours ago
llama3.2:latest        a80c4f17acd5    2.0 GB    9 hours ago

Und los geht es endlich

Die vorhandenen Modelle werden automatisch in Open WebUI hinzugefügt und sind nun bereit zur Arbeitsaufnahme. Das obere Modell in der Liste ist Qwen mit 35B Parametern, allerdings mit einem hybriden Ansatz:

Das obere Modell in der Liste ist Qwen mit 35B Parametern, allerdings mit einem hybriden Ansatz: Von den 35 Milliarden Parametern werden pro Token nur rund 3 Milliarden Parameter aktiviert. Die Architektur dahinter ist der moderne MoE-Ansatz (= Mixture of Experts), wo nur die jeweiligen „Experten“ für ein Thema geladen werden (Logik, Deutsch, Code z. B.).

Das bedeutet aber nicht, dass das Modell nun mit 8 GB VRAM auskommt, leider. Das komplette Modell muss in den VRAM rein (22–24 GB bei Q4), allerdings werden für den Rechenprozess nur 3–4 GB VRAM benötigt und nicht 35 GB.

Wer also keine 24 GB VRAM hat, wird es hier mit massivem Offloading zu tun bekommen. Allerdings sind die Ergebnisse dafür wirklich sehenswert: Ein Text von rund 2.200 Wörtern Länge benötigte zwar 3–4 Minuten zur Analyse auf Logik, technische Korrektheit, Faktencheck und Plausibilität. Die Qualität war dabei überzeugend.

Die Cloud-KI Qwen VL 235B schaffte den gleichen Text in 20 Sekunden allerdings. Dabei kann man dem 35B-Modell beim „Denken“ zusehen: Ein kleines Kontextfenster lässt sich anklicken und so die Gründe in Echtzeit mitverfolgen, wie das Modell zu seinem Ergebnis kommt.

Hast du bei diesem qwen3.6:35b-a3b-Modell nun den erwähnten Hardware-Monitor Mission Center geöffnet und lässt gerade einen Text verarbeiten, so wird dir mit 8 / 12 / 16 GB VRAM evtl. auffallen, dass die GPU kaum genutzt wird.

Dem kannst du mit einer simplen Rechnung folgen: Deine GPU hat eine Rechenleistung von z. B. 30 TFLOPS. Sie kann damit theoretisch 1.000 Tokens pro Sekunde berechnen. Bei 12 GB VRAM muss dann die Berechnung für jeden einzelnen Token das langsame DDR5-System-RAM bemüht werden. VRAM hat bis zu 1.000 GB/s, DDR5-RAM nur bis zu 64 GB/s, da die Daten über den PCIe-Bus geschaufelt werden müssen. Daher wartet die GPU 90 % der Zeit darauf, dass Daten ankommen.

Probiere die gleiche Aufgabenstellung in den oben genannten Modellen einmal aus – und sieh dabei auf die GPU-Last, die Geschwindigkeit auf dem Bildschirm sowie die Qualität der Ausgabe. Dann bekommst du ein Gefühl dafür, was tatsächlich für Arbeiten von wem wie erfolgreich in welcher Zeit erledigt werden kann.

Fazit: Der Preis für Souveränität

Ein Bekannter von mir aus Taiwan meinte: „Viel Spaß beim Administrieren“, als ich mir das Selbst-Hosten von Sprachmodellen als nächstes Ziel gesetzt hatte. Mir war klar, was da auf mich zukommt – und Spaß hatte ich auch daran tatsächlich.

So schlimm war es an sich auch nicht, wenn man sich vorab gut informiert und vor allem sein persönliches „Why“ in einen Zusammenhang mit dem Use-Case setzt. Das „Why“ habe ich in dem Beitrag KI Selber Hosten beleuchtet.

Dein Prompt, deine Ergebnisse: Eben, es ist DEINS und gehört nicht auf US-Server; schon gar nicht, wenn es um vertrauliche Daten oder Urheberrecht an deinen Werken geht.

Aber halte dir dabei den Aufwand und die Kosten unbedingt vor Augen; für ein paar Spaß-Bilder von Zeit zu Zeit oder Rechtschreibprüfungen unkritischer Texte sind Cloud-KIs dann die bessere Wahl. Und für Recherche-Zwecke sind diese Dienste einfach unschlagbar genau und schnell.

Für alles andere im datenschutzbewussten Umfeld, sei es aus Ideologie oder aus Notwendigkeit, ist eine Selbst-Hostung allerdings ein wichtiges Thema!

Thinking ‚bout’…