Mein KI-Rechner heißt Prime. Auf ihm laufen lokale Sprachmodelle, ComfyUI und verschiedene Werkzeuge, mit denen ich Modelle ausprobieren und in meine Arbeit einbauen kann. Ich bediene ihn vom Arbeitsrechner aus über SSH und die jeweiligen Browseroberflächen.
Die Basis ist ein älterer Intel Core i7-3930K mit sechs Kernen und zwölf Threads. Linux stehen rund 46 GiB Arbeitsspeicher zur Verfügung. Für die Modellberechnung sind vor allem zwei Grafikkarten interessant: eine RTX 3090 Ti mit 24 GB und eine RTX 3070 Ti mit 8 GB Grafikspeicher.
Die 3090 Ti: größere Modelle und Bildworkflows
Die große Karte trägt die speicherintensiven Aufgaben. Für Sprachmodelle verwende ich llama.cpp, das ich mit CUDA-Unterstützung selbst baue. Zum Zeitpunkt dieser Notiz läuft Qwen3.8-27B als Qwen3.8-27B-UD-Q4_K_XL.gguf auf der 3090 Ti. Alle Modellschichten sind für die GPU konfiguriert, der Server nutzt einen Kontext von 131.072 Token und einen Q8-KV-Cache.
Die quantisierte Modelldatei macht ein Modell dieser Größe auf der Karte praktikabel. Zum Modell selbst kommen aber noch Zwischenspeicher und Rechenpuffer hinzu. Der laufende llama-server belegt bei der Bestandsaufnahme rund 22 GiB auf der 3090 Ti. Das ist eine Momentaufnahme des geladenen Setups, keine Messung seiner Geschwindigkeit oder eine Aussage über jeden möglichen Lauf mit vollständig gefülltem Kontext.
Auch für ComfyUI ist die 3090 Ti wegen ihres größeren Speichers wichtig. Wenn ich einen aufwendigen Bildworkflow ausführen will, muss dafür genügend Platz frei sein. Ein großes geladenes Sprachmodell und ein Bildworkflow passen nicht automatisch gleichzeitig auf dieselbe Karte. Ich entscheide deshalb je nach Aufgabe, welches Modell gerade Speicher belegen soll.
Die 3070 Ti: kleinere Modelle und gezielte Tests
Die zweite Karte hat mit 8 GB deutlich weniger Spielraum. In meinen llamaup-Profilen verwende ich sie für kleinere Modelle und begrenztere Kontexte. Ein dokumentiertes Beispiel ist ein quantisiertes Qwen3-VL-Modell mit 8 Milliarden Parametern für Bildbeschreibung, mit 24K Kontext und Q8-KV. Ein weiterer vorbereiteter Test gilt Qwen3.5-9B bei 16K Kontext.
Bildbeschreibung ist dabei eine andere Aufgabe als Bildgenerierung: Das Modell erhält ein vorhandenes Bild und formuliert Text dazu. So kann auch die kleinere Karte eine eigene Aufgabe übernehmen, während die große Karte für einen anderen Lauf gebraucht wird. Ob zwei konkrete Workloads parallel passen, prüfe ich an ihrem tatsächlichen Speicherbedarf.
Bei der Bestandsaufnahme ist auf der 3070 Ti kein eigener llama-server aktiv; sie ist weitgehend frei. Die Profile beschreiben ihre vorgesehenen Einsätze, nicht mehrere dauerhaft laufende Modelle.
Zwei Karten sind kein gemeinsamer 32-GB-Speicher
In llamaup habe ich sowohl Einzelkarten- als auch Dual-GPU-Profile. Mein laufendes Qwen-Setup wählt mit CUDA_VISIBLE_DEVICES=0 die 3090 Ti aus und verwendet -sm none, also keine Modellaufteilung über mehrere Karten. Für größere Konfigurationen kann ich stattdessen ein Profil wählen, das Modellschichten auf beide GPUs verteilt.
Die Speicher werden dadurch nicht zu einem einzigen frei nutzbaren Block. Software und Konfiguration bestimmen, welche Teile auf welcher Karte liegen. Die kleinere Karte setzt dabei eigene Grenzen, und die Zusammenarbeit zwischen den Karten kann zusätzlichen Aufwand verursachen. Mehr belegbare Kapazität bedeutet deshalb nicht automatisch mehr Geschwindigkeit.
ComfyUI und meine eigenen Nodes
ComfyUI läuft in einem Docker-Container und erkennt beide GPUs. Welche Karte ein Workflow tatsächlich nutzt, hängt von den verwendeten Nodes und ihrer Gerätewahl ab. Ich habe keine dauerhaft exklusive Aufteilung nach dem Muster „eine Karte nur für Sprache, eine nur für Bilder“.
Meine Alf Nodes ergänzen diese Umgebung um Werkzeuge für Prompt-Bausteine, gezielte Varianten und Metadaten. Damit kann ich beispielsweise eine Reihe von Motiven durchgehen, fertige Einträge aus der Auswahl nehmen und Angaben zur Serie mit den erzeugten Bildern speichern. Mich interessiert dabei der Ablauf von der vorbereiteten Eingabe bis zum wiederauffindbaren Ergebnis.
Zusätzlich laufen auf Prime unter anderem Open WebUI, Open Notebook und Dienste für Sprachausgabe. Dass ein Dienst gestartet ist, heißt nicht, dass er gerade eine GPU auslastet. Ein Server kann untätig sein und trotzdem ein großes Modell im Grafikspeicher halten.
Betrieb gehört dazu
Die ältere CPU unterstützt AVX, aber kein AVX2. Das spielt auch bei GPU-Anwendungen eine Rolle: Python-Pakete und Hilfsbibliotheken können CPU-Instruktionen voraussetzen, die der Rechner nicht beherrscht. In meiner ComfyUI-Umgebung sind deshalb kompatible Varianten beziehungsweise Versionen einzelner Pakete festgelegt. Ein CUDA-fähiges Modell allein reicht nicht; auch die Umgebung darum herum muss passen.
Damit ich funktionierende Einstellungen wiederfinde, halte ich Modell, GPU-Zuordnung, Kontext und weitere Parameter in llamaup-Profilen fest. Vor einem Wechsel kann ich den erzeugten Serverbefehl ansehen und Varianten vergleichen. Auf dem Rechner kontrolliere ich mit nvidia-smi, wo die Prozesse tatsächlich laufen und wie viel Speicher sie belegen.
Warum ich das lokal mache
Ich möchte Modelle selbst betreiben, ihre Grenzen kennenlernen und sie mit eigenen Werkzeugen verbinden können. Lokal kann ich Modellversion, Quantisierung und Servereinstellungen selbst wählen und denselben Aufbau für weitere Versuche wiederverwenden.
Dafür kümmere ich mich auch um Builds, Speicher, Paketkompatibilität und Modellwechsel. Prime ist mein Arbeits- und Versuchsrechner: Hier prüfe ich, was mit der vorhandenen Hardware funktioniert und wie daraus ein brauchbarer Workflow wird.