Die neue Ökonomie des AI-Kostenmanagements

In den letzten zwei Jahren ging es bei der Nutzung von Enterprise-KI hauptsächlich darum, Menschen dazu zu bringen, sie zu verwenden. In den letzten Monaten hat sich das in vielen Unternehmen rasch geändert. AI-Observability, die den Erfolg einst am Token-Volumen gemessen hat, beginnt nun, den Erfolg am Return on Investment zu messen. Und die Unternehmen, die das Kostenmanagement zuerst in den Griff bekommen, sind diejenigen, die KI skalieren können, ohne dass ihre Ausgaben ihre Einnahmen übersteigen.

Im Kern ist KI-Kostenmanagement die Praxis der Messung, Zuordnung, Steuerung und Optimierung von KI-Ausgaben über Modelle, Agenten, Anwendungen und Teams hinweg. Das Ziel besteht nicht einfach darin, weniger Tokens zu verbrauchen, sondern den Geschäftswert zu maximieren, der für jeden ausgegebenen Dollar generiert wird. Da KI-Agenten immer mehr autonome Aufgaben übernehmen, erstreckt sich diese Disziplin zunehmend auf die Verwaltung der Kosten für Agent-Reasoning, Tool Calls und die zugrunde liegenden Modelle.

Wir haben uns mit Kevin Stumpf zusammengesetzt, einem Senior Staff Engineer bei Databricks und Technical Lead für Unity Gateway, um darüber zu sprechen, wie Teams diese Disziplin tatsächlich in die Praxis umsetzen sollten: KI-Kosten nicht als einzusetzenden Posten zu behandeln, den es zu minimieren gilt, sondern als ein System, das es zu steuern gilt.

Von Tokenmaxxing zu Valuemaxxing

In den sozialen Medien wimmelt es von Führungskräften, die behaupten, dass „Tokenmaxxing“ – also KI so intensiv und oft wie möglich auszuführen – der richtige Weg sei, um Innovationen zu beschleunigen. Abgesehen von den offensichtlichen Kostenfolgen: Warum ist das die falsche Herangehensweise an die KI-Einführung?

Kevin Stumpf: Die Branche bewegt sich von Tokenmaxxing zu Valuemaxxing. In der Anfangszeit gab es öffentliche Bestenlisten, die zeigten, wie viele Tokens verbraucht wurden, und das war damals als Strategie durchaus sinnvoll. Viele Menschen zögerten noch, KI einzusetzen. Zu zeigen, dass die Vorbilder, zu denen alle aufschauten, KI intensiv nutzten, gab anderen einen Anreiz zu folgen. Wenn ich sehe, dass jemand, den ich respektiere, Unmengen an KI nutzt, möchte ich sein wie diese Person.

Aber das System wurde ausgetrickst. Sobald der Spitzenplatz auf der Bestenliste zum Statussymbol wurde, fanden die Leute heraus, dass der schnellste Weg dorthin nicht gute Arbeit war, sondern Volumen. Man startet einen einfachen Agenten, der in einer Schleife läuft, lässt ihn immer wieder nach dem Wetter fragen und verbraucht Tokens für quasi nichts. Das war das absehbare Ergebnis einer Anreizstruktur, die reine Nutzung statt tatsächlicher Ergebnisse belohnte.

Nachdem sich KI in Unternehmen auf breiter Front durchgesetzt hat, hat sich die Diskussion hin zu einer verantwortungsvollen, effektiven Nutzung verlagert. Worauf wir hinarbeiten sollten, ist eine andere Art von Bestenliste: eine, die Personen nach dem Mehrwert einstuft, den sie mit KI generiert haben, geteilt durch die Kosten für dessen Erzielung. Das ist der Return on Investment – und das ist viel schwerer zu quantifizieren als reine Token-Zahlen, aber es ist die Kennzahl, auf die es wirklich ankommt. Ähnliches Thema: Was treibt die Einführung von Enterprise-KI voran?

Was Kostenzuordnung in der Praxis wirklich bedeutet

Können Sie uns erklären, was „Kostenzuordnung“ bei KI wirklich bedeutet?

Kevin Stumpf: Bei der KI-Kostenzuordnung geht es letztlich darum, zwei Fragen zu beantworten: Woher kommen meine Ausgaben und was habe ich dafür bekommen? Auf der einfachsten Ebene bedeutet das, Kosten einem einzelnen Benutzer oder Team zuzuordnen, beispielsweise einem Data-Science-Team oder einem Software-Engineering-Team. Es kann auch einem spezifischen Projekt oder einem Knotenpunkt im Organigramm zugeordnet werden – etwa um zu verstehen, wie hohe Ausgaben unter einem VP of AI im Vergleich zu einem SVP of Engineering liegen.

Das Ziel ist eine ausreichend detaillierte Transparenz, sodass Sie die Daten flexibel analysieren und verstehen können, woher die Kosten tatsächlich kommen – denn was man nicht messen kann, kann man nicht steuern. Databricks bietet Kostenzuordnung direkt ab Werk nach Benutzer, Gruppe, Agent, AI Gateway-Endpunkt, Modell, Anbieter und Zeitrahmen. Unternehmen können dies aber auch mithilfe von Tags auf Anfrageebene individuell anpassen. Ein Tag kann alles darstellen, was für Ihr Unternehmen wichtig ist – beispielsweise einen spezifischen Pull Request, ein Feature oder einen externen Kunden. Sobald jede Anfrage diesen Tag trägt, können Sie die Ausgaben nach Belieben aggregieren.

Dieser Wandel in der Kundenwahrnehmung ist spürbar. Vor sechs Monaten bestand die größte Sorge darin, bei der KI-Einführung ins Hintertreffen zu geraten. Heute ist es das Gegenteil: KI wird oft für unnötige Dinge genutzt, die Kosten wachsen schneller als die Einnahmen, und Führungskräfte fragen sich, wie sie diese Kostenkurve abflachen können, bevor sie die Profitabilität gefährdet. Das ist keine Theorie. Es ist ein Thema für die Geschäftsführung bei fast jedem Unternehmen, mit dem wir sprechen – auch intern bei Databricks.

Context Bloat in den Griff bekommen

Token-Verbrauch und die Größe des Kontextfensters werden oft beschuldigt, aber selten gut erklärt. Wie sieht „Context Bloat“ in einem Produktionssystem tatsächlich aus und was ist die praktische Lösung?

Kevin Stumpf: Context Bloat bedeutet, einen Agenten mit weit mehr Informationen zu überhäufen, als er für eine gute Entscheidung benötigt. Das ist aus zwei Gründen ein Problem. Erstens verbraucht es unnötige Tokens. Zweitens lenkt es ab: Der Agent muss diese zusätzlichen Informationen verarbeiten und entscheiden, ob sie relevant sind, was einen eigenen Aufwand darstellt. Das ist ähnlich, wie wenn man einer Person einen Stapel irrelevanter Dokumente übergibt und sie bittet herauszufinden, was wichtig ist, bevor sie überhaupt mit der Aufgabe beginnen kann.

Die beste Lösung ist nicht das spätere Kürzen oder Zwischenspeichern (Caching), sondern das Vermeiden des Bloats von vornherein. Ein gängiges und effektives Muster besteht darin, den Agenten relevanten Kontext bei Bedarf abrufen zu lassen – über Tools, MCP-Server oder Skills – anstatt ihm vorab vorsorglich alles bereitzustellen, was er benötigen könnte. Sie sollten einem Agenten standardmäßig nur dann Kontext bereitstellen, wenn Sie sich zu 90 % oder mehr sicher sind, dass er für die jeweilige Aufgabe wirklich wichtig ist. Andernfalls lassen Sie den Agenten wissen, was verfügbar ist, und ermöglichen Sie ihm, sich bei Bedarf das zu holen, was er braucht.

Dynamisches Modell- und Harness-Routing

Die Modellauswahl ist oft eine Einmalentscheidung. Warum sollte sie stattdessen dynamisch sein und wie entscheidet intelligentes Routing in Echtzeit, ob eine Aufgabe ein Frontier-Modell oder etwas Günstigeres und Schnelleres erfordert? Lässt sich dieser Gedanke auch auf die Wahl zwischen verschiedenen Agent-Harnesses übertragen?

Kevin Stumpf: Bei der KI-Kostenoptimierung geht es nicht darum, immer das günstigste Modell zu wählen. Teams sollten stattdessen dazu übergehen, das kostengünstigste Modell oder den kostengünstigsten Harness zu wählen, der die für eine Aufgabe erforderliche Qualität liefern kann. Die Realität ist derzeit, dass Frontier-Modelle hochleistungsfähig und teuer sind, während Nicht-Frontier-Modelle immer noch sehr leistungsfähig, aber eben günstiger sind. Ungefähr 5 bis 10 % der Aufgaben benötigen wirklich ein Frontier-Modell – entweder weil viel auf dem Spiel steht und Sie das bestmögliche Ergebnis wollen, oder weil das Problem für etwas anderes zu komplex ist. Die anderen 90 % der Aufgaben lassen sich durch einfachere Modelle lösen, sei es durch selbst gehostete Open-Source-Modelle oder günstigere Modellfamilien der großen Anbieter.

Überlässt man ihnen die Wahl, entscheiden sich die meisten Mitarbeitenden standardmäßig für das teuerste verfügbare Modell, weil ihr Ziel schlicht darin besteht, das Problem zu lösen, und niemand darauf achtet, was es im Einzelnen kostet. Smart Routing löst dies, indem eine Ebene eingefügt wird, die die Aufgabenkomplexität in Echtzeit bewertet und entscheidet, ob eine Anfrage an ein Frontier-Modell oder ein kostengünstigeres Modell gesendet werden soll – mit dem Ziel, die gleiche Ausgabequalität zu geringeren Kosten beizubehalten.

Harness-Routing ist die nächste Stufe nach dem Modell-Routing. Erste Forschungsergebnisse zeigen, dass genau dasselbe Modell, das über einen anderen Harness ausgeführt wird, zu deutlich unterschiedlichen Kosten führen kann. Das ist logisch, denn der Harness bestimmt, wie das Modell mit seiner Umgebung interagiert: welchen Regeln es folgt, wann es das Kontextfenster komprimiert und welche Geschäftslogik sein Verhalten steuert. All das hat direkten Einfluss darauf, wie viele Tokens verbraucht werden. Harness-Routing ist der nächste Schritt in der schrittweisen Entwicklung der Kostenoptimierung, die wir über Unity Gateway und Omnigent, unseren Meta-Harness, ermöglichen.

Leitplanken für Ausgaben festlegen

Sprechen wir über Leitplanken für die Ausgaben selbst, wie feste Obergrenzen, Budgets und Rate Limits. Wie gestaltet man diese am besten, damit sie ausufernde Kosten stoppen, ohne die Produktivität der Entwickler zu beeinträchtigen oder Produktionsabläufe zu unterbrechen?

Kevin Stumpf: Einige Regeln gelten für jedes Unternehmen, andere hängen vom Anwendungsfall oder dem Unternehmen ab. Jeder sollte feste Ausgabenobergrenzen haben, um eine ausufernde Nutzung abzufangen. Wenn Ihr typischer Power-User höchstens etwa 300 $ pro Tag für KI ausgibt, legen Sie die Obergrenze etwas darüber fest, vielleicht bei 500 $. Dieser Puffer gibt Ihnen Raum, um echte Fehler abzufangen – wie einen Agenten, der versehentlich in einer Schleife gelaufen ist –, ohne berechtigte Tage mit hoher Nutzung abzuscheiden.

Über diese Grundlinie hinaus sind differenzierte Budgets nach Team oder Projekt sehr sinnvoll. Ein Team, das an etwas Entscheidendem für den CEO arbeitet, rechtfertigt möglicherweise ein deutlich höheres Budget als ein Team, das an Aufgaben mit geringerer Priorität arbeitet. Diese Entscheidung sollte den Wert dessen, was dieses Team produziert, gegen die Kosten abwägen, die entstehen, wenn man ihm mehr Spielraum einräumt.

Budgets sollten auch verschiedene Arten von Reaktionen auslösen können, nicht nur einen harten Stopp. Sie können beispielsweise Warnungen senden, feste Obergrenzen anwenden oder die verfügbare Modellkapazität reduzieren – etwa indem der Standardzugriff auf Frontier-Modelle gesperrt wird, sobald ein Team 70 % seines Budgets verbraucht hat, und die restlichen Anfragen stattdessen an Open-Source-Modelle weitergeleitet werden. Die Kernprinzipien, die überall gelten: Ausufernde Ausgaben verhindern, differenzierte Limits nach Gruppe oder Projekt festlegen, vor dem Deckeln warnen und eine intelligente Kapazitätsreduzierung statt eines abrupten Abschaltens einbauen.

Messung dessen, was KI tatsächlich liefert

Welche Plattformen bieten Agenten-Monitoring und Kostenverfolgung zusammen an, und wie weit kann diese Transparenz dabei helfen, den tatsächlichen ROI zu messen, statt nur die Ausgaben?

Kevin Stumpf: Die Messung von Kosten ist viel einfacher, als diese Kosten mit dem Return on Investment zu verknüpfen. Das ist die Frage, auf die jeder eine Antwort sucht und die fast niemand bisher vollständig gelöst hat. Tagging auf Sitzungs- oder Anfrageebene macht dies möglich. Wenn ein Agent an einem bestimmten Pull-Request arbeitet, kann er seine Sitzung oder spezifische Anfragen mit der Kennung dieses Pull-Requests taggen. Diese Zuordnung fließt in ein Kosten-Dashboard zurück, sodass Sie beispielsweise sehen können, dass ein bestimmter Pull-Request 300 $ gekostet hat. Das machen wir intern bei Databricks bereits so.

Im Idealfall – und das ist etwas, das wir in das Produkt Unity Gateway einbauen – können Sie noch einen Schritt weitergehen und diesen Pull-Request mit einem bestimmten Feature verbinden und dieses Feature mit einem messbaren Ergebnis, wie etwa wie viel Umsatz oder Pipeline in einem bestimmten Zeitraum generiert wurde. Das ist der heilige Gral: Nicht nur zu wissen, was KI gekostet hat, sondern zu wissen, was sie gebracht hat. Mit Unity Gateway verfügen wir bereits über eine hochgradig anpassbare Plattform, auf der wir aufbauen können, und wir investieren darin, diese Kosten-Ertrags-Ansicht direkt ab Werk verfügbar zu machen, anstatt dass Teams sie selbst erstellen müssen.

Kostentransparenz erfordert ein zentralisiertes System

Was erfordert eine gute Kostentransparenz eigentlich für ein Unternehmen, das mehrere Modelle, Agenten und Tools über viele Teams hinweg betreibt? Ist es ein Dashboard-Problem, ein Governance-Problem oder ein FinOps-Problem?

Kevin Stumpf: Gute Kostentransparenz erfordert, dass jede KI-Interaktion über ein zentrales System läuft. Nur so lassen sich die richtigen Informationen konsistent erfassen, um darauf aufbauend zuverlässige Dashboards und Warnmeldungen zu erstellen. Ein KI-Gateway bietet einen zentralen Kontrollpunkt für das KI-Kostenmanagement über Modelle, Agenten, Tools und Teams hinweg. Databricks Unity Gateway ist darauf ausgelegt, diesen zentralen Kontrollpunkt für Modelle, Agenten, Tools und Coding-Agenten bereitzustellen. Wenn KI-Interaktionen über einen gemeinsamen Kontrollpunkt fließen, können Organisationen die Nutzung beobachten, Kosten zuordnen, Budgets durchsetzen und Ausgaben an einem Ort optimieren.

Ein zentrales System allein reicht jedoch nicht aus. Sie benötigen auch eine Möglichkeit durchzusetzen, dass wirklich jeder seinen KI-Traffic darüber leitet. Transparenz funktioniert nur, wenn die Nutzung universell und nicht optional ist.

Kostenoptimierung und Ergebnisqualität im Gleichgewicht halten

Kostenkontrolle darf nicht auf Kosten von Qualität oder Zuverlässigkeit gehen. Woher weiß man, wann eine Optimierung zu weit gegangen ist und anfängt, die Ergebnisse zu beeinträchtigen?

Kevin Stumpf: Das hängt ganz vom jeweiligen Anwendungsfall ab. Sie benötigen einen Feedback-Mechanismus, der entweder subjektiv oder objektiv sein kann. Subjektives Feedback ist anekdotisch – jemand im Team sagt Ihnen, dass er die Aufgabe mit dem aktuellen Budget nicht erledigen kann. Das lässt sich schnell einholen, aber auch leicht als Beschwerde einer einzelnen Person abtun. Objektives Feedback stammt aus automatisierten Evaluierungen, die zwar schwerer einzurichten, aber weit zuverlässiger sind.

Für einen gängigen Anwendungsfall wie Coding-Agenten könnte das bedeuten, eine Proxy-Metrik für Qualität zu definieren, beispielsweise gemergte Pull-Requests, die innerhalb von zwei Wochen nicht zurückgesetzt werden. Von dort aus können Sie experimentieren: Halbieren Sie das Budget und sehen Sie, ob sich diese Schlüsselmetrik verändert, stabil bleibt oder sich sogar verbessert – da Einschränkungen manchmal die Kreativität fördern. Durch parallele Experimente in Teams mit unterschiedlichen Budgets, Modellen und Harnesses oder zeitlich begrenzte Vergleiche über einige Wochen hinweg können Sie ableiten, ob ein bestimmtes Budget Wert schafft oder vernichtet, anstatt nur zu raten.

Der Wert von Ende-zu-Ende-Tracing

Welche Rolle spielen Ende-zu-Ende-Tracing und Überwachung an dieser Stelle? Wenn Sie Prompts, Tool-Aufrufe und Token-Nutzung über den gesamten Agenten-Workflow hinweg einsehen können, was schaltet das frei, was vorher nicht möglich war?

Kevin Stumpf: Beim Tracing geht es darum, sämtliche Spuren dessen zu erfassen, was Agenten tun: worüber sie nachdenken, welche Tools sie aufrufen, welche Daten sie heranziehen und ob die Prompts gut oder schlecht sind. Diese Rohdaten können Sie nach Erkenntnissen durchsuchen – sei es zur Identifizierung von Missbrauch, Verschwendung, Sicherheitslücken oder einfach nach Mustern, nach denen Sie nie gesucht hätten.

Dies spiegelt wider, was in der gesamten Datenbranche passiert ist. Zu Beginn hatten wir nur saubere, strukturierte Daten in Datenbanken. Dann kamen Data Lakes, die eine Zeit lang zu Data Swamps wurden, weil Menschen unstrukturierte Daten darin abluden, ohne eine Möglichkeit zu haben, Wert daraus zu ziehen. Schließlich wurden diese Sümpfe wieder zu nutzbaren Data Lakes, und heute sind wir besser denn je aufgestellt, um Erkenntnisse aus unstrukturierten und semistrukturierten Daten zu gewinnen – größtenteils, weil LLMs flexibel genug sind, sie zu verarbeiten. Agenten-Traces fallen in dieselbe Kategorie. Je mehr Sie davon erfassen, desto mehr Erkenntnisse stehen Ihnen zur Verfügung – und der Zugang dazu ist einfacher denn je.

Skalierung auf Agenten-Flotten

Viele Unternehmen wechseln von einzelnen KI-Anwendungen zu Agenten-Flotten. Ändert dieser Wandel die Kostenrechnung (neue Kostentreiber? neue blinde Flecken?) im Vergleich zum Betrieb eines einzelnen Modells hinter einer Anwendung?

Kevin Stumpf: Es ändert die Rechnung nicht so sehr, wie es sie vervielfacht. Agenten-Schwärme werden die neue Realität sein, und jeder dieser Agenten wird Token verbrauchen, die zugeordnet, überwacht und verwaltet werden müssen. Jetzt ist der richtige Zeitpunkt, das Fundament für Kostentransparenz und -management zu legen, bevor die Anzahl der Agenten in der Produktion so stark wächst, wie es prognostiziert wird.

Coding-Agenten sind heute die dominierende Kategorie, die Token verbraucht, aber das wird sich auf viele andere Klassen von Agenten ausweiten, die rund um die Uhr autonom arbeiten – Agenten, die andere Agenten aufrufen, die wiederum andere Agenten aufrufen. Organisationen, die mit dem Aufbau einer zentralen KI-Observability- und Kostenmanagement-Infrastruktur warten, bis diese Komplexität da ist, werden sie unter Druck aufbauen müssen, anstatt zu ihren eigenen Bedingungen.

Wenn Sie Führungskräften im Bereich Enterprise-KI für das kommende Jahr ein Umdenken beim Kostenmanagement mit auf den Weg geben müssten, welches wäre das?

Kevin Stumpf: Ich würde nicht bis nächstes Jahr warten. Das Thema ist dringend und sollte ab sofort so behandelt werden. Wenn ich es auf einen einzigen Gedanken reduzieren müsste, dann auf diesen: Was man nicht misst, kann man nicht steuern. Das gilt für Rohstoffe, es gilt für Menschen und es gilt genauso für KI. KI wird schnell zu einer der wichtigsten Positionen in der Kapitalflussrechnung eines Unternehmens, und sie muss vollständig instrumentiert werden, damit sie gemessen und wiederum gesteuert werden kann. Sie ist nur ein weiterer Rohstoff im System, das die Waren oder Dienstleistungen Ihrer Organisation herstellt, und sie verdient es, mit der gleichen Disziplin behandelt zu werden.

Die Zeit läuft ab jetzt Die Kontrolle von KI-Kosten über Teams hinweg, die mehrere Modelle und Tools nutzen, ist kein Problem, das sich mit einem einzigen Dashboard oder einer einmaligen Modellauswahl lösen lässt. Es ist eine betriebliche Disziplin: eine Zuordnung, die fein genug ist, um Ausgaben einer Person oder einem Projekt zuzuweisen, ein Routing, das sich in Echtzeit an die Anforderungen einer Aufgabe anpasst, Leitplanken, die ausufernde Ausgaben abfangen, bevor sie zu Negativschlagzeilen führen, und ein Tracing, das detailliert genug ist, um aus den Rohdaten der Nutzung echte Erkenntnisse zu gewinnen. Die Organisationen, die hier die Nase vorn haben, sind nicht diejenigen, die am wenigsten für KI ausgeben. Es sind diejenigen, die mit Gewissheit sagen können, was genau sie für ihr Geld bekommen haben.

Erfahren Sie mehr darüber, wie Unity Gateway Kostenzuordnung, intelligentes Routing und Ausgaben-Guardrails über Ihre gesamte KI-Landschaft hinweg zentralisiert.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag