Der Serverless-Mythos, dass man „nur für die Millisekunden zahlt, in denen der Code läuft“, bricht zusammen, wenn man versucht, einen KI-Agenten auf AWS Lambda auszuführen. In der Praxis sind die größten Posten nicht die Lambda-Rechengebühren, sondern die Cold-Start-Latenz, Retry-Loops und der Token-Verbrauch, den diese Loops verursachen.

Warum das übliche Serverless-Bild bei KI-Agenten in die Irre führt

Die meisten Entwickler behandeln eine Lambda-Funktion wie eine reine Compute-Sandbox: Den Handler schnell halten, eine moderate Speichergröße festlegen und zusehen, wie die Rechnung stabil bleibt. Das funktioniert bei einfachen HTTP-Endpunkten, aber ein Agent, der ein Sprachmodell aufruft, die Antwort auswertet und möglicherweise den gesamten Zyklus wiederholt, lässt sich nicht eins zu eins auf einen einzigen Lambda-Aufruf abbilden. Der interne Workflow des Agenten vervielfacht die Anzahl der Modellaufrufe, und jeder zusätzliche Aufruf verursacht Token-Kosten, die die Rechengebühren bei weitem übersteigen können.

Cold Starts sind der versteckte Preiszuschlag

Wenn ein Lambda-Container zum ersten Mal bereitgestellt wird, muss er das Deployment-Paket entpacken. Der betreffende Agent lädt eine große Menge an Python-Bibliotheken, weshalb das Image recht groß sein kann. Das Entfernen von reinen Entwicklungs-Tools – wie etwa einer Browser-Automatisierungsbibliothek, die nur für lokale Tests verwendet wird – reduziert die Image-Größe, was wiederum die Entpackzeit verkürzt. Ein schlankeres Paket bedeutet, dass die Funktion schneller bereit ist, eine Anfrage zu bearbeiten, wodurch die Wartezeit bis zum Aufwärmen des Containers sinkt.

Ein zweiter Hebel ist der Ort, an dem der Initialisierungscode liegt. Wenn man den Graphen des Agenten zum Zeitpunkt des Modul-Imports konstruiert, findet die Schwerstarbeit nur einmal pro Container-Start statt und nicht bei jeder Anfrage. „Warme“ Aufrufe überspringen diese Arbeit dann vollständig. Der Kompromiss ist ein etwas längerer Cold Start, aber der Vorteil ist eine nahezu bei Null liegende Setup-Zeit pro Anfrage, sobald der Container warm ist.

Arbeitsspeicher dient gleichzeitig als Latenz-Regler

Bei Lambda bestimmt die zugewiesene Speichermenge auch den Anteil der CPU, den die Funktion erhält. Wenn man der Funktion 1 GB Speicher zuweist, erhält sie einen vollen virtuellen CPU-Kern. Die zusätzliche CPU beschleunigt den Import von Bibliotheken und die Erstellung des Agenten-Graphen, wodurch sowohl die Cold-Start- als auch die Warm-up-Latenz verringert werden.

Die Loop-Kosten: Retries vervielfachen den Token-Verbrauch

Der Agent folgt einem Worker-Evaluator-Loop. Der Worker generiert eine Antwort, der Evaluator prüft sie, und wenn der Evaluator einen Fehler meldet, wird die Aufgabe an den Worker zurückgesendet. Der Loop kann sich bis zu fünfmal wiederholen, bevor er abbricht. Das bedeutet, dass eine einzige externe Anfrage Folgendes auslösen kann:

  • bis zu fünf Aufrufe des Worker-Modells
  • bis zu fünf Aufrufe des Evaluator-Modells
  • beliebig viele Tool-Aufrufe, die der Agent tätigen möchte

Die Lambda-Rechnung bleibt vorhersehbar, da AWS pro Millisekunde der Ausführung abrechnet, aber die Token-Rechnung kann je nach Anzahl der benötigten Retries stark schwanken.

Die Timeout-Falle: API Gateway vs. Lambda

API Gateway erzwingt ein hartes Timeout von 29 Sekunden für die HTTP-Anfragen, die es bereitstellt. Ein Agent-Loop mit fünf Durchläufen kann dieses Limit leicht überschreiten, selbst wenn die zugrunde liegende Lambda-Funktion für ein fünfminütiges Ausführungsfenster konfiguriert ist. Das Umgehen von API Gateway durch Lambda Function URLs hebt die 29-Sekunden-Grenze auf und ermöglicht es der Funktion, ihren Loop abzuschließen, ohne unterbrochen zu werden.

Was Entwickler budgetieren sollten

Die Lehre ist einfach: Die Budgetierung für einen Serverless-KI-Agenten erfordert mehr als nur das Zusammenrechnen der Lambda-Laufzeit in Millisekunden. Sie müssen Folgendes berücksichtigen:

  • die Größe des Deployment-Pakets und die daraus resultierende Cold-Start-Latenz
  • die Speichereinstellung, die die CPU und somit die Importgeschwindigkeit bestimmt
  • die erwartete Anzahl der Retries im Worker-Evaluator-Loop, die den Token-Verbrauch direkt antreibt
  • die Wahl des Frontends (API Gateway vs. Function URL), um vorzeitige Timeouts zu vermeiden

Wenn man eine dieser Variablen ignoriert, kann man am Ende mit einer Rechnung dastehen, die nichts mit der ursprünglichen Prognose zu tun hat.