Wann lohnt sich serverless für KI-Agenten wirklich? Diese Frage beantwortet man nicht am Reißbrett, sondern mit Blick auf das tatsächliche Laufzeitverhalten eines Agenten. Ein Team, das seine Agenten von Beginn an auf Dauerbetrieb auslegt, bezahlt viel Rechenzeit, die ungenutzt verstreicht. Datadog hat dazu einen Beitrag veröffentlicht: Serverless Computing als erste Option prüfen, erst danach anhand von Produktionsdaten entscheiden, welche Teile eines AI-Agent-Workloads eigene, dauerhaft laufende Kapazität brauchen.
Die Mechanik erinnert an eine gemietete Werkstatt. Die Miete läuft weiter, auch wenn das Material noch nicht geliefert ist und niemand an der Werkbank arbeitet. Wer die Werkstatt dauerhaft anmietet, obwohl nur zeitweise Aufträge eintreffen, zahlt für Bereitschaft statt für Arbeit. Der Autor überträgt dieses Bild auf die Ausführungsschicht von Agenten: On-Demand-Kapazität entsteht erst, wenn eine Anfrage eintrifft, und fällt auf null zurück, wenn keine mehr kommt. Das ist keine Garantie, sondern eine Ausgangshypothese, die man messen sollte.
Warum KI-Agenten den Großteil ihrer Laufzeit untätig verbringen
Die wichtigste Zahl des Beitrags stammt aus einer Auswertung von mehr als 35.000 produktiven Coding-Agent-Sessions. Im Median war ein Agent nur 20 Prozent seiner Lebenszeit aktiv mit LLM- oder Tool-Aufrufen beschäftigt. Die übrigen 80 Prozent verbrachte er im Warten zwischen den Schritten, während seine Sandbox weiter reserviert blieb. In der Werkstatt steht der Monteur vier Fünftel seiner Zeit mit dem Werkzeug in der Hand und wartet auf das nächste Teil – bezahlt wird er durchgehend. Für AI-Agent-Workloads heißt das: Ein großer Teil der Rechnung hat nichts mit Rechnen zu tun, sondern mit Bereithalten.
Zugleich wächst der Druck, Kapazität bereitzustellen. Laut der CIO- und Technologie-Erhebung von Gartner für 2026 haben KI-Agenten die steilste Adoptionskurve aller untersuchten Technologien, doch das Tempo überholt die Reife der Plattformen. Im State of AI Infrastructure Report 2026 von Google Cloud gaben 83 Prozent von mehr als 1.400 leitenden IT-Verantwortlichen an, ihre Infrastruktur aufrüsten zu müssen, um produktionsreife agentische KI zu tragen. Der Autor warnt davor, ein Reifeproblem mit mehr persistenter Rechenkapazität zu beantworten – also mit einem neuen Cluster, einer erweiterten Plattform oder einer anderen Deployment-Topologie, bevor klar ist, ob der Workload das braucht.
Ein Workload Execution Profile erstellen
Wer die Frage nach dem Placement sauber beantworten will, kommt um ein Workload Execution Profile nicht herum. Das Profil hält fest, welche Eigenschaften und Laufzeitanforderungen ein Workload mitbringt, und beantwortet eine pragmatische Frage: Welche Ressourcen müssen verfügbar bleiben, wenn gerade kein Agentenschritt aktiv läuft? Braucht es nur einen dauerhaften Zustand und einen Auslöser für den nächsten Schritt, spricht vieles für einen serverless Workflow. Der Autor empfiehlt eine feste Liste von Eingaben: Auslöser und Ankunftsmuster, Antwortmuster – synchron, asynchron oder streamend –, Spitzenankunftsrate und Burst-Dauer, Spitzenparallelität, das Antwortzeit-Ziel, aktive Rechenzeit pro Lauf, gesamte verstrichene Zeit pro Lauf, Rechenauslastung über das erwartete Betriebsfenster, maximale Schrittdauer, Speicher- und CPU-Bedarf sowie Anforderungen an Beschleuniger, lokalen Speicher, persistente Verbindungen und private Netze.
Diese Werte muss man zusammen lesen, nicht als Tagesdurchschnitt. Ein Workload mit 1.000 Events pro Tag wirkt auf den ersten Blick winzig, denn im Mittel ist das weniger als ein Ereignis pro Minute – ein kleiner Dauerläufer scheint zu genügen. Der Durchschnitt verdeckt aber, dass alle 1.000 Events in einem nächtlichen Batch eintreffen. Kommt der Batch, bricht der Worker zusammen oder schafft die Verarbeitung nicht rechtzeitig. Erst Spitzenrate, Burst-Dauer und die Frage, wie lange die Nachfrage bei null liegt, zeigen, ob On-Demand-Compute trägt – vorausgesetzt, die Plattform schluckt den Burst und die nachgelagerten Systeme halten die entstehende Parallelität aus. Für neue Agenten baust du das erste Profil aus erwartetem Traffic, einem repräsentativen Prototyp oder Lasttests und aktualisierst es nach dem Deployment mit echten Messwerten.
Aktive Rechenzeit und Gesamtlaufzeit auseinanderhalten
Das Verhältnis von aktiver Rechenzeit pro Lauf zur gesamten verstrichenen Zeit ist das früheste Signal für die Placement-Entscheidung. Ein niedriger Wert stärkt die On-Demand-Variante, weil der Agent den Großteil seines Lebens ohnehin nichts rechnet. Ein hoher Wert deutet zusammen mit stetig eintreffender Nachfrage darauf hin, dass dedizierte Worker wirtschaftlicher arbeiten. Beide Größen erfasst man getrennt, nicht aus einem einzelnen Gesamtwert geschätzt.
Für die Messung brauchst du Telemetrie auf mehreren Ebenen. Traces aus Agent Observability und APM liefern die gesamte Laufzeit pro Durchlauf und die Dauer einzelner Schritte auf Ebene von Modell, Tool und Anwendung. Serverless Monitoring misst die Ausführungsdauer der einzelnen serverless Komponenten – also den Anteil, der als aktive Rechenzeit zählt –, dazu Aufrufvolumen, Parallelität, CPU und Speicher. Bei AWS Lambda ergänzen erweiterte Metriken CPU-Auslastung und CPU-Zeit. Ohne diese Trennung bleibt die Diskussion über Serverless vs. dedizierte Kapazität ein Bauchgefühl.
Längere Agentenläufe als durable serverless Workflows aufsetzen
Ein Agentenlauf, der innerhalb eines einzigen Aufrufs abgeschlossen ist, braucht keine dauerhafte Orchestrierung. Hier vermeidet eine Funktion oder ein serverless Container unnötige Kosten und Komplexität. Erst wenn Läufe über mehrere Schritte gehen oder pausieren und wieder aufsetzen müssen, ist ein durabler serverless Workflow die bessere Wahl. Er kombiniert Bausteine mit unterschiedlichen Rollen: ein Orchestrator, der Fortschritt festhält und entscheidet, wann eine Einheit laufen darf; serverless Ausführungsprimitiven wie Funktionen, Container oder verwaltete Jobs, die die eigentliche Arbeit tun; und externe Speicher, die Artefakte und Anwendungsdaten über den Ausführungsprozess hinaus behalten.
Der Autor rät, den Lauf in begrenzte Arbeitseinheiten zu schneiden, jede mit definierten Eingaben, Ausgaben und Abbruch- oder Fehlerbedingungen. Nach jeder abgeschlossenen Einheit oder Pause kann der Orchestrator den Fortschritt notieren, und der Workflow setzt später vom gespeicherten Punkt auf, statt von vorn zu beginnen. Scheitert ein Schritt, lässt er sich wiederholen, ohne die bereits erledigten Schritte erneut auszuführen. Dabei muss jeder Schritt so gebaut sein, dass ein Retry keine externen Nebenwirkungen doppelt auslöst – keine zweite Mail, keine doppelte Abbuchung.
Für die Frage, wo pausiert werden darf, gehst du den Lauf vom Auslöser bis zum Abschluss durch und ordnest jede Wartezeit ein: Antwort eines Tools, Zurückhaltung wegen Rate Limits, Freigabe durch einen Menschen. Rechenzeit lässt sich freigeben, wenn der Zustand gespeichert und der nächste Schritt über Timer, Event oder Callback wieder anspringbar ist. Ein Schritt, der einen Prozess am Leben halten muss – etwa zum Streamen einer Antwort oder für eine persistente Verbindung –, kann nicht pausieren und braucht womöglich warme Kapazität. Agenten-Frameworks wie LangChain oder das Vercel AI SDK beschleunigen den Aufbau, ihre Verbreitung hat sich laut dem State of AI Engineering Report von 2025 auf 2026 nahezu verdoppelt. Der Autor trennt die Zuständigkeiten trotzdem: Der externe Orchestrator verwaltet Workflow-Zustand, Zeitplanung und Wiederaufnahme; das Framework übernimmt Modell- und Tool-Interaktion innerhalb der begrenzten Schritte. So kann der Framework-Prozess enden, ohne den Fortschritt zu verlieren.
Serverless mit warmer und dedizierter Kapazität vergleichen
Das Execution Profile erlaubt es, alle Placement-Optionen gegen dieselbe Nachfrage zu rechnen. On-Demand-Kosten steigen mit aktiver Rechenzeit und Workflow-Aktivität, warme und dedizierte Kapazität kosten dagegen auch dann, wenn die provisionierte Rechenleistung leersteht. In die Rechnung gehören Ausführungsdauer, Orchestrierungs-Übergänge, Zustandsspeicher, Netzwerktransfer und Telemetrie. Modell- und Tool-Kosten kannst du weglassen, solange sie über alle Varianten gleich bleiben – nicht aber, wenn Retries oder wiederholte Arbeit in einer Variante mehr Aufrufe erzeugen.
Vergleiche nicht den Preis pro Aufruf, sondern die AI-Agent-Infrastruktur-Kosten pro erfolgreichem Lauf. Dazu addierst du alle Kosten, die im selben Betriebsfenster durch Versuche entstehen – erfolgreiche, fehlgeschlagene und abgebrochene –, und teilst durch die Zahl der Läufe, die die Abschlussbedingung erreicht haben. Ein Beispiel aus dem Beitrag: Ein Recherche-Agent startet 100 Läufe an einem Tag, 80 liefern einen fertigen Bericht, 15 scheitern nach angefallenen Rechen- und Orchestrierungskosten, 5 werden beim Warten auf Freigabe abgebrochen. Zusammen kosten die 100 Läufe 12 Dollar. Geteilt durch die 80 erfolgreichen Läufe sind das 0,15 Dollar pro Erfolg; geteilt durch alle 100 wären es 0,12 Dollar – doch dann verschwände der Preis für aussichtslose Arbeit aus der Betrachtung. Wenn das Antwortzeit-Ziel nur mit dauerhaft bereitstehenden Instanzen zu halten ist, gehört auch die Mindestkapazität in die Kalkulation. Die Plattform skaliert dann oberhalb dieser Grundlast weiter, kann aber im Leerlauf nicht auf null herunterfahren.
Was das für die eigene KI-Agenten-Infrastruktur bedeutet
Die Botschaft ist keine Ideologie, sondern eine Reihenfolge. Serverless ist der Standard, mit dem du startest, weil er ohne Clusterverwaltung zusätzliche Agentenlast aufnimmt und im Leerlauf nichts kostet. Danach entscheidet die Messung, welche Schritte tatsächlich andere Kapazität brauchen. In der Praxis entstehen dadurch gemischte Setups: ein Chat-Dienst auf warmer Kapazität, der die erste Antwort streamt, während der Rest des Laufs als durabler serverless Workflow läuft, bei einer Tool-Rückmeldung ohne Rechenkosten pausiert, eine Freigabe abwartet und dann die Nachricht nachliefert. Der Orchestrator setzt nach jedem Schritt einen Checkpoint, die Schritte lesen und schreiben in externe Speicher.
Für dich heißt das: Formuliere das Execution Profile, bevor du Kapazität bestellst, und überarbeite es, sobald Produktionsdaten vorliegen. Verschiebe einzelne Schritte nur dann auf dedizierte Worker, wenn Latenz oder Laufzeitanforderungen es belegen, und prüfe die Entscheidung erneut, wenn sich Ankunftsmuster, Parallelität oder Antwortzeit-Ziele ändern. So bleiben KI-Agenten-Workloads skalierbar, ohne dass du dich früh auf eine Topologie festlegst, deren Kosten du noch nicht kennst.
Quelle: datadoghq.com
