Linux KI PC: den Rechner problemlos zur lokalen KI-Zentrale umrüsten

Linux KI PC: den Rechner problemlos zur lokalen KI-Zentrale umrüsten
Hardware

Ein vier Jahre alter Desktop-Rechner taugt in vielen Fällen als Grundlage für lokale Sprachmodelle. Maßgeblich ist, dass die Grafikkarte genügend eigenen Speicher mitbringt. Praktisch zählen drei Punkte. Eingaben verlassen das Heimnetz nicht und es entstehen keine Kosten pro Anfrage. Der Dienst läuft außerdem weiter, wenn ein Anbieter sein Modell abkündigt. Die Umrüstung zerfällt in drei Baustellen, nämlich Hardware, Treiberkette und laufenden Betrieb. Der teuerste Posten ist fast immer die Grafikkarte, der zeitraubendste die Treiberinstallation unter aktiviertem Secure Boot.

Das Projekt hat eine feste Reihenfolge. Am Anfang steht die Bestandsaufnahme des vorhandenen Rechners. Danach folgen die Entscheidung über die Grafikkarte sowie Treiber und Laufzeitumgebung. Zuletzt kommt die Absicherung des Dienstes im Heimnetz. Ein Modell mit acht Milliarden Parametern läuft auf einer 8-GB-Karte flüssig und erreicht dort zweistellige Ausgabegeschwindigkeiten. Modelle mit dreistelligen Parameterzahlen bleiben auf Heimhardware außer Reichweite. Diese Grenze verschiebt sich mit dem Speicher der Karte, kaum mit ihrer reinen Rechenleistung.

Bestandsaufnahme: was der vorhandene Rechner hergibt

Vier Werte bestimmen den Rahmen: Speicher der Grafikkarte, Arbeitsspeicher, freier Plattenplatz und Netzteilreserve. Unter Linux zeigt lspci mit einem Filter auf VGA, welche Karte verbaut ist. Nvidia-smi nennt bei Nvidia-Karten Gesamtspeicher und Belegung, rocm-smi leistet dasselbe bei AMD. Arbeitsspeicher und freien Platz liefern free -h und df -h. Beim Plattenplatz rechnen viele zu knapp. Ein Acht-Milliarden-Modell in Vierbit-Quantisierung belegt rund fünf Gigabyte, ein 27-Milliarden-Modell etwa 17 Gigabyte. Meist liegen drei bis fünf Modelle nebeneinander. Hundert Gigabyte freier Platz auf einer SSD bilden daher die vernünftige Untergrenze.

Die Wattzahl des Netzteils steht auf dem seitlichen Typenschild und lässt sich nur bei geöffnetem Gehäuse ablesen. Eine nachgerüstete Karte der 24-Gigabyte-Klasse zieht unter Last rund 350 Watt. Sinnvoll ist dann ein Netzteil ab 750 Watt mit etwa dreißig Prozent Reserve für Lastspitzen. Nötig sind außerdem zwei getrennte PCIe-Stromstränge ohne Daisy-Chain-Kabel. Beim Gehäuse zählen Baulänge und freie Steckplätze. Karten mit drei Lüftern messen häufig über dreißig Zentimeter und belegen zweieinhalb Steckplätze. Zwei Frontlüfter führen die Abwärme im Dauerbetrieb ab.

Der Grafikspeicher setzt die Grenze für die Modellgröße

Der Grafikspeicher (VRAM) begrenzt, welches Modell vollständig auf die Karte passt. Als Faustregel braucht ein Modell bei 16-Bit-Genauigkeit etwa zwei Gigabyte je Milliarde Parameter, Achtbit-Quantisierung halbiert den Bedarf, Vierbit viertelt ihn. In der Praxis tragen acht Gigabyte sieben bis acht Milliarden Parameter in Q4_K_M. Zwölf Gigabyte reichen für vierzehn Milliarden, sechzehn Gigabyte fassen gpt-oss-20b. Karten mit 24 Gigabyte nehmen dichte Modelle bis etwa 32 Milliarden Parameter auf. Ein Qwen3-Modell mit 27 Milliarden Parametern belegt dort rund 17 Gigabyte.

ai@localhost~ $nvidia-smi –query-gpu=memory.total –format=csvVRAM & Modellgröße
🔢Der Grafikspeicher entscheidet, welches Modell komplett auf die Karte passt – nicht die reine Rechenleistung. Faustregel bei 16-Bit: rund 2 GB je Milliarde Parameter.
🎮Welche Karte trägt welches Modell? (Q4_K_M)
VRAM Modellgröße Beispiel
8 GB 7–8 Mrd. Alltags-Modelle, ~5 GB Belegung
12 GB 14 Mrd. Mittelklasse-Modelle
16 GB ~20 Mrd. gpt-oss-20b
24 GB bis ~32 Mrd. Qwen3 27B ≈ 17 GB
⚖️Quantisierung halbiert & viertelt den Bedarf
16-Bit
~2 GB / Mrd.
volle Genauigkeit
8-Bit
~1 GB / Mrd.
halbiert
4-Bit
~0,5 GB / Mrd.
geviertelt (Standard)
📜Nicht vergessen: der Kontext frisst mit (7-Mrd.-Modell)
4.000 Token~0,3 GB
32.000 Token~2,5 GB
128.000 Token~10 GB
💡

Passt es nicht ganz rein? llama.cpp und Ollama lagern einzelne Schichten in den Arbeitsspeicher aus – deshalb sind 32 GB RAM sinnvoll. Reine CPU-Ausführung kostet aber massiv Tempo (nur wenige Token/s).

Der Kontext verlangt zusätzlichen Speicher, und der Bedarf wächst überproportional. Bei einem Sieben-Milliarden-Modell kostet ein Fenster von 4.000 Token rund 0,3 Gigabyte. Für 32.000 Token sind es etwa 2,5 Gigabyte, für 128.000 Token rund zehn Gigabyte. Passt ein Modell nicht vollständig in den Grafikspeicher, lagern llama.cpp und Ollama einzelne Schichten in den Arbeitsspeicher aus. Damit werden 32 Gigabyte RAM zur sinnvollen Ausstattung. Diese Rückfalllösung kostet erheblich Tempo, weil reine CPU-Ausführung mangels Speicherbandbreite auf wenige Token je Sekunde zurückfällt.

Nvidia, AMD und die Wege ohne neue Steckkarte

Nvidia mit CUDA bleibt der Weg des geringsten Widerstands. Neue Modellarchitekturen erscheinen dort zuerst, die ROCm-Unterstützung rückt oft erst Tage oder Wochen später nach. AMD hat den Abstand verkürzt. ROCm 7.2 vom Januar 2026 unterstützt RDNA 4 nativ. Die Kompatibilitätsmatrix führt gfx1201 (RX 9070, RX 9070 XT, Radeon AI PRO R9700) sowie gfx1200 (RX 9060 XT) offiziell auf. Ollama, LM Studio, llama.cpp und vLLM laufen damit ohne Handanpassungen. Für ROCm liefert Linux weiterhin bessere Ergebnisse als Windows.

Nvidia, AMD und die Wege ohne neue Steckkarte

Das Vulkan-Backend taugt bei AMD als vollwertige Alternative. Eine RX 9070 XT dekodiert Llama 2 7B in Q4_0 mit 137 Token je Sekunde über Vulkan gegenüber 101 über ROCm, während ROCm bei dichten 27-Milliarden-Modellen auf der Radeon AI PRO R9700 um 47 Prozent vorn liegt. Preiswert bleibt der Gebrauchtmarkt, wo eine RTX 3090 mit 24 Gigabyte je nach Zustand 800 bis 1.300 Euro kostet. Ohne Umbau kommen Systeme mit gemeinsam genutztem Speicher aus, etwa ein Ryzen AI Max+ 395, der bis zu 128 Gigabyte bereithält und bei Modellen unter zehn Milliarden Parametern 40 bis 80 Token je Sekunde erreicht. Ein Mac Studio mit M3 Ultra fasst bis zu 512 Gigabyte, und MLX gilt auf Apple-Hardware als reifer als ROCm auf Strix Halo.

Treiberkette unter Linux und ihre Stolperstellen

Der proprietäre Nvidia-Treiber kommt unter Ubuntu und Mint über ubuntu-drivers oder das Paket nvidia-driver-580-open ins System. Bei aktiviertem Secure Boot bleibt das Kernelmodul danach ungeladen, solange es keine gültige Signatur trägt. Der Ausweg heißt Machine Owner Key, wobei mokutil mit der Option import das eigene Zertifikat anmeldet und beim nächsten Start eine Passworteingabe im blauen MOK-Manager die Aufnahme bestätigt. Bei Blackwell-Karten entfallen die proprietären Kernelmodule vollständig, weil Nvidia dort ausschließlich die offenen Module pflegt, was die Signaturfrage keineswegs erübrigt.

root@linux~ #mokutil –sb-stateNvidia & Secure Boot
🔑Bei aktiviertem Secure Boot lädt das Kernelmodul nur mit gültiger Signatur. Der Ausweg ist ein Machine Owner Key (MOK) – das eigene Zertifikat wird einmalig in der Firmware angemeldet.
🔧MOK-Schlüssel anmelden – so läuft es ab
1

Treiber installieren

sudo ubuntu-drivers autoinstall

oder das Paket nvidia-driver-580-open
2

Zertifikat importieren

sudo mokutil --import MOK.der

Einmal-Passwort vergeben – für den nächsten Start merken
3

Im blauen MOK-Manager bestätigen
Nach dem Neustart: Enroll MOK → Continue → Yes – dann das Passwort aus Schritt 2 eingeben

Prüfen, ob es geklappt hat

mokutil --list-enrolled  ·  nvidia-smi

⚠️

Auch bei Blackwell-Karten nötig: Dort pflegt Nvidia nur noch die offenen Kernelmodule – die proprietären entfallen. Die Signaturfrage unter Secure Boot bleibt davon aber unberührt.

Bei AMD kommt ROCm über eine eigene Paketquelle des Herstellers ins System, denn die Distributionspakete hinken der aktuellen Version oft hinterher. Ältere oder inoffiziell unterstützte Karten melden sich nicht von selbst und brauchen die Umgebungsvariable HSA_OVERRIDE_GFX_VERSION mit passender Zielarchitektur. Ein Container nimmt die Bibliotheksfrage aus dem Grundsystem heraus, denn Docker mit dem NVIDIA Container Toolkit oder ein fertiges ROCm-Abbild trennt die Laufzeitumgebung sauber vom Host, wobei der Kerneltreiber weiterhin auf dem Host sitzt und die Abbilder mehrere Gigabyte Plattenplatz belegen.

Modelle, Quantisierung, Tempo und Stromkosten

Modelle werden über Ollama oder llama.cpp geladen, verwaltet und wieder entfernt, wobei sich der Speicherort per Umgebungsvariable auf eine große SSD legen lässt. Quantisierung bleibt die wichtigste Stellschraube zwischen Qualität und Speicherbedarf, Q4_K_M hat sich als Standard etabliert und kostet auf gängigen Benchmarks ein bis drei Prozent Qualität. Als Messgröße dient die Ausgabegeschwindigkeit in Token je Sekunde, und alles ab fünfzehn Token liegt über dem menschlichen Lesetempo, während llama.cpp und Ollama diese Rate im ausführlichen Modus selbst ausweisen.

Modelle, Quantisierung, Tempo und Stromkosten

Der Stromverbrauch teilt sich in Last und Leerlauf. Eine Stunde Volllast mit 350 Watt Kartenleistung kostet bei 37,0 Cent je Kilowattstunde, dem BDEW-Durchschnitt für Haushalte 2026, rund dreizehn Cent. Teurer wird der Leerlauf, weil ein durchgehend laufender Rechner mit großer Karte 60 bis 80 Watt zieht, was bei Betrieb rund um die Uhr knapp zwanzig Euro im Monat ergibt. Ein Timer, der den Dienst nachts beendet, oder ein Start per Wake-on-LAN drückt diesen Posten spürbar, sofern der Rechner keine anderen Aufgaben durchgehend erledigt.

Zugriff im Heimnetz und realistische Erwartungen

Ollama lauscht ab Werk nur auf 127.0.0.1 an Port 11434. Für den Zugriff von Tablet oder Laptop im Haus setzt man OLLAMA_HOST auf 0.0.0.0:11434, was den Dienst ohne jede Authentifizierung öffnet. Shodan listet weltweit über 7.000 solcher offenen Ollama-Instanzen, deren Rechenleistung und Modelle jeder Fremde abgreifen kann. Sicherer bleiben drei Wege: ein Reverse Proxy mit nginx oder Caddy samt Basic Auth und HTTPS, ein SSH-Tunnel bei unveränderter Bindung an localhost, oder ein Mesh-VPN wie Tailscale, das den Port am Router geschlossen hält und den Zugriff auf angemeldete Geräte begrenzt.

user@linux~ $rocm-smi –showproductnameAMD ROCm & Container
🔧ROCm kommt über die eigene Paketquelle von AMD ins System – die Distributionspakete hinken der aktuellen Version oft hinterher.
ROCm 7.2 (Jan 2026) – RDNA 4 nativ
Offiziell in der Kompatibilitätsmatrix geführt – läuft mit Ollama, LM Studio, llama.cpp und vLLM ohne Handanpassung:
gfx1201

RX 9070 / 9070 XT, Radeon AI PRO R9700
gfx1200

RX 9060 XT
🛠️Ältere Karte wird nicht erkannt?
export HSA_OVERRIDE_GFX_VERSION=11.0.0
Meldet einer inoffiziell unterstützten Karte eine passende Zielarchitektur vor – so springt ROCm auch dort an.
📦Container nimmt die Bibliotheksfrage raus
🏗️
Host
nur Kerneltreiber
+
📦
Container
komplette Laufzeit
Docker mit NVIDIA Container Toolkit oder ein fertiges ROCm-Abbild trennt die Laufzeit sauber vom Grundsystem. Nachteil: die Abbilder belegen mehrere GB Plattenplatz.
💡

Gut zu wissen: Für ROCm liefert Linux durchweg bessere Ergebnisse als Windows. Das Vulkan-Backend taugt zudem als vollwertige Alternative – eine RX 9070 XT schafft Llama 2 7B (Q4_0) mit 137 Token/s über Vulkan vs. 101 über ROCm.

Lokal überzeugen die Aufgaben mit klarem Rahmen. Zusammenfassen langer Texte, Umformulieren, Codehilfe im vorhandenen Projekt und die Suche im eigenen Dokumentenbestand über Einbettungen laufen auf einer 24-Gigabyte-Karte in einer Qualität, die für den Alltag genügt. Bei langen Argumentationsketten, aktuellem Weltwissen und sehr großen Kontextfenstern bleiben die großen Cloud-Modelle vorn, weil dreistellige Parameterzahlen und Rechenzentrumsspeicher zu Hause fehlen. Eine sinnvolle Aufteilung ordnet vertrauliche Unterlagen und wiederkehrende Routinearbeit dem eigenen Rechner zu und behält die Cloud für einzelne schwere Anfragen im Monat bei.

Fazit zum Linux-Rechner als lokale KI-Zentrale

Fazit zum Linux-Rechner als lokale KI-Zentrale Die Umrüstung gelingt planbar, sobald der Grafikspeicher als Maßstab dient. 24 Gigabyte auf einer gebrauchten Karte für 800 bis 1.300 Euro öffnen den Bereich bis 32 Milliarden Parameter, acht Gigabyte genügen für den Alltag mit Acht-Milliarden-Modellen. Die Treiberkette bleibt die zeitraubendste Etappe, bei Nvidia wegen der Signatur unter Secure Boot, bei AMD wegen der Paketquellen. Ein im Netz geöffneter Dienst gehört abgesichert, denn ein offener Port lädt fremde Nutzer auf die eigene Hardware ein und gibt Modelle wie Rechenzeit preis.