Eine Stateful-LLM-Plattform produktionsreif machen, ohne das Produkt neu zu bauen
Produktionsarchitektur für Stateful-LLM-Plattformen umfasst jene Systemgrenzen, die eine KI-Anwendung für mehrere Nutzer wiederholt und sicher betreibbar machen. Dazu gehören maßgebliche Daten, Identität, Objektzugriff, aufwendige Hintergrundarbeit, externe Schnittstellen, Deployment, Wiederherstellung und Verifikation. Der Modellaufruf ist nur eine Komponente dieses Betriebssystems.
Dieser Artikel beantwortet eine eng gefasste Frage: Wie wird aus einer funktionsreichen, zustandsbehafteten LLM-Anwendung für die lokale Forschung ein kontrollierter gemeinsamer Pilot? Ob überhaupt ein Knowledge Graph nötig ist, klärt unser Entscheidungsleitfaden zu Graph Engineering. Die allgemeine Checkliste vom Prototyp bis zur Produktion hat ebenfalls einen eigenen Suchintent. Hier geht es um die Abhängigkeitsreihenfolge für eine Plattform, die bereits wertvolle Produktlogik besitzt.
Was unterscheidet eine Stateful-LLM-Anwendung von einer Demo?
Eine Demo kann Kontext in einer Browser-Session halten, Fixtures aus Dateien laden und synchron auf eine Modellantwort warten. Eine gemeinsame Plattform kann das nicht. Nutzer erwarten, dass ihre Daten ein Deployment überleben, Berechtigungen über jede Schnittstelle gelten und ein Langzeitvorgang auch nach Timeout, Reload oder Fehler verständlich bleibt.
Die Ausgangsanwendung in diesem Projekt enthielt bereits umfangreiche Logik für strukturierte Fachdaten, Graph-Operationen, Dokumentaufnahme, fundierte Gespräche, Interviews, Simulationen und Evaluation. Es fehlte keine lange Feature-Liste. Es fehlte eine klare betriebliche Verantwortung über die Pfade hinweg, die diese Funktionen verbinden.
| Forschungsfreundliche Annahme | Anforderung an die gemeinsame Plattform | Fehler bei impliziter Lösung |
|---|---|---|
| Dateien sind der Live-Zustand | Ein maßgeblicher transaktionaler Store | Deployments oder parallele Nutzer erzeugen abweichende Daten. |
| Ein vertrauenswürdiger Operator | Servervalidierte Identität und Objektzugriff | Ein gültiger Nutzer erreicht fremde Daten. |
| Der Request wartet auf das Modell | Verantwortete, beobachtbare und wiederherstellbare Jobs | Timeouts wirken wie Fehler und Retries duplizieren Arbeit. |
| Der Browser ist der einzige Client | Eine Richtlinie für Browser, API und MCP | Eine neue Schnittstelle umgeht reine UI-Annahmen. |
| Ein laufender Prozess ist gesund | Abhängigkeitsbewusste Readiness und Rollback | Traffic erreicht eine Anwendung ohne korrekte Ergebnisse. |
| Manuelle Tests belegen den Release | Automatisierte Checks plus repräsentative Flow-QA | Schichtübergreifende Regressionen kehren zurück. |
Die Produktionsreihenfolge in sieben Schichten
Die Reihenfolge zählt. Wer das Interface vor Persistenz und Zugriffskontrolle poliert, macht instabiles Verhalten nur leichter vorführbar. Wer vor einer zentralen Autorisierung eine externe API ergänzt, baut ein zweites Sicherheitsmodell. Deshalb erhielt jede Grundlage einen stabilen Eigentümer, bevor die darüberliegende Oberfläche wuchs.
1. Betriebsrahmen definieren, bevor Infrastruktur gewählt wird
Das Ziel war eine kontrollierte Erstveröffentlichung, keine Behauptung global redundanter Enterprise-Infrastruktur. Daraus folgten konkrete Abnahmekriterien: reproduzierbares HTTPS-Deployment, persistente Daten, kontrolliertes Onboarding, rücksetzbare Releases, brauchbare Logs und eine offene Liste der verbleibenden Skalierungs- und Verfügbarkeitsschritte.
Diese Formulierung verhindert Architekturtheater. Ein einzelner Anwendungstask und eine Datenbank in einer Zone können für einen Design-Partner-Piloten angemessen sein, wenn Ausfallmodi, Backups und Eskalationswege dokumentiert sind. Hochverfügbarkeit sind sie nicht. Der benannte Rahmen erlaubt, die nächste Zuverlässigkeitsstufe erst dann zu kaufen, wenn die Nutzung sie rechtfertigt.
2. Maßgeblichen Laufzeitstatus nach PostgreSQL verlagern
Die Anwendung besaß portable Seed-Dateien und lokale Datenflüsse, die in der Forschung nützlich waren. Wavect behielt diese Dateien als kontrolliertes Bootstrap-Material bei, verlagerte aber aktive Fachobjekte, Ontologien, Nutzer, Organisationen, Zugriffsfreigaben, Sessions und Maschinenzugänge in PostgreSQL-gestützte Stores.
Die zentrale Entscheidung war Ownership, nicht die Datenbankmarke. Jede Domäne erhielt einen Store- oder Repository-Vertrag, gepoolte Verbindungen und explizites CRUD-Verhalten. Ein leeres System konnte deterministisch befüllt werden, doch ein laufender Container behandelte veränderliche Dateien nicht mehr als Source of Truth. Integrationstests prüften anschließend dasselbe Persistenzverhalten wie das gemeinsame Deployment.
3. Identität, Mandantenmitgliedschaft und Objektberechtigung zentralisieren
Authentifizierung belegt, wer einen Request gesendet hat. Sie belegt nicht, dass diese Person ein bestimmtes Objekt, einen Graph oder einen Job öffnen darf. Die Plattform verband deshalb widerrufbare serverseitige Browser-Sessions, Admin-Rollen, Organisationsmitgliedschaft und nutzerspezifische Objektfreigaben hinter einer gemeinsamen Zugriffsentscheidung. Browser-Routen, JSON-APIs und externe Clients mussten dieselbe Frage stellen.
Genau diese Grenze beschreibt OWASP API1:2023 Broken Object Level Authorization: Jeder Endpunkt, der eine Objekt-ID erhält, muss prüfen, ob der angemeldete Nutzer die angeforderte Aktion auf diesem Objekt ausführen darf. UUIDs, ein gültiges JWT oder ein versteckter Button ersetzen diese Prüfung nicht.
Die praktische Testmatrix kombinierte Rollen, Organisationen, Objekte und Transportwege. Ein normaler Nutzer durfte durch eine geänderte ID keinen Zugriff erhalten. Ein Organisationsadministrator musste innerhalb seiner Organisation bleiben. Eine widerrufene Session oder ein widerrufener API-Key durfte ohne neues Deployment nicht mehr funktionieren.
4. Langlaufende LLM-Arbeit als verantwortete Jobs behandeln
Dokumentenextraktion, Interviews, Profilerzeugung und Simulationen können einen normalen HTTP-Request überdauern. Ein längeres Webserver-Timeout lindert nur ein Symptom. Es beantwortet nicht, wem die Arbeit gehört, ob ein Retry sicher ist oder wie Nutzer den tatsächlichen Zustand erkennen.
Wavect führte einen backendunabhängigen Job-Vertrag mit typisierten Zuständen, Handler-Registrierung, nutzerspezifischen Parallelitätsgrenzen, Idempotency Keys, kooperativer Abbruchlogik, gespeicherten Ergebnissen und Fehlern, Ablauf fertiger Jobs und geordnetem Shutdown ein. Polling-Endpunkte bildeten die einfache Basis. Server-Sent Events lieferten Anwendungsfortschritt und Heartbeats, ohne die Browser-Verbindung zum Eigentümer des Jobs zu machen.
| Job-Eigenschaft | Zu beantwortende Frage | Release-Evidenz |
|---|---|---|
| Ownership | Welcher authentifizierte Nutzer darf ihn sehen oder abbrechen? | Tests für fremde Nutzer schlagen geschlossen fehl. |
| Idempotenz | Was passiert bei doppelter Übermittlung? | Das Duplikat führt zur gleichen beabsichtigten Ausführung. |
| Fortschritt | Sind aktiv, blockiert, fehlgeschlagen und fertig unterscheidbar? | Polling und Event-Pfad zeigen denselben Zustand. |
| Abbruch | Kann teure Arbeit an einer sicheren Grenze stoppen? | Der Handler kooperiert und speichert den Endzustand. |
| Shutdown | Was geschieht während eines Deployments? | Die Queue läuft aus oder markiert offene Arbeit zur Wiederaufnahme. |
Ein In-Process-Executor war ein bewusster Pilot-Trade-off, nicht die endgültige Skalierungslösung. Der Vertrag erlaubte später den Wechsel zu einer dauerhaften Queue, ohne jeden Produktflow neu zu schreiben. Der Job-Lebenszyklus muss vom ersten ausführenden Backend getrennt bleiben.
5. Browser-, API- und MCP-Zugriff mit expliziten Sicherheitsverträgen versehen
Die externe API wurde in modulare Routengruppen mit gemeinsamen Abhängigkeiten, Standardfehlern, Scope-Prüfungen, Objektberechtigungen und Throttling gegliedert. Human Sessions, JWTs und gehashte API-Keys bedienten unterschiedliche Clients, liefen aber in denselben Fachberechtigungen zusammen. Administrative Einstellungen konnten externen Zugriff für ein einzelnes Objekt abschalten, statt jede Fähigkeit standardmäßig freizugeben.
Für MCP gilt dieselbe Disziplin. Ein Tool Call ist nicht vertrauenswürdig, nur weil ein Agent ihn ausgelöst hat. ID-Validierung, getrennte Read- und Write-Scopes, Rate Limits und bereinigte Fehlermeldungen bleiben nötig. Die aktuelle Autorisierungsspezifikation des Model Context Protocol verlangt ressourcengebundene Autorisierungsanfragen und die Prüfung der Token-Audience. Neue Integrationen sollten dem aktuellen Protokoll folgen, statt Session- oder Transportannahmen einer älteren Implementierung zu kopieren.
6. Deployment-Gesundheit an den wirklich benötigten Dienst binden
Infrastructure as Code beschrieb Netzwerk, Container-Service, private Datenbank, Load Balancer, TLS, DNS, Image Registry, Logs und Berechtigungen. Ein Workflow baute aus einem Commit ein versioniertes Image, aktualisierte den Service und wartete auf Stabilität. Der Health-Endpunkt prüfte die Datenbankverbindung, weshalb ein Prozess ohne seinen maßgeblichen Store nicht als bereit galt.
Deployment-Kontrollen brauchen eine Fehleraktion. AWS dokumentiert Deployment Circuit Breaker und CloudWatch Alarms als Mechanismen, die fehlgeschlagene ECS-Deployments erkennen und auf den letzten bekannten guten Zustand zurücksetzen können. In diesem Programm waren health-basiertes Deployment und Rollback Teil des Release-Designs, nicht die improvisierte Reaktion eines Operators.
7. Automatisierte Tests mit wiederholter Browser-QA verbinden
Unit-Tests deckten isoliertes Graph-, Retrieval-, Grounding-, Safety- und Job-Verhalten ab. Ein eigener Integrationstrack nutzte einen echten PostgreSQL-Service für Persistenz, Authentifizierung, API und MCP. Dadurch blieb schnelles Feedback schnell, ohne genau jene Grenzen wegzumocken, die im gemeinsamen Deployment am ehesten versagen.
Automatisierung ersetzte keine explorative QA. Wiederholte Browser-Runden zeigten Interaktionsfehler bei Login-Ablauf, Auswahlstatus, Langzeitfortschritt, Graph-Bearbeitung, Berechnungen, Theme-Synchronisierung, Fehlermeldungen und Ladeverhalten. Jeder Defekt wurde beim niedrigsten stabilen Eigentümer behoben und, wo sinnvoll, mit einem Regressionstest abgesichert.
Dieser risikogeordnete Ansatz entspricht dem NIST Secure Software Development Framework. Es gliedert sichere Entwicklung in organisatorische Vorbereitung, Schutz der Software, sicher entwickelte Releases und den Umgang mit verbleibenden Schwachstellen. NIST beschreibt die Praktiken ausdrücklich als anpassbare Grundlage für risikobasierte Verbesserung, nicht als universelle Checkliste.
Welche Evidenz macht einen kontrollierten Piloten glaubwürdig?
Produktionsreife ist keine binäre Eigenschaft eines Repositories. Sie ist eine Release-Aussage, die über den definierten Betriebsrahmen hinweg belegt werden muss. Für diese Plattformklasse braucht es mindestens folgende Evidenz:
| Grenze | Evidenz vor dem Release | Offen zu nennendes Restrisiko |
|---|---|---|
| Daten | Persistenz- und Seed-Tests gegen PostgreSQL sowie Backup- und Restore-Ablauf | Reife von Migration und Wiederherstellung |
| Zugriff | Rollen-, Mandanten- und Objekttests für Session- und Token-Clients | Admin-Missbrauch und künftiges Richtlinienwachstum |
| LLM-Jobs | Duplikat-, Abbruch-, Timeout-, Fehler- und Shutdown-Verhalten | Haltbarkeit und Kapazität der prozesslokalen Queue |
| Externe Schnittstellen | Scope-, Rate-Limit-, Eingabe- und bereinigte Fehlertests | Protokollentwicklung und Verhalten fremder Clients |
| Deployment | Health-basierter Rollout, beobachtbarer Fehler und getesteter Rollback | Verfügbarkeit bei einem Task und einer Zone |
| User Journeys | Repräsentative Browser-Flows mit Recovery aus abgelaufenen oder partiellen Zuständen | Unbekannte Kombinationen in einer großen interaktiven Oberfläche |
Warum inkrementelle Produktionsreife den Rewrite schlug
Die bestehende Anwendung enthielt bereits schwer erarbeitete Produktlogik. Ein Rewrite hätte sichtbare technische Schulden gegen verborgenes Regressionsrisiko im Produkt getauscht. Der schnellere Weg bestand darin, validierte Flows zu erhalten, darunter stabile Verantwortungen einzubauen und Defekte gegen diese neue Grundlage zu reparieren.
Das bedeutet nicht, dass jede alte Entscheidung blieb. Dateibasierter Laufzeitstatus verlor seine Autorität. Zugriffsprüfungen wanderten aus Einzelrouten. Langzeitprozesse gehörten nicht mehr einem Request. API-Abhängigkeiten wurden explizit. Gemeinsame UI-Muster ersetzten lokale Korrekturen. Inkrementelle Produktionsreife ist selektiver Ersatz mit Evidenzspur, kein endloses Patchen.
Für Produkte mit ähnlicher Form deckt Wavects Service für AI Enablement und Architektur Evaluation, Systemgrenzen, Production Hardening und Übergabe ab. Die anonymisierte Fallstudie zur Analytics-Plattform zeigt unabhängig davon, wie ein komplexes Datenprodukt ohne Kundennamen stabilisiert wurde. Für die größere Keep-or-Rebuild-Entscheidung dient der Leitfaden vom Prototyp bis zur Produktion. Mit den aktuellen Betriebsbedingungen lässt sich außerdem direkt ein Review der Produktionsarchitektur anfragen.
FAQ zur Produktionsarchitektur von Stateful-LLM-Plattformen
Was ist eine Stateful-LLM-Plattform?
Was sollte bei einer LLM-Anwendung zuerst produktionsreif gemacht werden?
Soll langlaufende LLM-Arbeit in einem HTTP-Request bleiben?
Wie sollte ein MCP-Server auf Plattformdaten zugreifen?
Bedeutet ein erfolgreicher Pilot Hochverfügbarkeit?
Wann ist ein Rewrite gerechtfertigt?
Fazit
Eine Stateful-LLM-Plattform wird betreibbar, wenn jeder wichtige Zustand und jede Autorität einen Eigentümer besitzt. PostgreSQL verantwortet dauerhafte Laufzeitdaten. Eine zentrale Richtlinie verantwortet Mandanten- und Objektzugriff. Der Job-Layer verantwortet teure Arbeit. API- und MCP-Routen verwenden dieselben Entscheidungen. Deployment-Health bildet echte Abhängigkeiten ab, und Tests plus Browser-QA liefern Release-Evidenz.
Erhalte das Produktverhalten, das Nutzer bereits schätzen. Ersetze Grundlagen, die keinen gemeinsamen Betrieb tragen. Benenne vor allem den Betriebsrahmen ehrlich. Ein kontrollierter Pilot mit expliziten Trade-offs ist das stärkere Engineering-Ergebnis als eine undefinierte Production-Ready-Behauptung.