Agentische KI stößt an Infrastrukturgrenzen, bevor sie an Intelligenzgrenzen stößt

Die Modelle werden schneller besser, als wir sie mit dem versorgen können, was von ihnen verlangt wird.

Bei den meisten Diskussionen über die Zukunft von KI-Agenten geht es um ihre Fähigkeiten. Kann das Modell zuverlässig planen? Kann es seine eigenen Fehler korrigieren? Kann man ihm eine Handlung anvertrauen, die Folgen hat?

Das sind berechtigte Fragen. Sie werden jedoch nicht darüber entscheiden, ob Agenten in den nächsten Jahren in großem Maßstab eingesetzt werden, denn es gibt eine näherliegende Einschränkung, die sich schneller bemerkbar macht. Der Betrieb von Agenten ist wirtschaftlich schwierig, und genau die Fähigkeiten, die alle hinzufügen wollen, verschärfen das Problem.

Ein Chatbot und ein Agent stellen unterschiedliche Arbeitslasten dar

Eine Gesprächsanfrage besteht aus einem einzigen Hin und Zurück: Eingabe rein, Token raus, Verbindung geschlossen. Man kann sie stapelweise verarbeiten, den Präfix zwischenspeichern und den Durchsatz anhand einer einzigen Kennzahl beurteilen.

Eine Agentenanfrage ist eine Sitzung. Der Agent ruft ein Tool auf, wartet, liest das Ergebnis, entscheidet, was als Nächstes zu tun ist, ruft ein weiteres Tool auf und gibt schließlich eine Antwort. Eine einfache Aufgabe kann sechs oder acht Modellaufrufe umfassen, mit Wartezeiten dazwischen.

Dieser Unterschied ist aus einem Grund wichtig, der nichts mit Intelligenz zu tun hat. Zwischen den einzelnen Schritten hält der Agent einen Zustand aufrecht – das Gespräch, die Tool-Ausgaben und die angesammelten Überlegungen. Beim Betrieb liegt dieser Zustand im GPU-Speicher als KV-Cache und belegt während der gesamten Sitzung Speicher, auch während der Sekunden, in denen der Agent auf eine API wartet, die nicht von Ihnen betrieben wird.

Damit ist nicht mehr die Zahl der „Anfragen pro Sekunde“ die maßgebliche Kapazitätsgröße, sondern die Zahl der „gleichzeitig aktiven Sitzungen im Speicher“. Ein System, das problemlos tausend Gesprächsanfragen pro Sekunde bewältigte, schafft auf derselben Hardware möglicherweise nur einige Dutzend gleichzeitig laufende Agentensitzungen.

Das Warten ist der kostspielige Teil

Hier zeigt sich die unbequeme Seite: Während eines Tool-Aufrufs tut der Agent nichts. Es werden keine Token generiert. Es wird keine Rechenleistung beansprucht. Der GPU-Speicher bleibt dennoch belegt, denn den Kontext auszulagern und später neu zu berechnen wäre kostspieliger, als ihn vorzuhalten.

Ihre teuerste Hardware ist für eine Anfrage reserviert, die gerade auf eine Datenbankabfrage wartet.

In herkömmlichen verteilten Systemen haben wir dieses Problem schon vor langer Zeit gelöst: Man gibt die Ressource frei und setzt die Arbeit fort, sobald die Antwort eintrifft. Bei der Bereitstellung von Modellen müsste man dafür den KV-Cache in den Hauptspeicher oder auf die Festplatte auslagern und anschließend wiederherstellen. Die Übertragungskosten sind jedoch so hoch, dass die meisten Systeme darauf verzichten. Genau dazu wird geforscht – und zwar, weil das Problem kostspielig ist.

Sequentielle Ausführung verschärft das Problem unnötig

Fast alle Agenten-Frameworks führen Tool-Aufrufe nacheinander aus. Das Modell fragt das Wetter ab, erhält das Ergebnis, fragt den Kalender ab, erhält das Ergebnis, sucht nach Flügen und erhält das Ergebnis.

Häufig hängen diese drei Aufrufe nicht voneinander ab. Sie könnten gleichzeitig ausgeführt werden. Bei sequentieller Ausführung entspricht die Latenz der Summe ihrer Laufzeiten. Bei gleichzeitiger Ausführung entspricht sie der Laufzeit des längsten Aufrufs.

Das ist keine neue Erkenntnis über Agenten, sondern derselbe strukturelle Zusammenhang, der für jedes System gilt, das mehrere Modelle oder Dienste innerhalb eines Latenzbudgets ausführt. Die Gesamtlatenz sollte dem längsten Pfad durch den Abhängigkeitsgraphen entsprechen, nicht der Summe aller Schritte. Für Agenten ist das besonders wichtig, weil die Sitzung während ihrer gesamten Laufzeit im GPU-Speicher verbleibt. Eine kürzere Gesamtzeit verbessert daher nicht nur das Nutzererlebnis, sondern erhöht unmittelbar auch die Zahl der Sitzungen, die auf der Hardware Platz finden.

Halbiert sich die Sitzungsdauer, verdoppelt sich ungefähr die Zahl der gleichzeitig möglichen Sitzungen – auf denselben GPUs und ohne Änderungen am Modell.

Wiederholungsversuche summieren sich auf eine Weise, die niemand vorgesehen hat

Agenten-Frameworks übernehmen die Standardwerte für Wiederholungsversuche aus den zugrunde liegenden HTTP-Bibliotheken. Meist sind es drei Versuche.

Auch das Modell unternimmt auf seine Weise Wiederholungsversuche. Liefert ein Tool ein wenig hilfreiches Ergebnis, probiert ein Schlussfolgerungsmodell oft einen anderen Ansatz – das ist ebenfalls ein Wiederholungsversuch, nur hat ihn niemand konfiguriert.

Zusammen ergibt das Folgendes: Eine Richtlinie mit drei Versuchen, die ein Modell umgibt, das eigenständig drei weitere Ansätze entwickelt, führt zu einer Richtlinie mit neun Versuchen, die niemand festgelegt hat. Jeder dieser Versuche ist ein vollständiger Modellaufruf mit eigenen Token und eigener GPU-Laufzeit in Sekunden.

Verlangsamt sich eine Abhängigkeit, führt diese Verstärkung dazu, dass aus einer Beeinträchtigung ein Ausfall wird – und die Kosten pro Versuch liegen dabei um Größenordnungen über denen eines wiederholten REST-Aufrufs.

Wie sich die Grenze tatsächlich zeigt

Keine Grenze der Fähigkeiten, sondern etwas viel Alltäglicheres: ein Problem der Wirtschaftlichkeit, an dem Projekte beim Übergang vom Pilotbetrieb in die Produktion scheitern.

Der Pilot funktioniert. Es sind zehn Nutzer, die Latenz ist akzeptabel und die Rechnung fällt kaum ins Gewicht. Dann berechnet jemand den Bedarf für zehntausend Nutzer, und der erforderliche GPU-Einsatz erscheint unrealistisch – nicht, weil das Modell langsam ist, sondern weil jede gleichzeitig laufende Sitzung während ihrer gesamten Laufzeit Speicher belegt und zu dieser Laufzeit auch die Wartezeit gehört.

Dies ist der Punkt, an dem viele vielversprechende interne Demos stillschweigend eingestellt werden.

Was die Grenze verschiebt

Nichts Exotisches, und all das betrifft die Infrastruktur statt die Modellierung:

Unabhängige Tool-Aufrufe parallel ausführen. Der größte einzelne Gewinn, der heute verfügbar ist und keine neue Hardware erfordert.

Die Sitzungsdauer als Kapazitätskennzahl betrachten. Nicht Tokens pro Sekunde. Nicht GPU-Auslastung. Entscheidend ist, wie lange der Zustand im Speicher gehalten wird und wie viele Sitzungen hineinpassen.

Wiederholungsversuche systemweit statt pro Aufruf budgetieren. Eine globale Obergrenze – Wiederholungsversuche als kleiner Prozentsatz des Gesamtverkehrs – verhindert die oben beschriebene Kettenwirkung. Googles SRE-Praxis zum Umgang mit Überlast und Envoys Budgets für Wiederholungsversuche setzen diese Idee beide außerhalb des KI-Stacks um.

Planung und Ausführung voneinander trennen. Ein großes Modell für die Planung, ein deutlich kleineres für die mechanischen Schritte. Für die meisten Aufgaben eines Agenten ist kein Spitzenmodell nötig.

Das Verwerfen von Kontext kostengünstig machen. Ein quantisierter KV-Cache, seitenweise Aufmerksamkeitsberechnung und Auslagerungspfade für inaktive Sitzungen. Hier findet derzeit die spannendste Arbeit an der Bereitstellung statt.

Die Modelle werden sich weiter verbessern. Dieser Teil scheint sicher. Ob Agenten zur Infrastruktur werden oder Demos bleiben, hängt von etwas weniger Glamourösem ab – davon, ob wir eine Arbeitslast bereitstellen können, die teuren Speicher belegt, während sie wartet, und ob wir aufhören, die Summe einer Sequenz zu bezahlen, obwohl wir nur für ihren längsten Pfad bezahlen könnten.

Das Ausführungsmodell, das diesem letzten Punkt zugrunde liegt – die gleichzeitige Ausführung voneinander abhängiger Modellaufrufe innerhalb eines einzigen Latenzbudgets –, habe ich in „Asynchrone Ausführung von Inferenzgraphen für das Modellrouting in maschinellen Lernsystemen“, International Journal of Computer Trends and Technology 72(10), Oktober 2024, veröffentlicht. Zur Integration generativer Modelle in latenzgebundene Entscheidungssysteme im Besonderen siehe „Durch LLMs erweiterte Handels- und Entscheidungsplattformen: Generative Intelligenz mit finanziellen Entscheidungssystemen verbinden“, Journal of Information Systems Engineering and Management 11(1s), 2026.