Lokale KI im Eigenbetrieb, unser Erfahrungsbericht zum KI-Server

Vor allen Messwerten stand die Hardware. Das folgende Video zeigt den neuen KI-Server beim Einbau in unseren Serverschrank und bei der Inbetriebnahme.

Video in neuem Fenster öffnen

Ab dem Moment, in dem die Maschine lief, wanderte die Arbeit vollständig auf die Kommandozeile. Die nächsten Abschnitte beschreiben, was dort passierte.

Weil damit die Grundfragen beantwortet sind, bevor die erste Anfrage gestellt wird. Wem gehören die Daten, wer darf was sehen, was passiert beim Modellwechsel. Bei lokaler KI liegt die Antwort in der eigenen Infrastruktur, nicht in einem Vertrag.

Unsere Ausgangslage war ein neues Gigabyte-GPU-Gehäuse mit einer NVIDIA RTX PRO 6000 Blackwell und 96 GB Grafikspeicher. Konkret meldet die Karte 97.887 MiB. Darauf sollten drei Dienste laufen.

• Gemma 4 26B A4B als großes Sprachmodell für Chat und Textverarbeitung, ansprechbar über eine OpenAI-kompatible Schnittstelle. Es handelt sich um ein Mixture-of-Experts-Modell, von dem pro Anfrage nur 4 Milliarden Parameter aktiv sind.
• Whisper large-v3 als Transkriptionsdienst.
• PaddleOCR-VL 1.6 für die Dokumentenverarbeitung.

Alles auf derselben Grafikkarte, alles in Docker gekapselt, alles nach einem Neustart von selbst wieder oben. Dazu die Überwachung im bereits vorhandenen Zabbix.

Was wir nicht wollten, waren zwei Tage Arbeit an Treiberversionen, Container-Laufzeiten und Speicherbudgets. Also haben wir es anders gemacht. ALBERT | AI bekam Zugang zum Server, und wir haben die Einrichtung begleitet, statt sie selbst durchzuführen.

Drei Hürden haben uns am meisten Zeit gekostet. Die Fernwartung, der Grafiktreiber und eine Architekturkennung, die es in vorkompilierten Bibliotheken noch nicht überall gibt.

Die Installation aus der Ferne war die zähe Phase. Sie war unsere Aufgabe, weil sie durch eine Weboberfläche musste. Die virtuelle Laufwerkseinbindung fehlte im Viewer komplett, weil der Hersteller die Anzahl virtueller CD-Laufwerke ab Werk mit null ausliefert. Danach brauchte es einen Kaltstart des Management-Controllers, danach blockierte eine verwaiste Sitzung die Kontrolle. Der eigentliche Stolperstein war ein nicht bedienbarer Installer. Man sah eine blaue Fläche, Eingaben kamen an, der Dialog wurde nie gezeichnet. Ursache war die Videoerfassung des Management-Controllers, die mit dem Framebuffer-Modus des Installers nicht zurechtkommt. Ein einzelner Boot-Parameter löste es.

Der Grafiktreiber war die erste echte Überraschung. Die Vorgabe lautete, den Production Branch zu nehmen statt der höchsten Versionsnummer. Bei einem Server, der jahrelang laufen soll, ist Stabilität wichtiger als Neuheit. Das Problem war, dass das zugehörige Metapaket seine Versionsvorgabe nicht an die eigentlichen Treiberpakete weitergibt. Man installiert scheinbar den stabilen Zweig und bekommt den experimentellen. Es folgten drei Anläufe. Zwei scheiterten an Eigenheiten des Paketmanagers, der dritte funktionierte und förderte nebenbei einen Paketierungsfehler in der stabilen Version zutage. Am Ende standen 46 Pakete auf einer einheitlichen Version, gesperrt gegen automatische Aktualisierung. Im Einsatz ist NVIDIA 595.71.05 aus dem Production Branch.

Bemerkenswert war das Verhalten bei den Fehlschlägen. Jeder wurde benannt, keiner überspielt. Beim zweiten Fehlversuch kam von selbst die Ansage, dass es noch einen Versuch geben würde und danach die Entscheidung fällt. Diese Selbstbegrenzung hätten wir von einem Menschen erwartet.

Die dritte Hürde trägt eine Zahl, sm_120. Das ist die Architekturkennung der Blackwell-Generation. Grafikbibliotheken werden für bestimmte Kennungen vorkompiliert, und für diese neue war noch nicht überall etwas dabei. Die offiziellen PaddleOCR-Pakete sind für sieben ältere Architekturen gebaut, unsere ist nicht dabei.

Die naheliegende Reaktion wäre gewesen, PaddleOCR selbst zu kompilieren. Wir hatten das sogar vorgeschlagen. Stattdessen kam ein Gegenvorschlag. PaddleOCR ist zweistufig aufgebaut, die schwere Arbeit macht ein Vision-Sprachmodell, und das lässt sich auch von vLLM ausführen, der Software, die auf unserer Karte nachweislich läuft. Nur die kleine Vorverarbeitung bleibt bei PaddleOCR und läuft auf der CPU, wo die fehlende Architekturunterstützung keine Rolle spielt.

Bei Whisper wurde daraus eine Vorhersage. Der übliche Whisper-Server setzt auf eine Bibliothek namens CTranslate2, die genauso vorkompiliert wird. Statt das im Betrieb herauszufinden, wurde vorab geprüft, ob vLLM auch Whisper kann und die passende Schnittstelle mitbringt. Beides traf zu. Damit laufen Gemma 4, Whisper und die Bilderkennung auf einer einzigen Laufzeitumgebung. Ein Image, ein Aktualisierungspfad. Rückblickend ist das die wertvollste Entscheidung des Projekts.

Im Alltagsbetrieb antwortet unsere lokale KI nach etwa einer halben Sekunde. Bei 32 gleichzeitigen Anfragen liefert Gemma 4 insgesamt 1.724 Token pro Sekunde, die Wartezeit bis zum ersten Token bleibt dabei unter 150 Millisekunden.

Der Durchsatz steigt mit der Zahl paralleler Anfragen deutlich an, weil die Grafikkarte mehrere Anfragen gemeinsam verarbeitet. Pro einzelner Anfrage sinkt die Geschwindigkeit dabei, das Gesamtergebnis wächst aber weiter. Alle Werte stammen aus dem Lastwerkzeug von vLLM, jede Anfrage erzeugt exakt 256 Ausgabe-Token. Whisper und die Dokumentenerkennung liefen während der Messung mit auf derselben Karte.

Tabelle 1: Durchsatz von Gemma 4 auf einer NVIDIA RTX PRO 6000 Blackwell bei kurzen Anfragen mit 128 Token Eingabe und 256 Token Ausgabe. Quelle: eigene Messung mit dem Lastwerkzeug von vLLM 0.26.0, August 2026.

Von einer auf 32 parallele Anfragen steigt der Gesamtdurchsatz um den Faktor 12,6. Praktisch bedeutet das, dass eine einzelne Karte eine ganze Abteilung gleichzeitig bedienen kann, ohne dass die Wartezeit bis zum ersten Wort spürbar wächst.

Die folgende Aufnahme zeigt einen Chat mit Gemma 4 in ALBERT | AI ohne Zeitraffer. Die Aufgabe lautete, eine kurze Geschichte zu schreiben. Was du siehst, ist die tatsächliche Ausgabegeschwindigkeit der Karte im laufenden Betrieb.

Video in neuem Fenster öffnen

Unten links im Bild ist das aktive Modell auf der RTX PRO 6000 sichtbar. Genau dieses Tempo meinen wir, wenn wir von Alltagsleistung sprechen. Nicht der Spitzenwert im Lasttest zählt, sondern das, was ein Mitarbeitender am Bildschirm erlebt.

Weil der aufgebaute Kontext erhalten bleibt. Die erste Messreihe sah zunächst ernüchternd aus. Eine einzelne Anfrage mit 240.000 Token braucht rund 52 Sekunden bis zum ersten Wort. Bei zehn gleichzeitigen Anfragen dieser Größe bricht der Durchsatz ein, weil der Zwischenspeicher für zehn volle Kontexte nicht reicht. Zehn solche Anfragen bräuchten 2,4 Millionen Token Zwischenspeicher, vorhanden sind 1,63 Millionen. Das ist keine Softwareschwäche, das ist Arithmetik.

Und hier kam der Hinweis, der die Messung erst nützlich machte. Das ist nicht das Lastprofil eines Chats. In einem echten Gespräch wächst die Historie, sie wird nicht jedes Mal neu aufgebaut. Also folgte eine zweite Messung mit drei aufeinanderfolgenden Fragen auf einem Kontext von 175.000 Token.

Die Wartezeit bis zum ersten Token fällt dabei von 32,81 Sekunden bei der ersten Anfrage auf 0,57 Sekunden bei der zweiten und 0,56 Sekunden bei der dritten. Das ist Faktor 57. Die teure Aufbauphase fällt einmal pro Unterhaltung an, nicht pro Nachricht. Ohne diese zweite Messung hätten wir aus den ersten Zahlen den falschen Schluss gezogen und die Kontextlänge womöglich reduziert.

Weil Gemma 4 nicht jede Schicht den vollständigen Kontext betrachten lässt. Die Rechnung dazu bekamen wir, bevor irgendetwas installiert war, auf Basis der Konfigurationsdatei des Modells statt auf Basis von Vermutungen.

Gemma 4 hat 30 Schichten, aber nur fünf davon sehen den kompletten Verlauf. Die übrigen 25 arbeiten mit einem gleitenden Fenster von 1.024 Token. Nur diese fünf Schichten müssen den ganzen Kontext vorhalten.

Damit kostet eine vollständig ausgereizte Anfrage über 256.000 Token rund 10 GB Zwischenspeicher statt der etwa 61 GB, die ein klassisches Modell mit durchgehender Aufmerksamkeit gebraucht hätte. Genau das entscheidet zwischen machbar und nicht machbar.

Eine spätere Optimierung legt diesen Zwischenspeicher in niedrigerer Genauigkeit ab. Das verdoppelte die Kapazität bei unverändertem Speicherverbrauch, von 814.862 auf 1.625.419 Token, und damit von drei auf sechs gleichzeitige Anfragen mit vollem Kontext.

Über die vorhandene Überwachung, mit möglichst wenig Handarbeit. Wir betreiben ein bestehendes Zabbix. Der einzige Handgriff in der Oberfläche war das Erzeugen eines API-Zugriffstokens. Alles andere lief über die Schnittstelle. Der Host wurde angelegt, die Standardvorlagen für Linux und Erreichbarkeit verknüpft, und für unsere drei Dienste wurden eigene Prüfpunkte samt Auslösern eingerichtet.

Zwei Details sind bemerkenswert.

1. Geprüft wird, ob die Dienste antworten, nicht ob die Container laufen. Ein laufender Container sagt nichts darüber aus, ob die Anwendung darin funktioniert. Nach einem Speicherfehler oder während des Modellladens läuft der Container, der Dienst aber nicht.
2. Die Auslöseschwelle wurde zweimal korrigiert. Der erste Entwurf hätte bei jedem geplanten Neustart Alarm geschlagen, weil das Laden der Modelle mehrere Minuten dauert. Die Begründung für die Korrektur haben wir uns gemerkt. Alarme, die man wegklickt, sind keine Alarme mehr. Kurz darauf zeigte sich, dass auch der korrigierte Auslöser noch falsch war, weil er auf den ersten fehlgeschlagenen Test statt auf zehn Minuten Ausfall reagierte. Der Fehler wurde an den tatsächlichen Messwerten belegt, erklärt und behoben, ohne dass wir nachbohren mussten.

Am Ende stehen 41 Auslöser auf diesem Host. Später kam eine Dauerüberwachung dazu, die alle 30 Sekunden Temperaturen, Auslastung und Erreichbarkeit protokolliert. In der ersten Nacht waren das 1.013 Messpunkte über 8,4 Stunden, alle vier Dienste zu 100 Prozent erreichbar, kein einziger Eintrag im Ereignisprotokoll.

Die Zeitersparnis war real, aber sie war nicht der Hauptgewinn. Wertvoller war, dass Entscheidungen begründet und Annahmen überprüft wurden. Die Debian-Frage, die Speicherrechnung vor der Installation, der zweite Messdurchlauf mit realistischem Lastprofil. Das sind Dinge, die wir unter Zeitdruck vermutlich übersprungen hätten.

Fehler wurden benannt, nicht kaschiert. Der falsch konfigurierte Auslöser, die nicht wirkende Startreihenfolge, das zu eng gefasste Paket-Muster beim Treiber. In allen Fällen kam die Korrektur mit Messwerten statt mit Ausreden. Zweimal wurde eine frühere eigene Aussage von selbst richtiggestellt, ohne dass wir nachgehakt hätten. Bei einem System, das an unserer Stelle auf einer Produktivmaschine arbeitet, ist das die Eigenschaft, auf die es ankommt.

Unsere Rolle hat sich verschoben, sie ist nicht verschwunden. Wir haben keine Befehle mehr getippt, aber wir haben entschieden. Welches Betriebssystem, welcher Treiberzweig, welcher Ansatz für die Dokumentenerkennung, ob ein Neustart-Test sein muss. Die guten Fragen kamen zum richtigen Zeitpunkt, und bei allem, was heikel war, wurde nachgefragt statt einfach gemacht.

Und ganz praktisch. Am Ende stand eine Dokumentation, mit der sich die Maschine von blankem Blech neu aufbauen ließe, inklusive aller Stolperfallen mit Begründung. Das ist der Teil, den wir selbst garantiert nicht geschrieben hätten.

Für Unternehmen, die vor derselben Frage stehen, lässt sich das so zusammenfassen. Lokale KI ist heute keine Forschungsaufgabe mehr, sondern ein Infrastrukturprojekt mit bekannten Stolperfallen. Wer das Fundament sauber baut, betreibt darauf beliebig viele Prozesse. Und weil ALBERT | AI Multi-LLM arbeitet, bleibt Gemma 4 austauschbar, sobald ein besseres Modell verfügbar ist. Das Modell wechselt. Die Prozesse, die Berechtigungen und das Unternehmenswissen bleiben.

Eine Randbedingung stand allerdings in keinem Datenblatt. Einen Tag nach der Inbetriebnahme rief die Nachbarschaft an, weil die Maschine zu laut war. Wie wir die Lüfterkurve gemessen und angepasst haben, steht in unserem Beitrag Der Anruf um 23 Uhr, wie unser KI-Server leise wurde.

Tabelle 2: Aufteilung des Grafikspeichers auf die drei Dienste sowie die eingesetzte Software. Quelle: eigene Inbetriebnahme und Messungen, agorum® Software GmbH, August 2026.

Zuletzt aktualisiert am 3. August 2026. Alle Messwerte wurden mit dem Lastwerkzeug von vLLM 0.26.0 auf der beschriebenen Hardware erhoben.