Warum die Kosten für agierende KI in die Höhe schießen: Ein kostengestütztes Modell, das auf der Architektur basiert

Wenn Menschen über die Kontrolle der Ausgaben für LLMs sprechen, beginnt und endet die Diskussion in der Regel mit den Preisen für Tokens.

„Wie hoch ist die Gebühr pro Million Token für dieses Modell?“

Das ist eine berechtigte Frage, doch bei produktionstauglichen agierenden KI-Systemen wird dadurch die eigentliche Herausforderung übersehen.

Eine einzelne Anfrage eines Benutzers führt nicht zu einem einzigen Aufruf eines Sprachmodells.

Ein agierender Workflow verläuft in der Regel wie folgt:

User Request
     ↓
Router
     ↓
Planner
     ↓
Retrieval
     ↓
Tool Call
     ↓
Tool Result Interpretation
     ↓
Validator
     ↓
Final Response

Eine eingehende Anfrage kann fünf, sechs, zehn oder sogar mehr Aufrufe an Modelle und Tools auslösen, bevor sie abgeschlossen ist.

Deshalb liegt die Zahl, die man verfolgen sollte, nicht einfach darin:

Kosten pro Modellaufruf

Sondern darin:

Kosten pro abgeschlossener Aufgabe.

Was tatsächlich die Kosten eines Agents bestimmt

Die Gesamtkosten für den Betrieb eines agierenden Workflows gehen weit über die reine Tokenverbrauch hinaus:

Agent Cost
=
LLM inference
+ Embeddings
+ Reranking
+ Vector/Search infrastructure
+ Tool/API calls
+ Compute
+ Storage
+ Observability
+ Evaluations

Auch innerhalb des „LLM-Inferenz“-Bereichs haben Sie es mit Eingabetoken, Ausgabetoken, gecachten Token sowie möglicherweise mehreren verschiedenen Modellen zu tun, die in unterschiedlichen Phasen des Pipelines genutzt werden.

Diese Realität verändert die Art und Weise, wie Architekturentscheidungen getroffen werden sollten.

1. Senden Sie jede Anfrage an das für die Aufgabe geeignete Modell

Nicht jede Aufgabe rechtfertigt den Einsatz des leistungsstärksten Modells, auf das Sie Zugriff haben.

Request
   ↓
Router
   ├── Simple extraction → Small model
   ├── Moderate reasoning → Mid-tier model
   └── Complex reasoning → Strong model

Ein weiteres nützliches Muster ist die Eskalation.

Beginnen Sie mit einem leichten, günstigen Modell und wechseln Sie erst zu einem stärkeren Modell, wenn das Vertrauen in die Ergebnisse gering ist, die Validierung fehlschlägt oder die Aufgabe komplexer ist als erwartet.

Ziel ist es nicht, stets die günstigste Option zu wählen.

Ziel ist es, zur kostengünstigsten Architektur zu gelangen, die dennoch Ihre Anforderungen an Qualität und Zuverlässigkeit erfüllt.

2. Hören Sie auf, Modelle für deterministische Logik einzusetzen

Dieser Punkt scheint offensichtlich zu sein, ist aber bei großem Umfang von entscheidender Bedeutung.

Sobald reiner Code eine Frage zuverlässig beantworten kann, soll er das auch tun.

Aufgaben wie Berechtigungsprüfungen, Arithmetik, Schema-Validierung, Filtern, deterministische Routingentscheidungen sowie die meisten Geschäftsregeln benötigen in der Regel keinen Einsatz von LLMs.

Eine nützliche Faustregel:

Delegieren Sie niemals an ein LLM etwas, was deterministische Software bereits besser bewältigen kann.

Bewahren Sie probabilistisches Denken für die Schritte im Workflow auf, bei denen es tatsächlich seinen Wert zeigt.

3. Betrachten Sie den Kontext als Ausgabenbudget

Langlebige Agenten sammeln im Laufe ihrer Ausführung kontinuierlich Kontext an.

Wenn man dies unkontrolliert lässt, kann jeder zusätzliche Schritt die gesamte Konversationshistorie, frühere Tool-Ausgaben, heruntergeladene Dokumente sowie frühere Schlussfolgerungsverläufe erneut in das Modell einspeisen.

Anstatt den Kontext unbegrenzt wachsen zu lassen, sollte man einen Wert beibehalten, der eher dem folgt:

Recent Context
      +
Compact Summary
      +
Relevant Memory
      +
Task-Specific Retrieved Context

Praktiken wie Zusammenfassung, Ablaufzeitbegrenzung, schrumpfende Kontextfenster sowie memorielle Abfragen auf Basis der Relevanz dienen nicht nur dazu, die Größe des Kontexts zu verwalten.

Sie fungieren auch als Kostenkontrollmechanismen.

4. Ihre RAG Top-K-Einstellung ist ein Hebel für die Kostenkontrolle

Nehmen wir an, Sie holen 20 Blöcke ab, von denen jeder etwa 700 Token umfasst.

Das ergibt insgesamt rund 14.000 Token an heruntergeladenem Material.

Doch vielleicht sind nur vier dieser Blöcke tatsächlich für die Antwort relevant.

Ein besser konzipierter Abfrageschritt sieht eher so aus:

Query
  ↓
Retrieve broader candidate set
  ↓
Rerank
  ↓
Select best 4–6 chunks
  ↓
LLM

Das Einbeziehen eines großen Pools an Kandidaten bedeutet nicht, dass jeder Kandidat in das Kontextfenster des Modells aufgenommen werden muss.

Daher sind die Qualität der Informationsabrufung und die Rechenkosten miteinander verbundene architektonische Entscheidungen, keine getrennten Aspekte.

5. Caching auf mehreren Ebenen

Caching ist keine einzige Technik – es gibt verschiedene Arten, die miteinander kombiniert werden können.

Zum Beispiel:

Exact Cache
Semantic Cache
Prompt/Context Cache
Tool Result Cache
Retrieval Cache

Falls viele Benutzer semantisch identische Fragen stellen, ist es oft verschwenderisch, jedes Mal den gesamten Agentenprozess von Grund auf neu auszuführen.

Ebenso müssen umfangreiche statische Systemanweisungen, Tool-Definitionen und Richtlinientexte nicht bei jedem Aufruf neu verarbeitet werden, sofern Ihre Plattform oder der Modellanbieter ein geeignetes Caching-Verfahren unterstützt.

6. Festlegung strenger Grenzen für autonome Agenten

Agenten bringen ihr eigenes Risiko mit: abgehende Schleifen.

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
...

Ein einziger Orchestrierungsfehler kann gleichzeitig zu einem Zuverlässigkeitsversagen und zu erheblichen Kostensteigerungen führen.

Deshalb benötigen Produktionsagenten explizite Schutzmechanismen, die Aspekte wie folgende abdecken:

Maximum agent steps
Maximum tool calls
Maximum tokens
Maximum wall-clock time
Maximum cost per run

Sobald eines dieser Budgets aufgebraucht ist, sollte der Workflow stoppen, auf einen alternativen Weg umsteigen, sein Verhalten sanft abschwächen oder an einen Menschen weitergeleitet werden – je nach den Anforderungen der Situation.

7. Kosten in Ihren Observability-Stack integrieren

Jeder in der Produktion erzeugte Trace sollte es ermöglichen, Fragen wie folgende zu beantworten:

Which application?
Which workflow?
Which agent?
Which model/provider?
How many input tokens?
How many output tokens?
How many tool calls?
How long did it take?
How much did it cost?
Did the task actually succeed?

Daraufhin können Dashboards Metriken wie folgende anzeigen:

Cost / request
Cost / successful task
Cost / workflow
Cost / model
Cost / application
Cost / team
Cost / customer

Zu diesem Zeitpunkt ähnelt die Optimierung der KI-Ausgaben weitaus mehr Platform Engineering und FinOps als der Anpassung von Prompts.

Kosten und Qualität müssen zusammen abgestimmt werden

Der günstigste Arbeitsablauf ist nicht automatisch der beste.

Falls ein billiges Modell häufig versagt und Wiederholungsversuche, Alternativwege oder manuelle Eingriffe erfordert, kann seine tatsächliche Kostenbelastung höher ausfallen als die eines leistungsstärkeren Modells, das die Aufgabe bereits beim ersten Versuch korrekt erledigt.

Daher sieht die Metrik, die optimiert werden sollte, eher so aus:

Successful Tasks
Value = --------------------
        Cost + Latency + Risk

Das ist keine buchstäbliche universelle Gleichung – es handelt sich um eine ingenieurtechnische Denkweise.

Für produktive agierende KI ist der notwendige Denkwechsel folgender:

Hören Sie auf, Token isoliert zu optimieren. Beginnen Sie stattdessen mit der Optimierung der wirtschaftlichen Aspekte einer erfolgreichen Aufgabenerledigung.

Denn sobald Agenten in der Lage sind, zu reasoningen, Informationen abzurufen, Tools aufzurufen, Wiederholungsversuche zu starten, zu validieren und Schleifen einzubauen:

1 Benutzeranfrage entspricht nicht mehr 1 Modellaufruf.

Und genau da hört der Kostenfaktor auf, ein Preisdetail zu sein, und verwandelt sich in eine Systemdesign-Herausforderung.