Wenn KI-Tokens zur Kostenfalle werden

Token-basierte Abrechnungsmodelle erscheinen zunächst sehr transparent, denn die Kosten richten sich nach der Anzahl Input- und Output-Tokens. Doch wie viele Tokens im Arbeitsalltag tatsächlich anfallen, ist schwer zu kalkulieren. Der Verbrauch hängt vom Modell, der Länge der Prompts und den Antworten ab. Auch Kontextfenster, Wiederholungen und die individuelle Arbeitsweise beeinflussen die Zahl der benötigten Token.

Wie groß die Lücke zwischen Kostenkontrolle und Prognose sein kann, zeigt eine Untersuchung von Mavvrik und BenchmarkIT. Darin sagen zwar 98 Prozent der befragten Unternehmen, dass sie ihre KI-Kosten verfolgen und weitere 95 Prozent arbeiten auch mit KI-Budgets. Aber nur elf Prozent können ihre KI-Ausgaben mit höchstens zehn Prozent Abweichung prognostizieren. Bei 62 Prozent haben unerwartete KI-Kosten bereits eine Geschäftsentscheidung wesentlich verändert; ein Viertel verschob oder strich deswegen sogar eine KI-Initiative.

Agenten verschärfen die Kostenfalle

Mit Agentic AI wächst diese Unsicherheit. Ein Chatbot reagiert auf einzelne Prompts. Ein Agent plant Aufgaben, beschafft Informationen, ruft Werkzeuge auf, bewertet Zwischenergebnisse und korrigiert sich gegebenenfalls selbst. So kann ein Geschäftsprozess eine Kette von Modellaufrufen auslösen. Gartner erwartet, dass trotz fallender Token-Preise die Inferenzkosten pro agentischem Workflow bis 2028 um mehr als das Fünffache ansteigen. Das ist kein Widerspruch, denn KI-Anwendungen, insbesondere KI-Agenten, werden immer anspruchsvoller und verbrauchen deshalb wesentlich mehr Tokens.

Token Economy ist ein Architekturfrage

Aus diesem Grund lassen sich die Token-Kosten auch nicht mit Budget-Vorgaben oder Nutzungslimits beherrschen. Entscheidend ist, wie eine KI-Anwendung aufgebaut wird. Nicht jeder Verarbeitungsschritt benötigt das leistungsfähigste Modell, nicht jeder Agent denselben Kontext und nicht jeder Workload dieselbe Infrastruktur. Mit drei Architektur-Ansätzen lassen sich die KI-Kosten wesentlich besser kontrollieren als mit Token-Limits:

1. Die Modellwahl. Routineaufgaben können kleinere oder domänenspezifische Modelle übernehmen, leistungsfähigere Modelle bleiben komplexen Aufgaben vorbehalten. Hinzu kommen Routing und Orchestrierung: Ein Workflow sollte nur dann auf ein aufwendigeres Modell eskaliert werden, wenn die Aufgabe es erfordert. Gartner sieht hier Einsparungen von bis zu 50 Prozent ohne Qualitätsverlust.

• Die Datennutzung. Lange Kontextfenster, wiederholt übertragene Dokumente und unnötige Zwischenergebnisse treiben den Verbrauch nach oben. Kontext sollte deshalb begrenzt, Zwischenergebnisse zusammengefasst und wiederverwendbare Resultate zwischengespeichert werden.

• Der Rechenort. Wiederkehrende Inferenz, Entwicklung, Tests oder spezialisierte Agenten können auf der eigenen Infrastruktur laufen. Entscheidend ist das Zusammenspiel aus Modellwahl, Workflow, Auslastung und Rechenort. AMD kommt in einer Berechnung zu dem Ergebnis, dass bei rund sechs Millionen Tokens pro Tag ein Break-even gegenüber einer vergleichbaren Cloud-API schon nach etwa sechs Monaten erreicht wird. Das ist keine allgemeingültige ROI-Aussage: Modellwahl, Kontextlänge, Caching, Auslastung, Strompreis und Agentenverhalten beeinflussen das Ergebnis erheblich. Doch die Rechnung zeigt, dass sich eine eigene KI-Infrastruktur bei hoher und kontinuierlicher Auslastung bereits innerhalb weniger Monate amortisiert.

HP ZGX: KI-Kapazität statt Token zählen

HP greift diese Entwicklung mit der neuen ZGX-Klasse auf. Damit lassen sich lokale KI-Kapazitäten bereitstellen, um darauf geeignete Workloads kontinuierlich auszuführen. Anschaffung, Strom, Betrieb und Auslastung bleiben zwar Teil der Rechnung, doch die Kosten werden besser kalkulierbar.

HP greift diese Entwicklung mit der neuen ZGX-Klasse auf. Damit lassen sich lokale KI-Kapazitäten bereitstellen, um darauf geeignete Workloads kontinuierlich auszuführen. Anschaffung, Strom, Betrieb und Auslastung bleiben zwar Teil der Rechnung, doch die Kosten werden besser kalkulierbar.

Zwei Modelle stehen hier im Vordergrund: ZGX Nano und ZGX Fury.

• ZGX Nano ist für lokale Entwicklung, Tests und Inferenz auf Entwickler- und Teamebene ausgelegt. Nach Angaben von Red Hat lassen sich darauf auch komplexe, selbstkorrigierende Agentenarchitekturen vollständig lokal betreiben. „Dank schneller Iterationszyklen und Unit-Tests ohne Cloud-Kosten ist die lokale Entwicklung kein Kompromiss mehr“, sagt Vincent Caldeira, CTO bei Red Hat APAC.
•  
• ZGX Fury erweitert den Ansatz auf größere Modelle und größere team- oder abteilungsorientierte KI-Workloads. Das System bietet eine lokale Leistungsklasse zwischen Entwicklerarbeitsplatz und zentraler KI-Infrastruktur. Sie ist damit für lokale Modellentwicklung und Inferenz mit besser kalkulierbaren Infrastrukturkosten positioniert.

Fazit

Lokale KI-Systeme erweitern die Wahlmöglichkeiten: Kontinuierliche und gut auslastbare Workloads können auf eigener Kapazität laufen. Variable Lasten oder kurzfristig benötigte Zusatzleistung werden dagegen extern genutzt. Welche Variante wirtschaftlicher ist, entscheidet nicht der Token-Preis, sondern die zugrundeliegende Architektur.

Weitere Informationen: Alles über die Z Workstation