Die wahren Kosten der KI 

Der Preis pro Million Tokens stammt noch aus der Chatbot-Ära. KI-Agenten erzeugen jedoch komplexe Workloads: Sie planen, recherchieren, nutzen Tools und stoßen weitere Modellaufrufe an. Aus einem Prompt wird somit ein Workload und aus Tokenomics eine Frage von Architektur, Infrastruktur und Produktivität.

Die Euphorie um generative KI folgte einer einfachen ökonomischen Logik: Ein Mitarbeiter stellt eine Frage, ein Large Language Model verarbeitet den Prompt und gibt eine Antwort. Für die Kostenbetrachtung genügte es weitgehend, die Input- und Output-Tokens mit dem jeweiligen Modellpreis zu multiplizieren. Das war solange plausibel, wie KI überwiegend als interaktives Werkzeug eingesetzt wurde. Mit dem Übergang zu agentischen Systemen verändert sich die Rechnung jedoch grundlegend. Ein KI-Agent beantwortet nicht nur eine Anfrage, sondern bearbeitet eine Aufgabe. Dazu zerlegt er sie in einzelne Schritte, plant einen Lösungsweg, greift auf Daten und Tools zu, bewertet deren Ergebnisse und entscheidet anschließend, wie es weitergeht. Ein einziger Auftrag kann dadurch zahlreiche Modellaufrufe erzeugen, wobei jeder dieser Aufrufe reichlich Rechenleistung benötigt. Alles zusammen treibt die Kosten in die Höhe.

Aus Tokenomics wird eine Frage der Workload-Ökonomie

Tokens sind eine wichtige technische Messgröße, aber keine geeignete Beschreibung der Wirtschaftlichkeit eines KI-Systems. Entscheidend ist, was zwischen Eingabe und Ergebnis passiert. Ein gutes Beispiel ist ein Agent, der regelmäßig einen Marktbericht aktualisieren soll. Die Nutzeranweisung kann aus wenigen Worten bestehen. Für die eigentliche Aufgabe muss der Agent jedoch den bestehenden Bericht analysieren, relevante Datenquellen abfragen, neue Informationen gegen bestehende Erkenntnisse abgleichen, Widersprüche erkennen, Ergebnisse bewerten und anschließend eine neue Version erstellen. Je nach Architektur kann jeder dieser Schritte einen separaten Modellaufruf auslösen. Werden die Tool-Ergebnisse erneut in den Kontext übernommen, wächst dieser zusätzlich. Aus einer kurzen Anweisung wird somit ein mehrstufiger Inferenz-Workload.

Dabei entstehen nicht nur Kosten durch die Anzahl der Aufrufe. Auch das Verhältnis zwischen Input und Output spielt eine Rolle. Zwar sind Input-Tokens in der Regel günstiger, doch können umfangreiche Ausgaben etwa bei Reasoning- oder agentischen Workflows die Rechnung erheblich erhöhen. Ein System, das eine Aufgabe mit drei gut orchestrierten Modellaufrufen erledigt, hat eine andere Kostenstruktur als eines, das dafür zwölf Iterationen benötigt – selbst wenn beide Systeme dasselbe Modell verwenden.

Modellgröße ist kein Selbstzweck

Ein wesentlicher Hebel für Kostensenkungen liegt zunächst einmal in der Modellarchitektur. In vielen Unternehmen wird noch immer das leistungsfähigste LLM als universelle KI-Schicht betrachtet. Für agentische Anwendungen ist das jedoch weder technisch noch wirtschaftlich zwingend sinnvoll. So kann ein komplexer Reasoning-Schritt ein leistungsfähiges Modell erfordern, während eine anschließende Klassifikation, Extraktion strukturierter Informationen oder Validierung mit einem kleineren Modell auskommt. Wird trotzdem für jede Teilaufgabe dasselbe Frontier-Modell verwendet, wird Rechenleistung eingesetzt, ohne dass ein zusätzlicher Nutzen entsteht.

Das eröffnet Raum für eine heterogene Modellarchitektur. Kleine, spezialisierte Modelle können definierte Teilaufgaben übernehmen, während leistungsfähigere Modelle nur dann aktiviert werden, wenn ihre zusätzlichen Fähigkeiten tatsächlich benötigt werden. Open-Weight-Modelle sind interessant, weil sie sich für bestimmte Workloads anpassen, quantisieren und näher an den jeweiligen Daten und Anwendungen betreiben lassen. Gerade die Quantisierung kann die Anforderungen an Speicher und Rechenleistung deutlich reduzieren. Anstatt die Modellparameter mit hoher numerischer Präzision vorzuhalten, werden sie mit einer geringeren Präzision dargestellt. Das senkt den Speicherbedarf und kann die Inferenz effizienter machen, wobei immer ein Kompromiss zwischen Ressourcenbedarf, Latenz und Modellqualität gefunden werden muss. Auch die Architektur des Modells selbst spielt eine Rolle. Bei sogenannten Mixture-of-Experts-Modellen müssen beispielsweise nicht bei jeder Inferenz sämtliche Parameter aktiv sein. 

Um dieser Heterogenität gerecht zu werden, brauchen Unternehmen eine wichtige Architekturkomponente: den Model Router. Er entscheidet nicht statisch, welches Modell ein Unternehmen verwendet, sondern dynamisch, welches für einen bestimmten Verarbeitungsschritt am besten geeignet ist. Mögliche Kriterien sind die Komplexität der Aufgabe, die erforderliche Qualität, die Latenz, Datenschutzanforderungen und die verfügbaren Ressourcen. Damit wird Routing zu einem Bestandteil des KI-Controllings. Das System entscheidet nicht nur darüber, wie eine Aufgabe technisch verarbeitet wird, sondern auch, wie viel Rechenleistung dafür wirtschaftlich gerechtfertigt ist.

Kontext wird zum unterschätzten Kostenfaktor

Die zweite ökonomische Disziplin betrifft das Context Engineering. Dabei geht es nicht darum, möglichst wenig Kontext zu verwenden. Ein Agent ohne ausreichende Informationen produziert schlechtere Ergebnisse und benötigt anschließend zusätzliche Korrekturschritte. Das Ziel muss daher sein, den Kontext für jeden Arbeitsschritt gezielt zusammenzustellen. Mithilfe von Retrieval-Augmented Generation können beispielsweise nur die für den aktuellen Verarbeitungsschritt relevanten Dokumente oder Daten nachgeladen werden. Lange Gesprächs- oder Arbeitsverläufe lassen sich verdichten. Stabile Systeminstruktionen und wiederkehrende Kontextbestandteile können über Caching-Mechanismen wiederverwendet werden, anstatt sie bei jedem Aufruf vollständig neu zu verarbeiten. Gerade das Prompt- beziehungsweise Prefix-Caching – technisch die anfragenübergreifende Wiederverwendung des KV-Cache (Key-Value Cache) – kann bei wiederkehrenden Workloads einen erheblichen Unterschied machen, sofern der wiederverwendete Kontext unverändert am Anfang steht. Der technische Grund ist einfach: Teile des Kontextes, die sich zwischen Anfragen nicht verändern, beziehungsweise bereits berechnete Key- und Value-Vektoren vergangener Tokens müssen nicht jedes Mal von Grund auf verarbeitet werden. Damit lassen sich sowohl Latenz als auch Rechenaufwand reduzieren.

Einen Schritt weiter geht die Betrachtung des Agenten-Harness. Gemeint ist die Software- und Laufzeitumgebung, die das Sprachmodell mit Tools, Datenquellen, Speicher und Ausführungslogik verbindet. Wenn ein Agent einen unnötigen Tool-Aufruf ausführt, einen bereits bekannten Kontext erneut verarbeitet oder nach einem nicht erfolgreichen Schritt ohne klare Abbruchbedingung weitere Iterationen startet, steigen die Kosten, ohne dass der geschäftliche Nutzen proportional zunimmt. Ein gut konstruiertes Harness kann solche Situationen begrenzen. Dazu gehören beispielsweise maximale Schrittzahlen, Budgets für einzelne Aufgaben, Loop Detection, eine gezielte Tool-Auswahl und Regeln dafür, wann ein Agent einen Menschen einbeziehen muss.

Inferenz wird zur Infrastrukturfrage

Spätestens an diesem Punkt lassen sich die KI-Kosten nicht mehr von der Infrastruktur trennen. Bei der Nutzung einer externen API erscheinen die Ausgaben zunächst variabel und transparent. Unternehmen bezahlen entsprechend ihres Verbrauchs. Bei eigener Infrastruktur verschiebt sich die Rechnung dagegen auf die Bereiche Hardware, Energie, Kühlung, Software, Betrieb, Wartung und Abschreibung. Dafür entsteht eine andere Form der Planbarkeit: Bei einer dedizierten Inferenzplattform lässt sich die Kapazität gezielt für bestimmte Workloads dimensionieren. Entscheidend ist dann nicht allein die Zahl der GPUs, sondern deren produktive Auslastung. Ein System kann mit leistungsfähiger Hardware ausgestattet sein und trotzdem wirtschaftlich ineffizient arbeiten, wenn die GPUs überwiegend auf Anfragen warten. Umgekehrt kann ein hoher Durchsatz die Kosten pro Aufgabe deutlich reduzieren. Daher muss die Infrastrukturplanung mehrere Größen gemeinsam betrachten: Modellgröße, aktive Parameter, Quantisierung, Kontextlänge, Parallelität, Latenzanforderungen, Inference Throughput und GPU-Auslastung. 

Damit wird auch die Entscheidung über die Infrastruktur differenzierter. Cloud-Deployments bieten Vorteile, wenn Nachfrage und Workload stark schwanken oder Kapazitäten kurzfristig benötigt werden. Eine dedizierte Infrastruktur kann hingegen bei dauerhaft hoher und planbarer Auslastung eine andere Kostenstruktur ermöglichen. Eine pauschale Aussage, dass eine der Varianten grundsätzlich günstiger sei, wäre deshalb zu kurz gegriffen. Entscheidend ist das konkrete Lastprofil. Dazu gehören die Zahl der Nutzer, die erwartete Parallelität, die verwendeten Modelle, die durchschnittliche Kontextgröße, die gewünschte Antwortzeit und das Anfragevolumen. Bei agentischen Anwendungen müssen zusätzlich die durchschnittliche Zahl der Iterationen und die Tool-Nutzung berücksichtigt werden.

Ohne Observability bleibt das KI-Controlling Blindflug

Eine weitere Optimierungsmöglichkeit besteht in der zeitlichen Steuerung der Inferenz. Nicht jeder KI-Workload muss in Echtzeit verarbeitet werden. Die Analyse historischer Support-Tickets, die Klassifikation großer Dokumentbestände oder die regelmäßige Erstellung von Reports kann häufig asynchron erfolgen. Solche Aufgaben lassen sich bündeln und per Batch-Verarbeitung erledigen. Dadurch werden Ressourcen besser ausgelastet. Die Batch-Verarbeitung kann beispielsweise nachts auf GPUs erfolgen, die tagsüber für einen Coding-Assistenten verwendet werden, auf den viele Anwender gleichzeitig zugreifen. 

Fakt ist: Im Zeitalter der KI-Agenten rücken die Kosten pro erledigte Aufgabe in den Mittelpunkt. Die entscheidende Größe ist deshalb das Verhältnis zwischen Rechenaufwand und Geschäftsergebnis. Dafür benötigen Unternehmen Transparenz auf Workload-Ebene, denn ein klassisches Infrastrukturmonitoring reicht hier nicht aus. Ein modernes KI-Observability-Konzept muss unter anderem erfassen, welches Modell eingesetzt wurde, wie viele Input- und Output-Tokens entstanden sind, wie viele Agentenschritte durchgeführt wurden, welche Tools zum Einsatz kamen, wie lange die Inferenz gedauert hat und welche Infrastrukturressourcen dafür benötigt wurden. Diese Informationen müssen sich anschließend Anwendungen, Teams oder Geschäftsprozessen zuordnen lassen. Erst dadurch entsteht eine belastbare Grundlage für FinOps beziehungsweise ein KI-spezifisches Kostenmanagement.

Dabei geht es nicht darum, jede KI-Nutzung möglichst billig zu machen. Vielmehr muss sichtbar werden, wo Kosten entstehen und welchen Wert sie erzeugen. Das verhindert zwei gegensätzliche Fehler: einen unkontrollierten KI-Einsatz auf der einen und eine zu aggressive Kostenbegrenzung auf der anderen Seite.

Autor: Autor: Stefan Muthmann, AI Solutions BDM bei Dell Technologies in Deutschland