Quality-adjusted inference cost: Warum der Tokenpreis täuscht

Ein günstiges Modell kann die teure Wahl sein.

Das klingt zunächst widersprüchlich – bis ein KI-System mehr tun muss, als einen einzelnen Prompt zu beantworten. Ein Agent kann mehrere Modellaufrufe ausführen, Tools aufrufen, Fehler behandeln, eine Aufgabe erneut versuchen und eine wachsende Gesprächshistorie in spätere Turns mitnehmen. Scheitert er, ist dieser Aufwand trotzdem angefallen. Ein Tokenpreis sagt dir, was eine Einheit Modelleingabe oder -ausgabe kostet. Er sagt nicht, wie viel du ausgeben musst, um ein Arbeitsergebnis zu erhalten, das dein System tatsächlich akzeptieren kann.

Genau darum geht es bei Quality-adjusted inference cost: den Ressourcenaufwand zu messen, der nötig ist, um ein Ergebnis mit einem festgelegten Qualitätsstandard zu erzeugen. Dafür findest du auch Bezeichnungen wie Cost per successful task, Cost per correct answer, Cost per accepted outcome oder Cost-of-pass. Die Begriffe sind nicht einheitlich, die Engineering-Frage schon: Was hat ein erfolgreiches Ergebnis wirklich gekostet?

AWS hat diese Frage in einem am 11. September veröffentlichten Benchmarking-Harness konkret umgesetzt. Die Evaluation misst Cost per correct answer, Agent trajectory cost und per Rubrik bewertete professionelle Ergebnisse; dabei bleibt die Evaluierungslogik über die getesteten Model Backends hinweg gleich. Die Beschreibung des Harness durch AWS ist gerade deshalb relevant, weil sie einen Agentenlauf als vollständigen Ausführungspfad behandelt – nicht als einzelnen Inference-Request.

Einfach gesagt: Frage nicht, welches Modell den günstigsten Request erzeugt. Frage, welche Konfiguration akzeptierte Arbeit mit dem geringsten Gesamtaufwand liefert.

Der Nenner ist entscheidend

Die einfachste Form ist ein Verhältnis:

gesamte direkt zurechenbare Ausführungskosten / Anzahl akzeptierter Ergebnisse

Der Zähler enthält jeden Versuch, auch fehlgeschlagene. Der Nenner enthält nur Ergebnisse, die die Annahmeregel bestanden haben. Angenommen, Konfiguration A kostet pro Lauf wenig, ist aber selten erfolgreich, während Konfiguration B pro Lauf teurer ist, aber deutlich häufiger gelingt. Dann kann A leicht die höheren Kosten pro akzeptiertem Ergebnis haben.

Bei unabhängigen Wiederholungsversuchen ist eine nützliche Näherung: Kosten eines einzelnen Versuchs geteilt durch die Erfolgswahrscheinlichkeit. Das ist eine Näherung, kein Naturgesetz: Retries scheitern oft aus verwandten Gründen. Eine fehlerhafte Tool-Integration, fehlende Berechtigungen, eine mehrdeutige Aufgabe oder eine kaputte Retrieval-Quelle können Fehler korrelieren lassen. Dann erhöht ein bloßer Retry die Kosten, ohne die Chance auf einen Pass wesentlich zu steigern.

Die Metrik ist wichtig, weil ein KI-Service selten Token um ihrer selbst willen einkauft. Er kauft Incident-Zusammenfassungen, die korrekt genug fürs Routing sind, Migrationspläne, die eine Review-Rubrik erfüllen, bestandene Tests oder nach Review akzeptierte Änderungen. OpenAI beschreibt Cost per successful task ebenfalls als abhängig von Preis, Rechenaufwand und der Wahrscheinlichkeit, das korrekte Ergebnis zu erreichen. Die Hinweise zu unabhängigen Evaluierungen empfehlen, bei messbarem Erfolg die erwarteten Kosten pro erfolgreichem Solve über wiederholte Versuche zu berücksichtigen, statt nur eine Erfolgsrate bei einem festen Tokenbudget zu berichten. OpenAIs Scorecard und die Hinweise zu Evaluierungen vertreten damit denselben Grundgedanken: Leistung und Aufwand gehören in dieselbe Entscheidung.

Erfolg definieren, bevor du Kosten misst

Die schwierige Aufgabe ist nicht die Division. Sie besteht darin, festzulegen, was „erfolgreich“ bedeutet, ohne versehentlich auf das falsche Ziel zu optimieren.

Beginne mit einem Ergebniskriterium, das von der Kostenmessung unabhängig ist. Für einen Code-Maintenance-Workflow könnte Erfolg heißen, dass eine deterministische Testsuite und erforderliche statische Checks bestehen und ein Reviewer die Änderung akzeptiert. Für einen Support-Workflow könnte es bedeuten, dass eine Antwort notwendige Fakten enthält, keine Richtlinie verletzt und eine menschliche oder rubrikbasierte Bewertung besteht. Ein Rubric-based grader ist ein strukturierter Kriterienkatalog zur Beurteilung einer Ausgabe; er ist hilfreich, wenn es keine einzige deterministisch richtige Antwort gibt.

Erfasse anschließend die vollständigen Kosten jedes Versuchs. Dazu gehören typischerweise Input- und Output-Token, gegebenenfalls Reasoning-Aufwand, Tool-Ausführung, Retries und andere dem Lauf direkt zurechenbare Ressourcen. Breitere Betriebskosten solltest du zunächst getrennt halten. Engineering-Zeit, Plattform-Hosting, Aufsicht, Integration und Incident-Bearbeitung sind reale Kosten, doch sie zu früh einzurechnen kann verdecken, welches Agentenverhalten sich verändert hat. Sie gehören später in eine umfassendere Analyse der Total cost of ownership.

Zeichne danach den Ausführungspfad auf, nicht nur die endgültige Antwort. Die Trajectory eines Agenten umfasst Turns, Tool-Calls, Retries, Wiederherstellungsverhalten, Latenz und Context-Wachstum. AWS evaluiert mehrstufige Web-Research-Trajectories und weist darauf hin, dass clientseitig verwaltete Histories in späteren Turns angesammelten Context erneut senden können. Damit werden Turn-Anzahl und Umfang des bisherigen Context zu wesentlichen Kostentreibern, nicht zu harmlosen Implementierungsdetails. AWS erläutert diesen Context-Effekt hier.

Einfach gesagt: Ein erfolgreiches Endergebnis kann einen ineffizienten Weg verbergen. Zeichne den Weg auf, denn wiederholter Context, Umwege und Retries stehen alle auf der Rechnung.

Vergleiche Konfigurationen schließlich bei einer ausdrücklich benannten Annahmeschwelle. Die richtige Wahl ist häufig die günstigste Konfiguration, die die verlangten Ziele für Qualität, Latenz und Zuverlässigkeit erreicht. Sie ist nicht automatisch das billigste Modell, das Modell mit dem höchsten Score oder das Modell mit den niedrigsten durchschnittlichen Request-Kosten.

Was das nicht ist

Quality-adjusted inference cost liegt neben mehreren nützlichen Metriken, ersetzt sie aber nicht alle.

Es ist nicht Token pricing. Token pricing ist ein Grenzpreis für Modell-Input oder -Output. Er hilft beim Schätzen eines Requests, kann aber weder erfassen, ob ein Modell ein gültiges Ergebnis erreicht, wie viele Turns es braucht, noch wie oft es erneut versuchen muss.

Es ist auch nicht der Durchschnittspreis pro Request. Dieser Durchschnitt vermischt bestandene und fehlgeschlagene Arbeit – genau das kann die schwachen Ergebnisse einer scheinbar günstigen Konfiguration verdecken. Ebenso wenig ist es eine Pass rate. Eine Pass rate zeigt, wie oft etwas funktioniert hat, nicht aber, ob dafür eine lange und teure Trajectory nötig war.

Auch Trajectory cost allein genügt nicht. Diese Metrik zeigt, was ein bestimmter Pfad verbraucht hat. Quality-adjusted cost stellt die zusätzliche, für Produktionsverantwortliche entscheidende Frage: Hat dieser Pfad ein akzeptiertes Ergebnis geliefert? Schließlich ist die Kennzahl enger als Total cost of ownership. Sie ist eine Ausführungsmetrik auf Workload-Ebene, kein vollständiges Finanzmodell für ein KI-Produkt.

Ein praktisches Engineering-Beispiel

Betrachte einen hypothetischen internen Agenten, der Pull Requests für eine routinemäßige Service-Migration vorbereitet. Er liest ein Repository, schlägt Änderungen vor, führt verfügbare Checks über Tools aus und erstellt eine Zusammenfassung für eine erfahrene Entwicklerin oder einen erfahrenen Entwickler.

Ein sinnvolles Evaluierungsset enthält repräsentative Migrationsaufgaben: einfache Änderungen, Aufgaben mit inkompatiblen Dependencies und Fälle, in denen die richtige Reaktion darin besteht, anzuhalten und einen Blocker zu erklären. Definiere den Pass vor dem Modellvergleich: Die Änderung muss verfügbare deterministische Checks erfüllen; die Zusammenfassung muss geänderte Dateien und Restrisiken benennen; und Reviewer müssen sie anhand einer festen Rubrik als akzeptabel bewerten.

Pro Versuch protokollierst du Modell-Input und -Output, Tool-Calls, Tool-Fehler, Anzahl der Retries, Laufzeit und die Context-Menge in jedem Turn. Außerdem protokollierst du das abschließende Annahmeergebnis und den Ablehnungsgrund. Lasse jedes Kandidatenmodell und jede Policy über dieselbe Aufgabenmenge laufen. Eine Policy sind hier die Betriebsregeln um das Modell: sein Prompt, ob es Retries nutzen darf, wann es ein Tool aufruft und wie es Context verwaltet.

Stell dir vor, eine Konfiguration erzeugt günstige erste Versuche, gerät aber nach einem fehlgeschlagenen Test häufig in Schleifen und sendet wiederholt Repository-Material. Eine andere kostet beim ersten Versuch mehr, stoppt aber nach einer gezielten Diagnose und liefert häufiger akzeptierte Patches. Durchschnittliche Request-Kosten können die erste Konfiguration bevorzugen. Kosten pro akzeptierter Migration können die zweite bevorzugen. Der Trace zeigt auch warum: Der günstige Start der ersten Konfiguration übersteht ihre Retries und ihren wachsenden Context nicht.

Dieses Setup ermöglicht zudem besseres Routing. Einfache Migrationen könntest du an die günstigere Konfiguration senden und Fälle mit bestimmten Dependency-Mustern an die stärkere weiterleiten. Erkläre Routing jedoch nicht aufgrund eines Durchschnitts voreilig zum Erfolg. Evaluiere die gemischte Policy nach denselben Annahmekriterien und prüfe, ob sie ihre Latenz- und Zuverlässigkeitsgrenzen einhält.

Einfach gesagt: Miss den gesamten Workflow an Arbeit, die wirklich zählt. Dann siehst du, ob eine niedrigere Modellrechnung Geld spart oder nur mehr fehlgeschlagene Läufe einkauft.

Wo die Metrik scheitert

Ein präzises Verhältnis kann falsche Sicherheit erzeugen. Seine größte Schwäche ist das Annahmekriterium. Belohnt ein Grader oberflächliche Antworten, kann ein niedriger Cost per success lediglich zeigen, dass das System einen schwachen Test erfüllt. Binäre Pass/Fail-Regeln können zudem bedeutsame Qualitätsunterschiede oberhalb der Schwelle verdecken. Ergänze Rubrik-Scores, Ergebnisse aus Human Review, nachgelagerte Nacharbeit oder getrennte Sicherheitschecks, wenn diese Unterschiede wichtig sind.

Aggregate können unterschiedliche Aufgabenpopulationen verbergen. Ein Modell kann bei einfachen Repository-Edits ausgezeichnet und bei Dependency-Änderungen unzuverlässig sein. Berichte deshalb nach Aufgabenfamilie, Schwierigkeit, Fehlermodus und gegebenenfalls Nutzersegment, statt nur ein Verhältnis für das gesamte Portfolio zu veröffentlichen. Kleine Samples sind besonders gefährlich, wenn Pass rates niedrig sind oder zwei Kandidaten nah beieinander liegen. Wiederholte Läufe und Unsicherheitsschätzungen sind nötig, bevor du eine folgenreiche Beschaffungs- oder Architekturentscheidung triffst.

Vergleiche hängen von der Deployment-Umgebung ab. Andere Reasoning-Einstellungen, Context-Limits, Tool-Implementierungen, Caching, Regionen, Provider-Infrastruktur und Timeout-Policies können das beobachtete Ergebnis verändern. Die Metrik ist keine unveränderliche Eigenschaft eines Modells. Sie ist Evidenz über eine Konfiguration aus Modell, Policy und Tools unter einem bestimmten Workload.

Widerstehe außerdem der Versuchung, jedes Ergebnis in Geld zu pressen. Latenz, Concurrency, Review-Aufwand, Schwere von Fehlern und Nutzervertrauen können Grenzen sein statt Bestandteile eines vermischten Scores. Eine Konfiguration mit den besten Kosten pro akzeptierter Aufgabe kann trotzdem unbrauchbar sein, wenn sie ein interaktives Latenzziel verfehlt oder seltene, aber unakzeptable Fehler erzeugt.

Was du diese Woche tun kannst

Wähle einen abgegrenzten Agenten-Workflow mit einer bestehenden, verlässlichen Erfolgsquelle. Beginne nicht mit einem offenen Assistant. Eine durch Tests abgesicherte Code-Aufgabe, eine Extraktionsaufgabe für Dokumente oder eine Support-Klassifikation mit bekannten Antworten ist hilfreicher.

Schreibe die Annahmeregel auf, bevor du ein Modell auswählst. Halte sie für den ersten Vergleich stabil. Instrumentiere jeden Versuch, damit du die Trajectory rekonstruieren und ihre Kosten zurechnen kannst. Lasse dann mindestens zwei Modell- oder Policy-Konfigurationen über dieselben repräsentativen Aufgaben laufen. Berichte vier Ansichten gemeinsam: Annahmerate, Kosten pro akzeptiertem Ergebnis, Latenzverteilung und Ablehnungsgründe.

Nutze das Ergebnis, um eine betriebliche Entscheidung zu ändern: ein Retry-Limit, eine Regel für Context-Management, eine Grenze für Model Routing oder eine Berechtigungs-Policy für Tools. Wiederhole danach die Evaluation. So wird aus einem Benchmark zur Einführung ein Engineering-Regelkreis.

Die nützliche Verschiebung ist klein, aber folgenreich. Tokenpreise bleiben wichtig. Sie sind nur Eingaben in eine größere Rechnung: die Kosten, zuverlässig Arbeit erledigen zu lassen.