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.

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.

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. Die MCP-Revision 2026-07-28 entfernte den initialize-Handshake und Mcp-Session-Id aus dem modernen, zustandslosen Kern. Jede Anfrage trägt Protokollversion, Identität und Fähigkeiten. Damit verschwindet versteckter Transport-Sitzungszustand, nicht der Anwendungszustand: Dauerhafte Datensätze und explizite Zustandshandles brauchen bei jedem Aufruf Eigentum und Autorisierung. Der Server-Sent-Events-Fortschrittsstrom der Anwendung ist außerdem nicht dasselbe wie MCPs veralteter HTTP+SSE-Transport.

MCP-Autorisierung ist auf Protokollebene optional. Wenn ein HTTP-Deployment den OAuth-Ablauf der Spezifikation umsetzt, verlangt die aktuelle Autorisierungsspezifikation, dass Clients die Zielressource in Autorisierungs- und Token-Anfragen mitsenden und Server nur für sie bestimmte Tokens annehmen. Token-Passthrough an vorgelagerte APIs ist verboten. Die Revision ergänzt RFC-9207-Issuer-Prüfungen und bevorzugt Client ID Metadata Documents; Dynamic Client Registration bleibt zur Kompatibilität erhalten, ist aber veraltet. Diese Transportkontrollen ergänzen ID-Validierung, Objektberechtigungen, Least-Privilege-Scopes, Rate Limits und bereinigte Fehler, ersetzen sie aber nicht.

Langzeitjobs der Plattform und MCP Tasks sind verwandte, aber nicht identische Verträge. Im aktuellen Protokoll sind Tasks die opt-in Erweiterung io.modelcontextprotocol/tasks, nicht Teil des Kerns. Ein Server darf nur dann ein dauerhaftes Task-Handle zurückgeben, wenn der Client Unterstützung erklärt hat; danach nutzt der Client tasks/get, tasks/update und tasks/cancel. Die Client-Unterstützung variiert. Ein internes Jobsystem kann die Erweiterung tragen, aber ein Polling-Endpunkt oder SSE-Strom implementiert nicht automatisch MCP Tasks.

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 Readiness-Endpunkt prüfte die Datenbankverbindung, weshalb ein Prozess ohne seinen maßgeblichen Store keinen Traffic erhielt. Prozess-Liveness blieb ein getrenntes Signal.

Deployment-Kontrollen brauchen eine Fehleraktion. AWS dokumentiert Deployment Circuit Breaker und CloudWatch Alarms als Mechanismen, die unterstützte ECS-Deployments als fehlgeschlagen markieren können. Beide können ein automatisches Rollback auslösen, wenn Rollback konfiguriert ist und ein zuvor abgeschlossenes Deployment existiert. 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. Für Systeme, die generative KI-Modelle entwickeln, nutzen oder beschaffen, ergänzt NIST SP 800-218A den SSDF 1.1 um KI-spezifische Praktiken und Erwägungen; das Profil ersetzt das Grundgerüst nicht.

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:

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.