Kosten, Infrastruktur und Betrieb

Auftrag, Reichweite und Kernbegriffe

AUFTRAG: Untersucht werden die tatsächlichen Kosten einer KI-Anwendung vom ersten Modellaufruf bis zu Betrieb, Wartung und Stilllegung. Gegenstand sind API-Modelle, Managed Services, Open-Weight-Modelle, Cloud- und lokale Infrastruktur, Datenbanken, Vektorsuche, Storage, Netzwerk, Observability, Security, Personal, Compliance und Ausfallvorsorge. ^{[S-068] [S-073] [S-092]}

Systemgrenze

Die Rechengrenze beginnt beim fachlichen Vorgang und endet beim verwertbaren Ergebnis. Eingeschlossen sind alle wiederholten Modellaufrufe, Toolpfade, Datenoperationen, manuelle Prüfungen und Ressourcen, die den Vorgang ermöglichen. Ein isolierter Modellpreis ist nur eine Teilmenge. ^{[S-069] [S-070] [S-099]}

*Tabelle 1: Vollständige Kostenblöcke einer produktiven KI-Anwendung*

Arbeitsdefinition der Wirtschaftlichkeit

ARBEITSFORMEL: Wirtschaftlich ist eine Architektur nur, wenn sie bei erforderlicher Qualität, Sicherheit und Verfügbarkeit geringere Vollkosten oder einen höheren belegbaren Wert als die beste realistische Alternative erzeugt.

Die Formel schließt ausdrücklich ein, dass klassische Software, ein Formular, eine Suche, ein Regelwerk oder der unveränderte Prozess die bessere Option sein können. ^{[S-119] [S-069] [S-073]}

Belegstufen

Management Summary

1. Tokenpreise sind selten der größte Block — Bei kleinen und mittleren Anwendungen dominieren häufig Entwicklung, Datenpflege, Review, Support und Governance. ^{[S-068] [S-089]}
2. Der Nenner entscheidet — Kosten müssen durch fachlich erfolgreiche Ergebnisse geteilt werden; reine Request- oder Tokenmetriken verschleiern Fehlversuche. ^{[S-069] [S-165]}
3. Ausgabe ist oft teurer als Eingabe — Aktuelle Preislisten weisen häufig deutlich höhere Outputpreise aus. Antwortlänge ist deshalb ein unmittelbarer Hebel. ^{[S-001] [S-007] [S-014]}
4. Caching ist kein Pauschalrabatt — Nur wiederverwendbare Eingaben profitieren; Schreib-, Speicher- und Invalidierungskosten bleiben. ^{[S-002] [S-009] [S-015]}
5. Batch und Flex brauchen passende Deadlines — Rabatte werden mit asynchroner Verarbeitung oder geringerer Kapazitätsgarantie erkauft. ^{[S-004] [S-003] [S-016]}
6. Agenten brauchen ein Laufbudget — Mehrstufige Tool- und Modellschleifen können Kosten und Seiteneffekte vervielfachen. ^{[S-098] [S-099]}
7. RAG ist eine Datenpipeline — Ingestion, Embeddings, Index, Retrieval, Re-Ranking, Kontext und Pflege gehören in dieselbe Rechnung. ^{[S-053] [S-121]}
8. Self-hosting lohnt nur bei Auslastung und Fähigkeit — Eigene Modelle ersetzen Tokenpreise durch Hardware, Engineering, Betrieb und Risiko. ^{[S-080] [S-100] [S-107]}
9. Observability kann teuer werden — Logs, Traces und hochkardinale Metriken wachsen mit jedem Lauf; Sampling ist ein Qualitätskompromiss. ^{[S-064] [S-060] [S-061]}
10. Verfügbarkeit ist eine finanzierte Leistung — Replikate, Puffer, Multi-Region und Bereitschaft sind bewusst bezahlte Risikoreduktion. ^{[S-170] [S-117]}
11. Einführungspreise und Modellabschaltungen gehören ins Budget — Preisgültigkeit und Migrationsfenster können innerhalb eines Jahres wechseln. ^{[S-007] [S-011]}
12. Routing kann sparen, muss aber getestet werden — Kaskaden konzentrieren starke Modelle auf schwierige Fälle; Fehlrouting kann den Nutzen aufheben. ^{[S-077] [S-078]}
13. Sicherheit begrenzt finanziellen Schaden — Quoten, Rate Limits, Secrets und Kill Switches schützen zugleich vor Missbrauchsausgaben. ^{[S-098] [S-167]}
14. Preisvergleiche brauchen Servicegleichheit — Direkt-API, Bedrock, Vertex und Azure liefern unterschiedliche Regionen, Plattformfunktionen und Verträge. ^{[S-019] [S-017] [S-020]}
15. Weniger KI ist häufig die beste Optimierung — Deterministische Schritte sollten aus dem LLM-Pfad entfernt werden. ^{[S-119] [S-073]}

Abbildung 1: Illustrative Vollkostenstruktur einer KI-Anwendung – im PDF und DOCX eingebettet.

*Eigene Darstellung. Prozentwerte sind bewusst illustrative Annahmen, keine Marktstatistik.*

Kostenmodell, Formeln und Preis-Snapshot

Kernformeln

REGEL: Jede Formel benötigt Messdaten für Volumen, Tokenverteilung, Erfolgsquote, Nacharbeit und Lastform. Ein Preisrechner ohne diese Größen ist nur eine grobe Oberflächenrechnung.

Preis-Snapshot ausgewählter Modelle und Spezialdienste

*Tabelle 2: Öffentliche Listenpreise am 08.08.2026; keine Angebots- oder Vertragszusage*

SCHNELL VERALTEND: Diese Tabelle muss vor jeder Veröffentlichung, Beschaffung oder Kalkulation erneut gegen die Anbieterpreise geprüft werden. Besonders kritisch sind Aktionspreise, Service-Tier-Namen, Langkontext, regionale Verarbeitung und Freikontingente.

Warum Outputlänge wirtschaftlich relevant ist

Abbildung 2: Listenkosten je 1.000 Anfragen bei wachsender Ausgabe – im PDF und DOCX eingebettet.

*Eigene Berechnung mit 1.500 Eingabetoken und den im Dossier dokumentierten Preis-Snapshots; keine Qualitätsaussage.*

Lastform und Kapazität

Abbildung 3: Gleicher Tagesverbrauch, unterschiedliche Kapazitätsanforderung – im PDF und DOCX eingebettet.

*Eigene illustrative Lastprofile. Die Flächen sind ähnlich; Peak- und Queuebedarf unterscheiden sich.* Eine Monatsmenge allein zeigt weder benötigte Parallelität noch Cold Starts, Queuealter oder Kapazitätspuffer. Für API- und Self-hosting-Entscheidungen sind P95/P99-Last und Deadline erforderlich. ^{[S-104] [S-105] [S-106]}

81 belastbare Kernaussagen

A. Die richtige Recheneinheit

Preis ist nicht Vollkosten

Der API-Preis bildet nur die unmittelbar abgerechnete Modellnutzung ab. Für eine belastbare Entscheidung gehören Datenhaltung, Integration, Tests, Telemetrie, Support, Sicherheit, Ausfallvorsorge, Migration und Personal in dieselbe Rechnung. Ein Modell kann pro Token billig und als Gesamtsystem dennoch teuer sein. ^{[S-067] [S-068] [S-072] [S-074]}

Das wirtschaftliche Ziel ist ein Ergebnis, kein Token

Token sind eine technische Verbrauchseinheit. Für Führung und Produktsteuerung sind Kosten pro gelöstem Fall, freigegebenem Dokument, qualifiziertem Lead, erledigtem Auftrag oder vermiedener Bearbeitungsminute aussagekräftiger. FinOps empfiehlt den Übergang von Ressourcenmetriken zu geschäftsbezogenen Einheiten. ^{[S-069] [S-070] [S-068]}

Erfolgsquote gehört in den Nenner

Eine scheinbar günstige Anfrage wird teuer, wenn nur ein Teil der Antworten verwertbar ist. Daher muss die Kennzahl auf erfolgreiche, nach Qualitätskriterien akzeptierte Ergebnisse bezogen werden. Fehlversuche, manuelle Nacharbeit und eskalierte Fälle bleiben sonst unsichtbar. ^{[S-165] [S-166] [S-112]}

Fixe und variable Kosten müssen getrennt werden

API-Nutzung ist überwiegend variabel, während Self-hosting, reservierte Kapazität, Mindestgebühren und Betriebsteams hohe Fixanteile erzeugen. Die Trennung zeigt, ab welchem Volumen eine Architektur überhaupt auslastungsfähig ist. Ohne sie wird ein vermeintlicher Break-even aus Monatswerten abgeleitet, die nicht vergleichbar sind. ^{[S-024] [S-026] [S-021] [S-069]}

Die Lastkurve ist wichtiger als die Monatssumme

Zwei Systeme mit gleichem Tokenverbrauch können völlig andere Kapazitätskosten haben. Gleichmäßige Batchlast lässt Hardware gut auslasten; kurze Spitzen erfordern Überkapazität, Queueing oder teure Prioritätsklassen. Planung benötigt daher Verteilung, Parallelität, Saisonalität und Latenzziel. ^{[S-104] [S-105] [S-106] [S-073]}

Goodput schlägt Rohdurchsatz

Rohdurchsatz zählt alle erzeugten Token oder Requests. Goodput betrachtet nur Ergebnisse, die innerhalb der vereinbarten Zeit und Qualität tatsächlich nutzbar sind. Eine aggressive Optimierung, die mehr Antworten produziert, aber Fehlerquote oder Timeout-Rate erhöht, kann die Stückkosten verschlechtern. ^{[S-080] [S-149] [S-157]}

Kosten brauchen Bandbreiten statt Punktwerte

Vor Produktionsstart sind Tokenlänge, Trefferquote, Wiederholungen, Toolaufrufe und Wachstum unsicher. Eine Planung mit Basis-, Belastungs- und Stressszenario ist belastbarer als ein einzelner Monatsbetrag. Die Bandbreite muss die Annahmen offen ausweisen. ^{[S-158] [S-072] [S-074]}

Währungs-, Steuer- und Vertragsfaktoren sind separat

Öffentliche Listenpreise sind häufig in US-Dollar und ohne Umsatzsteuer, individuelle Rabatte, Mindestabnahmen oder Supportpakete angegeben. Ein deutscher Business Case benötigt Wechselkursannahme, Netto-/Bruttologik und Vertragskonditionen. Diese Faktoren dürfen nicht stillschweigend in die technische Verbrauchsrechnung gemischt werden. ^{[S-071] [S-067] [S-018]}

Kostenallokation beginnt bei Identität und Metadaten

Ohne Projekt-, Mandanten-, Team-, Modell- und Use-Case-Kennzeichnung lassen sich Rechnungen nur nachträglich schätzen. Kostenstellen, Tags und korrelierbare Request-IDs müssen bereits im Design verankert sein. FOCUS zielt auf eine normalisierte Kosten- und Nutzungsstruktur über Anbieter hinweg. ^{[S-071] [S-099] [S-065]}

Die Nullvariante ist Teil jeder Rechnung

Ein KI-System ist nur wirtschaftlich, wenn es gegen eine reale Alternative gewinnt: bestehender Prozess, klassische Suche, Regelwerk, Formular, SQL-Abfrage, OCR ohne LLM oder gar keine Automatisierung. Ohne Nullvariante wird lediglich zwischen KI-Architekturen optimiert, obwohl KI selbst die falsche Lösung sein kann. ^{[S-069] [S-073] [S-119]}

B. Modell-, Token- und API-Kosten

Eingabe und Ausgabe haben unterschiedliche Preise

Aktuelle Anbieter rechnen Eingabe- und Ausgabetoken getrennt ab; Ausgabe ist häufig deutlich teurer. Deshalb kann eine kurze, präzise Antwort mehr sparen als eine kleine Kürzung des Eingabekontexts. Die Preisrelation ist modell- und serviceabhängig und muss aus der aktuellen Tabelle übernommen werden. ^{[S-001] [S-007] [S-014] [S-018]}

Ausgabelänge ist ein steuerbarer Kostentreiber

Maximale Ausgabetoken, strukturierte Schemata und klare Abbruchbedingungen begrenzen Kosten und Latenz. Eine pauschale Aufforderung zu ausführlichen Antworten erzeugt dagegen unkontrollierte Streuung. Die Grenze muss so gewählt werden, dass sie fachliche Vollständigkeit nicht zerstört. ^{[S-001] [S-147] [S-014]}

Reasoning- und Thinking-Token können abrechnungsrelevant sein

Bei Modellen mit internem Denken kann die Abrechnung nicht allein aus dem sichtbaren Antworttext abgeleitet werden. Anbieter weisen Thinking- oder Reasoning-Verbrauch unterschiedlich aus. Kostenmessung muss deshalb die tatsächlichen Usage-Felder der API und nicht nur Zeichen im Ergebnis erfassen. ^{[S-014] [S-001] [S-007]}

Langer Kontext kann eine neue Preisstufe auslösen

Einige Preistabellen unterscheiden Kurz- und Langkontext oder ändern Preise oberhalb definierter Schwellen. Dadurch kann ein kleiner Kontextzuwachs die gesamte Anfrage verteuern. Budgetwächter müssen die jeweils gültige Preisstufe kennen. ^{[S-001] [S-017] [S-008]}

Tokenisierung ist nicht über Anbieter hinweg identisch

Dasselbe Dokument kann je nach Tokenizer, Sprache und Format unterschiedlich viele Token erzeugen. Zeichen- oder Wortzählungen sind nur grobe Vorabschätzungen. Für belastbare Prognosen sind anbieterspezifische Tokenzähler oder gemessene API-Nutzungsdaten erforderlich. ^{[S-005] [S-014] [S-007]}

Freikontingente sind kein Produktionspreis

Kostenlose Stufen helfen beim Experimentieren, können aber andere Rate Limits, Datenbedingungen oder Funktionsgrenzen besitzen. Eine Produktionsrechnung muss den bezahlten Tarif und das erwartete Volumen zugrunde legen. Sonst kippt der Business Case beim Übergang aus dem Prototyp. ^{[S-014] [S-022] [S-023]}

Batch ist günstig, aber nicht interaktiv

Batchangebote senken bei mehreren Plattformen die direkte Modellrechnung, verlangen jedoch asynchrone Verarbeitung und tolerierte Wartezeit. Sie eignen sich für Backfills, nächtliche Extraktion, Evaluationsläufe oder Massenklassifikation. Für Echtzeitdialoge sind sie kein Ersatz. ^{[S-004] [S-016] [S-018] [S-019]}

Flexible Kapazität tauscht Preis gegen Planbarkeit

Flex- oder vergleichbare Servicestufen nutzen verfügbare Restkapazität und können billiger sein. Dafür sind längere Laufzeiten, geringere Verfügbarkeit oder Ressourcenknappheit möglich. Der Use Case muss Verzögerung und Wiederanlauf verkraften. ^{[S-003] [S-014] [S-017] [S-019]}

Prioritätsklassen sind eine bewusste Versicherung

Priority- oder Fast-Angebote erhöhen den Preis, um Latenz und Kapazitätszugang zu verbessern. Sie sind nur wirtschaftlich, wenn ein langsames Ergebnis messbar mehr Schaden verursacht als der Aufpreis. Ein pauschaler Einsatz für alle Anfragen verschwendet Budget. ^{[S-001] [S-014] [S-017]}

Regionale Verarbeitung kann einen Aufschlag auslösen

Datenresidenz und regionale Endpunkte können technisch oder vertraglich erforderlich sein, sind aber nicht immer preisneutral. Die Kalkulation muss konkrete Region, Endpoint-Typ und Anbieterhinweise berücksichtigen. Datenschutzanforderungen sind damit zugleich Kosten- und Architekturtreiber. ^{[S-001] [S-006] [S-017] [S-018]}

Cloud-Marktplätze können vom Direktpreis abweichen

Dasselbe Modell kann über Direkt-API, Bedrock, Vertex AI oder Azure andere Preise, Regionen, SLAs, Mindestmengen und Zusatzdienste haben. Ein Vergleich nur nach Modellname ist daher unvollständig. Entscheidend ist der tatsächlich bezogene Service. ^{[S-019] [S-017] [S-020] [S-007]}

Zeitlich begrenzte Einführungspreise sind kein Dauerbudget

Aktionspreise müssen mit Enddatum und künftigem Normalpreis dokumentiert werden. Ein Beispiel ist der für Claude Sonnet 5 ausgewiesene Einführungspreis bis zum 31. August 2026. Jahresbudgets sollten danach mindestens den regulären Listenpreis simulieren. ^{[S-007] [S-012]}

Modellabschaltungen erzeugen Migrationskosten

Preise sind nicht die einzige veränderliche Größe. Anbieter nehmen Modelle aus dem Betrieb, ändern Aliasse oder führen neue Versionen ein. Regressionstests, Promptanpassung und Freigabe der Nachfolgeversion gehören deshalb in die laufenden Kosten. ^{[S-011] [S-138] [S-139] [S-141]}

C. Kontext, Caching, Retrieval und Daten

Prompt Caching rabattiert nur wiederverwendbare Teile

Caching reduziert nicht automatisch den gesamten Eingabepreis. Nur ein identischer oder nach Anbieterregeln wiederverwendbarer Präfix profitiert. Dynamische Inhalte, wechselnde Reihenfolge oder geringe Wiederholung senken die Trefferquote. ^{[S-002] [S-009] [S-015] [S-018]}

Cache-Schreiben und -Speicherung können kostenpflichtig sein

Einige Plattformen unterscheiden Lesen, Schreiben und zeitabhängige Speicherung. Ein Cache lohnt sich daher erst bei ausreichender Wiederverwendung innerhalb des Gültigkeitsfensters. Reine Aktivierung ohne Hit-Rate-Messung kann Mehrkosten erzeugen. ^{[S-001] [S-009] [S-015]}

Semantisches Caching ist eine Qualitätsentscheidung

Ein semantischer Cache beantwortet ähnliche, nicht identische Anfragen aus früheren Ergebnissen. Das kann Modellaufrufe vermeiden, birgt aber Risiken bei Aktualität, Berechtigung und Bedeutungsabweichung. Schwellenwert, Mandantentrennung und Invalidierung müssen getestet werden. ^{[S-165] [S-093] [S-090]}

Kontextwachstum entsteht oft schleichend

Chatverläufe, Systemregeln, Toolbeschreibungen, Dokumente und Zwischenergebnisse werden bei jeder Runde erneut übertragen. Ohne Kompaktierung steigt die Eingabe mit der Sitzungsdauer. Das belastet Preis, Latenz und gegebenenfalls Antwortqualität. ^{[S-001] [S-148] [S-002]}

Mehr Kontext ist nicht automatisch mehr Qualität

Forschung zu langen Kontexten zeigt, dass relevante Information je nach Position schlechter genutzt werden kann. Eine große Kontextgrenze ersetzt daher keine Retrieval-, Auswahl- und Anordnungslogik. Ungefilterter Kontext kann zugleich Kosten und Fehlerrisiko erhöhen. ^{[S-148] [S-123]}

RAG hat Kosten vor und während jeder Anfrage

Retrieval-Augmented Generation verursacht Ingestion, Parsing, Chunking, Embeddings, Indexspeicher, Abfragen, Re-Ranking und zusätzlichen Modellkontext. Nur die Embeddingrechnung zu betrachten unterschätzt den Betrieb. Auch Neuindizierung und Löschung gehören dazu. ^{[S-053] [S-056] [S-057] [S-059]}

Embeddings sind oft klein, Reindexierung aber nicht kostenlos

Bei Text-RAG sind Embeddings häufig günstiger als Generierung. Große Bestände, häufige Aktualisierung, mehrere Modelle oder Dimensionswechsel können jedoch wiederholte Vollindizierung auslösen. Der Datenlebenszyklus muss deshalb als Pipeline geplant werden. ^{[S-053] [S-059] [S-121]}

Vektordatenbanken besitzen eine Grundlast

Managed Vector Stores rechnen nicht nur Suchanfragen ab, sondern je nach Produkt Kapazität, Speicher, Read/Write Units, Replikate oder Mindestpakete. Kleine Projekte können dadurch stärker von Mindestkosten als vom tatsächlichen Suchvolumen geprägt sein. ^{[S-052] [S-055] [S-057] [S-059]}

Chunking beeinflusst zugleich Qualität und Rechnung

Kleine Chunks erhöhen Anzahl und Metadaten; große Chunks übertragen mehr irrelevanten Text. Overlap vervielfacht gespeicherte und eingebettete Token. Die optimale Einstellung muss anhand echter Fragen, Treffer und Kosten gemessen werden. ^{[S-165] [S-053] [S-119]}

Re-Ranking kann Kontext sparen

Ein zusätzlicher Ranking-Schritt kostet selbst Rechenleistung, kann aber die Zahl der an das teure Generierungsmodell gesendeten Passagen reduzieren. Wirtschaftlich ist die Kombination, wenn der eingesparte Kontext und die bessere Trefferqualität den Re-Ranker übersteigen. ^{[S-069] [S-078] [S-165]}

Datenbereinigung ist Personalkosten, nicht Nebensache

Duplikate, veraltete Dateien, schlechte Scans, unklare Rechte und inkonsistente Metadaten erhöhen Fehlantworten und Nacharbeit. Der Aufwand fällt häufig außerhalb der API-Rechnung an. Er muss als Aufbau- und laufende Pflegeposition erfasst werden. ^{[S-089] [S-119] [S-093]}

Speicheroperationen und Egress zählen

Objektspeicher wird nach Kapazität, Operationen, Abrufklasse und Datenübertragung abgerechnet. Eine billige Gigabyte-Rate kann durch sehr viele kleine Zugriffe oder Cloud-Wechsel relativiert werden. Der Datenfluss ist deshalb konkreter als nur in Gigabyte pro Monat zu modellieren. ^{[S-040] [S-041] [S-042] [S-043]}

D. Agenten, Tools und multimodale Verarbeitung

Agenten vervielfachen Modellaufrufe

Ein Agentenlauf kann Planungs-, Tool-, Prüf- und Reparaturschritte enthalten. Die Kosten pro Nutzeraktion sind daher die Summe aller Modell- und Toolaufrufe, nicht der sichtbaren Endantwort. Maximalzahl, Zeitbudget und Tokenbudget je Lauf sind Pflicht. ^{[S-098] [S-099] [S-001]}

Toolschleifen brauchen harte Grenzen

Fehlerhafte Zustände oder unklare Abbruchkriterien können wiederholte Suche, Browseraufrufe oder API-Schritte auslösen. Neben Kosten entstehen Seiteneffekte und Belastung fremder Systeme. Loop-Counter, Idempotenz und Circuit Breaker reduzieren das Risiko. ^{[S-098] [S-153] [S-146]}

Websuche kann pro Suchvorgang berechnet werden

Grounding- und Suchdienste besitzen neben Tokenpreisen eigene Requestpreise. Eine Nutzerfrage kann mehrere Suchanfragen erzeugen. Kostenplanung muss zwischen Nutzeranfrage, Modellaufruf und tatsächlicher Zahl externer Suchen unterscheiden. ^{[S-014] [S-001] [S-019]}

Dokumenten-OCR hat eigene Einheiten

OCR- und Document-AI-Angebote rechnen beispielsweise pro Seite statt pro Texttoken. Danach können weitere Modellkosten für Klassifikation, Extraktion oder Prüfung anfallen. Ein Seitenpreis allein beschreibt daher nicht die gesamte Dokumentpipeline. ^{[S-018] [S-019] [S-017]}

Audio wird nach Minute, Token oder Zeichen abgerechnet

Transkription, Sprachverständnis und Sprachausgabe verwenden je nach Dienst verschiedene Einheiten. Pausen, Mehrkanalton, Echtzeitbetrieb und erneut erzeugte Sprache verändern die Rechnung. Sprachsysteme benötigen deshalb eine eigene Mengenlogik. ^{[S-018] [S-014] [S-001]}

Bilder und Video sind keine Textkosten

Vision-, Bildgenerierungs- und Videoangebote berechnen Auflösung, Dauer, Qualitätsstufe oder medienspezifische Token. Eine Umrechnung in Texttoken ist nur dann zulässig, wenn der Anbieter sie ausdrücklich definiert. Für Budgets sind Medienart und Qualitätsprofil separat zu führen. ^{[S-001] [S-014] [S-017]}

Human-in-the-Loop kostet Zeit und verhindert Schaden

Freigaben, Stichproben und Eskalation erhöhen zunächst Bearbeitungskosten. Bei rechtsrelevanten, finanziellen oder reputationskritischen Vorgängen können sie jedoch Fehlentscheidungen und teure Rückabwicklung verhindern. Die richtige Kennzahl ist daher Gesamtverlust, nicht maximale Automatisierungsquote. ^{[S-090] [S-091] [S-094]}

Dauerhafte Zustände vermeiden teure Wiederholungen

Queues, Checkpoints und idempotente Schritte erlauben Wiederaufnahme nach Fehlern. Ohne sie wird ein langer Lauf vollständig neu gestartet und bezahlt. Zustandsmanagement ist damit sowohl Reliability- als auch Kostenfunktion. ^{[S-105] [S-106] [S-150] [S-173]}

Missbrauchsschutz ist Kostenkontrolle

Offene Endpunkte können durch Bots, gestohlene Schlüssel oder Prompt-Angriffe hohe Verbräuche auslösen. Authentifizierung, Quoten, Rate Limits, Ausgabenlimits und Alarmierung begrenzen nicht nur Sicherheitsrisiken, sondern den finanziellen Blast Radius. ^{[S-098] [S-140] [S-167] [S-160]}

E. API, Managed Service und Self-hosting

API ist bei kleinen und unsicheren Lasten häufig die Referenz

Nutzungsbasierte APIs vermeiden eigene GPU-Fixkosten und verkürzen den Start. Das macht sie besonders für Pilotphasen und schwankende Volumina attraktiv. Der Vorteil kann bei sehr hoher, stabiler Last oder besonderen Kontrollanforderungen abnehmen. ^{[S-001] [S-008] [S-014] [S-068]}

Managed Plattformen verkaufen mehr als Rechenzeit

Bedrock, Vertex AI, Azure und andere Plattformen bündeln Identität, Regionen, Monitoring, Netzwerkoptionen und Unternehmensverträge. Ein Preisaufschlag kann wirtschaftlich sein, wenn dadurch Integrations- oder Governanceaufwand sinkt. Vergleichbar ist nur der vollständige Serviceumfang. ^{[S-019] [S-017] [S-020] [S-073]}

Self-hosting verschiebt Kosten statt sie zu löschen

Open-Weight-Modelle beseitigen den Tokenpreis eines externen APIs, erzeugen aber GPU-, Speicher-, Netzwerk-, Orchestrierungs-, Update-, Bereitschafts- und Fachpersonalkosten. Auch ungenutzte Kapazität wird bezahlt. Open Source bedeutet daher nicht kostenloser Betrieb. ^{[S-100] [S-102] [S-107] [S-024]}

Auslastung entscheidet über Self-hosting

Eine GPU-Instanz wird pro Zeit oder reservierter Kapazität bezahlt, unabhängig davon, wie viele verwertbare Antworten entstehen. Hohe, gleichmäßige Auslastung verteilt Fixkosten; Burstlast lässt Hardware leer oder zwingt zu Überprovisionierung. Gemessene Tokens pro GPU-Sekunde und P95-Latenz sind zentrale Größen. ^{[S-080] [S-038] [S-039] [S-024]}

Modellgröße ist eine Kapazitätsgrenze

Gewichte, KV-Cache, Aktivierungen und Parallelität beanspruchen Speicher. Ein Modell, das technisch auf eine GPU passt, kann unter langen Kontexten oder parallelen Anfragen dennoch aus dem Speicher laufen. Kapazitätsplanung muss Lastprofil und Servingverfahren gemeinsam betrachten. ^{[S-080] [S-087] [S-100]}

Batching tauscht Latenz gegen Effizienz

Dynamisches Batching bündelt Anfragen und erhöht die Hardwarenutzung. Es kann jedoch Wartezeit und Tail-Latenz erhöhen. Für interaktive Anwendungen braucht es Grenzen, für Offlineverarbeitung darf die Batchgröße größer sein. ^{[S-038] [S-080] [S-106]}

Quantisierung ist kein kostenloser Schalter

Weniger Bit reduzieren Speicher und können Durchsatz verbessern, beeinflussen aber je nach Modell, Aufgabe und Hardware die Qualität. Die Wirkung muss auf dem eigenen Evaluationssatz geprüft werden. Außerdem entstehen Konvertierungs-, Kompatibilitäts- und Wartungsaufwände. ^{[S-085] [S-084] [S-086] [S-165]}

Serving-Software kann den Durchsatz deutlich verändern

PagedAttention, optimierte Attention-Kernels, Speculative Decoding und spezialisierte Server adressieren Speicher- und Decodingengpässe. Veröffentlichte Gewinne gelten jedoch nur für die jeweiligen Tests. Eine eigene Lastmessung bleibt notwendig. ^{[S-080] [S-081] [S-082] [S-083]}

Spot-Kapazität ist billig, aber unterbrechbar

Cloud-Spotangebote können gegenüber On-Demand erheblich günstiger sein, dürfen jedoch entzogen werden. Sie passen zu fehlertoleranten Batchjobs, Training oder replizierten Workern. Ein einzelner interaktiver Produktionsserver ohne Checkpointing ist dafür ungeeignet. ^{[S-025] [S-105] [S-150]}

Reservierung lohnt nur bei belastbarer Grundlast

Kapazitätsblöcke, Commitments und reservierte Instanzen reduzieren Unsicherheit oder Einheitspreise, binden aber Budget. Vor Abschluss müssen Grundlast, Wachstumsband und Migrationsrisiko bekannt sein. Sonst wird ein Rabatt zur Leerkostenquelle. ^{[S-026] [S-072] [S-074] [S-075]}

Lokaler Betrieb ist nicht automatisch datenschutzkonform

On-Premises oder Edge verringern bestimmte Datenflüsse, ersetzen aber weder Rechtsgrundlage noch Zugriffsschutz, Löschung, Protokollierung und Sicherheitsbetrieb. Die Organisation übernimmt mehr Verantwortung selbst. Datenschutz und Sicherheit müssen als Betriebsaufwand kalkuliert werden. ^{[S-093] [S-090] [S-163]}

Lizenzbedingungen können die Architektur bestimmen

Verfügbare Gewichte sind nicht zwingend Open Source. Modell-, Code- und Datenlizenzen können Einsatzgebiet, Weitergabe, Copyleft oder kommerzielle Nutzung regeln. Vor Self-hosting ist eine konkrete Lizenzprüfung erforderlich. ^{[S-107] [S-108] [S-109] [S-018]}

Hardwarepreise und Generationen ändern den Break-even

GPU-Preise, neue Instanztypen und Leistungssteigerungen verschieben die wirtschaftliche Grenze fortlaufend. Ein einmal berechneter Break-even ist daher keine dauerhafte Wahrheit. Refresh-Zyklen und Restwert beziehungsweise Mietflexibilität gehören in das Modell. ^{[S-029] [S-027] [S-028] [S-032]}

Portabilität hat einen Optionswert

Ein Providerwechsel ist leichter, wenn Modellaufrufe, Evaluationsdaten, Prompts, Telemetrie und Toolverträge getrennt verwaltet werden. Diese Abstraktion kostet initial, kann aber spätere Preis- oder Lebenszyklusänderungen abfedern. Vollständige Austauschbarkeit ist wegen unterschiedlicher Fähigkeiten selten erreichbar. ^{[S-011] [S-138] [S-099] [S-115]}

F. Datenbank, Observability und Reliability

Datenbanken kosten mehr als Speicherplatz

Managed PostgreSQL und ähnliche Dienste berechnen Compute, Storage, I/O, Backups, Hochverfügbarkeit und Netzwerk. Replikate oder Multi-Zone-Betrieb verdoppeln nicht nur Sicherheit, sondern oft wesentliche Kostenblöcke. Die Datenbank ist deshalb als Dienstprofil zu kalkulieren. ^{[S-045] [S-047] [S-049] [S-050]}

Veraltete Datenbankversionen können Aufschläge erzeugen

Managed Anbieter berechnen für verlängerten Support älterer Versionen teilweise Zusatzgebühren. Aufgeschobene Upgrades sind damit kein kostenfreier Zustand. Migration, Test und Upgradefenster müssen in der Roadmap stehen. ^{[S-046] [S-048] [S-134]}

Backups sind nur mit Restore-Test eine Absicherung

Speicher für Sicherungen ist eine Kostenposition; ungetestete Sicherungen bieten dennoch keine belastbare Wiederherstellung. Regelmäßige Restore-Übungen, Aufbewahrung und RPO/RTO erhöhen Aufwand, senken aber das Risiko existenzgefährdender Datenverluste. ^{[S-172] [S-117] [S-150]}

Telemetry kann selbst zum Großverbraucher werden

Logs, Traces, Metriken, Prompt-/Response-Metadaten und Profile wachsen mit jedem Request. Anbieter rechnen nach Hosts, Datenmenge, aktiven Zeitreihen oder Retention. Unbegrenzte Vollerfassung kann die Modellkosten überholen. ^{[S-060] [S-061] [S-063] [S-064]}

Sampling spart Geld und kann Fehler verbergen

Trace-Sampling reduziert Datenmenge, darf aber seltene, teure oder fehlerhafte Läufe nicht systematisch ausblenden. Head-, Tail- und regelbasiertes Sampling haben unterschiedliche Eigenschaften. Kosten- und Incident-Fragen benötigen gezielte Aufbewahrung. ^{[S-064] [S-062] [S-149]}

OpenTelemetry senkt nicht automatisch die Rechnung

Offene Telemetriestandards reduzieren Lock-in und vereinheitlichen Daten, erzeugen aber weiterhin Erfassungs-, Collector-, Speicher- und Analyseaufwand. Der Vorteil liegt in Kontrollierbarkeit und Portabilität, nicht in kostenfreier Beobachtung. ^{[S-065] [S-099] [S-066]}

Reliability braucht eine finanzierte Reserve

Kapazitätspuffer, Replikate, Failover und Bereitschaft wirken im Normalbetrieb wie Leerkosten. Sie kaufen jedoch Verfügbarkeit und begrenzen Ausfallschäden. Das richtige Niveau folgt aus SLO, Geschäftsfolgen und Wiederanlaufzeit. ^{[S-170] [S-171] [S-117]}

Multi-Region ist keine Gratisversicherung

Mehrere Regionen erhöhen Compute, Replikation, Datenübertragung, Tests und operative Komplexität. Sie sind nur gerechtfertigt, wenn Ausfall- oder Datenresidenzanforderungen den Aufwand tragen. Ein ungetestetes Multi-Region-Design kann trotz Mehrkosten versagen. ^{[S-044] [S-033] [S-150]}

Fehlerbudgets verbinden Zuverlässigkeit und Geschwindigkeit

SLO und Fehlerbudget machen sichtbar, wie viel Unzuverlässigkeit akzeptiert wird. Ohne diese Grenze wird entweder zu wenig abgesichert oder jede denkbare Störung mit unverhältnismäßigem Aufwand bekämpft. Die ökonomische Entscheidung braucht Wirkung und Wahrscheinlichkeit. ^{[S-170] [S-149] [S-158]}

Stilllegung verursacht Abschlusskosten

Modelle, Indizes, Secrets, Datenkopien, Verträge, Dashboards und Zugriffsrechte müssen kontrolliert entfernt oder archiviert werden. Sonst laufen Rechnungen weiter oder Daten bleiben unzulässig verfügbar. Decommissioning ist ein geplanter Lebenszyklusabschnitt. ^{[S-110] [S-093] [S-167]}

G. Menschen, Qualität, Governance und Risiko

Entwicklungszeit dominiert kleine KI-Projekte häufig

Bei niedrigen Volumina können wenige Euro Modellkosten neben vielen Stunden Integration, Datenarbeit, Tests und Fachabnahme stehen. Tokenoptimierung vor Prozessvereinfachung spart dann am falschen Ende. Arbeitszeit ist mit realistischem Vollkostensatz anzusetzen. ^{[S-068] [S-089] [S-159]}

Evaluation ist eine laufende Betriebsfunktion

Qualität muss bei Modell-, Prompt-, Daten- und Tooländerungen erneut geprüft werden. Evaluationssätze, Labeling, Review und Vergleichsläufe verbrauchen Personal und API-Budget. Ohne diese Kosten wird ein System nur scheinbar günstig betrieben. ^{[S-165] [S-166] [S-123]}

Manuelle Nacharbeit muss gemessen werden

Wenn Mitarbeitende Antworten korrigieren, Quellen suchen oder Formatfehler bereinigen, entsteht versteckte Bearbeitungszeit. Diese Zeit gehört pro Fall erfasst und mit dem Ausgangsprozess verglichen. Sonst wird Arbeit lediglich aus der Hauptaufgabe in Qualitätskontrolle verschoben. ^{[S-112] [S-069] [S-090]}

Support und Bereitschaft sind Teil der Stückkosten

Produktive Systeme benötigen Ansprechpartner, Incidentbearbeitung, Anbieterkommunikation und gelegentlich Rufbereitschaft. Der Aufwand wächst nicht linear mit Token, sondern mit Kritikalität, Nutzerzahl und Integrationsbreite. Er ist als fixe oder gestufte Kostenposition zu führen. ^{[S-170] [S-171] [S-161]}

Security ist keine einmalige Prüfung

Secrets, Abhängigkeiten, Prompt Injection, Berechtigungen und Missbrauch entwickeln sich weiter. Scans, Updates, Penetrationstests, Audit und Incident Response erzeugen laufenden Aufwand. Ein nicht finanzierter Sicherheitsbetrieb ist lediglich aufgeschobenes Risiko. ^{[S-098] [S-097] [S-164] [S-137]}

Compliance-Aufwand hängt vom Einsatz ab

Datenschutz, AI Act, Cyber Resilience Act und Branchenregeln wirken je nach Rolle, Daten und Risikoklasse unterschiedlich. Dokumentation, Verträge, Risikomanagement, Überwachung und Support können relevante TCO-Blöcke sein. Eine pauschale Prozentzahl ist nicht belastbar. ^{[S-093] [S-094] [S-095] [S-092]}

Modellmigration ist planbare Wartung

Ein Wechsel umfasst nicht nur die API-ID. Er kann Tokenisierung, Tool Calling, Ausgabeformat, Moderation, Latenz und fachliche Qualität verändern. Budget und Kalender brauchen regelmäßige Migrationsfenster. ^{[S-011] [S-139] [S-141] [S-165]}

Schattennutzung verhindert Steuerung

Wenn Teams private Schlüssel, Einzelabos oder unmarkierte Workloads verwenden, fehlen Kostenallokation, Datenschutzprüfung und gemeinsame Optimierung. Zentraler Zugang allein reicht nicht; er muss nutzbar, schnell und transparent sein. Governance soll den sicheren Weg leichter machen. ^{[S-068] [S-092] [S-090]}

Showback kommt vor Chargeback

Zunächst sollte Nutzung sichtbar gemacht werden, ohne sofort interne Rechnungen zu stellen. Showback schafft Verständnis für Treiber und Datenqualität. Chargeback ist erst sinnvoll, wenn Zuordnung und Einheit belastbar sind. ^{[S-067] [S-069] [S-071]}

Bruttomarge braucht Kosten pro erfolgreicher Einheit

Bei einem KI-Produkt genügt Umsatz pro Nutzer nicht. Modell, Plattform, Support, Zahlung, Ausfälle und variable Tools müssen dem tatsächlich gelieferten Ergebnis gegenüberstehen. Nur dann lässt sich erkennen, ob Wachstum Marge schafft oder Verlust skaliert. ^{[S-069] [S-070] [S-068]}

Kostenoptimierung ist ein Regelkreis

Preise, Modelle, Nutzungsverhalten und Qualität ändern sich laufend. Messen, Hypothese, Test, Rollout und Nachkontrolle müssen wiederholt werden. Ein einmaliger „günstigeres Modell“-Wechsel ist kein FinOps-Prozess. ^{[S-067] [S-072] [S-074] [S-075]}

Das billigste Modell ist nicht automatisch wirtschaftlich

Ein günstigeres Modell kann durch geringere Erfolgsquote, mehr Rückfragen, längere Prompts oder zusätzliche Prüfungen teurer werden. Routing und Kaskaden brauchen deshalb Qualitätsgrenzen je Aufgabentyp. Kosten werden auf das akzeptierte Ergebnis bezogen. ^{[S-077] [S-078] [S-079] [S-165]}

Weniger KI kann die beste Optimierung sein

Validierung, Sortierung, Berechnungen und Datenbankabfragen sind häufig deterministisch lösbar. Wenn klassische Software dieselbe Aufgabe zuverlässiger und billiger erledigt, sollte das LLM nur die unstrukturierte Teilaufgabe übernehmen oder ganz entfallen. Das ist Architekturdisziplin, kein Rückschritt. ^{[S-119] [S-069] [S-073]}

32 Praxisfelder der technischen Kostenrechnung

Jedes Praxisfeld wird mit Leitfrage, Messgrößen, typischen Fehlannahmen und einer Entscheidungsregel beschrieben. Die Felder bilden zusammen eine produktionsfähige Kostenanalyse. ^{[S-067] [S-073] [S-171]}

Nachfrage, Volumen und Lastform

Geschäftliche Einheit und Baseline

Token- und Usage-Metering

Prompt- und Kontextbudget

Ausgabeformat und Antwortlänge

Prompt- und Kontext-Caching

Batch-, Flex- und Prioritätsklassen

Modellwahl, Routing und Kaskaden

Retries, Fallbacks und Idempotenz

Agenten- und Toolbudget

Suche, Grounding und externe Werkzeuge

OCR, Sprache, Bilder und Video

RAG-Ingestion und Aktualisierung

Retrieval- und Vektordatenbankbetrieb

Datenhaltung, Retention und Löschung

Direkt-API versus Cloud-Marktplatz

Managed AI-Plattform

Self-hosting und Open-Weight-Modelle

GPU-Sizing und Serving

Queueing, Autoscaling und Kapazitätspuffer

Transaktionsdatenbank und Zustandsbetrieb

Objektspeicher, Abruf und Datenverkehr

Logs, Metriken, Traces und Profile

Qualitätsevaluation und Freigabe

Sicherheit, Quoten und finanzieller Blast Radius

Verfügbarkeit, Backup und Disaster Recovery

Datenschutz, AI Act und Dokumentation

Team, Support und Bereitschaft

Anbieter-, Modell-, Lizenz- und Exit-Risiko

Budget, Forecast, Showback und Alarmierung

Energie und Umweltwirkung

Stilllegung und Kostenabschluss

25 Anbieter- und Technikprofile

Die Profile dienen nicht als Kaufempfehlung. Sie zeigen Abrechnungslogik, Nutzen, Risiken und die jeweils notwendige Entscheidungsregel.

OpenAI API

Anthropic Claude API

Google Gemini Developer API

Mistral API

Amazon Bedrock

Vertex AI Generative AI

Azure OpenAI und AI Foundry

Hugging Face Inference Providers

Serverless CPU/Container

On-Demand-GPU in der Cloud

Spot-/Preemptible-GPU

Reservierte oder blockierte GPU-Kapazität

vLLM

Triton und TensorRT-LLM

llama.cpp und Ollama

Objektspeicher

Managed PostgreSQL

Supabase

Pinecone

Qdrant Cloud

Weaviate Cloud

OpenTelemetry

Kommerzielle Observability-Plattformen

FinOps Framework und FOCUS

Routing, Caching und Kaskaden als Optimierungsschicht

12 dokumentierte Kosten- und Kapazitätslektionen

LESEHINWEIS: Forschungsergebnisse und Anbieteränderungen werden nur im dokumentierten Kontext wiedergegeben. Prozentwerte aus Benchmarks sind keine allgemeine Einspargarantie.

FrugalGPT: Kaskaden können Kosten stark senken – im jeweiligen Experiment

RouteLLM: Ein Router ist selbst ein Modell- und Evaluationsproblem

vLLM/PagedAttention: Serving-Software verschiebt die Hardwareökonomie

FlashAttention: Speicherbewegung kann wichtiger sein als reine Rechenoperationen

Speculative Decoding: Zusätzliche Rechenarbeit kann die Latenz senken

QLoRA und AWQ: Quantisierung spart Speicher, verlangt aber Qualitätsprüfung

AWS-GPU-Preissenkung: Ein Break-even altert auch ohne Codeänderung

Cloudflare R2: Kostenloser Egress beseitigt nicht alle Speicherkosten

RDS Extended Support: Nicht migrieren kann eine direkte Rechnung erzeugen

Gemini Grounding: Eine Nutzerfrage kann mehrere kostenpflichtige Suchqueries auslösen

Claude Sonnet 5: Einführungspreis endet innerhalb des Budgetjahres

Observability-Sampling: Weniger Telemetrie kann Kosten senken und Erkenntnis kosten

18 transparente Modellrechnungen

Alle Szenarien sind Rechenbeispiele, keine Marktangebote. Öffentliche Token-, Seiten- oder Minutenpreise stammen aus den angegebenen Preisquellen. Personal, Plattform, Storage, Auslastung, Erfolg und Reserve sind ausdrücklich bezeichnete Annahmen. Beträge sind netto in US-Dollar; Wechselkurs und Umsatzsteuer fehlen bewusst.

Kleiner FAQ-Assistent für eine Unternehmenswebsite

Ausgangslage: 10.000 Nutzerfragen monatlich; kurze Antworten; statischer Systemkontext ist teilweise cachefähig. ^{[S-001] [S-002] [S-069]} Mengen: 10.000 Requests × 800 Input × 180 Output; Cache 40 %; Batchrabatt 0 %; Retry-Faktor 1,03; Erfolgsquote 86,0 %. Modell: Economy-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 8.240.000 Input- und 1.854.000 Outputtoken. Direkte Inputkosten 1,05 USD; direkte Outputkosten 2,22 USD; nach Batch/Flex 3,28 USD.

ERGEBNIS: 8.600 erfolgreiche Einheiten; Vollkosten 537,11 USD; 0,062454 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,6 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Kundenservice-Assistent mit CRM-Übergabe

Ausgangslage: 100.000 Vorgänge, davon 91 Prozent nach Qualitätsregel erfolgreich; mehrere Integrationen und Eskalation. ^{[S-014] [S-069] [S-099]} Mengen: 100.000 Requests × 1.400 Input × 280 Output; Cache 55 %; Batchrabatt 0 %; Retry-Faktor 1,06; Erfolgsquote 91,0 %. Modell: Balanced-Textmodell ^[S-014] Abgerechnete Mengen nach Retry: 148.400.000 Input- und 29.680.000 Outputtoken. Direkte Inputkosten 112,41 USD; direkte Outputkosten 222,60 USD; nach Batch/Flex 335,01 USD.

ERGEBNIS: 91.000 erfolgreiche Einheiten; Vollkosten 5.258 USD; 0,057785 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 6,4 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Interner Wissensassistent mit umfangreichem RAG

Ausgangslage: Langer Retrievalkontext und höhere Qualitätsanforderung; Datenpflege dominiert gegenüber reinen Tokenkosten. ^{[S-001] [S-053] [S-148]} Mengen: 20.000 Requests × 5.500 Input × 450 Output; Cache 35 %; Batchrabatt 0 %; Retry-Faktor 1,04; Erfolgsquote 88,0 %. Modell: Premium-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 114.400.000 Input- und 9.360.000 Outputtoken. Direkte Inputkosten 391,82 USD; direkte Outputkosten 280,80 USD; nach Batch/Flex 672,62 USD.

ERGEBNIS: 17.600 erfolgreiche Einheiten; Vollkosten 5.201 USD; 0,295512 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 12,9 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Nächtliche E-Mail-Klassifikation im Batch

Ausgangslage: Hohe Menge, kurze strukturierte Ausgabe, keine Interaktion; daher Batch als passende Serviceklasse. ^{[S-018] [S-105] [S-147]} Mengen: 500.000 Requests × 550 Input × 45 Output; Cache 0 %; Batchrabatt 50 %; Retry-Faktor 1,02; Erfolgsquote 97,5 %. Modell: Mistral Small 4 ^[S-018] Abgerechnete Mengen nach Retry: 280.500.000 Input- und 22.950.000 Outputtoken. Direkte Inputkosten 42,07 USD; direkte Outputkosten 13,77 USD; nach Batch/Flex 27,92 USD.

ERGEBNIS: 487.500 erfolgreiche Einheiten; Vollkosten 1.445 USD; 0,002964 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 1,9 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Rechnungs-OCR mit anschließender Plausibilisierung

Ausgangslage: Drei Seiten pro Dokument im Mittel; OCR-Seitenpreis und menschliche Stichprobe werden getrennt ausgewiesen. ^{[S-018] [S-040] [S-069]} Mengen: 100.000 Requests × 900 Input × 120 Output; Cache 0 %; Batchrabatt 50 %; Retry-Faktor 1,05; Erfolgsquote 94,0 %. Modell: Mistral Small 4 ^[S-018] Abgerechnete Mengen nach Retry: 94.500.000 Input- und 12.600.000 Outputtoken. Direkte Inputkosten 14,17 USD; direkte Outputkosten 7,56 USD; nach Batch/Flex 10,87 USD.

ERGEBNIS: 94.000 erfolgreiche Einheiten; Vollkosten 12.142 USD; 0,129168 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,1 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Marketingtexte mit verpflichtender Redaktionsfreigabe

Ausgangslage: Das Modell ist billig gegenüber der redaktionellen Pflichtprüfung; Automatisierungsquote darf nicht mit Personaleinsparung verwechselt werden. ^{[S-001] [S-090] [S-069]} Mengen: 5.000 Requests × 1.800 Input × 900 Output; Cache 15 %; Batchrabatt 0 %; Retry-Faktor 1,12; Erfolgsquote 96,0 %. Modell: Premium-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 10.080.000 Input- und 5.040.000 Outputtoken. Direkte Inputkosten 43,60 USD; direkte Outputkosten 151,20 USD; nach Batch/Flex 194,80 USD.

ERGEBNIS: 4.800 erfolgreiche Einheiten; Vollkosten 52.852 USD; 11,010737 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,4 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Interner Coding-Assistent für 50 Entwickler

Ausgangslage: API-basierter Unternehmensdienst; Erfolg bedeutet akzeptierte Hilfe, nicht lediglich erzeugten Code. ^{[S-001] [S-165] [S-097]} Mengen: 100.000 Requests × 3.200 Input × 900 Output; Cache 30 %; Batchrabatt 0 %; Retry-Faktor 1,08; Erfolgsquote 82,0 %. Modell: Premium-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 345.600.000 Input- und 97.200.000 Outputtoken. Direkte Inputkosten 1.261 USD; direkte Outputkosten 2.916 USD; nach Batch/Flex 4.177 USD.

ERGEBNIS: 82.000 erfolgreiche Einheiten; Vollkosten 12.762 USD; 0,155635 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 32,7 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Recherche-Agent mit kostenpflichtigem Search Grounding

Ausgangslage: Annahme: durchschnittlich 2,4 Queries je Lauf, abzüglich 5.000 Freikontingent; Suchquote muss real gemessen werden. ^{[S-014] [S-099] [S-165]} Mengen: 20.000 Requests × 2.400 Input × 700 Output; Cache 20 %; Batchrabatt 0 %; Retry-Faktor 1,07; Erfolgsquote 84,0 %. Modell: Balanced-Textmodell ^[S-014] Abgerechnete Mengen nach Retry: 51.360.000 Input- und 14.980.000 Outputtoken. Direkte Inputkosten 63,17 USD; direkte Outputkosten 112,35 USD; nach Batch/Flex 175,52 USD.

ERGEBNIS: 16.800 erfolgreiche Einheiten; Vollkosten 9.105 USD; 0,541973 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 1,9 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Transkription von 1.000 Audiostunden

Ausgangslage: Minutenbasierter Spezialpreis; Textmodellnutzung wird als separate Pauschalannahme geführt. ^{[S-018] [S-040] [S-069]}

ERGEBNIS: 57.000 erfolgreiche Einheiten; Vollkosten 4.466 USD; 0,078351 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,0 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Aufbau eines RAG-Index mit einer Million Dokumenten

Ausgangslage: Einmaliges Aufbauprojekt; die größten Positionen sind als Annahmen für Datenarbeit und Indexbetrieb sichtbar. ^{[S-053] [S-056] [S-121] [S-089]} Mengen: 1.000.000 Requests × 350 Input × 20 Output; Cache 0 %; Batchrabatt 50 %; Retry-Faktor 1,03; Erfolgsquote 98,0 %. Modell: Mistral Small 4 ^[S-018] Abgerechnete Mengen nach Retry: 360.500.000 Input- und 20.600.000 Outputtoken. Direkte Inputkosten 54,07 USD; direkte Outputkosten 12,36 USD; nach Batch/Flex 33,22 USD.

ERGEBNIS: 980.000 erfolgreiche Einheiten; Vollkosten 50.320 USD; 0,051347 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,1 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Nächtliche Zusammenfassung von einer Million Datensätzen

Ausgangslage: Deadline innerhalb eines Tages; Economy-Modell und Batch halbieren die direkte Modellrechnung in dieser Annahme. ^{[S-001] [S-004] [S-069]} Mengen: 1.000.000 Requests × 1.000 Input × 180 Output; Cache 0 %; Batchrabatt 50 %; Retry-Faktor 1,02; Erfolgsquote 97,0 %. Modell: Economy-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 1.020.000.000 Input- und 183.600.000 Outputtoken. Direkte Inputkosten 204,00 USD; direkte Outputkosten 220,32 USD; nach Batch/Flex 212,16 USD.

ERGEBNIS: 970.000 erfolgreiche Einheiten; Vollkosten 2.840 USD; 0,002928 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 7,5 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Vertragsprüfung mit hohem Schadenspotenzial

Ausgangslage: KI unterstützt, ersetzt aber die angenommene juristische Freigabe nicht; Tokenkosten sind ökonomisch nahezu irrelevant. ^{[S-001] [S-090] [S-093]} Mengen: 2.000 Requests × 18.000 Input × 1.800 Output; Cache 10 %; Batchrabatt 0 %; Retry-Faktor 1,05; Erfolgsquote 95,0 %. Modell: Premium-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 37.800.000 Input- und 3.780.000 Outputtoken. Direkte Inputkosten 171,99 USD; direkte Outputkosten 113,40 USD; nach Batch/Flex 285,39 USD.

ERGEBNIS: 1.900 erfolgreiche Einheiten; Vollkosten 584.102 USD; 307,422222 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,0 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Kleine lokale Inferenz auf einer einzelnen GPU

Ausgangslage: Illustrative Mietannahme; 24/7-Betrieb trotz nur 30 Prozent mittlerer GPU-Auslastung. Kein externer Tokenpreis. ^{[S-024] [S-100] [S-102]}

ERGEBNIS: 50.000 erfolgreiche Einheiten; Vollkosten 5.348 USD; 0,106950 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,0 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Stabile Hochlast auf vier eigenen Cloud-GPUs

Ausgangslage: Illustrative Vollauslastungsarchitektur mit vier GPUs; tatsächlicher Durchsatz muss benchmarkbasiert nachgewiesen werden. ^{[S-080] [S-038] [S-024]}

ERGEBNIS: 12.000.000 erfolgreiche Einheiten; Vollkosten 28.292 USD; 0,002358 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 0,0 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Break-even-Vergleich API gegen Self-hosting

Ausgangslage: Vergleich einer stabilen Monatslast von 8 Mio. erfolgreichen Antworten; API- und Eigenbetrieb erhalten dieselben Personal- und Qualitätsgrenzen. ^{[S-069] [S-080] [S-001]}

Ergebnis unter diesen Annahmen: API 36.975 USD beziehungsweise 0,004622 USD je erfolgreicher Einheit; Self-hosting 60.145 USD beziehungsweise 0,007518 USD. Die Differenz ist kein universeller Break-even, sondern folgt aus den gewählten Personal- und Kapazitätsannahmen. Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Mehrmandanten-SaaS mit 500 Unternehmenskunden

Ausgangslage: Kosten werden zusätzlich pro Tenant und erfolgreichem Vorgang ausgewiesen; Long-Tail-Kunden dürfen nicht im Mittel verschwinden. ^{[S-001] [S-069] [S-099]} Mengen: 2.500.000 Requests × 900 Input × 220 Output; Cache 50 %; Batchrabatt 10 %; Retry-Faktor 1,05; Erfolgsquote 90,0 %. Modell: Economy-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 2.362.500.000 Input- und 577.500.000 Outputtoken. Direkte Inputkosten 259,88 USD; direkte Outputkosten 693,00 USD; nach Batch/Flex 857,59 USD.

ERGEBNIS: 2.250.000 erfolgreiche Einheiten; Vollkosten 39.166 USD; 0,017407 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 2,2 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Saisonales E-Commerce-System mit sechsfachem Peak

Ausgangslage: Monatssumme reicht nicht: sechsfacher Peak verlangt Queue, Puffer oder Priority. Reserve ist bewusst höher. ^{[S-014] [S-105] [S-170]} Mengen: 600.000 Requests × 1.100 Input × 260 Output; Cache 45 %; Batchrabatt 0 %; Retry-Faktor 1,08; Erfolgsquote 89,0 %. Modell: Balanced-Textmodell ^[S-014] Abgerechnete Mengen nach Retry: 712.800.000 Input- und 168.480.000 Outputtoken. Direkte Inputkosten 636,17 USD; direkte Outputkosten 1.264 USD; nach Batch/Flex 1.900 USD.

ERGEBNIS: 534.000 erfolgreiche Einheiten; Vollkosten 16.875 USD; 0,031601 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 11,3 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Regulierter Enterprise-Betrieb mit zwei Regionen

Ausgangslage: Zwei Regionen, formalisierter Betrieb und Audit; die Kostentreiber sind Governance und Verfügbarkeit, nicht allein Tokens. ^{[S-001] [S-094] [S-095] [S-117]} Mengen: 1.000.000 Requests × 2.200 Input × 500 Output; Cache 40 %; Batchrabatt 0 %; Retry-Faktor 1,04; Erfolgsquote 93,0 %. Modell: Premium-Textmodell ^[S-001] Abgerechnete Mengen nach Retry: 2.288.000.000 Input- und 520.000.000 Outputtoken. Direkte Inputkosten 7.322 USD; direkte Outputkosten 15.600 USD; nach Batch/Flex 22.922 USD.

ERGEBNIS: 930.000 erfolgreiche Einheiten; Vollkosten 112.346 USD; 0,120802 USD je erfolgreicher Einheit. Anteil direkter Modellkosten: 20,4 %.

Sensitivität: Das Ergebnis muss mindestens gegen ±30 Prozent Volumen, veränderte Erfolgsquote, doppelten Output, Preisänderung und zusätzliche Reviewzeit getestet werden. Bei Self-hosting sind Auslastung und Personal der erste Prüfpunkt.

Szenarioübersicht

Architektur- und Beschaffungsentscheidung

Abbildung 4: Illustrative Kostenkurven für API, dedizierte Kapazität und Self-hosting – im PDF und DOCX eingebettet.

*Eigene Annahmen; ausschließlich zur Darstellung der Fix-/Variabellogik.*

*Tabelle 3: Qualitative Entscheidungsmatrix; konkrete Preise bleiben use-case- und vertragsabhängig*

Entscheidungsschwellen

Optimierungshebel – Reihenfolge vor Radikalität

Abbildung 5: Illustrative Optimierungsleiter – im PDF und DOCX eingebettet.

*Eigene Darstellung. Restkostenindex ist kein empirischer Marktwert.*

Abbildung 6: Wirkung einer steigenden Cache-Trefferquote auf ein Beispiel – im PDF und DOCX eingebettet.

*Eigene Berechnung: 1 Mio. Anfragen, 2.000 Input, 400 Output, Balanced-Preis; Cachefaktor 0,1.*

56-stufiger Weg zu belastbaren KI-Betriebskosten

Phase 1 – Geschäft und Messgrenze

Phase 2 – Mengen- und Qualitätsmodell

Phase 3 – Architektur- und Beschaffungsoptionen

Phase 4 – Vollkostenmodell und Entscheidung

Phase 5 – Produktionskontrollen

Phase 6 – Laufende Steuerung und Optimierung

Phase 7 – Lebenszyklus, Migration und Stilllegung

Checklisten

Vor der ersten Kalkulation

• ☐ Fachlichen Vorgang und Nullvariante schriftlich definiert.
• ☐ Erfolg und unzulässige Fehler messbar festgelegt.
• ☐ Volumen, Peak, Parallelität und Deadline erfasst.
• ☐ Reale Token- und Toolstichprobe vorhanden.
• ☐ Aktuelle Preislisten mit Datum, Region, Währung und Tarif gesichert.
• ☐ Personalkostensätze und Reviewzeit vereinbart.
• ☐ Rechts-/Risikorolle des Systems geprüft.
• ☐ Abbruchgrenze für den Business Case festgelegt.

Für jede Monatsrechnung

• ☐ Uncached input, cached input, cache write, output und Reasoning getrennt.
• ☐ Retries und abgebrochene Agentenläufe enthalten.
• ☐ Search/OCR/Audio/Bild und fremde APIs enthalten.
• ☐ Datenbank, Storage, Vector Store, Egress und Backups enthalten.
• ☐ Observability, Security und Support enthalten.
• ☐ Erfolgsquote und Nacharbeit aktualisiert.
• ☐ Reserve und Preisänderungen transparent.
• ☐ Stückkosten pro Erfolg, Tenant und Use Case ausgewiesen.

Vor Self-hosting

• ☐ Benchmark mit realen Kontextlängen und Parallelität.
• ☐ P95-Latenz, Tokens/s, GPU-Auslastung und OOM gemessen.
• ☐ Qualität gegen API-Referenz evaluiert.
• ☐ Hardware-, Speicher-, Netzwerk- und Lizenzkosten erfasst.
• ☐ 24/7-, Bereitschafts- und Vertretungskosten eingerechnet.
• ☐ Backup, Update, CVE, Monitoring und Rollback geplant.
• ☐ Peak- und Ausfallkapazität finanziert.
• ☐ API-Rückfallpfad oder Exit definiert.

Vor Produktionsfreigabe

• ☐ Kostenmetadaten und Requestkorrelation aktiv.
• ☐ Mandanten- und Nutzerquoten getestet.
• ☐ Agentenschritt-, Zeit- und Toolbudget erzwungen.
• ☐ Secrets geschützt und Rotation getestet.
• ☐ Budgetalarm und Kill Switch ausprobiert.
• ☐ Golden Set und Regression Gate bestanden.
• ☐ Restore/Rollback und Dead-Letter-Verarbeitung getestet.
• ☐ Eigentümer, Supportzeiten und Eskalation dokumentiert.

Monatliches FinOps-Review

• ☐ Forecast versus Ist erklärt.
• ☐ Top-Kostentreiber nach Use Case und Tenant.
• ☐ Erfolg, Nacharbeit und Stückkosten verglichen.
• ☐ Output-, Kontext- und Retry-Ausreißer untersucht.
• ☐ Cache- und Batchquote auf Nettoersparnis geprüft.
• ☐ Commitments und ungenutzte Kapazität überprüft.
• ☐ Preis-/Modelländerungen und Deprecations geprüft.
• ☐ Konkrete Optimierung mit Messziel und Rollback beschlossen.

Beschaffung und Vertrag

• ☐ Listpreis und Vertragsangebot getrennt.
• ☐ Region, Endpoint und Datenverarbeitung festgehalten.
• ☐ Mindestverbrauch, Laufzeit und Preisänderungsklausel geprüft.
• ☐ SLA, Support und Incidentkommunikation bewertet.
• ☐ Datenexport und Löschung zugesichert.
• ☐ Modelllebenszyklus und Migrationshilfe geklärt.
• ☐ Unterauftragsverarbeiter und Compliance geprüft.
• ☐ Exitkosten und Restbindung in TCO aufgenommen.

Stilllegung

• ☐ Traffic gestoppt und Nutzer informiert.
• ☐ API-Keys, Servicekonten und Secrets widerrufen.
• ☐ Modelle, Endpunkte, GPU, Datenbanken und Queues entfernt.
• ☐ Vektoren, Testdaten, Logs und Backups nach Regel gelöscht.
• ☐ Datenexport und Aufbewahrung dokumentiert.
• ☐ Verträge, Commitments und Marketplace-Abos beendet.
• ☐ Dashboards, Alarmwege und DNS bereinigt.
• ☐ Abschlussrechnung und Lessons Learned erstellt.

20 Mythenprüfungen

20 offene Forschungs-, Markt- und Praxisfragen

Wie stabil sind Router über Modellgenerationen?

Router können auf einem Modellpaar gut funktionieren und nach Modellupdates falsch kalibriert sein. Langzeitdaten aus heterogenen Produktionssystemen bleiben begrenzt. ^{[S-078] [S-079]}

Welche Unit-Metric eignet sich branchenübergreifend?

Kosten pro Token sind vergleichbar, aber geschäftlich schwach; Kosten pro Erfolg sind sinnvoll, jedoch use-case-spezifisch. ^{[S-069] [S-070]}

Wie werden Reasoning-Token providerneutral normalisiert?

Anbieter weisen internes Denken und sichtbare Ausgabe unterschiedlich aus. FOCUS und GenAI-Semantik entwickeln sich weiter. ^{[S-071] [S-099] [S-014]}

Wie belastbar sind öffentliche Self-hosting-Benchmarks?

Hardware, Quantisierung, Kontext, Batch und Softwareversion unterscheiden sich stark. Reproduzierbare Kostenbenchmarks fehlen oft. ^{[S-080] [S-086]}

Wann schlägt semantisches Caching direkte Modellaufrufe?

Trefferquote, Aktualität, Mandantentrennung und Fehlantwortkosten bestimmen den Break-even; allgemeine Schwellen sind nicht belegt. ^{[S-165] [S-090]}

Wie viel Telemetrie ist für Agenten wirtschaftlich optimal?

Vollständige Traces sind teuer und sensibel, zu starkes Sampling verbirgt seltene Schleifen und Sicherheitsereignisse. ^{[S-064] [S-099]}

Wie verändern sehr lange Kontexte die Kosten-Qualitäts-Grenze?

Preisstufen und Modellverhalten ändern sich schnell; Retrieval kann trotz größerer Fenster weiterhin besser sein. ^{[S-001] [S-148]}

Welche Energiekennzahl ist für KI-Anwendungen praktisch genug?

Hardwareenergie allein erfasst weder Qualität noch vermiedene Arbeit. Eine funktionale Einheit ist nötig, aber schwer zu standardisieren. ^{[S-076] [S-088]}

Wie sollten menschliche Reviewkosten in Echtzeit geroutet werden?

Nicht jeder Fall braucht gleiche Prüfung; risikobasierte Stichproben benötigen robuste Fehlerprognosen. ^{[S-090] [S-094]}

Wie groß ist der langfristige Migrationsaufwand proprietärer Tools?

APIs standardisieren Text teilweise, nicht jedoch Tool Calling, Caching, Agentenstatus und Safety-Funktionen. ^{[S-011] [S-146] [S-147]}

Welche Mindestreserve ist für variable Modellpreise angemessen?

Es gibt keine universelle Quote; Vertrag, Wechseloption, Kritikalität und Budgethorizont bestimmen sie. ^{[S-067] [S-158]}

Wie verteilt man gemeinsame Plattformkosten fair auf Mandanten?

Token lassen sich zuordnen, gemeinsame Datenbanken, Bereitschaft und Basisinfrastruktur nur über nachvollziehbare Regeln. ^{[S-069] [S-071]}

Wann ist Multi-Region für KI-Komponenten wirklich erforderlich?

Geschäftsfolgen, Datenresidenz und Provider-SLA müssen den doppelten Betrieb rechtfertigen. ^{[S-117] [S-006]}

Wie bewertet man Qualitätseinbußen durch Quantisierung domänenspezifisch?

Allgemeine Benchmarks erfassen selten juristische, medizinische oder unternehmensinterne Fehlerkosten. ^{[S-085] [S-086] [S-165]}

Wie misst man Kosten von Halluzinationen vollständig?

Nacharbeit ist messbar; Reputationsschäden, Fehlentscheidungen und nicht entdeckte Fehler sind schwieriger. ^{[S-090] [S-091]}

Welche Agentenschritte sind deterministisch ersetzbar?

Viele Prüfungen, Berechnungen und Zustandsübergänge benötigen kein LLM; systematische Klassifikationen fehlen. ^{[S-119] [S-073]}

Wie wirken EU-Pflichten auf kleine Anbieter-TCO?

Die tatsächlichen Kosten hängen von Rolle, Risiko, Produkt und Umsetzungshilfen ab; pauschale Marktwerte wären unseriös. ^{[S-094] [S-095] [S-093]}

Wie zuverlässig sind automatische Kostenprognosen bei Produktwachstum?

Nutzerverhalten verändert Promptlänge, Toolpfade und Erfolgsquote; historische Linearität ist oft unzureichend. ^{[S-067] [S-099]}

Wann lohnt dedizierte Kapazität gegenüber variabler API-Abrechnung?

Der Break-even hängt von stabiler Grundlast, SLA, Hardwareentwicklung und Personalkosten ab und muss regelmäßig neu gerechnet werden. ^{[S-026] [S-021] [S-080]}

Wie verhindert man, dass Kostenoptimierung Qualität heimlich verschlechtert?

Notwendig sind versionierte Tests, Guardrails, kontrollierte Rollouts und Ergebniskennzahlen; perfekte Abdeckung bleibt offen. ^{[S-165] [S-166] [S-157]}

Glossar

Das Glossar verwendet Arbeitsdefinitionen für dieses Dossier. Anbieterbegriffe können abweichen; maßgeblich bleibt die jeweilige aktuelle Primärdokumentation.

Methodik, Belegmatrix und Qualitätssicherung

Recherche- und Bewertungsmethodik

Primär bevorzugt wurden offizielle Preis- und Produktdokumentationen, Standards, Gesetze und Originalarbeiten. Anbieterpreise werden als Herstellerangaben, nicht als unabhängige Leistungsbelege behandelt. Forschungsresultate werden nur im beschriebenen Setup wiedergegeben. Eigene Szenarien sind transparent als Annahmen gekennzeichnet. ^{[S-090] [S-071] [S-123]}

Belegmatrix der Kernaussagen

Quellenabdeckung

QUALITÄTSGRENZE: Eine Quellenkennung belegt nur die Aussage, die aus ihrer Primärquelle tatsächlich folgt. Eigene Architektur- und Kalkulationsfolgerungen sind als Schlussfolgerung oder Annahme formuliert und dürfen nicht als Herstellerzitat ausgegeben werden.

Quellenregister

Das Register enthält die im Dossier verwendeten Primärquellen, offiziellen Preis- und Produktdokumentationen, Standards sowie Originalarbeiten. „Living Documentation“ bedeutet: kein belastbares statisches Veröffentlichungsdatum; der Prüfstand ist deshalb ausdrücklich angegeben. URLs wurden für den Stichtag zusammengestellt und sind erneut zu prüfen, bevor Zahlen veröffentlicht oder Verträge geschlossen werden.

A. Modell- und API-Preise

B. Compute, GPU und Kapazität

C. Daten, Speicher und Observability

D. FinOps, TCO und Unit Economics

E. Forschung zu Effizienz und Serving

F. Betrieb, Standards und Governance

G. Reliability, Datenbetrieb und Qualität

Schnell veraltend – Refresh-Plan

Unmittelbare Refresh-Risiken am Stichtag

Schlussfolgerung

KERNERGEBNIS: KI-Kosten werden nicht durch den Modellpreis entschieden, sondern durch Architektur, Last, Erfolgsquote, Daten, Personal und die Konsequenz eines Fehlers. Die belastbare Einheit lautet: Vollkosten pro erfolgreichem Geschäftsergebnis.

Für kleine und unsichere Workloads ist eine nutzungsbasierte API häufig die wirtschaftliche Referenz. Für stabile Hochlast kann dedizierte oder eigene Kapazität sinnvoll werden, wenn Benchmark, Team, Lizenz und SLO nach Vollkosten überzeugen. Dazwischen liegen Managed Plattformen, die einen Teil der Betriebsarbeit gegen Plattformpreis und Bindung übernehmen. ^{[S-068] [S-080] [S-019]} Die risikoärmste Optimierungsreihenfolge lautet: messen, Erfolg definieren, Ausgabe begrenzen, Kontext bereinigen, deterministische Schritte auslagern, Caching und Batch nutzen, dann Routing und erst zuletzt Infrastruktur oder Provider radikal wechseln. Jede Änderung muss gegen dasselbe Golden Set und dieselbe Ergebniskennzahl geprüft werden. ^{[S-165] [S-077] [S-072]} Wann KI die falsche Lösung ist: wenn ein Regelwerk, eine Datenbankabfrage oder klassische Software die Aufgabe zuverlässiger und günstiger erfüllt; wenn Datenqualität oder Erfolgsdefinition fehlen; wenn Betrieb und Verantwortung nicht finanziert sind; oder wenn der Wert pro Erfolg die Vollkosten dauerhaft nicht deckt. ^{[S-119] [S-069] [S-090]}

Kennzahlen des Dossiers

ENDE DES DOSSIERS