Enterprise-KI-Stack im Eigenbetrieb
Referenzkunde: Eigenbetrieb: die firmeneigene KI-Infrastruktur des Studios
Kundendaten in Texten und Bildern sind neutralisiert.
Ausgangslage
Eigene KI-Modelle auf eigener Hardware zu betreiben heißt, jede Entscheidung selbst zu treffen, die eine gemietete API einem abnimmt: welches Modell, welcher Kontext, welche Karte, welcher Ausweichweg. Dafür bleiben die Daten im Haus, und niemand sonst entscheidet, wann ein Modell abgeschaltet oder ausgetauscht wird.
Diese Referenz kommt aus dem Eigenbetrieb: die Flotte, die LibreChat, die eigenen Agenten und die interne Dokumentenverarbeitung täglich trägt — stößt hier eine Karte an ihre Grenze, wissen wir es zuerst, nicht ein Kunde, der gerade wartet.
Das Schwierige daran
Am Anfang stand ein einziges großes Modell, das ein Cron-Job morgens und abends austauschte. Das hielt so lange, bis der Zeitplan das Modell überlebte: Der Umschalter versuchte noch Wochen später, ein längst abgelöstes Modell wiederzubeleben, weil ihn niemand davon in Kenntnis gesetzt hatte.
Eine zweite Karte las Dokumente für die Rechnungsverarbeitung — mit einer eigenen, unabhängigen Modellarchitektur, damit zwei Leser nicht auf derselben Grundlage sitzen und sich gemeinsam irren. Diese Karte war Spezialhardware, die zum Rest der Flotte nicht kompatibel war, und musste für ein anderes Projekt weichen.
Ein dritter Dienst, ein Telegram-Bot für die tägliche Kurzmeldung, zog binnen drei Wochen über drei verschiedene Karten, immer dorthin, wo gerade Kapazität frei war. Auf der letzten lief er fünf Tage lang blind, weil eine einzelne Datei — der Bildmodul für das Sehen — beim Umzug schlicht vergessen wurde. Kein Fehler, keine Warnung, nur eine Antwort, die nie zum Bild passte.
Lösung
Die Flotte trägt heute eine einzige Modellfamilie über alle Chat-Lanes hinweg — Denken an, Denken aus, Agenten-Betrieb, Dokumentensicht — von einem Server mit vier Grafikkarten, statt sieben verschiedener Modellnamen für sieben verschiedene Zwecke.
Fällt der Hauptserver aus oder braucht er zu lange, springt automatisch eine zweite Karte mit derselben Modellfamilie ein — kleinerer Kontext, andere Quantisierung, aber ohne dass ein Nutzer etwas davon merkt.
Die kleinen, ständig gebrauchten Dienste — Einbettung für die Suche, Neu-Sortierung der Treffer, Texterkennung — sitzen zusammen auf einer einzigen kleinen Karte statt verstreut über die Flotte.
Wie es gebaut ist
Ein Gateway ist der einzige Ansprechpartner für jeden Aufrufer — LibreChat, die Agenten, die interne Automatisierung, sogar die CNC-Anlage in der Fertigung. Welche Karte tatsächlich antwortet, ist dahinter verborgen, und genau das macht den Ausweichserver möglich, ohne dass ein Client umgestellt werden müsste.
Der Weg zur heutigen Kontextgröße von 262.144 Token war kein gerader. Ein neues Modell brauchte zunächst einen niedrigeren, ehrlicheren Wert, weil der alte Höchstwert für die neue Architektur nicht mehr galt — ein Fehler, der sonst erst beim ersten abgeschnittenen Gespräch aufgefallen wäre. Ein Patch am Zwischenspeicher der Karten hob die gleichzeitige Kapazität von 3,2 auf 5,9 volle Gespräche an, bevor der Kontext wieder auf sein echtes Maximum stieg.
Eine andere Software für dasselbe neue Modell lieferte im Alleinbetrieb hervorragende Werte — und brach bei acht gleichzeitigen Anfragen auf weniger als die Hälfte des Einzeldurchsatzes ein. Die jetzige Lösung sättigt stattdessen bei über 30 gleichzeitigen Gesprächen, statt bei acht zusammenzubrechen. Das allein hat über die Wahl der Serversoftware entschieden.
Bei der Dokumentenverarbeitung stimmen vier unabhängige Leseversuche über jedes Feld ab — zwei Sprachmodelle, zwei deterministische Texterkennungen. Nachdem die Spezialkarte wegfiel, teilen sich zwei dieser vier Stimmen denselben Server. Das ist offen dokumentiert und wird nicht schöngeredet: Es sind heute drei unabhängige Meinungen, nicht vier.
Im Betrieb
Ein Wächter-Skript startet gestoppte Dienste automatisch neu — praktisch, bis er ein Modell falsch identifiziert und ein längst abgelöstes wiederbelebt. Die Regel dazu ist inzwischen so einfach wie hart: Ein Dienst gilt nur dann als 'sollte laufen', wenn seine eigene Neustart-Richtlinie das auch sagt.
Der automatische Ausweichweg wird nicht nur konfiguriert, sondern regelmäßig scharf geprüft: Der Hauptserver wird kurz lahmgelegt, und es zählt nur, ob der zweite tatsächlich übernimmt — nicht, ob die Konfiguration plausibel aussieht.
Ergebnis
Alle Chat-Lanes laufen heute über eine Modellfamilie mit automatischer Ausfallsicherung, bei 262.144 Token nativer Kontextgrenze — gemessen, nicht behauptet.
Der frühere Kopfknoten der Flotte trägt heute keine einzige Grafikkarte mehr; sein komplettes Spezialtreiber-Softwarepaket wurde entfernt, 22 GB Speicherplatz frei.
Was wir daraus gelernt haben
Die fehlende Bilddatei beim Bot-Umzug ist die teuerste Lehre: Ein Dienst, der auf ein fehlendes Modul mit einer plausibel klingenden, aber falschen Antwort reagiert, sieht fünf Tage lang wie ein funktionierender Dienst aus. Seither gilt: Nach jedem Umzug ein bekanntes Testbild schicken und die erwartete Antwort wirklich prüfen, nicht nur den Health-Check.
Dass zwei von vier Prüfspuren in der Dokumentenverarbeitung denselben Server teilen, war kein geplanter Kompromiss, sondern die Folge eines Hardware-Abbaus an anderer Stelle. Gefunden wurde es erst, als für diese Referenz nachgemessen wurde, welches Modell hinter welchem Namen tatsächlich läuft — nicht, was die Konfiguration behauptete.
Der Wächter, der Dienste wiederbelebt, hat einmal mitten in einer Wartung das falsche, viel größere Modell hochgefahren und den knappen Grafikspeicher belegt. Seither steht vor jedem Eingriff an dieser Flotte derselbe erste Schritt: den Wächter anhalten, bevor man irgendetwas anderes anfasst.
Ähnliches Problem?
Erzähl uns, was du vorhast — ein kurzes Gespräch klärt, ob sich das rechnet.
senn-tech