Das Modell ist fertig, der Agent wartet

Kurzfassung: Ein schnelleres KI-Modell verkürzt nicht automatisch den vollständigen Auftrag. Agenten brauchen auch Dienste für Datenabruf und Werkzeugausführung. Die AWS-Dokumentation beschreibt diese Arbeit als eigene Last neben der Modellinferenz. Für Investitionen zählt, welcher Teil eines Vorgangs seine Bearbeitungszeit bestimmt. Mehr Modellkontingent und mehr Ausführungskapazität sind unterschiedliche Ausgaben.

Ein Agent soll eine Serviceanfrage vorbereiten. Das Modell hat entschieden, welche Unterlagen fehlen, und den nächsten Abruf angefordert. Nun wartet die Anwendung auf einen Dokumentendienst. In diesem gedachten Fall würde ein schnelleres Modell den nächsten Schritt früher anstoßen. Ob die fertige Fallvorbereitung deshalb wesentlich früher vorliegt, hängt aber auch von der Ausführung dieses Schritts ab.

Rund um die Antwort wird weitergerechnet

Für das KI-Management wird damit eine zweite Leistung neben dem Modellzugang sichtbar: der Betrieb der ausführenden Anwendung. Beide Leistungen können von einem Anbieter kommen. Die Zahl möglicher Modellantworten beschreibt aber noch nicht die Zahl vollständig vorbereiteter Fälle.

Amazon beschreibt in seiner EKS-Dokumentation CPUs und GPUs als komplementäre Ressourcen. Um einen Modellaufruf herum liegen Werkzeugausführung, Kontextaufbereitung, Suche und die Steuerung des Ablaufs. Die Dokumentation behandelt diese Aufgaben als eigene CPU-Last und beschreibt eine Architektur, in der sich die entsprechende Anwendungsschicht unabhängig von der GPU-Schicht erweitern lässt.

Das ist keine feste Arbeitsteilung nach Chipnamen. Auch kleinere Sprachmodelle können auf CPUs rechnen. Umgekehrt nutzt ein Werkzeug möglicherweise selbst einen beschleunigten Rechendienst. Entscheidend ist, welche Aufgabe wo läuft und wodurch ihre Leistung begrenzt wird. Die Herstellerdokumentation empfiehlt deshalb Messungen mit den eigenen Modellen, Daten und Anforderungen an die Antwortzeit. Sie ist eine technische Orientierung, kein unabhängiger Leistungstest.

Für ein Unternehmen, das ein externes Modell nutzt, bleibt ein Teil dieser Arbeit häufig im eigenen Betrieb oder beim Integrationspartner: Dokumente aufbereiten, Datenbankabfragen auslösen, Zwischenergebnisse halten und den nächsten Schritt starten. Ein größeres Kontingent beim Modellanbieter erweitert diese Dienste nicht automatisch.

Ein Werkzeugaufruf ist nicht gleich Prozessorarbeit

Im gedachten Servicefall werden Vertrag, Gerätehistorie und Wartungsunterlagen zusammengeführt. Dazu fragt die Anwendung mehrere Systeme ab und lässt Dokumente auslesen. Bei wenigen gleichzeitigen Anfragen funktioniert das unauffällig. Treffen morgens viele Fälle zusammen ein, kann sich vor dem Dokumentendienst eine Warteschlange bilden.

Daraus folgt noch nicht, dass zusätzliche Prozessoren nötig sind. Vielleicht rechnet die Dokumentverarbeitung tatsächlich an ihrer Kapazitätsgrenze. Vielleicht wartet sie auf einen entfernten Speicher. Oder ein angeschlossenes System lässt nur eine begrenzte Zahl gleichzeitiger Abfragen zu. Aus Sicht des Agenten sehen diese Situationen ähnlich aus: Das Werkzeug ist noch nicht fertig. Für die Investitionsentscheidung verlangen sie unterschiedliche Antworten.

Mehr Ausführungskapazität hilft im ersten Fall möglicherweise direkt. Im zweiten könnten Datenzugriff und Übertragung entscheidend sein. Im dritten kann weniger Parallelität sinnvoller sein als mehr Rechner. Auch unnötig wiederholte Abrufe lassen sich vermeiden, sofern Aktualität und Zugriffsrechte das erlauben. Die lange Laufzeit eines Werkzeugs ist deshalb zunächst eine Beobachtung, noch keine Hardwarebestellung.

Dieser Unterschied verändert die Zusammenarbeit mit einem Integrationspartner. Die Frage lautet nicht nur, wie schnell das gewählte Modell antwortet. Sie lautet auch, wie viele vollständige Servicefälle die Anwendung unter realistischer Last innerhalb der vereinbarten Zeit vorbereitet. Wer nur den Modellaufruf vorführt, zeigt einen Teil der angebotenen Leistung.

Ein stärkeres Modell kann weniger Nebenarbeit auslösen

Die Kapazitätsplanung wird durch bessere Modelle nicht einfach größer. Ein leistungsfähigeres Modell könnte einen geeigneten Abruf sofort wählen, statt mehrere Varianten auszuprobieren. Vielleicht braucht es weniger Rückfragen, Korrekturschleifen oder parallele Unteragenten. Dann nimmt mit der Zahl der Werkzeugaufrufe auch ein Teil der Ausführungslast ab.

Ebenso denkbar ist, dass das Unternehmen die bessere Leistung für umfangreichere Aufträge nutzt: mehr Dokumente je Fall, zusätzliche Prüfungen oder mehr bearbeitete Anfragen. Dann kann die Anwendung trotz effizienterer Einzelentscheidungen stärker ausgelastet sein. Welche Entwicklung eintritt, lässt sich weder aus der Agentenzahl noch aus dem Modellnamen ablesen.

Eine feste Umrechnung von zusätzlichen Agenten in zusätzliche CPU-Kerne wäre daher irreführend. Ein Agent kann lange auf einen fremden Dienst warten und dabei wenig eigene Rechenleistung beanspruchen. Viele kurze Aufgaben können dagegen eine gemeinsame Datenbank stark belasten. Die technische Trennung von Modell und Werkzeugbetrieb ist nützlich; eine allgemeine Prognose weltweiter CPU-Knappheit ergibt sich daraus nicht.

Zwei Vergleiche vor der nächsten Erweiterung

Ein brauchbarer Kapazitätstest beginnt mit einem Bestand repräsentativer Vorgänge und unveränderten Anforderungen an deren Ergebnis. Er zeigt sowohl die Bearbeitung einzelner Fälle als auch das Verhalten bei der erwarteten Spitzenlast. Erfasst werden die Zeit beim Modell, die Zeit für Werkzeuge und deren Warteschlangen sowie erneute Versuche nach Fehlern.

Diese Zeiten dürfen nicht einfach addiert werden, wenn Schritte gleichzeitig laufen. Für den Kunden zählt, wann der gesamte Vorgang fertig ist. Für die technische Entscheidung zählt zusätzlich, welcher Schritt diesen Abschluss bestimmt. So wird sichtbar, ob eine schnellere Modellantwort tatsächlich den Ablauf beschleunigt oder nur eine nachgelagerte Warteschlange früher erreicht.

Anschließend lassen sich zwei Veränderungen getrennt untersuchen. Beim Modellvergleich bleibt die ausführende Anwendung zunächst gleich. Ändern sich Qualität, Zahl der Werkzeugaufrufe und vollständige Bearbeitungszeit? Beim zweiten Vergleich bleibt das Modell gleich, während die Kapazität eines konkret ausgelasteten Dienstes verändert wird. Entsteht dadurch mehr nutzbare Leistung? Ein Test, der Modell, Rechnerzahl und Aufgaben zugleich austauscht, kann die beobachtete Verbesserung keinem dieser Hebel sauber zuordnen.

Damit wird auch die Budgetentscheidung präziser. Zusätzlicher Modellzugang finanziert andere Möglichkeiten als eine erweiterte Dokumentverarbeitung. Weniger doppelte Abfragen können wirtschaftlicher sein als beide Erweiterungen. Ein integrierter Dienstleister kann diese Entscheidungen übernehmen; seine Leistungszusage sollte dann aber den vollständigen Vorgang unter vereinbarter Last umfassen.

Der nächste Ausbau beginnt somit nicht zwingend beim stärkeren Modell oder beim größeren Server. Er beginnt bei der konkreten Leistung, die zusätzlich entstehen soll. Wenn sich zeigen lässt, wo die Zeit eines Auftrags bleibt, lässt sich auch entscheiden, welcher Ausbau sie tatsächlich verkürzt.