Wie viel kostet es, mehrere AI Agents gleichzeitig zu betreiben? Token-Kosten, parallele Aufgaben und Serverbudget

Zeitplan: erst messen, dann parallelisieren

Die Kosten mehrerer gleichzeitig laufender AI Agents lassen sich nicht zuverlässig berechnen, indem Sie den Preis einer Unterhaltung mit der Zahl der Agents multiplizieren. Protokollieren Sie stattdessen jeden Aufgabenpfad samt Modellaufrufen, Werkzeugen, Wiederholungen und Laufzeit; begrenzen Sie anschließend Token-Budget und Parallelität getrennt. Diese Woche sollten Sie zunächst eine repräsentative Aufgaben-ID durch Ihre Protokollierung führen und einen kontrollierten Belastungstest planen. Das gilt besonders, wenn mehrere Agents denselben Kontext weiterreichen oder Werkzeuge eigenständig aufrufen.

Für Sie ist dieser Leitfaden gedacht, wenn Sie Backend-Workflows mit mehreren Agents entwickeln und deren Kosten je Aufgabe erfassen möchten.
Als technische Gründerin oder technischer Gründer erhalten Sie eine Grundlage, um Ausgaben und Produktmarge nicht nur aus einer API-Rechnung abzuleiten.
Als SRE oder Plattformverantwortliche können Sie Modellkosten von Laufzeit-, Speicher- und Netzwerkkosten trennen.

Vor dem Start: Aufgabenketten statt Agent-Anzahl erfassen

„Drei Agents“ ist keine Kostenformel. Ein Agent kann einen kurzen Modellaufruf ausführen; ein anderer kann erst planen, dann Werkzeuge aufrufen, Zwischenergebnisse bewerten und die Antwort erneut formulieren. Außerdem können mehrere Agents denselben Verlauf übernehmen. Dadurch wächst das Eingabetokenvolumen, obwohl sich die sichtbare Nutzeranfrage nicht verändert.

Legen Sie vor dem ersten Test fest, was bei Ihnen als Aufgabe zählt. Eine sinnvolle Aufgaben-ID bleibt vom Eingang einer Anfrage bis zum endgültigen Ergebnis erhalten. Jeder protokollierte Schritt sollte dieser ID zugeordnet sein. Erfassen Sie mindestens:

• Aufgaben-ID und Aufgabenart;
• Rolle des aufrufenden Agents, etwa Haupt-Agent oder Unter-Agent;
• Modellname und Modellversion, sofern die Schnittstelle diese ausweist;
• Eingabe- und Ausgabetoken je Aufruf;
• Werkzeugname, Aufrufgrund und Ergebnisstatus;
• Wiederholungen, Zeitüberschreitungen und Abbruchgrund;
• Beginn, Ende und Wartezeit in der Warteschlange.

Trennen Sie direkte Aufrufe von weitergereichtem Kontext. Wenn ein Unter-Agent den vollständigen bisherigen Verlauf erhält, können dieselben Informationen bei späteren Aufrufen erneut als Eingabe anfallen. Ein kurzer Verweis auf ein strukturiertes Zwischenergebnis kann anders zu Buche schlagen als die erneute Übergabe des gesamten Gesprächs. Welcher Ansatz günstiger ist, hängt vom Modell, der Aufgabe und Ihrer Implementierung ab. Prüfen Sie dafür die jeweils geltende Dokumentation zur Modellabrechnung und Informationen zur Abrechnung von API-Nutzung, bevor Sie Kosten aus Tokenmengen ableiten.

Auch Werkzeugaufrufe benötigen eine eigene Spur. Ein Agent kann beispielsweise erst eine Suche auslösen, deren Ergebnis in den nächsten Modellaufruf eingeht. Eine Schleife aus Werkzeug, Antwortprüfung und erneutem Werkzeugaufruf ist dann nicht ein einzelner Vorgang, sondern eine Kette mit mehreren Kostenstellen. Notieren Sie den Auslöser eines Aufrufs sowie, ob er ein verwertbares Ergebnis geliefert hat. So sehen Sie später, ob ein kostenpflichtiger Werkzeugpfad funktional nötig war oder durch unklare Anweisungen entstand.

Erster Belastungstest: API-Abrechnung und Laufzeit getrennt messen

Testen Sie nicht nur mit einer einzelnen Anfrage. Wählen Sie typische Aufgaben aus Ihrem Produkt und lassen Sie sie zunächst kontrolliert einzeln, dann mit wachsender Parallelität laufen. Vergleichen Sie dabei nicht nur die Gesamtdauer. Messen Sie auf der Serverseite CPU-Auslastung, Arbeitsspeicher, Netzwerkverkehr, Warteschlangenzeit und Laufzeit der Worker. Legen Sie für jeden Messwert dieselbe Aufgaben-ID zugrunde wie für die Modellaufrufe.

Diese Trennung zeigt, wo das Problem liegt. Steigen API-Kosten, während Serverressourcen stabil bleiben, liegt die Ursache eher bei langen Eingaben, häufigen Modellrunden oder aufwendigen Werkzeugpfaden. Wachsen dagegen Warteschlange, Arbeitsspeicher oder Laufzeit, obwohl die Tokenmengen ähnlich bleiben, sollten Sie Ausführung, Worker und Parallelitätsgrenzen untersuchen. Eine Gesamtsumme aus API-Rechnung und Serverrechnung verrät diese Unterschiede nicht.

Einheitliche Messbegriffe erleichtern den Vergleich zwischen Anwendung und Infrastruktur. Wenn Sie Metriken, Protokolle und verteilte Ablaufspuren zusammenführen, können Sie dem Überblick zu Observability-Signalen entnehmen, welche Signalarten unterschiedliche Aspekte eines Ablaufs abbilden. Das ist keine Garantie für vollständige Kostendaten: Entscheidend ist, dass Ihre Anwendung Modellaufrufe und Werkzeuge selbst mit einer gemeinsamen Aufgaben-ID versieht.

Für die Kostenberechnung verwenden Sie die Tokenmengen aus den Protokollen und die aktuellen Abrechnungsregeln des tatsächlich verwendeten Modells. Ein- und Ausgabe können unterschiedlich berechnet werden; auch Werkzeugnutzung oder besondere Funktionen können eigene Bedingungen haben. Vergleichen Sie diese Regeln mit den offiziellen Preis- und Abrechnungsangaben für API-Modelle sowie den Preisangaben für multimodale Modell- und Werkzeugnutzung, soweit diese für Ihre Integration relevant sind. Übernehmen Sie keine feste Beispielsumme aus einer älteren Kalkulation, ohne die aktuelle Dokumentation zu prüfen.

Wichtig: Die Kosten eines Belastungstests sind ein Ergebnis Ihres konkreten Aufgabensatzes, nicht automatisch ein Branchenmittelwert. Halten Sie Aufgaben, Modellversion, Eingaben und Messbedingungen fest, damit spätere Vergleiche aussagekräftig bleiben.

Vor dem Produktivstart: niedrige, mittlere und hohe Last kalkulieren

Erstellen Sie Ihre Szenarien aus protokollierten Aufgaben und nicht aus einer angenommenen Zahl täglicher Nutzer. Wählen Sie dafür repräsentative Abläufe: eine leichte Aufgabe mit wenigen Schritten, eine typische Aufgabe aus dem Produktbetrieb und einen anspruchsvollen Ablauf mit mehreren Unter-Agenten oder Werkzeugen. Verwenden Sie keine erfundenen Tokenmengen. Wo Ihnen noch Messungen fehlen, kennzeichnen Sie den Wert ausdrücklich als Annahme und notieren Sie, wie eine Abweichung die Schätzung verändert.

Rechnen Sie die Modellkosten je Szenario als Summe der protokollierten Ein- und Ausgabemengen multipliziert mit den dafür aktuell geltenden Preisen. Halten Sie Werkzeugkosten getrennt, sofern sie nicht bereits in der Abrechnung des Anbieters enthalten sind. Kalkulieren Sie Serverkosten anhand Ihrer tatsächlichen Laufzeitumgebung: Ein dauerhaft bereitgestellter Worker kann auch außerhalb seiner aktiven Modellaufrufe Ressourcen binden. Speicher, Netzwerk und Hintergrundverarbeitung sind eigene Positionen, sofern sie bei Ihrer Infrastruktur Kosten verursachen.

Dokumentieren Sie Unsicherheiten als Variablen, nicht als scheinbar präzise Schätzung. Zum Beispiel: „Wenn der Anteil wiederholter Modellaufrufe steigt, erhöht sich die gemessene Tokenmenge je erfolgreicher Aufgabe.“ Diese Aussage lässt sich mit Betriebsdaten prüfen. Eine nicht belegte Aussage wie „Werkzeuge erhöhen die Kosten um einen festen Prozentsatz“ sollten Sie vermeiden. Kosten und Leistung hängen unter anderem von Aufgabenmix, Kontextlänge, Modellwahl und Fehlerbehandlung ab.

FAQ: Token, Werkzeuge und Grenzen

Wie berechnen Sie Token-Kosten bei parallel laufenden Agents?

Addieren Sie Eingabe- und Ausgabetoken für jeden Modellaufruf und ordnen Sie den Wert dem Modell sowie der Aufgaben-ID zu. Parallele Ausführung ändert nicht automatisch den Tokenpreis, kann aber mehr Aufgaben gleichzeitig durch das System führen. Der tatsächliche Verbrauch entsteht durch deren Aufrufketten, geteilten Kontext und Wiederholungen. Nutzen Sie für die Multiplikation die aktuell gültigen Anbieterangaben, nicht eine frühere Schätzung.

Wie wirken sich Werkzeugaufrufe und Wiederholungen auf die Kosten aus?

Ein Werkzeug kann direkte Gebühren auslösen oder zusätzliche Modellaufrufe erforderlich machen, etwa wenn ein Agent sein Ergebnis auswertet und eine weitere Aktion startet. Wiederholungen verursachen weitere Kosten, wenn dabei erneut ein Modell oder ein kostenpflichtiges Werkzeug verwendet wird. Erfassen Sie deshalb Aufrufgrund, Ergebnis und Folgeaktionen. Erst die Protokolle zeigen, welche Wiederholungen zur Fehlerbehandlung nötig sind und welche auf eine Schleife oder schlechte Eingaben zurückgehen.

Wie setzen Sie Parallelitätsgrenzen und Budgetwarnungen?

Legen Sie pro Aufgabenklasse eine begrenzte Warteschlange fest und definieren Sie, wie viele Aufträge gleichzeitig ausgeführt werden dürfen. Ergänzen Sie ein Ausgabenlimit pro Aufgabe, eine Obergrenze für Wiederholungen und Warnungen an den von Ihnen gewählten Budgetpunkten. Eine Überschreitung sollte nicht nur eine Meldung erzeugen: Entscheiden Sie, ob neue Aufgaben pausieren, in eine Warteschlange verschoben oder mit einer günstigeren Ausführung fortgesetzt werden dürfen.

Sollten Server- und Modell-API-Kosten getrennt bleiben?

Ja. Ermitteln Sie Modell- und Werkzeugabrechnung einerseits sowie Laufzeit, Arbeitsspeicher, Netzwerk, Speicherung und Hintergrundjobs andererseits als getrennte Positionen. Verknüpfen Sie beide Kostenarten über dieselbe Aufgaben-ID, damit Sie pro erfolgreicher Aufgabe vergleichen können. Bleiben die Serverkosten gleich, während die Modellabrechnung wächst, ist eine Skalierung der Worker wahrscheinlich nicht die erste Maßnahme. Umgekehrt können Warteschlange und Laufzeit auf ein Infrastrukturproblem hinweisen.

In der ersten Betriebswoche: Schätzungen mit echten Aufrufen abgleichen

Vergleichen Sie die geplante Kostenverteilung mit den tatsächlichen Protokollen, sobald der Ablauf produktiv genutzt wird. Suchen Sie zuerst nicht nach einer allgemeinen Durchschnittszahl, sondern nach Aufgaben, deren Verbrauch deutlich von der Schätzung abweicht. Öffnen Sie deren Ablaufspur und prüfen Sie, ob der Grund ein langer Kontext, unnötige Wiederholung, fehlgeschlagene Werkzeugausführung oder eine ungeplante zusätzliche Modellrunde ist.

Ordnen Sie jede Abweichung einer Ursache zu. Wenn die Eingabetoken pro Aufgabe steigen, prüfen Sie, ob der vollständige Verlauf wiederholt übertragen wird. Steigt die Zahl der Werkzeugaufrufe, sehen Sie nach, ob ein Werkzeug wiederholt dasselbe Ergebnis liefert oder ob seine Ausgabe zu umfangreich ist. Steigt die Laufzeit, prüfen Sie, ob Worker auf externe Antworten warten und währenddessen Ressourcen belegen. Verändern Sie nicht gleichzeitig mehrere Teile des Ablaufs, wenn Sie die Ursache der Kostenabweichung herausfinden möchten.

Führen Sie eine nachvollziehbare Kostenübersicht, die mindestens geplante und gemessene Aufrufe, Tokenmengen, Werkzeugnutzung, Ausführungszeit und Ergebnisstatus enthält. Vermerken Sie zusätzlich die verwendete Preisgrundlage mit dem Datum Ihrer Prüfung. So kann das Team einen späteren Preiswechsel von einer Veränderung des Aufgabenmixes unterscheiden. Eine nachträglich erstellte Durchschnittszahl ohne zugrunde liegende Aufgabenprotokolle reicht für diese Diagnose nicht.

Im Dauerbetrieb: Grenzwerte und Skalierung an Messungen binden

Wählen Sie Parallelitätsgrenzen nicht nach dem maximal möglichen Durchsatz einer einzelnen Komponente. Entscheidend ist, ob das Gesamtsystem unter gleichzeitiger Ausführung seine zugesagten Antwortzeiten einhält, ohne dass Warteschlange, Arbeitsspeicher oder Fehlerquote problematisch werden. Begrenzen Sie konkurrierende Aufgaben je Klasse: Ein kurzer, klar begrenzter Ablauf muss nicht dieselbe Warteschlangenbehandlung erhalten wie eine umfangreiche Aufgabe mit mehreren Werkzeugen.

Ergänzen Sie die Begrenzung um klare Regeln für Wiederholungen. Legen Sie fest, welche Fehler einen erneuten Versuch rechtfertigen, wann ein Versuch abgebrochen wird und wie lange eine Aufgabe auf ein Werkzeug warten darf. Verhindern Sie, dass ein Agent dieselbe Aktion ohne neue Information immer wieder ausführt. Ein Wiederholungsmechanismus ohne Gesamtgrenze kann sowohl die API-Ausgaben als auch belegte Laufzeitressourcen unbemerkt erhöhen.

Skalierung ist sinnvoll, wenn Messwerte zeigen, dass die vorhandene Ausführungskapazität den Auftragseingang nicht mehr zuverlässig verarbeitet: Die Warteschlange bleibt anhaltend bestehen, die Antwortzeit überschreitet Ihr vereinbartes Ziel oder Ressourcen werden dauerhaft knapp. Prüfen Sie dann zunächst, ob das Problem durch unnötige Modellrunden oder Werkzeugschleifen entsteht. Wenn es tatsächlich an zu wenigen Ausführungsinstanzen liegt, können Sie die Kriterien für horizontale Skalierung anhand der Dokumentation zur automatischen Anpassung von Arbeitslasten beurteilen. Das Dokument ersetzt keine Messung Ihrer Anwendung und begründet keinen festen Schwellenwert für Ihren Betrieb.

Für eine belastbare Kostenobergrenze sollten Warnung und Reaktion zusammengehören. Eine Warnung ohne zuständige Person oder Handlung ist kein wirksamer Schutz. Bestimmen Sie, wer bei auffälligen Ausgaben die Protokolle prüft, ob neue Aufgaben vorübergehend gedrosselt werden und wie bereits laufende Aufgaben behandelt werden. Berücksichtigen Sie bei der Datenhaltung außerdem, welche Eingaben und Ablaufprotokolle Sie für die Abrechnung wirklich benötigen. Begrenzen Sie sensible Inhalte, Zugriffsrechte und Aufbewahrung nach Ihren Datenschutzvorgaben und der DSGVO.

Nach der Messung: Modell, Ablauf oder Umgebung ändern

Wählen Sie die Optimierung nach dem Kostenanteil, den Ihre Protokolle tatsächlich zeigen. Bei hohen Eingabemengen prüfen Sie zuerst Kontextauswahl, Zusammenfassungen und wiederverwendbare Ergebnisse. Bei vielen erfolglosen Modellrunden überarbeiten Sie Aufgabengrenzen und Abbruchbedingungen. Häufen sich kostenpflichtige Werkzeugaufrufe, legen Sie fest, wann ein Werkzeug notwendig ist und wie sein Ergebnis geprüft wird. Bei knappen Serverressourcen untersuchen Sie Worker-Laufzeit, Warteschlangen und Speicherbedarf, bevor Sie Kapazität ergänzen.

Ein Modellwechsel ist kein reiner Kostenvergleich. Prüfen Sie auch, ob sich Ergebnisqualität, Fehlerquote, Latenz und notwendige Nacharbeit verändern. Ein günstigerer Aufruf kann unterm Strich ungünstig sein, wenn er mehr Wiederholungen oder menschliche Korrekturen nach sich zieht. Vergleichen Sie deshalb Ausgangs- und Zielversion auf demselben Aufgabensatz, mit denselben Erfolgskriterien und derselben Art der Kostenmessung. Ändern Sie nur eine wesentliche Einflussgröße pro Vergleich, damit der Effekt zuordenbar bleibt.

Für Teams, die einen Arbeitsablauf erst bereitstellen, kann die Hashvps-Anleitung zu OpenClaw als ergänzende Lektüre für die Einrichtung dienen. Prüfen Sie dabei unabhängig, welche Ausführungsumgebung Ihr Agent benötigt; eine Anleitung ersetzt weder die eigene Lastmessung noch den Kostenabgleich.

Entscheidungspfad für die nächste Maßnahme

• Wenn die Tokenmenge je erfolgreicher Aufgabe wächst, obwohl Serverwerte stabil bleiben, optimieren Sie zuerst Kontextübergabe, Modellrunden und Wiederholungslogik. Skalieren Sie nicht vorschnell die Ausführungsumgebung.
• Wenn die Tokenmenge stabil bleibt, aber Warteschlange und Laufzeit anhaltend über Ihren Zielwerten liegen, untersuchen Sie Worker-Auslastung und Aufgabenparallelität. Erhöhen Sie Kapazität erst, wenn die Messung einen Engpass der Umgebung bestätigt.
• Wenn Werkzeugaufrufe oder Wiederholungen die Abweichung erklären, begrenzen Sie die betreffenden Pfade und testen Sie die Fehlerbehandlung erneut. Eine pauschale Erhöhung des Budgets würde die Ursache lediglich verdecken.
• Wenn Messwerte fehlen oder Aufgaben nicht über mehrere Dienste hinweg zugeordnet werden können, erweitern Sie zuerst Protokollierung und Ablaufspuren. Ohne gemeinsame Aufgaben-ID ist weder eine verlässliche Kostenverteilung noch ein fairer Optimierungsvergleich möglich.

Die Kosten mehrerer gleichzeitig laufender AI Agents werden steuerbar, wenn Modellabrechnung, Werkzeuge und Serverressourcen nicht in einer undurchsichtigen Gesamtsumme verschwinden. Halten Sie die Messung aktuell, und passen Sie Budgets an Ihre eigenen Aufgaben statt an vermutete Branchenwerte an. Eine vorhandene Linux- oder Cloud-Umgebung kann für dauerhaft laufende, allgemeine Backend-Arbeit die passende Wahl sein; eine Mac-Umgebung ist kein automatischer Ersatz und lohnt sich besonders dann, wenn Ihr Ablauf macOS-spezifische Entwicklung, Tests oder Apple-Werkzeuge voraussetzt. Für einen zeitlich begrenzten Kompatibilitätstest kann das Mieten eines Mac von Hashvps eine Alternative zum Kauf sein. Prüfen Sie die verfügbaren Optionen auf der Hashvps-Seite mit Paketdetails und vergleichen Sie sie mit Ihrem tatsächlichen Bedarf, bevor Sie die Umgebung wechseln.