Von DataTip · Veröffentlicht am 1. September 2026

Ein KI-Workload sollte nicht einfach deshalb skalieren, weil Nutzer ihn annehmen. Die wichtigere Frage ist, ob jede zusätzliche Anfrage genug Wert schafft – durch Umsatz, Servicequalität, eingesparte Arbeit oder reduziertes Risiko –, um ihre Inferenzkosten zu rechtfertigen. KI-Inferenzkosten: Erst ein Ergebnisbuch führen, dann die Nutzung skalieren beginnt bei dieser Entscheidung und nicht bei einem günstigeren Modell.

KI-Inferenzkosten werden ebenso von Token-Volumen, Anfragestruktur und Architektur bestimmt wie von den nominalen Modellpreisen. Führungskräfte sollten Input-, Output-, Cache-, Reasoning- und Batch-Nutzung je Feature oder Aufgabe erfassen und diese Stückkosten mit dem gelieferten Wert verknüpfen. ProjectDiscovery hat gezeigt, wie die Umstrukturierung des Prompt-Speichers und Cache-Steuerungen die Wirtschaftlichkeit verändert haben – ohne Änderungen an Modellen, Features oder Traffic.

ProjectDiscovery ist ein aufschlussreiches Beispiel. Das Unternehmen hinter dem Open-Source-Sicherheitsscanner Nuclei berichtete, dass seine Cache-Trefferquote von 7 % auf 74 % und anschließend auf 84 % stieg, nachdem es die Paketierung des Prompt-Speichers geändert und explizite Cache-Steuerungen eingeführt hatte. Über 9,8 Milliarden gecachte Tokens hinweg senkten diese Änderungen die gesamten LLM-Kosten um 59 % bis 70 %. Modelle, Features und Traffic blieben gleich. Verändert hat sich die Struktur der Anfragen.

Das ist die praktische Lehre zu Inferenzkosten: Der nominale Token-Preis zählt, aber Volumen, Anfragestruktur und architektonische Standardeinstellungen zählen oft mehr. Bevor Sie mehr Nutzung freigeben, brauchen Sie ein Ergebnisbuch, das den Verbrauch mit der Arbeit verknüpft, die das System tatsächlich leistet.

Was ist LLM-Inferenz, und warum verursacht sie laufende Kosten?

LLM-Inferenz ist der Laufzeitprozess, in dem ein trainiertes Modell einen Prompt Token für Token auf Beschleuniger-Hardware in eine Antwort umwandelt. Training erzeugt das Modell einmal; Inferenz führt es immer wieder aus – für jede Anfrage, jeden Nutzer, jedes Feature und jeden automatisierten Workflow.

Diese Unterscheidung ist für die Planung wichtig. Training wird meist als einmalige Investition behandelt. Inferenz ist ein Betriebsaufwand, der mit der Nutzung wächst. Mehr Nutzer, mehr Produktfeatures und mehr agentische Workflows können den Verbrauch erhöhen – so kann ein erfolgreiches KI-Feature mit der Zeit eine höhere Inferenzrechnung anhäufen als das ursprüngliche Modelltraining.

Die geschäftliche Entscheidung lautet daher nicht einfach, ob ein Modell teuer ist. Sondern ob die wiederkehrenden Kosten des Workloads in einem angemessenen Verhältnis zu seinem gelieferten Ergebnis stehen. Ein Feature, das die Servicequalität verbessert, kann seinen Verbrauch rechtfertigen; ein Feature, das Aktivität ohne messbaren Nutzen erzeugt, womöglich nicht.

Ein Ergebnisbuch sollte diesen Unterschied sichtbar machen. Mindestens sollte es jedem Workload Folgendes zuordnen:

• Das Feature, die Customer Journey oder den operativen Prozess, den er unterstützt
• Die verbrauchten Tokens und die verwendete Modellkonfiguration
• Das relevante Ergebnis, etwa Umsatz, Servicequalität, eingesparte Arbeit oder reduziertes Risiko
• Die verantwortliche Person, die prüft, ob die weitere Nutzung gerechtfertigt ist

Wie entsteht eine Inferenzrechnung bei tokenbasierter Abrechnung?

Die Inferenzabrechnung basiert auf Tokens – kleinen Textstücken, die im typischen englischen Sprachgebrauch etwa drei Viertel eines englischen Wortes entsprechen. Anbieter nennen in der Regel getrennte Preise für Input-Tokens und Output-Tokens, sodass die Rechnung davon abhängt, was Sie an das Modell senden und was es erzeugt.

Zum Input gehören der Prompt, Systemanweisungen, Gesprächsverlauf, abgerufene Dokumente und weiterer Kontext. Output ist die vom Modell generierte Antwort. Output kostet typischerweise etwa das Fünffache des Input-Preises – unnötige Ausführlichkeit ist daher ein wiederkehrendes Kostenproblem und kein einmaliges Detail.

Um den Zähler zu verstehen, hilft es, die wichtigsten Abrechnungskategorien zu trennen:

• Standard-Input: Der gewöhnliche Prompt und Kontext, der mit einer Anfrage gesendet wird.
• Standard-Output: Die für den Nutzer oder das aufrufende System generierte Antwort.
• Gecachter Input: Wiederverwendete Prompt-Inhalte, die nach den Regeln des Anbieters für einen niedrigeren Preis für gecachten Input infrage kommen.
• Reasoning-Tokens: Interne Modellarbeit, die als Output abgerechnet werden kann, auch wenn der Nutzer das Reasoning nie sieht.
• Batch-Verarbeitung: Arbeit, die – sofern unterstützt – zu Batch-Konditionen eingereicht wird, für Workloads, die keine sofortige Antwort erfordern. Diese Kategorien wirken sich nicht auf jeden Workload gleich aus. Ihre effektiven Token-Kosten sind ein Mischwert, gewichtet nach der Architektur: wie viel Kontext wiederholt wird, wie lang die Ausgaben sind, ob Reasoning aktiviert ist und ob Arbeit im Batch laufen kann.

Deshalb ist die Modellauswahl allein ein schwacher Kostenkontrollmechanismus. Zwei Teams können dasselbe Modell nutzen und sehr unterschiedliche Rechnungen erhalten, weil das eine langen abgerufenen Kontext sendet, mehrere Aufrufe auslöst oder Caching verhindert und das andere nicht.

Warum erzeugen einfache, Retrieval- und agentische Aufgaben unterschiedliche Rechnungen?

Die Anzahl der Aufgaben reicht nicht aus, um Inferenzkosten vorherzusagen. Die Aufrufe innerhalb jeder Aufgabe, die Größe des Kontexts und die Menge des generierten Outputs bestimmen, wie viel Arbeit das Modell leistet.

Die Quelle nennt drei beispielhafte Workloads auf Basis eines gemischten Standardpreises. Das genaue monetäre Ergebnis hängt von den geltenden Anbieterpreisen ab – entscheidend ist daher der Vergleich der Verbrauchsmuster:

• Einfache Chat-Antwort: 500 Input-Tokens und 300 Output-Tokens pro Aufgabe
• RAG-Abfrage mit abgerufenem Kontext: 6.000 Input-Tokens und 500 Output-Tokens pro Aufgabe
• Agentische Aufgabe mit 12 verketteten Aufrufen: 60.000 Input-Tokens und 15.000 Output-Tokens pro Aufgabe Bei gleichem Aufgabenvolumen verbraucht der agentische Workflow drastisch mehr Tokens als die einfache Chat-Interaktion. Eine auf Retrieval basierende Antwort liegt dazwischen, weil das System zusätzlichen Kontext sendet, auch wenn die sichtbare Antwort relativ kurz bleiben kann.

Hier wird ein Ergebnisbuch nützlich. Statt aggregierte monatliche Tokens zu prüfen, prüfen Sie die Kosten pro Feature, Kunde oder Aufgabe und vergleichen sie mit dem Ergebnis, das den Workload rechtfertigt. Kostet eine agentische Aufgabe mehr, weil sie wertvolle Arbeit erledigt, kann das ein sinnvoller Kompromiss sein. Erzeugen die zusätzlichen Aufrufe nur interne Aktivität, verdient ihre Skalierung eine genaue Prüfung.

Warum können die gesamten Inferenzkosten steigen, während die Token-Preise sinken?

Günstigerer Modellzugang kann den Gesamtverbrauch erhöhen, statt die Gesamtkosten zu senken. Dieses Muster ist als Jevons-Paradoxon bekannt: Wenn ein Einsatzfaktor billiger wird, wird er oft stärker genutzt, und der Anstieg der Nutzung kann den niedrigeren Stückpreis übertreffen.

Inferenz folgt diesem Muster, wenn Teams KI in mehr Workflows einbauen, Kontextfenster vergrößern, mehrstufige Agenten einführen oder Modelle auf Aufgaben ansetzen, die bisher gar nicht automatisiert waren. Niedrigere Preise machen solche Entscheidungen leichter genehmigungsfähig, beweisen aber nicht, dass der neue Verbrauch Wert schafft.

Deshalb sind sinkende Token-Preise für sich genommen keine Kostenstrategie. Sie sind Rückenwind, den Sie nur nutzen, wenn Sie sehen, wo und warum die Nutzung wächst. Stückkosten sind die belastbarere Steuerungsgröße, weil sie den Verbrauch mit dem Feature, dem Kunden oder der Aufgabe verknüpfen, die davon profitiert.

Stellen Sie eine härtere Frage als „Was haben wir ausgegeben?“. Fragen Sie: Was hat jede Einheit Inferenz bewirkt? Ohne diese Verknüpfung kann aggregierte Nutzung wie Produktdynamik aussehen und dabei Workloads mit schwacher Wirtschaftlichkeit verdecken.

Was hat ProjectDiscovery an seiner Inferenz-Wirtschaftlichkeit geändert?

Das dokumentierte Ergebnis von ProjectDiscovery zeigt, dass die Paketierung von Prompts die Inferenzkosten erheblich beeinflussen kann, ohne Modelle, Features oder Traffic zu ändern. Die anfängliche Cache-Trefferquote lag bei 7 %, weil dynamischer Arbeitsspeicher im System-Prompt lag und das cachebare Präfix bei fast jedem Schritt ungültig machte.

Das Team verlagerte diesen dynamischen Arbeitsspeicher aus dem System-Prompt heraus und steigerte die Cache-Trefferquote damit in einem Deployment auf 74 %. Anschließend fügte es explizite Cache-Breakpoints und bewusst gewählte Time-to-Live-Einstellungen hinzu und erreichte 84 %.

Bevor Sie die Nutzung skalieren, untersuchen Sie die Mechanik hinter der Rechnung:

• Kommen wiederholte Anweisungen und Kontexte für Caching infrage?
• Macht sich ändernder Arbeitsspeicher ein wiederverwendbares Präfix ungültig?
• Sind die Ausgaben länger, als der Anwendungsfall erfordert?
• Ist Reasoning dort aktiviert, wo sein zusätzlicher Aufwand nicht bewertet wurde?
• Können nicht dringende Workloads Batch-Verarbeitung nutzen?
• Liefert ein Workflow mit mehreren Aufrufen ein Ergebnis, das seinen kumulierten Verbrauch rechtfertigt? Das ist Governance, nicht bloß Optimierung. Teams müssen wissen, welche Architekturentscheidungen den Verbrauch verändern, welche Ergebnisse sie rechtfertigen und wer einen Workload stoppen oder neu gestalten kann, wenn die Wirtschaftlichkeit nicht mehr trägt.

Wie sollten Führungskräfte ein Ergebnisbuch vor dem Skalieren nutzen?

Beginnen Sie beim Workload, nicht beim Anbieterkatalog. Erfassen Sie für jedes wichtige KI-Feature den Input- und Output-Verbrauch, das Cache-Verhalten, den Reasoning-Modus, die Anzahl der Aufrufe und den geschäftlichen Zweck.

Das Ergebnisbuch sollte stattdessen eine Entscheidung unterstützen: skalieren, neu gestalten, zurückstellen oder einstellen. Diese Entscheidung wird belastbar, wenn Finanzen, Produkt, Engineering und Betrieb beide Seiten der Gleichung sehen – was die Inferenz kostet und was der Workload liefert.

Die wichtigsten Erkenntnisse

• Prüfen Sie die Stückkosten pro Feature, Kunde oder Aufgabe, nicht nur den gesamten Token-Verbrauch.
• Behandeln Sie Input und Output als getrennte Kostentreiber; generierter Output ist typischerweise teurer.
• Erfassen Sie gecachten Input, Reasoning-Tokens und Batch-Nutzung als eigene Abrechnungskategorien.
• Untersuchen Sie die Prompt- und Speicherstruktur, bevor Sie annehmen, dass ein günstigeres Modell das Problem löst.
• Skalieren Sie nur, wenn das gelieferte Ergebnis des Workloads seinen wiederkehrenden Inferenzverbrauch trägt.

Praktische Tipps

• Weisen Sie Input- und Output-Tokens im operativen Reporting getrennt aus; zusammengefasst verbergen sie die teurere generierte Arbeit.
• Nehmen Sie Cache-Trefferquote und Cache-Invalidierung in Workload-Reviews auf, besonders wenn System-Prompts sich ändernden Arbeitsspeicher enthalten.
• Halten Sie fest, ob der Reasoning-Modus aktiviert ist, damit ein unerklärter Anstieg des abgerechneten Outputs untersucht werden kann.
• Klassifizieren Sie Workloads nach Dringlichkeit der Antwort; Batch-Verarbeitung kann für Arbeit relevant sein, die keine sofortigen Antworten erfordert.
• Wenn Sie ein Ergebnis zur Kostensenkung prüfen, vergleichen Sie Modelle, Features, Traffic und Architektur des Workloads, damit Einsparungen nicht dem falschen Hebel zugeschrieben werden.

Machen Sie KI-Verbrauch überprüfbar

Nutzen Sie ein Ergebnisbuch, um Engineering, Produkt, Finanzen und Betrieb eine gemeinsame Sicht darauf zu geben, was jeder KI-Workload kostet und was er liefert.

KI-BEARBEITET