Der Rechner, der bis Mai 2025 meine Arbeit gemacht hat — und was er heute noch kann.
Als ich im Mai 2025 auf den Mac umgestiegen bin, blieb mein bisheriger Arbeitsrechner einfach stehen: ein i9-10900KF von 2020 auf einem Gigabyte Z490 Vision, 64 GB DDR4. Kein Bastelobjekt, sondern die Maschine, auf der jahrelang mein Tagesgeschäft lief. Dazu kam jetzt eine neue RTX 5060 Ti mit 16 GB.
Solche Rechner stehen in vielen Büros und Kellern: zu gut zum Entsorgen, zu langsam für den aktuellen Arbeitsplatz, seit Monaten unbenutzt.
Die Frage war nicht, ob man daraus einen KI-Server bauen kann. Man kann. Die interessante Frage war, wo die Grenze liegt — und was man macht, wenn man an sie stößt.
Am Ende dieser Serie wird auf genau dieser Kiste ein lokales Modell selbstständig einen kaputten Docker-Stack diagnostizieren, über die Portainer-Schnittstelle reparieren und sein eigenes Ergebnis nachprüfen. Ohne Cloud, ohne API-Schlüssel, ohne dass Daten das Haus verlassen. Der Weg dorthin führt über eine Reihe von Entscheidungen, die man bei einer Cloud-API nie treffen muss — weil dort niemand 16 GB abzählt.
Warum kein Proxmox
Meine erste Überlegung war, die Kiste wie den Rest meiner Infrastruktur aufzusetzen: Proxmox drunter, virtuelle Maschinen drauf. Ich betreibe das seit Jahren so, ich kenne die Werkzeuge, es hätte gut ins Bild gepasst.
Es wäre trotzdem falsch gewesen. Die GPU ist der Kern dieser Maschine, und Virtualisierung ist der natürliche Feind einer GPU. Unter Proxmox hätte ich die Karte per PCIe-Passthrough an eine virtuelle Maschine durchreichen müssen. In dieser einen Maschine wäre dann Docker gelaufen — mit exakt denselben Containern, die jetzt direkt auf dem Blech laufen. Ich hätte dieselbe Architektur bekommen, nur mit einer zusätzlichen Schicht darunter: IOMMU-Gruppen, Passthrough-Eigenheiten, eine verschwundene Konsole beim Booten und ein zweites Betriebssystem zum Pflegen.
Also Ubuntu Server direkt auf die Hardware. Die Regel dahinter gilt über diesen Fall hinaus: Eine Abstraktionsschicht muss sich verdienen, dass sie da ist. Wenn ihr einziger Beitrag darin besteht, dass man die Hardware anschließend mühsam wieder durchreicht, hat sie sich nicht verdient.
Eine Kleinigkeit bei der Installation, die Ärger spart
Auf der Kiste lag noch mein altes Windows-System, auf einer eigenen SSD. Ich habe diese SSD während der Ubuntu-Installation physisch abgezogen. Das klingt übervorsichtig, ist aber der einzige Weg, bei dem der Installer die Windows-Partition garantiert nicht anfassen kann — kein falscher Klick, keine überschriebene Boot-Partition. Nach der Installation kam sie wieder rein. Fünf Minuten Aufwand gegen eine ganze Klasse von Fehlern, die man sonst erst bemerkt, wenn es zu spät ist.
Die Blackwell-Falle
Die RTX 5060 Ti gehört zur Blackwell-Generation. Wer hier reflexhaft den proprietären NVIDIA-Treiber installiert, wie man es seit Jahren gewohnt ist, kommt nicht weit: Für Blackwell sind die offenen Kernel-Module Pflicht, die klassischen proprietären Module unterstützen die Karte schlicht nicht. Das ist keine ideologische Frage, sondern eine harte Voraussetzung — und der Punkt, an dem die meisten Anleitungen aus dem Netz veraltet sind.
Die Architektur folgt aus 16 Gigabyte
Auf der Kiste sollte einiges laufen: ein Inferenz-Server für Sprachmodelle, ComfyUI für Bilder und Video, Unsloth zum Feintunen, dazu meine Agenten und n8n. Der naheliegende Weg wäre gewesen, alles in einen großen Verbund zu packen und starten zu lassen.
Das scheitert an einer simplen Zahl. 16 GB VRAM reichen nicht für zwei Dinge gleichzeitig, die beide die ganze Karte wollen. Sobald ComfyUI ein Modell lädt, ist für den Inferenz-Server kein Platz mehr — und umgekehrt.
Deshalb ist die Kiste in getrennte Stacks aufgeteilt, die einzeln startbar sind. Grob in drei Gruppen:
→ Die Verwaltung — Portainer, läuft immer, steuert alles andere
→ Die GPU-Nutzer — der Inferenz-Server, ComfyUI, Unsloth: jeder ein eigener Stack, weil immer nur einer die Karte haben kann
→ Die Dauerläufer — Agenten und n8n, die keine GPU brauchen und deshalb nie angefasst werden müssen
Alle im selben Docker-Netz, sodass sich die Container über ihre Namen erreichen statt über IP-Adressen. Der Inferenz-Endpunkt heißt für alle anderen einfach http://vllm:8000/v1, egal auf welchem Port er nach außen hängt.
Aus dieser Aufteilung ist über die Zeit ein Aufbau mit neun Stacks geworden, erreichbar über echte Namen statt IP und Port, mit Monitoring und neustartfest.
Was bewusst nicht auf die Kiste kam
Ich betreibe meine Hausautomatisierung mit Home Assistant, und es lag nahe, sie mit umzuziehen — die neue Maschine ist schließlich um ein Vielfaches schneller als das NAS, auf dem sie läuft.
Sie ist geblieben, wo sie war. Der Grund ist eine Unterscheidung, die ich für die wichtigste beim Aufbau solcher Systeme halte: Hausautomatisierung will Langeweile. Sie soll laufen, wenn niemand hinsieht, jahrelang, ohne Aufmerksamkeit. Das NAS läuft ohnehin rund um die Uhr und wird nicht angefasst.
Die GPU-Kiste ist das genaue Gegenteil: eine Werkbank. Auf ihr werden Stacks umgeschaltet, Treiber getauscht, Experimente gefahren, und sie wird neu gestartet, wann immer es nötig ist. Jeder dieser Vorgänge würde bedeuten, dass im Haus das Licht nicht mehr auf Kommando angeht.
Werkbank und Dauerbetrieb gehören nicht auf dieselbe Maschine. Nicht weil es technisch nicht ginge, sondern weil die beiden gegensätzliche Ansprüche haben — der eine will Ruhe, der andere ständige Veränderung.
Die Schwachstelle, die dieses Design hat
Es wäre unehrlich, den Aufbau zu beschreiben, ohne seinen Preis zu nennen. Das Umschaltmodell hat eine klare Bruchstelle: Die Dauerläufer laufen zwar durch — aber ihr Inferenz-Endpunkt verschwindet, sobald ich auf ComfyUI umschalte. Ein n8n-Workflow, der in diesem Moment ein Sprachmodell anfragt, läuft in einen Verbindungsfehler.
Für den Bastelbetrieb ist das verkraftbar. Für alles, was verlässlich laufen soll, ist es das nicht. Die Antwort darauf ist eine Zwischenschicht: Ein Proxy, auf den alle Workflows zeigen, statt direkt auf den Inferenz-Server. Er bekommt einen Ausweichpfad hinterlegt — ist die Karte gerade mit Bildern beschäftigt, geht die Anfrage eben woanders hin. Aus einem spürbaren Ausfall wird ein unsichtbarer Umweg.
Und noch eine Lektion aus dem laufenden Betrieb, die man erst nach dem dritten Neustart lernt: Der Modell-Cache gehört in ein eigenes Volume. Liegt er im Container, lädt jeder Neuaufbau mehrere Gigabyte neu aus dem Netz. Liegt er daneben, überlebt er jeden Redeploy, und ein Modellwechsel kostet nur noch die reine Ladezeit.
Was in den nächsten Teilen kommt
Damit steht die Grundlage. Die eigentlichen Fragen fangen jetzt erst an:
→ Teil 2: Was passt wirklich in 16 GB? Der ehrliche Kassensturz — was läuft, was nicht, und warum das größere Modell auch mit allen Tricks nicht hineingeht.
→ Teil 3: Warum ich nicht selbst quantisiere. Ein Ausflug in die Frage, warum 2 Bit technisch besser funktioniert als 3.
→ Teil 4: Batching. Wo diese Karte meinen Mac deutlich schlägt — und warum die Kennzahl, die alle angeben, die falsche ist.
→ Teil 5: Der Praxistest. Ein lokales Modell repariert einen kaputten Docker-Stack, selbstständig, mit sichtbaren Grenzen.
→ Teil 6: Wann sich das lohnt. Nicht wegen der Kosten — sondern weil manche Daten das Haus nicht verlassen dürfen.
Wenn du so etwas selbst vorhast: Die teuerste Entscheidung ist nicht die Grafikkarte. Es ist die Frage, was auf dieser Maschine laufen soll und was gerade nicht.
