Wer über KI-Kosten spricht, redet fast immer über das Modell: das große Frontier-Modell für die schwierigen Fälle, ein kleineres für den Rest, dazwischen ein Gateway, das verteilt. Dahinter steht die Annahme, dass Genauigkeit Geld kostet und billige Modelle billig antworten. Ein Whitepaper des Datenanbieters CData dreht das um. Nach 1.034 Testläufen mit 22 Modellen kommt es zu dem Schluss: Die Kosten bestimmt nicht das Modell, sondern die Datenebene darunter. Steht die Geschäftslogik im Data Layer statt im Prompt, liefern günstige und teure Modelle dieselbe richtige Antwort. Der einzige messbare Unterschied ist der Preis. Wer KI-Kosten senken will, sollte nicht im Modellkatalog anfangen.
Ein Benchmark, der alle Modelle absichtlich gleich behandelt
Die Zahl 178x klingt nach Marketing. Sie hält nur, wenn die Anordnung sauber ist. Die Autoren beschreiben 22 Modelle von acht Entwicklern, verteilt über drei Aufgaben und zwei bis drei Tool-Bedingungen pro Aufgabe, insgesamt 1.034 Läufe. Die Daten kamen live und föderiert: Kundenkonten aus einem CRM, Nutzungstelemetrie aus einem Cloud-Warehouse, Support-Vorfälle aus einer ITSM-Plattform, verbunden über die eigene Schicht. Nichts davon wurde vorab aufbereitet oder in eine Testdatei kopiert.
Wichtiger als die Zahl der Modelle ist die Vergleichbarkeit. Jedes Modell lief durch denselben clientseitigen Tool-Loop, es gab also keinen Heimvorteil für einen bestimmten Anbieter. Token wurden so gezählt, wie der jeweilige Anbieter sie abrechnet, zu Listenpreisen. Leseaufgaben bewertete man per Set-F1 gegen einen offline berechneten Golden Key, Schreibaufgaben am tatsächlichen Endzustand der Zieltabelle, abgelesen über einen separaten Endpunkt. Der Unterschied zwischen einem Benchmark und einer Vorführung: Die Bewertung entsteht nicht dort, wo das Modell arbeitet.
Der Fehler, der wie die richtige Antwort aussieht
Ohne die Datenschicht lieferten die Modelle vollständige, wohlgeformte Kontolisten, die falsch waren. Das ist der gefährliche Fall: Eine falsche Antwort, die richtig aussieht, fällt niemandem auf, weil nachgelagerte Systeme keine Abweichung melden. Ein offensichtlicher Fehler kostet einen Retry. Ein plausibler kostet Vertrauen.
Dahinter steckt ein Strukturproblem. Rohdatenzugriff zeigt dem Modell das Schema, aber nicht die Regeln. Es muss erraten, welche Telemetrie zu welchem Gesundheitssignal gehört, ab welchem Schwellenwert ein Konto als gefährdet gilt und wie drei getrennte Systeme überhaupt zusammenhängen. Diese Regeln stehen nirgends im Datenbestand, sie stehen im Kopf der Fachabteilung. Wer sie einmal in der Datenebene hinterlegt, vererbt dieselbe korrekte Definition an jedes Modell, das sie aufruft.
Bei Schreiboperationen wurde es unangenehm. Ohne Grenze im Werkzeug schrieben die Modelle weit über die autorisierte Menge hinaus, im schlechtesten Lauf tausende falsche Werte. Dasselbe Modell auf derselben Aufgabe schrieb in einem Durchlauf die 21 korrekten Datensätze und im nächsten hunderte falsche. Ein Verhalten, das von Lauf zu Lauf schwankt, lässt sich nicht betreiben. Die Grenze muss dort liegen, wo das Modell sie nicht umdeuten kann.
Kosten pro korrekter Antwort
Sobald die Datenschicht die Logik trägt, ändert sich das Bild. Alle Tiers waren gleich genau, übrig blieb die Rechnung pro richtigem Ergebnis. Die Baseline-Genauigkeit der untersuchten Modelle lag bei null bis 19 Prozent, optimiert bei 100 Prozent – bei identischem Ergebnis, demselben Satz von 44 Konten.
| Modell | Klasse | Kosten pro korrekter Antwort (optimiert) |
|---|---|---|
| Mistral Small | Economy | 0,0009 $ |
| DeepSeek V4 Flash | Economy | 0,0032 $ |
| Gemini 3.7 Flash | Mid | 0,0156 $ |
| Sonnet 5 | Frontier | 0,0604 $ |
| Opus 5 | Frontier | 0,0753 $ |
| Fable 5 | Frontier | 0,1571 $ |
Zwischen billigstem und teuerstem Wert in dieser Tabelle liegt rechnerisch etwa der Faktor 175, über alle 22 Modelle hinweg spricht CData von 178x. Bei der Ranking-Aufgabe erreichten neun Modelle exakt dieselbe Punktzahl und spannten trotzdem einen Faktor von 279 auf. Ohne Datenschicht war selbst das beste Modell nur in 40 Prozent der Fälle korrekt – der Preisunterschied half nicht. Bei den Schreibaufgaben schrieben 20 von 22 Modellen mit der Datenschicht exakt korrekt, ohne sie produzierte der schlechteste Lauf tausende falscher Werte.
Wie aus einer Genauigkeitsfrage eine Preisfrage wird
Man kann sich das wie eine Küche vorstellen. Ein Sternekoch ohne Rezeptur improvisiert – manchmal brillant, manchmal ungenießbar. Ein günstiger Koch mit klarer Rezeptur liefert dagegen verlässlich dasselbe Gericht. Solange die Rezeptur fehlt, bezahlt man für Kochkunst, die das eigentliche Problem nicht löst: Das Gericht ist immer noch falsch, nur teurer produziert.
Die Datenebene ist diese Rezeptur. Sie hält die Geschäftslogik und die Leitplanken, aus denen ein Modell eine korrekte Handlung ableitet. Ist sie einmal kodiert, erbt jedes Modell, das sie aufruft, dieselbe Definition – und erst dann ist ein Modellkosten-Vergleich sinnvoll. Vorher vergleicht man Fehlerraten, die von Prompt zu Prompt schwanken, und hält das Ergebnis für einen Preisvergleich.
Auf der Sicherheitsseite gilt dasselbe Prinzip. Wo die Grenze im Werkzeug liegt und nicht im Prompt, kann das Modell sie nicht neu interpretieren. Der erlaubte Schreibbereich wird zu einer Eigenschaft der Umgebung statt zu einer Bitte an das Sprachmodell. Mit Data Layer entstehen Genauigkeit und Sicherheit an derselben Stelle wie die Kosten.
Was das für die eigene Modellauswahl bedeutet
Die praktische Konsequenz beginnt bei der Maßeinheit. Solange man Preise pro Million Token vergleicht, optimiert man am falschen Wert, weil die Fehlerrate die Kosten pro brauchbarem Ergebnis dominiert. Erst die Kennzahl Kosten pro korrekter Antwort macht sichtbar, dass ein 178-mal teureres Modell nicht besser, sondern nur teurer ist. Sobald beide Kandidaten dieselbe Trefferquote liefern, ist die Entscheidung eine reine Budgetfrage.
Der zweite Schritt ist eine ehrliche Bestandsaufnahme: Welche Regeln stecken heute in Prompts, Templates oder Systemnachrichten? Jede Regel dort ist eine Regel, die pro Aufruf neu erklärt und neu geraten wird. Wandert sie in die Datenebene, verschwindet sie aus dem Kontext und damit aus den Tokenkosten. Der dritte Schritt betrifft Schreibzugriffe, die man getrennt betrachten sollte. Eine Leseaufgabe mit 70 Prozent Trefferquote ist ein Ärgernis, eine Schreiboperation ohne Grenze ist ein Datenvorfall.
Wer die Zahlen nicht glauben will, muss sie nicht glauben. Der Test-Harness liegt auf GitHub, samt der wörtlichen Aufgabenstellungen, der Tool-Schemas für jede Bedingung und dem Generator für die Golden Answers. Man kann denselben Aufbau gegen die eigenen Systeme laufen lassen, und das ist der einzige Weg, aus einem Anbieter-Benchmark eine belastbare eigene Entscheidungsgrundlage zu machen.
Was die 178x konkret bedeuten – und wo die Grenzen liegen
Eine Einschränkung vorweg: Das Whitepaper stammt von CData, und CData verkauft genau die Datenschicht, um die es geht. Die Ergebnisse sind nicht unabhängig nachgeprüft, die Preise sind Listenpreise, und die Spanne gilt für einen bestimmten Aufgabentyp, der Komposition über mehrere Datenquellen verlangt. Für einen einzelnen Klassifikationslauf über einen kurzen Text sehen die Verhältnisse anders aus. Die Richtung des Befunds ist trotzdem robust und deckt sich mit dem, was viele Teams in der Praxis beobachten: Kontextqualität schlägt Modellgröße.
Für die nächste Planungsrunde heißt das: Die Frage lautet nicht, welches Modell man sich leisten kann, sondern wie viel Geschäftslogik noch im Prompt steht, weil sie nirgends sonst hinterlegt ist. Jede dieser Regeln ist ein wiederkehrender Kostenfaktor, eine Quelle für Schwankungen und ein Risiko für stille Fehler. Die Modellauswahl bleibt wichtig, aber sie wird zur zweiten Frage. Die erste lautet, woher das Modell weiß, was hier richtig bedeutet.
Quelle: cdata.com
