KI-Modelle lokal betreiben: dein Betriebsstack auf eigener Linux-Hardware

Der Einstieg ist heute niedrig. llama.cpp, Ollama oder vLLM laufen nach kurzer Zeit, ein quantisiertes Modell antwortet, und im Meeting sieht das nach einer fertigen Lösung aus. Sobald aber zwanzig Kolleginnen und Kollegen gleichzeitig Anfragen stellen, kippt das Bild: der Speicher der GPU reicht für den KV-Cache nicht mehr, die Latenz schwankt, und niemand kann sagen, warum. Der Unterschied zwischen einem Demo-Server und einem produktiven Inferenz-Dienst liegt nicht im Modell, sondern im Betriebsstack darunter.

Dazu kommt die Hardware-Frage, die sich schlecht raten lässt. Entscheidend ist zuerst der Videospeicher, denn das Modell muss samt Kontext hineinpassen: grob gerechnet braucht ein Modell in 4-Bit-Quantisierung etwa halb so viele Gigabyte wie es Milliarden Parameter hat, dazu der KV-Cache, der mit Kontextlänge und Zahl paralleler Anfragen wächst. Erst danach werden Speicherbandbreite, PCIe-Anbindung, NVLink zwischen mehreren Karten und schlicht Netzteil und Kühlung im Rack relevant. Wer nur auf die Rechenleistung schaut, kauft am Bedarf vorbei.

Typische Fehler wiederholen sich: Treiber und Container-Toolkit werden per Hand installiert und beim nächsten Kernel-Update zerlegt es das Setup, weil DKMS oder Secure Boot nicht bedacht wurden. Modelle liegen unversioniert im Home-Verzeichnis statt in einer Registry. Es gibt keine Metriken zu Tokens pro Sekunde, GPU-Auslastung und Queue-Tiefe, also auch keine Grundlage für Kapazitätsplanung. Und der Datenschutzvorteil, wegen dem der ganze Aufwand betrieben wird, verpufft, wenn der Dienst ohne Authentifizierung, ohne Netzwerksegmentierung und ohne Protokollierung im Firmennetz hängt.