Die fehlende Kennzahl zwischen Tokens und Cloud‑Ausgaben

Das Problem ist nicht, dass KI‑Teams keine Kostendaten haben. Es ist, dass das Token‑Dashboard und die Cloud‑Rechnung unterschiedliche Systeme beschreiben, die von verschiedenen Teams verwaltet werden, und es keinen verlässlichen Weg gibt, sie zu verbinden.

Ein Support‑Mitarbeiter kann ein Ticket nach fünf Modellaufrufen, einem Abrufschritt, zwei Werkzeugaufrufen und einem Wiederholungsversuch lösen. Das Unternehmen erfasst einen abgeschlossenen Fall. Die Infrastruktur protokolliert eine Vielzahl von Anfragen, Pods, Speicher, Beschleunigerzeit und gemeinsam genutzten Diensten. Solange diese Aufzeichnungen nicht zusammengeführt werden, ist die Kostenoptimierung zum Teil ein Ratespiel.

Warum erzählen Token‑Metriken und Cloud‑Rechnungen unterschiedliche Geschichten?

Token‑Zahlen sind nützlich. Sie zeigen, wie viel Text ein Modell erhalten und zurückgegeben hat, und sie helfen Teams, Eingabeaufforderungen, Modelle oder Routing‑Entscheidungen zu vergleichen. Sie sagen jedoch nicht, was rund um den Modellaufruf geschehen ist, wie viel Rechenleistung die Abruf‑ und Werkzeugnutzung unterstützt hat, wie viele fehlgeschlagene Versuche zuerst auftraten oder ob das Endergebnis überhaupt nützlich war.

Der State of FinOps 2026 zeigt, wie schnell KI in die reguläre FinOps‑Arbeit eingezogen ist: 98 % der Befragten verwalten jetzt KI‑Ausgaben, gegenüber 63 % im Jahr 2025. Doch eine größere Budgetposition sagt immer noch nicht, welcher Workflow das Geld verbraucht hat oder warum. 

Zwei Dokumentverarbeitungs‑Jobs können etwa die gleiche Anzahl an Tokens verbrauchen. Der eine kann mit einer einzigen Modellanfrage abgeschlossen werden. Der andere kann Kontext aus mehreren Speichern abrufen, einen externen Dienst aufrufen, auf ein alternatives Modell zurückgreifen und das Dokument nach einer fehlgeschlagenen Validierungsprüfung, die der Nutzer nie sieht, erneut ausführen. Die Token‑Summen sehen ähnlich aus, während die Ausführungswege unterschiedlich sind.

Unite.ai hat bereits untersucht, warum Token‑Zahlen nicht automatisch den geschäftlichen Wert widerspiegeln. Der nächste Schritt besteht darin, diese Zahlen mit den Workloads zu verknüpfen, die sie erzeugt haben. Andernfalls kann ein Team die Kosten pro Token senken, während die Kosten pro abgeschlossener Aufgabe steigen.

Wie sieht eine vollständige Kostenkette aus?

Eine nützliche Kostenkette beginnt mit dem Ergebnis, das dem Unternehmen wichtig ist. Das kann ein gelöster Support‑Fall, ein verarbeitetes Dokument, eine akzeptierte Code‑Änderung oder ein abgeschlossener Agent‑Workflow sein. Alles darunter benötigt eine Kennung, die im gesamten System nachverfolgt werden kann.

Die Anwendungsschicht liefert die erste Verbindung. Eine Request‑ID, Trace‑ID, ein Workflow‑Name oder eine Gesprächs‑ID kann mehrere Modell‑ und Werkzeugoperationen zu einer Arbeitseinheit verknüpfen. Ohne diesen Zusammenhang sehen zehn verwandte Ereignisse wie zehn unabhängige Kosten aus.

Die OpenTelemetry‑Konventionen für GenAI‑Agenten bieten ein aufkommendes Vokabular für diese Schicht. Sie decken Operationen, Anbieter, angeforderte Modelle, Agenten, Gespräche, Token‑Verbrauch, Werkzeugausführung, Fehler und Workflows ab. Die Konventionen befinden sich noch in der Entwicklung, sodass Teams sie nicht als fertigen universellen Standard betrachten sollten. Sie sind nützlich, weil sie das Korrelationsproblem greifbar machen.

Dann folgt die Infrastruktur. Die Split‑Cost‑Allocation‑Daten für EKS von AWS können gemeinsam genutzte Rechen‑ und Speicherkosten Kubernetes‑Pods zuordnen und Details wie Cluster, Namespace, Deployment, Node, Workload‑Name und Workload‑Typ anzeigen. Für unterstützte beschleunigte Instanzen decken die Daten zudem GPU‑, Trainium‑ und Inferentia‑Reservierungen ab.

Das ist die andere Hälfte der Kette. Ein Trace kann erklären, was die Anwendung zu tun versuchte; die Kubernetes‑Zuweisung kann zeigen, welche Ressourcen die Arbeit getragen haben. Unite.ais Leitfaden zum Bereitstellen und Überwachen von LLMs auf Kubernetes liefert den breiteren Produktionskontext, einschließlich Ressourcen‑Zuweisung, Skalierung und Beobachtbarkeit.

Die Verknüpfung wird nicht zufällig geschehen. Teams benötigen eine stabile Kennung, die lange genug überlebt, um Anwendungs‑Telemetry mit Workload‑Labels, Zuweisungs‑Datensätzen oder einer anderen Mapping‑Ebene zu verbinden. Kundendaten gehören nicht in Kubernetes‑Tags. Teams sollten entscheiden, welche Low‑Cardinality‑Kennungen sicher eine Workflow‑Kategorie, einen Service oder ein Feature mit den verbrauchten Ressourcen verknüpfen können.

Sobald dieser Anwendungskontext vorhanden ist, können Teams beginnen, Kubernetes‑Kosten nach Workload zu verfolgen und Namespace-, CPU-, Speicher- und GPU‑Nutzung zurück zum ausgeführten Vorgang zu verbinden. Das sagt immer noch nicht, ob der Workflow geschäftlichen Wert geschaffen hat, aber es gibt der Infrastrukturseite der Berechnung etwas Konkretes, an das sie angehängt werden kann. 

Welcher Kennwert sollte das Unternehmen vertrauen?

Es gibt keinen einzigen KI‑Kostenkennwert, den jedes Team verwenden sollte. Kosten pro Token beantworten die Frage nach dem Modellverbrauch. Kosten pro Pod beantworten die Frage nach der Infrastrukturzuweisung. Keiner von beiden sagt einem Produktverantwortlichen, ob das Feature seine Kosten rechtfertigt.

Der beste Nenner ist in der Regel das kleinste Ergebnis, das das Unternehmen klar definieren und das Produktteam beeinflussen kann. Ein Support‑Betrieb könnte die Kosten pro gelöstem Fall verfolgen. Ein Dokumentensystem könnte Kosten pro erfolgreich verarbeiteter Datei verwenden, während ein Coding‑Assistent Kosten pro akzeptierter Änderung statt Kosten pro Vorschlag untersuchen könnte.

Erfolg ändert die Rechnung.

Ein Workflow mit niedrigen Kosten pro Versuch kann teuer sein, wenn er häufig fehlschlägt, wiederholte Validierungen auslöst oder zu viele Fälle zur menschlichen Prüfung weiterleitet. Deshalb sollten Teams die Kosten pro Versuch von den Kosten pro Abschluss trennen und, wo möglich, die Kosten pro akzeptiertem Ergebnis betrachten. Letztere Zahl ist oft die nützlichste, weil sie die vom System erbrachte Arbeit einschließt, die das Unternehmen nicht nutzen konnte.

Agent‑Systeme erschweren das, weil ihre Pfade von Durchlauf zu Durchlauf variieren können. Unite.ais Analyse der Wirtschaftlichkeit beim Skalieren agentischer KI‑Workloads behandelt Routing, Werkzeugaufrufe, Wiederholungen und Workflow‑bezogene Zuordnung. Diese Verhaltensweisen gehören zum Kennwert, wenn sie Ressourcen verbrauchen, selbst wenn der Endnutzer nur eine Antwort sieht.

Der Kennwert wird dennoch nicht perfekt sein. Gemeinsame Dienste, zwischengespeicherte Ergebnisse, Batch‑Jobs und verzögerte Verarbeitung können die Zuordnung verwischen. Eine für Entscheidungen nützliche Schätzung ist besser als falsche Präzision, besonders wenn sie Ingenieuren zeigt, welche Ebene einer Untersuchung bedarf.

Wer besitzt die Zahl?

Der schwierigste Teil könnte organisatorischer Natur sein. ML‑Teams verstehen Modellaufrufe und Evaluationen. Plattform‑Teams verstehen Workloads und das Cluster‑Verhalten. FinOps versteht Abrechnungsdaten und Zuweisungsregeln. Produkt‑Teams wissen, welches Ergebnis wichtig ist.

Kein einzelnes Team besitzt die gesamte Kette.

Das führt zu vorhersehbaren Diskussionen darüber, welches Dashboard korrekt ist. Das ML‑Team kann auf einen geringeren Token‑Verbrauch verweisen, während das Plattform‑Team steigende GPU‑Stunden sieht und das Produkt‑Team weniger abgeschlossene Aufgaben als zuvor feststellt. Alle drei Beobachtungen können gleichzeitig zutreffen. Der gemeinsame Kennwert muss die Beziehung zwischen ihnen erklären.

Ein praktikabler Ausgangspunkt ist ein Produktions‑Workflow mit einem klaren Abschluss‑Ereignis. Vergeben Sie ihm eine stabile Kennung. Übertragen Sie diesen Kontext durch die Modell‑ und Werkzeug‑Traces, ordnen Sie ihn dem Service oder der Workload in Kubernetes zu und wählen Sie einen geschäftlichen Nenner. Bringen Sie dann die Teams zusammen, wenn die Zahl unerwartet schwankt.

Diese Überprüfung ist wichtiger als ein ausgefeiltes Dashboard. Ein plötzlicher Anstieg kann durch längere Prompt‑Eingaben, einen neuen Fallback‑Pfad, ungenutzte GPU‑Kapazität, eine geänderte Auto‑Scaling‑Richtlinie oder eine Produktentscheidung entstehen, die mehr Arbeit durch die KI‑Funktion leitet. Jede Ursache gehört zu einem anderen Verantwortlichen.

Automatisierung sollte später kommen. Eine Empfehlungs‑Engine kann nur auf die Labels und Schwellenwerte reagieren, die sie erhält, und ein schlechter Nenner kann ein effizientes System verschwenderisch erscheinen lassen oder einen günstigen Workflow belohnen, den Nutzer ablehnen. Teams benötigen ausreichend gemeinsame Sichtbarkeit, um das Modellverhalten von Anwendungsdesign und Infrastrukturzuweisung zu unterscheiden, bevor sie ein System auf das Ergebnis reagieren lassen. Andernfalls kann eine automatisierte Kostenkorrektur die Kapazität reduzieren, die Latenz erhöhen und die Ausgaben an weniger sichtbare Stellen verlagern.

Die Kostenkette muss geteilt werden

Die KI‑Kostenkontrolle wird fragmentiert bleiben, solange jedes Team nur die Ebene optimiert, die es sehen kann. Tokens, Traces, Pods, Beschleuniger und Rechnungen sind keine konkurrierenden Messgrößen. Sie sind Teile derselben Kostenkette.

Die Unternehmen, die sie verbinden, werden nicht am ersten Tag eine perfekte Zahl erhalten. Wichtig ist, ob das Team eine hohe Rechnung zurückverfolgen kann zum auslösenden Workflow, herausfindet, was sich geändert hat, und entscheidet, ob das Ergebnis die Kosten rechtfertigt.