KI-Anwendungen, die auf Agenten basieren, benötigen ein anderes Design als herkömmliche Webschnittstellen – nicht unbedingt wegen eines neuen Protokolls, sondern weil sich das Verkehrsmuster selbst unterscheidet. Ein einzelnes Gespräch kann sich über Dutzende unabhängiger Anfragen erstrecken, während der Agent mit maschineller Geschwindigkeit und ohne menschliche Wartezeiten arbeitet, die den Druck auf die Infrastruktur verringern würden.
Der in The New Stack in einem von Oracle gesponserten Beitrag veröffentlichte Artikel schlägt vor, ältere Prinzipien aus Microservices wiederzuverwenden, um OpenAI-kompatible und skalierbare Schnittstellen zu entwickeln. Als Proof of Concept dient Oracle AI Database Free.
Warum unterscheidet sich der Datenverkehr von Agenten von dem von Webanwendungen?
Ein Browser kann eine Sitzung dank Sticky Sessions und der Denkpausen des Nutzers über einen einzelnen Server aufrechterhalten. Ein Agent hingegen kann 40 aufeinanderfolgende Zyklen ausführen, wobei jeder Zyklus als eigenständige HTTP-Anfrage eintrifft und das Protokoll nicht garantiert, dass sie an denselben Server weitergeleitet wird. Bleibt der Gesprächsverlauf im lokalen Speicher eines Prozesses, kann die nächste Anfrage den Kontext verlieren, sobald sie zu einer anderen Instanz des Dienstes gelangt.
Auch Tool-Aufrufe können sich unerwartet verzweigen: Eine einzelne Anfrage kann dazu führen, dass kein zusätzlicher Dienst oder mehrere Dienste aufgerufen werden, darunter Vektorsuchen, die 400 Millisekunden dauern können. Agenten erhöhen den Druck außerdem durch ihre eigenen Wiederholungsrichtlinien, während der Datenverkehr in fortlaufenden Wellen eintrifft, die stärker durch Nebenläufigkeitsgrenzen und Hardware als durch das Nutzerverhalten bestimmt werden.
Das stille Problem im ursprünglichen Design
Der Autor stellt einen Prototyp vor, der den Gesprächsverlauf in einem prozessinternen Dictionary speichert, eine einzige Gruppe zur Steuerung der Nebenläufigkeit verwendet und Tool-Aufrufe innerhalb desselben Anfragepfads ausführt. Dieses Design funktioniert in Tests, ist praktisch jedoch darauf angewiesen, dass alle Rollen eines Gesprächs dasselbe Gerät erreichen.
Werden 200 Gespräche mit jeweils vier Rollen abwechselnd auf mehrere Instanzen verteilt, können die Server weiterhin HTTP-200-Codes zurückgeben, während das Modell ohne den korrekten Gesprächsverlauf antwortet. Der Fehler zeigt sich daher nicht unbedingt als klarer technischer Ausfall, sondern als aus Nutzersicht falsches Verhalten.
Drei Prinzipien zur Behebung des Fehlers
- Zustand aus dem Prozess herauslösen: Der Gesprächszustand und der Verlauf der Tool-Aufrufe werden in einem gemeinsamen Speicher abgelegt, sodass jede Instanz jede Rolle eines Gesprächs bedienen kann.
- Isolierung oder Schutzmechanismen: Den verschiedenen Pfaden und Abhängigkeiten, etwa der Vervollständigung des Gesprächs und der Ausführung von Tools, werden unabhängige Nebenläufigkeitsgrenzen und Zeitüberschreitungen zugewiesen, damit der Ausfall eines Bereichs nicht das gesamte System erschöpft.
- Smarte Endpunkte und einfache Pipelines: Das OpenAI-kompatible Protokoll bleibt eine stabile Transportschicht, während Routinglogik, Budgetverwaltung, Speicherverwaltung und Richtlinien für Tool-Aufrufe darüber angesiedelt werden.
Was ändert sich praktisch?
Das Proof of Concept teilt das System in ein Gateway auf, das über das OpenAI-Protokoll kommuniziert und keinen Zustand speichert, einen Speicherdienst, der den Gesprächsverlauf und die Prüfprotokolle verwaltet, einen unabhängigen Tool-Dienst mit eigenen Nebenläufigkeitsgrenzen und Zeitüberschreitungen sowie Oracle AI Database Free als gemeinsamen Speicher. Das Design verwendet unabhängige Steuerungssignale, etwa 24 Plätze für die Gesprächsnebenläufigkeit und 8 für Tool-Aufrufe.
Diese Aufteilung ermöglicht die horizontale Skalierung, ohne vom lokalen Dateisystem oder von Sticky Sessions abhängig zu sein. Auch der offizielle OpenAI-Client kann die Schnittstelle ohne Änderungen am SDK verwenden, solange das Protokoll kompatibel ist.
Die redaktionelle Schlussfolgerung lautet, dass sich die Skalierbarkeit von KI-Agenten nicht allein durch eine Erhöhung der Instanzzahl lösen lässt. Der eigentliche Test besteht darin, den Zustand zu erhalten, langsame Abhängigkeiten zu kontrollieren und zu verhindern, dass Wiederholungsversuche oder Tool-Aufrufe die Agentenwellen in einen Kaskadenausfall verwandeln. Da es sich um von Oracle gesponserten Inhalt handelt, stellt der Artikel eine architektonische Vorgehensweise und ein Proof of Concept vor, nicht jedoch einen unabhängigen Vergleich von Datenbanken oder eine Garantie für eine bestimmte Leistung in jeder Umgebung.