Kostenfalle cloudbasierter KI-Betrieb So sprengt das KI-Inferencing die Cloud-Budgets

Von Dr. Dietmar Müller 9 min Lesedauer

Beim Training großer Foundation-Models entstehen gigantische Kosten. Die viel größere und sich wiederholende Kostenbelastung entsteht jedoch in der Inferencing-Phase. Um davon nicht erschlagen zu werden, müssen Unternehmen auf ganz neue Tools und Frameworks setzen.

Tritt das KI-Modell erst einmal in Aktion, steigen die Compute-Ausgaben und können dauerhaft die Cloud-Budgets von Unternehmen belasten.(Bild: ©  DAYA-DAKSH - stock.adobe.com / KI-generiert)
Tritt das KI-Modell erst einmal in Aktion, steigen die Compute-Ausgaben und können dauerhaft die Cloud-Budgets von Unternehmen belasten.
(Bild: © DAYA-DAKSH - stock.adobe.com / KI-generiert)

Alle Welt erregt sich über die gigantischen Kosten und den enormen Energieverbrauch, die das Training von Large Language Models (LLMs) mit sich bringen. Auch der Autor dieses Artikels hat in den vergangenen Monaten sein Augenmerk vorrangig darauf gerichtet und die entsprechenden Rechenzentren bestaunt. Das ist jedoch kurzsichtig, denn das langfristige finanzielle Risiko liegt woanders: Die Ausbildung von LLMs ist nur eine einmalige Investition. Die viel größere, sich wiederholende und oft unkontrollierte Kostenbelastung entsteht in der Inferencing-Phase, also während der eigentlichen Nutzung des Modells durch Abfragen über die Cloud.

Das ökonomische Ungleichgewicht: Training vs. Inferencing

Lassen Sie uns das Problem eingangs nochmal kurz verdeutlichen, denn es ist ein großes: Das Training eines Modells wie GPT-4 oder ein spezialisiertes Llama-Modell ist ein massiver, aber zeitlich begrenzter Kraftakt. Man benötigt für Wochen oder Monate tausende High-End-GPUs wie beispielsweise Nvidias H100. Die dabei anfallenden Fixkosten sind hoch. Das war’s dann aber auch – die Ausgaben skalieren nicht mit der Nutzung.

Während der Phase des Inferencings wird dagegen das bereits trainierte Modell verwendet, um Vorhersagen oder generierte Ausgaben – gemeinhin Tokens genannt – basierend auf neuen Eingabedaten zu liefern. Die dabei anfallenden variable Kosten pro Anfrage sind niedrig und wägen Unternehmen damit erstmal in Sicherheit, allerdings wachsen sie linear mit der Nutzungsfrequenz. Bei breiter Nutzung wie etwa durch die Integration künstlicher Intelligenz (KI) in den Kundenservice übersteigen diese Kosten schnell die Trainingskosten.

In der Betriebswirtschaft könnte man das Training im Prinzip wie eine Capex-Investitionsausgabe behandeln. Inferenz ist dagegen ein laufender Prozess und erzeugt Operational Expenditure – Opex.

Hyperscaler rechnen pro Token – und das wird teuer

In klassischen Software-as-a-Service-Modellen (SaaS) sinken die Grenzkosten pro Nutzer oft massiv, je mehr Kunden man hat. Bei der KI-Inferenz bleibt dieser Effekt weitgehend aus: Ein Token kostet auf der GPU immer eine bestimmte Menge Energie und Zeit, egal ob es der erste oder der millionste Nutzer ist. Und wenn ein Geschäftsmodell vorsieht, dass Kunden eine Flatrate zahlen, ihre Cloud-Kosten für die KI-Antworten aber pro Anfrage abgerechnet werden, kann ein „zu aktiver“ Nutzer den Gewinn pro Kunde komplett auffressen.

Die großen Cloud-Anbieter wie AWS, Azure oder Google haben dies erkannt und ihre Preise daher an die Inferenz gekoppelt: Anwender zahlen meist nach dem „Pay-per-Token“-Prinzip, also in der Regel pro 1.000 generierte oder verarbeitete Token. Für Unternehmen ist es aber schwer vorhersagbar, wie viele Token ein Nutzer verbrauchen wird. Ein „gesprächiger“ Bot ist teurer als ein knapper – das macht die Budgetierung im Vergleich zu klassischen Cloud-Servern, wo man für die Laufzeit zahlt, hochkomplex.

Das Management der Inferenzkosten ist entsprechend kein vernachlässigbares technisches Detail, sondern vielmehr eine strategische Notwendigkeit. Wer die Inferenz nicht optimiert, riskiert, dass sein KI-Projekt mit zunehmendem Erfolg wirtschaftlich unrentabel wird. Hier braucht es unbedingt eine Kosten/Nutzen-Rechnung, die bei der Diskussion über den Einsatz von Neural Processing Units (NPUs), Application-Specific Integrated Circuits (ASICs) oder spezialisierten Chips wie AWS Inferentia und Google Tensor Processing Units (TPUs) beginnt.

Das Problem: universelle, ineffiziente GPUs

Anbieter wie Nvidia haben ihre universelle GPUs für das Training konzipiert. Sie sind darauf ausgelegt, gigantische Mengen an Daten gleichzeitig zu verarbeiten und komplexe mathematische Berechnungen für die Gewichtsoptimierung des Modells durchzuführen. Das bringt Nachteil bei der Inferenz mit sich: Wenn nur eine Antwort generiert werden muss, ist eine Hochleistungsmaschine wie die H100 oft unterfordert. Ein Großteil ihrer Architektur liegt brach, verbraucht aber trotzdem massiv Strom. Hinzu kommt, dass diese Chips einerseits sehr teuer, aufgrund des KI-Booms aber andererseits schwer zu bekommen sind. Sie für einfache Abfragen zu nutzen, ist daher ökonomisch gerade ineffizient.

Die neue Metrik: Effizienz beim Durchsatz

Entsprechend haben Unternehmen wie Amazon, Google und auch Start-ups wie Groq Chips entwickelt, die besagten ASICs, um die Kosten pro Abfrage zu senken. Ein Beispiel dafür ist der eigens und ausschließlich für die Inferenz gedachte und ebenfalls schon erwähnte AWS Inferentia. Er lässt alles weg, was man fürs Training braucht, und konzentriert sich nur auf das schnelle Ausgeben von Daten. Das senkt die Kosten pro Inferenz im Vergleich zu Standard-GPU-Instanzen um bis zu 40 Prozent.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Google versucht es mit den TPUs, die schon früh bei der Suche und Google Translate zum Einsatz kamen. Sie sind ziemlich effizient bei Matrix-Multiplikationen, dem Kern jeder KI-Antwort. NPUs finden sich dagegen oft in Laptops oder Smartphones, z.B. als Apple Neural Engine. Sie verbraucht deutlich weniger Strom pro KI-Rechenschritt als eine GPU.

Token-Ökonomie betrachten

In der Inferenz ist die wichtigste Währung nicht mehr die reine Rechenkraft in Form von Floating Point Operations Per Second (FLOPS), sondern der Durchsatz, es geht um Tokens pro Sekunde (TPS): Die Frage lautet, wie schnell ein Chip Text generieren kann. Ein spezialisierter Baustein ist oft in der Lage, mehr Tokens pro Sekunde zu liefern als eine universelle GPU, weil sein Speicherpfad genau auf das „Herauslesen“ des Modells optimiert ist.

Auch die aufgewendete Energie pro Token spielt eine große Rolle: Sie liefert die entscheidende Kennzahl für die Cloud-Anbieter. Wenn ein Chip für die gleiche Antwort nur zehn Prozent des Stroms einer GPU benötigt, kann der Anbieter den Dienst viel günstiger anbieten oder seine Marge erhöhen.

Hardware, Modelle und Betrieb gezielt wählen

Das alles führt zu einem architektonischen Wandel: Unternehmen, die ihre Inferenz-Workloads optimieren wollen, mieten in der Cloud nicht mehr einfach „eine GPU“. Sie wählen gezielt Instanzen, die auf spezialisierter Hardware wie Inferentia oder TPUs laufen. Anders gesprochen: Während die GPU der unangefochtene König des Trainings bleibt, findet in der Inferenz-Phase eine stille Revolution statt. Spezialisierte ASICs verdrängen den Alleskönner GPU, indem sie eine deutlich höhere Anzahl an Tokens pro investiertem Euro und Watt liefern.

Der gezielte Einsatz spezialisierter Hardware ist das eine, eine optimierte Strategie das andere: Dabei ist zunächst grundsätzlich an eine Modell-Komprimierung, gerne auch Quantisierung oder Destillation genannt, zu denken. Es geht dabei darum, wie Modelle optimiert, verkleinert oder simplifiziert werden können, um weniger Speicher und Rechenleistung zu benötigen.

Nehmen wir das Beispiel von Inferencing für Industriesteuerungen oder lokale Einzelhandelsanalyse: Hier könnte es ökonomisch sinnvoll sein, Inferenz-Workloads vom zentralen Cloud-Rechenzentrum auf Edge-Geräte oder in die eigene Rechenzentrums-Infrastruktur zu verlagern. Die Reduzierung der Latenz und der Abhängigkeit vom Cloud-Token-Pricing spielt prinzipiell in allen Industrial Internet-of-Things-Szenarien eine große Rolle.

Prompt-Strategie: Wortkarge sparen

Apropos Token-Pricing: In der Welt der Large Language Models ist ein Wort nicht einfach ein Wort, sondern eine Rechenoperation. KI-Modelle lesen keinen Text, sie lesen Tokens, also Zahlenrepräsentationen von Wortteilen. Dabei entsprechen 1.000 Tokens etwa 750 Wörtern. Anbieter wie OpenAI, Google oder AWS rechnen fast immer pro 1 Million Tokens ab. Je länger ein Eingabe-Prompt und je ausführlicher die Antwort, desto mehr Einheiten stehen auf der Rechnung.

Die Inferenz durchläuft dabei zwei Phasen, nämlich Input und Output. Während der Eingabe-Phase, auch „Prefill“ genannt, muss ein Modell den gesamten Kontext auf einmal „lesen“ und verstehen. Dabei steigt der Aufwand für die Berechnung der sogenannten „Attention“ – das ist die Aufmerksamkeit, die jedes Wort jedem anderen Wort im Text schenkt – bei Standard-Modellen quadratisch zur Länge des Inputs. Da dies sehr speicherintensiv ist, lassen sich die Cloud-Anbieter jedes einzelne Wort in einem Prompt bezahlen.

Ein mindestens genauso unerbittlicher Kosten-Treiber findet sich in der Ausgabe-Phase, also beim Decoding. Im Gegensatz zum Input, der auf einmal verarbeitet wird, generiert die KI nämlich die Antwort Token für Token nacheinander. Für jedes neue Wort muss das gesamte Modell erneut durchlaufen werden. Und je länger die Antwort, desto länger belegt eine Anfrage die wertvolle GPU. Zeit ist in der Cloud direkt Geld.

Hinzu kommt: Während die KI antwortet, muss sie sich an alles erinnern, was sie zuvor in diesem Gespräch von sich gegeben hat. Je länger der Prompt und die bisherige Antwort sind, desto größer wird der zwischenspeichernde Key-Value Cache. Und der belegt den extrem teuren und begrenzten VRAM-Grafikspeicher der GPU. Wenn der Speicher dann voll ist, kann die GPU kaum mehr Nutzer bedienen – die Effizienz sinkt, die Kosten für den Anbieter steigen. Und er wird diese über die Token-Preise an den Anwender weitergeben. In der Praxis sieht es dann so aus, dass in Preislisten z. B. von GPT-4o Output-Tokens oft das dreifache von Input-Tokens kosten.

Unternehmen können konkret Geld sparen, indem sie präzise Prompts schreiben. „Fasse diesen Text in drei Sätzen zusammen“ ist deutlich günstiger als „Schreibe eine ausführliche Analyse“. Auch müssen sie die System-Prompts optimieren: Viele Entwickler schicken bei jeder Anfrage hunderte Zeilen Anweisungen mit. Das summiert sich bei tausenden Nutzern zu gigantischen Summen. Grundsätzlich sollten nur wirklich relevante Informationen an die KI gesendet werden. Retrieval-Augmented Generation (RAG) fungiert hier als Kostenbremse: Der Einsatz von Vektordatenbanken reduziert die Notwendigkeit, große Kontextfenster an das LLM zu senden, was die API-Kosten senkt.

Softwareoptimierung mit FinOps für KI

Aktuell bringt der Markt jede Menge Tools hervor, die sich auf das Management und die Optimierung der Inferencing-Kosten konzentrieren. Wir befinden uns damit mitten in der Geburtsstunde einer neuen Kategorie von Software: AI FinOps, also Financial Operations für KI. Während man bislang vergleichsweise einfach eine API-Schnittstelle zu OpenAI oder Anthropic genutzt hat, bauen Unternehmen heute komplexe Architekturen dazwischen, um Kosten und Performance zu kontrollieren. Dafür stehen aktuell drei Ansätze mit entsprechenden Tools zur Verfügung:

1. AI Gateways & Model Routers

„Intelligente Gateways“ sind ein schnell wachsender Bereich. Anstatt eine Anfrage direkt an ein teures Modell wie GPT-4o zu schicken, schaltet man eine solche davor, um die Anfrage zu analysieren. Ist es eine simple Aufgabe wie etwa die Zusammenfassung eines Textes, leitet es sie an ein günstiges Modell, z. B. Llama 3 oder GPT-4o-mini, weiter. Komplexe Aufgaben gehen an ein teures Modell. An Tools stehen hier u.a. Martian bereit, ein Vorreiter beim Model Routing, der dynamisch das beste Preis-Leistungs-Verhältnis pro Prompt ermittelt. Portkey und Helicone offerieren Gateways, die Caching, Durchsatzbegrenzung und Kostenverfolgung in Echtzeit übernehmen. Das Open-Source-Tool LiteLLM bündelt hunderte KI-Modelle in einer einheitlichen Schnittstelle und ermöglicht Kosten-Tracking.

2. Observability & AI FinOps

Viele Unternehmen erschrecken bei der ersten Cloud-Rechnung für KI. Um unliebsame Überraschungen zu vermeiden, ist zu Observability- und AI FinOps-Tools zu raten. Sie machen die Kosten pro Nutzer, pro Projekt oder sogar pro Feature sichtbar. Sie hängen sich als Monitoring-Schicht in den Datenfluss und schlüsseln Token-Verbräuche präzise auf. Sie helfen dabei, „verschwenderische“ Prompts oder Endlosschleifen von Agenten zu identifizieren. Beispiele dafür wären etwa LangSmith von LangChain, das ursprünglich mal für das Debugging gedacht war. Oder Arize Phoenix und Weights & Biases – beide kommen aus dem Machine Learning-Umfeld und wurden für die Überwachung von Inferenz-Kosten und Modelldrift ausgebaut.

3. Inference Engines & Serving Frameworks

Bei Inference Engines & Serving Frameworks geht es nicht um das Management, sondern um die technische Senkung der Kosten pro Token. Tools optimieren, wie ein Modell im VRAM-Grafikspeicher liegt, und wie Anfragen gebündelt werden, Stichwort Continuous Batching and PagedAttention. An Werkzeugen steht zum Beispiel vLLM bereit, ein leistungsfähiges Open-Source-Framework, das die Zahl der Tokens pro Sekunde massiv erhöht und damit die benötigte Anzahl an GPUs halbiert. Nvidias TensorRT-LLM schaltet die Ausführung von Sprachmodellen auf Nvidia-Grafikkarten in den „Turbo-Modus“. Unify bietet eine Plattform, die das gleiche Modell bei verschiedenen Cloud-Anbietern testen und automatisch den Anbieter wählen kann, der gerade die niedrigste Latenz zum kleinsten Preis bietet.

Die Ära der naiven API-Nutzung ist vorbei

Damit können wir zum Schluss kommen: Die „Ära der naiven API-Nutzung“ – ein Zitat des letztgenannten Tool-Anbieters – ist vorbei. Ein professioneller Cloud-Architekt baut heute keine KI-Anwendung mehr ohne eine Orchestrierungsschicht, die erstens cacht, zweitens routet und drittens überwacht. Dann halten die Cloud-Budgets hoffentlich mit der Inferenz von KI-Modellen mit.

(ID:50692952)