KI-Inferenzkosten, nicht das Training, verändern die Ökonomie des Modell-Servings

Die Kosten für einen Trainingslauf eines Frontier-Modells sind eine Zahl, die Journalisten gerne zitieren — Hunderte von Millionen Dollar, Zehntausende von GPUs, Monate an Rechenzeit. Für die meisten KI-Unternehmen ist das jedoch die falsche Zahl, über die man sich Sorgen machen sollte. Training findet einmal statt (oder ein paar Mal im Jahr, für ein Update). Inferenz findet bei jeder einzelnen Nutzeranfrage statt, für immer, und skaliert mit dem Erfolg: Je besser ein Produkt läuft, desto teurer wird der Betrieb. Das kehrt einen Teil der Ökonomie um, der den größten Teil der Softwaregeschichte geprägt hat, in dem die Grenzkosten für die Bedienung eines weiteren Nutzers nahezu null waren.

Deshalb ist Inferenz, nicht Training, der Posten, der tatsächlich verändert, wie KI-Unternehmen 2026 Produkte bauen. Die Unternehmen, die bei der Einheitsökonomie gewinnen, sind nicht notwendigerweise die mit dem besten Modell — es sind die, die die Kosten für die Beantwortung einer einzelnen Anfrage am stärksten gesenkt haben, durch eine Reihe von Techniken, die inzwischen ausgereift genug sind, um Standardpraxis zu sein statt Forschungskuriositäten.

Die Rechnung, die Inferenz teuer macht

Ein Forward Pass eines Transformers kostet etwa 2 × Parameteranzahl × verarbeitete Tokens an Gleitkommaoperationen. Training kostet pro Token etwa das Dreifache davon, weil es zusätzlich einen Backward Pass und ein Gradienten-Update ausführt — aber Training findet für eine feste, begrenzte Anzahl von Tokens statt. Inferenz hat keine solche Grenze; sie skaliert mit jeder Anfrage jedes Nutzers, unbegrenzt. Ein Modell, das eine Milliarde Anfragen pro Tag bedient, verbraucht in wenigen Wochen mehr kumulierte Rechenleistung, als sein Training in Monaten verbraucht hat, sobald ein Produkt echte Nutzung erfährt.

Die Kontextlänge verschärft das Problem. Der Key-Value-Cache (KV-Cache), den ein Transformer während der Generierung vorhält, wächst mit Sequenzlänge × Anzahl der Schichten × Anzahl der Attention-Köpfe × Dimension pro Kopf × Batchgröße. Wenn Kontextfenster von 8K auf 128K oder mehr ausgedehnt werden — was Produkte inzwischen routinemäßig tun — wächst der benötigte Speicher pro gleichzeitiger Anfrage entsprechend, was begrenzt, wie viele Anfragen eine gegebene GPU gleichzeitig bedienen kann. Diese Obergrenze bestimmt tatsächlich die Kosten pro Anfrage, mehr als die reinen FLOPs.

Die Techniken, die wirklich Kosten senken

Quantisierung ist der direkteste Hebel: Inferenz in FP8 oder INT8 statt FP16/BF16 auszuführen, halbiert etwa den Speicherbandbreitenbedarf und kann den Durchsatz auf derselben Hardware verdoppeln oder mehr, bei sorgfältig kontrolliertem Genauigkeitsverlust. INT4 geht für Modelle, bei denen der Genauigkeitsverlust tolerierbar ist, noch weiter.

Mixture-of-Experts-Architekturen (MoE) verändern, was "Modellgröße" für die Kostenfrage überhaupt bedeutet. DeepSeek-V3 hat insgesamt 671 Milliarden Parameter, aktiviert aber nur etwa 37 Milliarden pro Token — man bezahlt Rechenleistung für die aktive Teilmenge, nicht für das gesamte Modell. Das ist der Hauptgrund, warum MoE-Modelle Frontier-Fähigkeiten zu einem Bruchteil der Inferenzkosten eines dichten Modells mit vergleichbarer Gesamtparameterzahl bieten können.

Attention-Varianten greifen das KV-Cache-Problem direkt an. Grouped-Query Attention (GQA), verwendet in Llama 3 und vielen aktuellen Modellen, teilt Key/Value-Projektionen über Gruppen von Attention-Köpfen hinweg, statt jedem Kopf seine eigene zu geben, was die KV-Cache-Größe um ein Mehrfaches mit minimalem Qualitätsverlust reduziert. DeepSeeks Multi-Head Latent Attention (MLA) komprimiert den Cache weiter, indem Keys und Values vor dem Caching in einen kleineren latenten Raum projiziert werden.

Spekulative Dekodierung fügt ein kleines, schnelles "Entwurfsmodell" hinzu, das mehrere Tokens im Voraus vorschlägt, die das vollständige Modell dann parallel verifiziert, statt ein Token nach dem anderen zu generieren. Wenn das Entwurfsmodell richtig rät — was bei alltäglichem Text oft genug vorkommt — senkt das Latenz und GPU-Zeit pro Ausgabe-Token um etwa die Hälfte bis zwei Drittel, ohne Qualitätsverlust bei der Ausgabe (das große Modell hat weiterhin das letzte Wort bei jedem Token).

Auf der Seite der Serving-Infrastruktur erlauben kontinuierliches Batching und paginiertes KV-Cache-Management — die Technik, die vLLM als PagedAttention populär gemacht hat — einem Server, deutlich mehr gleichzeitige Anfragen in denselben GPU-Speicher zu packen, indem die Cache-Zuweisung wie ein virtuelles Speichersystem verwaltet wird, statt für jede Anfrage einen festen Worst-Case-Block zu reservieren. Das ist ein reiner Infrastrukturgewinn: gleiches Modell, gleiche Hardware, deutlich mehr Durchsatz.

Routing: das teure Modell nur bei Bedarf einsetzen

Eine andere Strategie verzichtet darauf, die Inferenz eines einzelnen Modells zu optimieren, und optimiert stattdessen, welches Modell jede Anfrage beantwortet. Eine Routing-Schicht schickt einfache Anfragen mit hoher Konfidenz an ein billiges, schnelles Modell und eskaliert nur wirklich schwierige Anfragen an ein teures Frontier-Modell. Produkte, die so aufgebaut sind, berichten von durchschnittlichen Kosten pro Anfrage, die deutlich unter dem liegen, was es kosten würde, jede Anfrage durch das Top-Modell laufen zu lassen, weil die meisten realen Anfragen keine Frontier-Modell-Logik benötigen — sie brauchen eine korrekte, schnelle Antwort.

Die finanziellen Schwierigkeiten von Character.AI — das Unternehmen meldete am 13. Oktober 2026 Insolvenz nach Chapter 11 an — sind ein nützliches Fallbeispiel dafür, was passiert, wenn dies nicht gelöst wird. Ein Chat-Produkt erzeugt ein enormes Inferenzvolumen pro Nutzer (lange, häufige Hin-und-her-Gespräche), und wenn die Inferenzkosten pro Nachricht nicht aggressiv genug im Verhältnis zu dem gesenkt werden, was Nutzer zahlen oder was Werbung einbringt, geht die Einheitsökonomie einfach nicht auf, egal wie groß die Nutzerbasis wird.

Spezialisierte Inferenz-Hardware

Allzweck-GPUs bleiben die Standardwahl, aber dedizierte Inferenz-Silizium-Lösungen — Groqs LPU, Cerebras' Wafer-Scale-Engine, SambaNovas Dataflow-Architektur — tauschen Trainingsflexibilität gegen geringere Latenz und geringere Kosten pro Token bei reinen Inferenz-Workloads. Das zählt am meisten bei Anwendungen mit hohem Volumen und Latenzempfindlichkeit (Sprachassistenten, Echtzeit-Coding-Tools), bei denen das Einsparen von Millisekunden und Cents pro Anfrage in riesigem Maßstab die Flexibilität eines Allzweck-Beschleunigers übertrifft.

Praktische Schlussfolgerungen

Wenn Sie ein Produkt auf einer LLM-API aufbauen, verfolgen Sie die Kosten pro 1.000 Ausgabe-Tokens als zentrale Einheitsökonomie-Kennzahl, nicht die Kosten pro Anfrage — das schleichende Wachstum der Kontextlänge ist der stille Margenkiller. Legen Sie ein festes Kontextlängen-Budget pro Feature fest, statt es unkontrolliert wachsen zu lassen. Verwenden Sie standardmäßig ein billiges, schnelles Modell und eskalieren Sie nur bei erkannter Unsicherheit oder expliziter Nutzeranfrage nach tieferer Argumentation zu einem teuren Modell. Und wenn Sie API-Anbieter bewerten, fragen Sie direkt nach deren Quantisierungs-, MoE- und Caching-Strategie — ein Anbieter, der FP8-MoE-Inferenz mit KV-Cache-bewusstem Batching betreibt, kann bei exakt derselben nominellen Modellqualität deutlich günstiger sein als einer, der das nicht tut.