LLM-Kosten pro erfolgreicher Aufgabe berechnen

Zwei KI-Systeme sollen eingehende E-Mails kategorisieren und dem zuständigen Team zuordnen. Das erste System ist pro Modellaufruf günstiger. Es benötigt aber häufiger einen weiteren Versuch oder eine menschliche Prüfung. Das zweite System kostet pro Aufruf mehr, liefert jedoch häufiger direkt ein verwendbares Ergebnis.

Welches System ist wirtschaftlicher?

Eine Tokenpreisliste beantwortet diese Frage nicht. Dafür muss ich untersuchen, wie viel Aufwand bis zu einem akzeptierten Ergebnis entsteht – einschließlich fehlgeschlagener Versuche.

Im folgenden Beitrag verwende ich dafür die Kennzahl Kosten pro erfolgreich erledigter Aufgabe. Der E-Mail-Workflow und alle Beispielzahlen sind hypothetisch. Ich beschreibe eine Methode, keine bereits durchgeführte Produktivmessung.

Eine bekannte Kennzahl praktisch anwenden

„Cost per successful task“ ist keine von mir entwickelte Kennzahl. LangWatch beschreibt den Ansatz als durchschnittliche Kosten pro Durchlauf geteilt durch Erfolgsquote. AgenticWire bezieht die Kosten aller Versuche auf die Anzahl erfolgreicher Aufgaben und berücksichtigt unter anderem Tools und menschliche Prüfung.

Die Forschungsarbeit „AI Agents That Matter“ argumentiert ebenfalls dafür, Kosten und Leistung gemeinsam zu bewerten, anstatt ausschließlich erfolgreiche Aufgaben zu maximieren.

Mein Beitrag besteht darin, diese Überlegungen in ein nachvollziehbares Vorgehen zu übersetzen: Was messe ich, welche Kosten zähle ich mit und unter welchen Bedingungen würde ich ein System auswählen?

1. Was bedeutet „erfolgreich erledigt“?

Bevor ich Kosten vergleiche, definiere ich die Aufgabe und die Akzeptanzkriterien.

Für den hypothetischen E-Mail-Workflow könnte die Aufgabe lauten:

Ordne jede eingehende Nachricht einer festgelegten Kategorie und einem zuständigen Team zu. Gib das Ergebnis im vorgegebenen JSON-Format aus. Falls die Zuordnung nicht ausreichend abgesichert ist, eskaliere die Nachricht zur menschlichen Prüfung.

Mögliche Akzeptanzkriterien:

Die Kategorie entspricht der vorher festgelegten Referenzbewertung.
Das gewählte Team ist für den Inhalt zuständig.
Die Ausgabe entspricht dem vereinbarten Schema.
Mehrdeutige Fälle werden nach den definierten Regeln eskaliert.
Vertrauliche Inhalte werden nicht an unberechtigte Stellen weitergegeben.

Valides JSON allein genügt nicht: Ein formal korrektes Ergebnis kann inhaltlich falsch sein.

Bei mehrdeutigen Nachrichten muss ich klären, ob mehrere Zuordnungen zulässig sind. Die Referenzbewertung und der Umgang mit Streitfällen werden vor dem Modellvergleich festgelegt.

Modellleistung und Workflow-Leistung unterscheiden

Wird eine falsche Modellantwort von einem Menschen korrigiert, kann die Aufgabe am Ende erfolgreich abgeschlossen sein. Dieser Erfolg gehört dann zum gesamten Workflow, nicht allein zum Modell.

Deshalb unterscheide ich:

Erstversuchs-Erfolg: Die erste Modellantwort erfüllt die Kriterien ohne Korrektur.
Automatischer Abschluss: Die Aufgabe gelingt innerhalb der erlaubten Modellversuche ohne menschliche Bearbeitung.
Workflow-Erfolg: Die Aufgabe gelingt gegebenenfalls nach erlaubter menschlicher Prüfung oder Korrektur.

Für die wirtschaftliche Kennzahl lege ich fest, welche dieser Erfolgsebenen im Nenner steht. Im folgenden Beispiel verwende ich den Workflow-Erfolg und berücksichtige den zugehörigen menschlichen Aufwand im Zähler.

Eine regelkonforme Eskalation kann ein korrektes Zwischenergebnis sein. Sie ist aber nicht automatisch eine vollständig erledigte Aufgabe. Ob sie bereits als Abschluss zählt, hängt von der ausdrücklich definierten Aufgabe ab.

2. Die zentrale Kostenformel

K_m = \frac{\displaystyle\sum_{i=1}^{N} C_{m,i}} {\displaystyle\sum_{i=1}^{N} S_{m,i}}

Dabei ist:

$m$ : das untersuchte Modell beziehungsweise Anwendungssystem.
$N$ : die Anzahl der Testaufgaben.
$C_{m,i}$ : die Kosten der Aufgabe $i$ innerhalb der festgelegten Systemgrenze.
$S_{m,i}$ : 1, wenn Aufgabe $i$ erfolgreich abgeschlossen wurde, sonst 0.
$K_m$ : die Kosten pro erfolgreich erledigter Aufgabe.

In Worten:

Ich teile die Kosten aller bearbeiteten Aufgaben durch die Anzahl erfolgreicher Abschlüsse.

Die Kosten fehlgeschlagener Aufgaben bleiben enthalten. Andernfalls würde ich den Vergleich zugunsten eines Systems beschönigen, das viele erfolglose Versuche produziert.

Wenn $S_{m,i}$ für alle Aufgaben 0 ist, wurde keine Aufgabe erfolgreich abgeschlossen. Der Nenner der Kostenformel ist dann 0:

K_m = \frac{\displaystyle\sum_{i=1}^{N} C_{m,i}} {\underbrace{\displaystyle\sum_{i=1}^{N} S_{m,i}}_{=\,0}}

Die Kennzahl ist damit nicht definiert. Das ist kein Rechenfehler, sondern ein Fall, der ausdrücklich behandelt werden muss: Es gibt keinen erfolgreichen Abschluss, auf den sich die Kosten verteilen lassen.

Saubere Definition

Definiere zunächst die Anzahl erfolgreicher Aufgaben:

E_m = \sum_{i=1}^{N} S_{m,i}

Dann gilt:

K_m = \begin{cases} \displaystyle\frac{C^{\text{gesamt}}_m}{E_m}, & \text{wenn } E_m>0 \\[8pt] \text{nicht definiert}, & \text{wenn } E_m=0 \end{cases}

Dabei ist:

$E_m$ : die Anzahl erfolgreich erledigter Aufgaben.
$C^{\text{gesamt}}_m$ : die Gesamtkosten aller Testaufgaben.
$K_m$ : die Kosten pro erfolgreich erledigter Aufgabe.
$S_{m,i}$ : der Erfolgsindikator für Aufgabe $i$ im System $m$ ; 1 bei Erfolg, sonst 0.
$C_{m,i}$ : die Kosten der Aufgabe $i$ im System $m$ .
$N$ : die Anzahl der Testaufgaben.

Wenn keine Aufgabe erfolgreich abgeschlossen wird, ist die Kennzahl nicht definiert. Eine Division durch null ergibt keinen sinnvoll interpretierbaren Kostenwert.

Warum „Durchschnittskosten geteilt durch Erfolgsquote“ dasselbe ergibt

Für denselben Testlauf und dieselbe Erfolgsebene gilt:

\frac{C_{\text{gesamt}}/N}{S/N} = \frac{C_{\text{gesamt}}}{S}

Dabei ist:

$C_{\text{gesamt}}$ : die Gesamtkosten des Testlaufs.
$S$ : die Anzahl erfolgreicher Aufgaben, mit $S>0$ .
$S/N$ : die Erfolgsquote als Anteil zwischen 0 und 1.

Entscheidend ist, dass die durchschnittlichen Kosten und die Erfolgsquote aus demselben Aufgabenbestand und derselben Kostengrenze stammen. Ein beliebiger Einzelpreis darf nicht stellvertretend für die gemessenen Durchschnittskosten eingesetzt werden.

3. Welche Kosten gehören in den Vergleich?

Ich betrachte zunächst die laufenden Kosten der Aufgabenbearbeitung:

Kostenbestandteil	Beispiel
Modellaufrufe	Input- und Output-Gebühren aller Versuche
Zusätzliche Tools	Kosten für Suche, externe APIs oder Codeausführung
Menschliche Prüfung	Kontrolle und Freigabe auch ohne Änderung der Antwort
Menschliche Korrektur	Änderung einer Kategorie oder Bearbeitung einer Eskalation
Zurechenbarer Betrieb	Infrastruktur und weitere laufende Betriebskosten

Menschliche Arbeit umfasst nicht nur Korrekturen. Auch zwei Minuten Prüfung mit anschließender unveränderter Freigabe sind Aufwand. Die Einbeziehung solcher Review-Kosten ist auch Bestandteil des AgenticWire-Ansatzes.

Alle beteiligten Modellaufrufe werden berücksichtigt. Wird nach einem günstigen Modell ein stärkeres Modell aufgerufen, gehört auch dieser Aufruf zur Aufgabe.

Eigenbetrieb und API-Nutzung nicht doppelt berechnen

Bei selbst betriebenen Modellen treten zurechenbare Infrastruktur- und Betriebskosten an die Stelle externer Modellgebühren. Ich dokumentiere, wie ich diese Kosten auf Aufgaben verteile und welche Auslastung ich annehme.

Eine mögliche Konvention ist, die Kosten eines abgegrenzten Betriebszeitraums auf die darin ausgeführten Aufgaben zu verteilen. Das Ergebnis hängt dann auch von der Auslastung ab. Diese Konvention muss im Vergleich sichtbar bleiben.

Bereits erfasste Hardware- oder Hostingkosten dürfen nicht zusätzlich als fiktive Tokengebühren ein zweites Mal angesetzt werden.

Dieser Test ersetzt keine vollständige Investitionsrechnung

Einmalige Entwicklung, Integration und Migration sowie längerfristige Wartung weise ich separat aus, sofern sie nicht ausdrücklich auf die betrachteten Aufgaben umgelegt werden.

Damit trenne ich zwei Fragen:

Was kostet die Aufgabenbearbeitung im betrachteten System?
Lohnt sich die Einführung oder der Wechsel über den erwarteten Nutzungszeitraum?

Der folgende Vergleich beantwortet primär die erste Frage.

4. Durchgerechnetes Beispiel

Beide Systeme bearbeiten dieselben 100 Aufgaben. Die Gesamtkosten enthalten sämtliche Modellversuche und den definierten menschlichen Prüf- und Bearbeitungsaufwand. Die Zahlen sind hypothetisch.

Kennzahl	System A	System B
Gesamtkosten	12 USD	18 USD
Erfolgreiche Abschlüsse	75	95
Erfolgsquote	75 %	95 %
Kosten pro erfolgreicher Aufgabe	0,16 USD	ca. 0,19 USD
Aufgaben mit zusätzlichem Modellversuch oder menschlichem Eingriff	30 %	10 %

K_A = \frac{12\,\text{USD}}{75} = 0{,}16\,\text{USD}

K_B = \frac{18\,\text{USD}}{95} \approx 0{,}1895\,\text{USD}

System A ist pro erfolgreicher Aufgabe günstiger. Das muss ich nicht wegargumentieren, nur weil System B mehr Aufgaben erfolgreich abschließt.

Wenn die Anwendung aber mindestens 90 % erfolgreiche Abschlüsse verlangt, scheidet A aus. B bleibt ein geeigneter Kandidat, sofern auch Laufzeit, Sicherheit und weitere Anforderungen erfüllt sind.

Der Unterschied lautet:

Nicht das günstigste System gewinnt automatisch, sondern das günstigste unter den ausreichend geeigneten Systemen.

Die Quote zusätzlicher Eingriffe erklärt in diesem Beispiel nicht allein die Kosten. Sie ist eine zusätzliche Beobachtung; die Kosten entstehen aus den tatsächlich erfassten Aufrufen und menschlichen Arbeitszeiten.

5. Qualität, Laufzeit und Risiken bleiben eigene Kriterien

Ich möchte Euro, Sekunden und Erfolgsprozente nicht ohne begründete Gewichtung zu einem einzigen Score addieren.

Stattdessen minimiere ich die Kosten pro erfolgreicher Aufgabe unter vorher definierten Anforderungen:

m^* = \underset{m}{\operatorname{arg\,min}}\; K_m

unter den Bedingungen:

Q_m \geq Q_{\min}

L_{95,m} \leq L_{\max}

Optional:

U_m \leq U_{\max}

Dabei ist:

$m^*$ : ein ausgewähltes System mit minimalem Kostenwert unter den geeigneten Kandidaten.
$Q_m$ : die Erfolgsquote.
$Q_{\min}$ : die geforderte Mindesterfolgsquote.
$L_{95,m}$ : das 95. Perzentil der Bearbeitungszeit.
$L_{\max}$ : die dafür gesetzte maximale Zeit.
$U_m$ : der Anteil der Aufgaben mit zusätzlichem Versuch oder notwendigem menschlichem Eingriff.
$U_{\max}$ : die maximal akzeptierte Eingriffsquote.

Erfüllt kein Kandidat die Bedingungen, liefert die Regel keine geeignete Auswahl. Bei gleichen Kostenwerten sind weitere Kriterien nötig.

Kritische Fehler dürfen nicht in einer Durchschnittsquote verschwinden

Eine falsch zugeordnete allgemeine Anfrage und die Weitergabe einer vertraulichen Nachricht können sehr unterschiedliche Folgen haben.

Deshalb dokumentiere ich kritische Fehler getrennt und lege gegebenenfalls Ausschlussregeln fest. Die Kostenkennzahl ersetzt keine Sicherheits- oder Risikobewertung. Nicht jede Konsequenz muss künstlich in einen Geldbetrag übersetzt werden.

Auch ein Test ohne beobachteten kritischen Fehler beweist nicht, dass ein solcher Fehler im Betrieb ausgeschlossen ist.

6. Faire Versuchsbedingungen festlegen

Für einen nachvollziehbaren Vergleich dokumentiere ich mindestens:

Aufgabenbestand: dieselben Fälle für alle Systeme, mit typischen Fällen und bewusst ausgewählten Sonderfällen.
Akzeptanzkriterien: dieselben Referenzen und dieselben Regeln für Erfolg, Eskalation und Abbruch.
Konfiguration: Modellversion, Prompt, Systemanweisungen, Tools und relevante Generierungseinstellungen.
Versuchsbudget: erlaubte Wiederholungen, Eskalationsregeln und gegebenenfalls Zeit- oder Kostenlimits.
Menschliche Hilfe: vergleichbare Regeln sowie gemessene Prüf- und Bearbeitungszeit.
Zeitmessung: einheitlicher Start- und Endpunkt einschließlich definierter Abbruchfälle.
Kostenbasis: Preisstand, Währung, Infrastrukturzuordnung und Abgrenzung einmaliger Kosten.
Testtrennung: Optimierungen an Entwicklungsfällen vornehmen und die endgültige Bewertung an zurückgehaltenen Fällen durchführen.

Für einen ersten kontrollierten Vergleich kann ich dasselbe Versuchsbudget setzen. Vergleiche ich unterschiedliche Workflow-Strategien, dürfen ihre Regeln abweichen; dann müssen diese Unterschiede transparent dokumentiert und sämtliche Kosten erfasst werden.

Das folgt dem Grundgedanken reproduzierbarer Evaluationen, den „AI Agents That Matter“ besonders hervorhebt.

Pro Aufgabe protokollieren

Feld	Zweck
Aufgaben-ID und Systemversion	Ergebnis eindeutig zuordnen
Erste Antwort akzeptiert?	Erstversuchs-Erfolg bestimmen
Anzahl Modellaufrufe	Wiederholungen und Eskalationen erfassen
Input- und Output-Verbrauch je Aufruf	Modellkosten berechnen
Toolkosten	Weitere Ausführungskosten erfassen
Menschliche Prüf- und Korrekturzeit	Personalkosten berücksichtigen
Gesamte Bearbeitungszeit	Laufzeit auswerten
Endstatus und Fehlerart	Erfolg und kritische Fehler unterscheiden

7. Die Messung hat Grenzen

100 Testaufgaben liefern eine Beobachtung für diesen Datensatz und diese Konfiguration, keinen endgültigen Nachweis für den späteren Betrieb.

Ich würde deshalb:

Ergebnisse nach Aufgabentyp aufschlüsseln.
Bei wichtigen Vergleichen mehrere Durchläufe prüfen.
Kleine Unterschiede nicht vorschnell als belastbaren Vorteil darstellen.
Den Aufgabenmix mit der erwarteten Nutzung abgleichen.
Preise und Systemversionen mit den Ergebnissen dokumentieren.

Ein absichtlich hoher Anteil schwieriger Sonderfälle kann für einen Sicherheitstest sinnvoll sein. Er entspricht aber nicht automatisch der Häufigkeit dieser Fälle im Betrieb. Eine daraus berechnete Durchschnittszahl ist ohne weitere Gewichtung keine Produktionsprognose.

Die Kennzahl bewertet außerdem nicht den gesamten Nutzen: Umsätze, vermiedene Schäden, Zufriedenheit und Investitionskosten können für eine weitergehende Entscheidung ebenfalls relevant sein.

Fazit

Ein niedriger Tokenpreis macht noch kein wirtschaftliches KI-System. Relevant ist der Aufwand bis zum erfolgreichen Abschluss – einschließlich Fehlversuchen, Tools und menschlicher Prüfung.

Die Kennzahl „Kosten pro erfolgreich erledigter Aufgabe“ hilft, diesen Zusammenhang sichtbar zu machen. Sie ist aber nur dann aussagekräftig, wenn Erfolg, Kostengrenze und Versuchsbedingungen klar definiert sind.

Mein Entscheidungsprinzip lautet daher:

Ich wähle das System mit den niedrigsten Kosten pro erfolgreicher Aufgabe unter den Systemen, die die fachlichen, zeitlichen und sicherheitsbezogenen Anforderungen erfüllen.

Methodenanhang: Formeln und Definitionen

A. Kosten je Aufgabe bei API-Nutzung

Wenn verschiedene Modelle innerhalb einer Aufgabe verwendet werden, können die Preise je Aufruf unterschiedlich sein:

C_{m,i} = \sum_{j=1}^{A_{m,i}} \left( \frac{T^{\text{in}}_{m,i,j}}{1\,000\,000}P^{\text{in}}_{m,i,j} + \frac{T^{\text{out}}_{m,i,j}}{1\,000\,000}P^{\text{out}}_{m,i,j} \right) + H_{m,i}w + Z_{m,i}

Dabei ist:

$A_{m,i}$ : die Anzahl aller Modellaufrufe für Aufgabe $i$ im System $m$ .
$T^{\text{in}}_{m,i,j}$ : die abgerechneten Input-Tokens des Aufrufs $j$ .
$T^{\text{out}}_{m,i,j}$ : die abgerechneten Output-Tokens des Aufrufs $j$ .
$P^{\text{in}}_{m,i,j}$ : der zugehörige Preis pro Million Input-Tokens.
$P^{\text{out}}_{m,i,j}$ : der zugehörige Preis pro Million Output-Tokens.
$H_{m,i}$ : notwendige menschliche Prüf-, Freigabe- und Bearbeitungszeit in Stunden.
$w$ : angesetzte Personalkosten pro Stunde.
$Z_{m,i}$ : weitere zurechenbare Kosten ohne Doppelzählung.

Bei mehreren menschlichen Rollen wird der Term für menschliche Arbeit entsprechend nach Rolle und Stundensatz aufgeteilt. Unterschiedliche Tarife für gecachte Eingaben werden ebenfalls als eigene Kostenpositionen erfasst. Bei Eigenbetrieb wird der API-Gebührenterm durch eine dokumentierte Infrastrukturkosten-Zuordnung ersetzt.

B. Einfacher Spezialfall: Input-Kosten

C_{\text{Input}} = \frac{N_{\text{Input-Tokens}}}{1\,000\,000} \times P_{\text{Input}}

Dabei ist:

$C_{\text{Input}}$ : die Kosten der Eingabe.
$N_{\text{Input-Tokens}}$ : die Anzahl der Input-Tokens.
$P_{\text{Input}}$ : der Preis pro Million Input-Tokens.

Diese Formel berechnet nur Input-Kosten, nicht die vollständigen Kosten pro erfolgreicher Aufgabe.

C. Durchschnittlicher Tokenverbrauch

Für den ersten Aufruf:

\overline{T}^{\text{in, erster Aufruf}}_m = \frac{1}{N} \sum_{i=1}^{N}T^{\text{in}}_{m,i,1}

Für alle Aufrufe einschließlich Wiederholungen:

\overline{T}^{\text{gesamt}}_m = \frac{1}{N} \sum_{i=1}^{N} \sum_{j=1}^{A_{m,i}} \left(T^{\text{in}}_{m,i,j}+T^{\text{out}}_{m,i,j}\right)

Dabei ist:

$\overline{T}^{\text{in, erster Aufruf}}_m$ : durchschnittlicher Input-Verbrauch des ersten Aufrufs.
$\overline{T}^{\text{gesamt}}_m$ : durchschnittlicher Gesamtverbrauch pro Testaufgabe.

Für die Kostenrechnung bleiben Input und Output getrennt. Der erste Wert gilt hier für Systeme, die pro Aufgabe mindestens einen Modellaufruf ausführen. Bei regelbasierten Baselines oder Aufgaben ohne Modellaufruf wird der fehlende Verbrauch als null erfasst und entsprechend dokumentiert.

D. Erfolgsindikator und Erfolgsquote

S_{m,i} = \begin{cases} 1, & \text{wenn die Aufgabe die Akzeptanzkriterien erfüllt}\\ 0, & \text{sonst} \end{cases}

Q_m = \frac{1}{N} \sum_{i=1}^{N}S_{m,i}

Dabei ist:

$S_{m,i}$ : Erfolg auf der vorher festgelegten Ebene.
$Q_m$ : Erfolgsquote als Anteil zwischen 0 und 1.

Erstversuchs-, Automations- und Workflow-Erfolg werden bei Bedarf als getrennte Indikatoren und Quoten geführt. Sie dürfen nicht nachträglich vermischt werden.

E. Gesamtkosten des Testlaufs

C^{\text{gesamt}}_m = \sum_{i=1}^{N}C_{m,i}

Dabei ist:

$C^{\text{gesamt}}_m$ : die Kosten aller erfolgreichen und fehlgeschlagenen Aufgaben innerhalb der definierten Systemgrenze.

F. Bearbeitungszeit

\overline{L}_m = \frac{1}{N} \sum_{i=1}^{N}L_{m,i}

L_{95,m} = P_{95}\left(L_{m,1},\ldots,L_{m,N}\right)

Dabei ist:

$L_{m,i}$ : Zeit vom definierten Start bis zum Abschluss oder Abbruch.
$\overline{L}_m$ : mittlere Bearbeitungszeit.
$L_{95,m}$ : 95. Perzentil der Bearbeitungszeit.
$P_{95}$ : Operation zur Bestimmung dieses Perzentils.

Abbruchzeiten werden berücksichtigt, aber fehlgeschlagene Aufgaben werden nicht als schnelle Erfolge interpretiert. Ergänzend können Laufzeiten erfolgreicher Aufgaben separat ausgewiesen werden.

G. Wiederholung, menschliche Prüfung und Korrektur

Definiere je Aufgabe:

$R_{m,i}=1$ : mindestens ein zusätzlicher Modellversuch, sonst 0.
$V_{m,i}=1$ : notwendige menschliche Prüfung, Freigabe oder Bearbeitung, sonst 0.
$B_{m,i}=1$ : tatsächliche menschliche Korrektur des Ergebnisses, sonst 0.

Daraus folgen:

R_m = \frac{1}{N}\sum_{i=1}^{N}R_{m,i}

V_m = \frac{1}{N}\sum_{i=1}^{N}V_{m,i}

B_m = \frac{1}{N}\sum_{i=1}^{N}B_{m,i}

Die gemeinsame Eingriffsquote lautet:

U_m = \frac{1}{N} \sum_{i=1}^{N}\max\left(R_{m,i},V_{m,i}\right)

Dabei ist:

$R_m$ : Wiederholungsquote.
$V_m$ : Quote mit notwendiger menschlicher Beteiligung.
$B_m$ : Quote tatsächlicher menschlicher Korrekturen.
$U_m$ : Anteil mit Wiederholung oder notwendiger menschlicher Beteiligung.

Ein Fall mit beidem wird nur einmal gezählt. Eine ohne weiteren Eingriff aufgegebene Aufgabe bleibt ein Misserfolg, erhöht aber nicht automatisch die Eingriffsquote.

Für Prozentwerte werden die Anteile mit 100 multipliziert. Häufigkeit und Aufwand sind verschieden: Zwei Systeme mit gleicher Review-Quote können sehr unterschiedliche menschliche Bearbeitungszeiten verursachen.