KI-Kosten, Prozesskosten und TCAI

Stand: 11. September 2026. Recherche und Entwurf für den Kostenrechner von Oliver Gausmann. Dies ist eine begründete Modellierungsentscheidung, keine veröffentlichte Norm. Die Recherche verbindet begutachtete Arbeiten, aktuelle Preprints und technische Primärquellen; sie ist keine systematische Literaturübersicht mit Anspruch auf Vollständigkeit.

Empfehlung

Die Startgröße ist Reine KI-Kosten. Daneben steht die Frage: Was kostet eine nutzbare, ausreichend abgesicherte Erledigung dieser Aufgabe? Dafür eignet sich eine zweite, klar abgegrenzte Rechnung. Als sichtbaren Namen empfehle ich Gesamtkosten je KI-Aufgabe, ergänzt um TCAI – unsere Definition einschließlich Prüfung, Nacharbeit und erwartetem Restrisiko.

„Total Cost of AI Inference“ ist erklärungsbedürftig: Inferenz bezeichnet technisch die Modellausführung; menschliche Nacharbeit reicht darüber hinaus. TCAI sollte deshalb weder als etablierter Standard noch ohne die ausgeschriebene Abgrenzung erscheinen. Wer ausschließlich den technischen Begriff bevorzugt, nennt die erste Größe „Inferenzkosten“ und die zweite schlicht „Betriebskosten der KI-Aufgabe“. Der Rechner braucht kein Akronym, um verständlich zu sein.

Meine Empfehlung für die Grenze: ab Betriebsbereitschaft bis zum abgeschlossenen Vorgang. Eine ausschließlich zeitliche Grenze „nach der Inferenz“ würde wiederkehrende Wissenssuche, Kontextaufbereitung und weitere Modellaufrufe falsch ausklammern. Entwicklung und Einführung stehen separat. Erwartete Fehlerfolgen sind kein regulärer Rechnungsbetrag und werden auch visuell separat ausgewiesen.

1. Was an der Ausgangsaussage trägt – und was wir präzisieren müssen

Niedrige Temperatur: konsistenter ist nicht automatisch richtiger

Temperatur steuert die Auswahl möglicher Ausgaben bei der Inferenz. Sie ist eine Einstellung einer konkreten Ausführung, keine feste Eigenschaft einer Modellklasse. Niedrige Werte können Streuung reduzieren. Das beweist weder fachliche Richtigkeit noch vollständige Reproduzierbarkeit. Ein systematischer Irrtum kann sehr konsistent sein.

Atıl et al. untersuchten fünf gehostete Modelle auf acht Aufgaben mit je zehn Läufen unter Einstellungen, die deterministisches Verhalten erwarten ließen. Sie beobachteten dennoch Unterschiede in Ausgaben und Genauigkeit. Die Untersuchung belegt das Problem für diese Systeme; daraus folgt keine universelle Schwankungsquote für alle heutigen Modelle. Eval4NLP 2025, ACL.

Ein aktueller Pilot von Tamba vom 24. Juni 2026 untersucht Reproduzierbarkeit bei LLM-Sicherheitsbewertungen. Temperaturkontrolle reduzierte, beseitigte aber nicht alle Unterschiede bei grenzwertigen Testfällen. Die Stichprobe ist eng: 690 Aufrufe und sieben Grenzfälle; zudem handelt es sich um einen Preprint. Das ist ein zusätzlicher Hinweis, kein belastbarer Abschlagsfaktor für geschäftliche Fehlerkosten. Tamba 2026.

Umgekehrt kann gezielte Vielfalt mit anschließender Auswahl bei bestimmten Denkaufgaben helfen. Die bei ICLR 2023 veröffentlichte Self-Consistency-Arbeit verbessert Ergebnisse durch mehrere unterschiedliche Lösungswege und Aggregation gegenüber der untersuchten gierigen Einzelausgabe. Das kostet zusätzliche Aufrufe und ist weder für jede Aufgabe noch für jedes heutige Modell garantiert besser. Wang et al..

Konsequenz für den Rechner: kein Regler „Temperatur niedriger = x % weniger Fehler“. Temperatur, Sampling, Denkaufwand und Wiederholungsstrategie werden als Konfiguration dokumentiert. Ein Kosteneffekt entsteht durch veränderten tatsächlichen Verbrauch; ein Qualitätseffekt erst durch eine passende Messung.

Kontext und Prompting sind Teil der Leistung

Die NoLiMa-Arbeit, angenommen bei ICML 2025, zeigt bei 13 untersuchten Modellen deutliche Leistungsabfälle bei längeren Kontexten, wenn sich die gesuchte Information nicht durch einfache Wortübereinstimmung finden lässt. Ein großes Kontextfenster ist deshalb kein Nachweis, dass eine konkrete Aufgabe mit viel Kontext zuverlässig gelöst wird. Die Untersuchung betrifft ihren eigenen Retrieval-Benchmark und ältere Modellversionen, nicht pauschal heutige Geschäftsprozesse. NoLiMa.

Anthropics technische Darstellung betont die Auswahl relevanter Informationen, klare Anweisungen sowie das laufende Verwalten von Werkzeugen und Verlauf. Dies ist eine Primärquelle aus der Herstellerpraxis, keine unabhängige Effektmessung. Wir können daraus Gestaltungshinweise ableiten, aber keine allgemeine Prozentzahl für „gutes Prompting“. Effective context engineering.

Eine sehr neue Forschungsrichtung verbindet Kontexttreue und Ausführungseffizienz: SFAD, eingereicht am 1. September und aktualisiert am 3. September 2026, kombiniert ein speziell trainiertes Entwurfsmodell mit einer veränderten Dekodierung. Die Autoren berichten Verbesserungen in ihren Experimenten. Es handelt sich um einen Preprint und eine spezielle Architektur, nicht um eine Einstellung, die beliebige APIs anbieten. Die Resultate fließen daher nicht als Standardfaktor in den Rechner ein. Chen et al., SFAD.

Konsequenz: Wir vergleichen Modell + Version + Konfiguration + Arbeitsablauf, nicht nur Modellnamen. Ein günstigeres Modell mit geeigneten Daten und Prüfregeln kann wirtschaftlicher sein; das muss für die konkrete Aufgabe gezeigt werden. Ein größeres oder teureres Modell ist ebenfalls keine automatische Garantie.

Menschliche Kontrolle muss selbst wirksam sein

Eine preregistrierte Metaanalyse von 106 Experimenten mit 370 Effektgrößen zeigt, wie stark der Nutzen von Mensch-KI-Kombinationen von Aufgabe und relativer Leistungsfähigkeit abhängt. Die Kombination war im Mittel nicht besser als die jeweils bessere Einzelkomponente. Die zugrunde liegenden Studien stammen aus 2020–2023 und bilden aktuelle LLM-Arbeitsabläufe nur begrenzt ab. Trotzdem widerspricht der Befund einer pauschalen Annahme, dass zusätzliche Kontrolle automatisch eine feste Fehlerreduktion bewirkt. Vaccaro et al., Nature Human Behaviour 2024.

Konsequenz: Prüfzeit ist ein eigener Kostenwert. Verbleibende Fehler werden nach dem gesamten Ablauf gemessen. Weniger Prüfzeit darf im Rechner nicht automatisch dieselbe Qualität behalten; mehr Prüfzeit darf nicht automatisch eine bessere Quote erzeugen.

2. Reine KI-Kosten: nach Betriebsform rechnen

Für API-Betrieb werden alle beteiligten Modelle und Aufrufe gezählt: Erzeugung, KI-Prüfung, erneute Versuche, Embeddings oder Reranking, soweit sie als Modellinferenz abgerechnet werden. Einmal im KI-Posten erfasste Gebühren dürfen nicht noch einmal bei Nacharbeit erscheinen. Andere Werkzeuge, Datenbankdienste und menschlicher Betrieb kommen in getrennte Prozessposten.

Für Selbstbetrieb ist der faire Vergleich zur API der zugeordnete vollständige Infrastrukturaufwand, nicht nur die aktive GPU-Zeit. OpenCost unterscheidet in seiner Veröffentlichung vom 5. August 2026 ausdrücklich nutzungsbezogene und allokationsbezogene Kosten. Letztere berücksichtigen die Bereitstellung und sind für eine Eigenbetrieb-versus-API-Entscheidung relevant. CNCF / OpenCost.

Ein Preprint vom 10. Juni 2026 untersucht die Abhängigkeit effektiver Inferenzkosten von tatsächlicher Last, Hardware und Konfiguration. Die Experimente mit H100 und A100 zeigen große Unterschiede bei wechselnder Last. Das unterstützt die Notwendigkeit eigener Lastmessungen; die veröffentlichten Tokenpreise sind keine universellen Vorgabewerte. Patil 2026.

Einfache Eingabe im Entwurf: Kosten der bereitgestellten Infrastruktur je Stunde × gebuchte Stunden × zugeordneter Anteil. Der Stundensatz muss alle hier zu berücksichtigenden Infrastrukturposten umfassen. Bei eigenen Geräten: Abschreibung beziehungsweise interne Kapitalkosten, Strom, Kühlung und Betriebsmittel sachgerecht zuordnen; Miete und Abschreibung desselben Geräts nicht doppelt zählen. Personal zur Betreuung zählt zu Prozesskosten. Ein geteilter Cluster braucht eine dokumentierte Verteilung, keine frei gewählte niedrige Prozentzahl.

Ein Eintrag eines API-Modells belegt noch nicht, dass es selbst betreibbar ist. Im Entwurf steht diese Betriebsform nur bei als Open Weight erfassten Modellen zur Auswahl. Eine tatsächlich verfügbare, kompatible Gewichts- und Laufzeitversion muss zusätzlich geprüft werden. Bei einer anderen Menge darf man fixe Hostingkosten nicht proportional wie Tokenkosten skalieren. Kapazität und Antwortzeit müssen erneut zur Last passen.

3. Vier getrennte Posten, zwei klar bezeichnete Summen

Für einen Monat mit N eingehenden Aufgaben:

1. KI-Inferenz: C_KI = Summe der Anbietergebühren oder zugeordnete Infrastrukturkosten. Alle tatsächlichen zusätzlichen Inferenzaufrufe genau einmal zählen.
2. Prüfung und Nacharbeit: C_Mensch = N × (mittlere Prüfminuten + mittlere Nacharbeitsminuten) / 60 × interne Stundenkosten. Die Mittelwerte beziehen sich auf alle eingehenden Aufgaben. Beispiel: 10 % benötigen fünf Minuten Korrektur → 0,5 Minuten im Durchschnitt. Prüfung und Korrektur nicht doppelt erfassen. Unterschiedliche Rollen können später getrennte Stundensätze bekommen.
3. Sonstiger laufender Prozess: C_Prozess = wiederkehrende nicht bereits erfasste Kosten für Wissenssuche, Werkzeuge, Monitoring und Betreuung. KI- und Personalkosten, die in 1 oder 2 stehen, ausnehmen.
4. Verbleibende Fehlerfolgen: C_Risiko = N × Restfehlerquote nach Prüfung und Nacharbeit × zusätzliche durchschnittliche Kosten je verbleibendem Fehler. Bei unterschiedlichen Schadensklassen getrennt summieren. Bereits gezählte Korrekturzeit und Wiederholungsgebühren ausschließen.

Laufende Kosten = C_KI + C_Mensch + C_Prozess.

TCAI in diesem Entwurf = laufende Kosten + erwartete verbleibende Fehlerfolgen.

Die Summe je Aufgabe teilt durch N. Das ist eine Größe je eingehender Aufgabe, nicht je erfolgreich erledigter Aufgabe. Für letztere ist zusätzlich die gemessene Abschlussquote des gesamten Prozesses erforderlich. Diese beiden Nenner dürfen nicht vermischt werden.

Unbekannt ist nicht null. Die Oberfläche zeigt für offene Posten „Noch offen“ und weist keine vollständige TCAI-Summe oder Preisempfehlung aus. Eine ausdrücklich eingetragene Null ist eine eigene Annahme. Erwartete Schäden sind keine sichere Monatszahlung und für seltene gravierende Ereignisse oft kein ausreichendes Entscheidungskriterium. Fehlertoleranz und Sensibilität führen deshalb zu Anforderungen an den Ablauf, nicht zu einem pauschalen Geldmultiplikator.

4. Warum sich die bisherige Rechnung nicht unverändert als TCAI eignet

Das Original verbindet eine passende Benchmark-Lösequote p mit 1,2 / p Anläufen und berechnet Fehlerfolgen aus (1 − p) × Fehlerbetrag. Beide Regeln sind im Bestand erhalten und im Referenzbereich einsehbar. Der Faktor 1,2 ist eine Modellannahme.

Eine geometrische Erwartung von 1/p Versuchen setzt unter anderem gleichartige unabhängige Versuche, eine verlässliche Erfolgserkennung und Wiederholung bis zum Erfolg voraus. Solche Bedingungen gelten bei LLM-Fehlern nicht automatisch. Begrenzte Wiederholungen, korrelierte Fehler und unvollkommene Prüfer verändern die Rechnung.

Vor allem ist die Benchmarkquote vor menschlicher Kontrolle keine gemessene Restfehlerquote nach dem gesamten Prozess. Wer zusätzlich Korrekturarbeit berechnet und denselben Ausgangsfehler als verbleibenden Schaden wertet, kann Kosten doppelt oder sachlich falsch zuordnen. Daher bleibt die Benchmarkrechnung eine gekennzeichnete Referenz. Die neue Betriebsrechnung verwendet eigene Angaben für Aufrufmenge, menschlichen Aufwand und Restfehler, ohne automatische Übertragung der Benchmarkquote.

5. Modell- und Konfigurationsvergleich

Gleich bleiben Aufgabe, Qualitätsziel, Sprache, Eingangsmenge und die Definition eines erledigten Vorgangs. Variieren dürfen Modell, Kontextaufbereitung, Promptversion, Sampling, Denkaufwand, Werkzeuge, Wiederholungs- und Prüfstrategie. Diese Unterschiede werden je Variante gespeichert.

Pro Variante werden angezeigt: reine KI-Kosten; Prüfung und Nacharbeit; sonstige laufende Kosten; verbleibende Fehlerfolgen; TCAI oder fehlende Angaben. Bei einem Wechsel sind unbekannte Nacharbeitswerte des anderen Modells nicht automatisch identisch. Ein Vergleichskorb kann deshalb auch dasselbe Modell mit zwei Konfigurationen enthalten.

Die Schnellwahl „geringste KI-Kosten“ ist zulässig, wenn Tarif und Eingabemenge vergleichbar sind. „Beste Qualität“ setzt einen passenden Nachweis voraus. „Niedrigste TCAI“ darf nur unter vergleichbaren Qualitätsanforderungen und vollständigen, gleichartig erhobenen Annahmen erscheinen. Unterschiedliche Evidenzstände müssen sichtbar bleiben. Eine pauschale Empfehlung allein aus Kosten wäre zu stark.

Temperatur und Kontextstrategie erscheinen in einer aufklappbaren Konfigurationsnotiz. Kein voreingestelltes Versprechen „gutes Prompting spart 30 %“. Eine Variante kann auch zusätzliche Inferenz kosten und trotzdem menschliche Nacharbeit einsparen.

6. Ein bewusst erfundenes Rechenbeispiel

Die folgenden Zahlen sind nur Illustration, keine Messung bestimmter Modelle:

B wäre unter diesen Annahmen günstiger, obwohl die KI-Gebühr höher ist. Die Rechnung beweist nicht, dass ein teureres Modell diese Nacharbeits- oder Restfehlerquoten erreicht. Genau diese Unterschiede muss ein Pilot messen.

7. Was vor dem Betrieb notwendig ist

Ein eigener, zunächst geschlossener Bereich „Was muss vor dem Einsatz stehen?“ enthält: Aufgabe und Qualitätskriterien definieren; Datenzugriff und Datenqualität klären; geeigneten Kontext und Prompt entwickeln; repräsentative Testfälle einschließlich Grenzfällen zusammenstellen; Prüflogik und Eskalation festlegen; Integration, Zugriffsrechte und Protokollierung einrichten; Pilot messen; Betrieb und Verantwortlichkeiten festlegen.

Optional lässt sich ein separater Einführungsaufwand erfassen. Es gibt ohne Projektumfang und Ist-Prozess keine seriöse automatische Standardsumme. Falls Amortisation gewünscht ist, lautet die Zusatzsicht „Projektkosten über X Monate“ mit ausdrücklichem Zeithorizont. Sie überschreibt die laufende Inferenz- und TCAI-Rechnung nicht. Laufende Pflege ist im Gegensatz zum erstmaligen Aufbau Teil des Betriebs.

8. Wie Annahmen belastbar werden

Jeder Wert braucht Wert und Einheit, Herkunft, Datum, Modellversion, Konfiguration und Geltungsbereich. Drei Evidenzzustände genügen in der einfachen Oberfläche: eigene Messung, Planungsannahme, noch unbekannt. Ein veröffentlichter Benchmark erhält einen eigenen Quellenhinweis und ersetzt keine Prozessmessung.

Für einen Vergleich dieselben repräsentativen Eingangsaufgaben verwenden, Ausführungsreihenfolge soweit sinnvoll randomisieren und nicht nur gute Beispiele auswählen. Fachlich überprüfbare Bewertungskriterien vorab festlegen. Kritische Randfälle zusätzlich prüfen und gesondert ausweisen. Tatsächliche API-Nutzung, Laufzeit, Prüfdauer, Korrekturzeit, Eskalation, vollständigen Abschluss und nachgelagerte Fehler getrennt protokollieren. Wiederholte Läufe bei schwankenden Ausgaben berücksichtigen.

Stichprobengröße und Unsicherheit gehören zur Quote. Null beobachtete Fehler sind kein Beleg für ein Nullrisiko. Für seltene schwerwiegende Fehler reicht ein kleiner Pilot nicht. Ein KI-Prüfer muss gegen unabhängige fachliche Bewertungen geprüft werden; mehrere ähnlich arbeitende Modelle sind nicht automatisch unabhängige Kontrollen.

Produktentscheidung: erst eine schnell verständliche KI-Rechnung, dann eine geführte Erweiterung um den eigenen Betrieb, schließlich die vollständige Evidenz. Diese Staffelung kombiniert einfache Nutzung mit fachlicher Tiefe, ohne Wissen oder Quellen zu entfernen.