Titelbild zur Veranschaulichung, kein Screenshot einer Produktoberfläche.
Jede Benchmark-Tabelle der Welt zählt dasselbe: richtig oder falsch. Das ist die falsche Achse.
Denn wie ein Modell scheitert, ist praktisch wichtiger als wie oft. Ein Fehler, der eine Ausnahme wirft, kostet dich eine Stunde. Ein Fehler, der still bleibt, kostet dich einen Monat – weil du nicht weißt, dass du einen hast.
Ich habe zwei Modelle durch 19 Aufgaben geschickt und dabei beide Sorten gesehen. Dieser Beitrag handelt nicht davon, welches besser ist. Er handelt davon, wie unterschiedlich sie kaputtgehen.
Vier Arten zu scheitern
Nicht jede Niete ist gleich. Nach diesem Durchlauf sortiere ich so:
1. Falsch geantwortet. Das Modell liefert eine Antwort, sie ist inhaltlich daneben. Unangenehm, aber sichtbar. Test rot, Mensch schaut drauf, fertig.
2. Richtig geantwortet, unbrauchbar formatiert. Die Antwort stimmt, der Parser kommt trotzdem nicht dran. Ebenfalls sichtbar: Die Verarbeitung wirft einen Fehler, irgendwo leuchtet etwas rot. Kostet Bereinigungscode, aber kein Vertrauen.
3. Abgeschnitten. Die Ausgabe endet mitten im Satz, weil das Token-Limit greift. Sichtbar, weil der Abbruchgrund mitgeliefert wird – sofern man ihn liest.
4. Kein finaler Antworttext. Das Modell verbraucht Ressourcen, ruft weiter Werkzeuge auf und erreicht das Rundenlimit, ohne eine lesbare Antwort zu liefern. In den API-Daten steht dabei tool_calls, kein API-Fehler. Wer nur den äußeren Jobstatus prüft, kann den fehlenden Antworttext trotzdem übersehen.
Die vierte Sorte ist die gefährliche.
19 Aufgaben, je ein Durchlauf, 20. Oktober 2026.
Warum die vierte Sorte gefährlich ist
In meinem Durchlauf hat genau das ein Modell getan. Aufgabe: In einem 400-Zeilen-Protokoll steht ein Schlüssel in Zeile 288.
Das eine Modell fand ihn und gab den Wert zurück. Das andere verbrauchte sechs Runden ausschließlich mit Dateizugriffen, las 42766 Eingabe-Token und gab am Ende keine einzige Zeile aus.
Betrachte die Rechnung:
- Die sechs Runden endeten mit
tool_calls - Die Ausführung erreichte das Rundenlimit
- Es gab keinen API-Fehler, aber auch keinen finalen Antworttext
- Ohne Prüfung von Stop-Grund und Rundenlimit kann der äußere Job trotzdem als beendet erscheinen
- Verbraucht wurden 42766 Eingabe-Token
Bezahlt und nicht geliefert: 42766 Eingabe-Token gegen null Zeichen Ausgabe.
Wenn deine Überwachung nur den äußeren Jobstatus betrachtet, kann der Abbruch unauffällig bleiben. Für deine Nutzer ist die Funktion trotzdem kaputt.
Und in jeder Benchmark-Tabelle steht dafür: eine Aufgabe nicht bestanden. Genau eine Zeile, gleichwertig mit „falsch geraten". Die Tabelle unterscheidet nicht zwischen „hat falsch geantwortet" und „hat aufgehört zu existieren".
Der laute Fehler auf der anderen Seite
Die Formatfehler waren eine andere Sorte als der stille Abbruch. Bei M3 enthielt content Denktext vor der verlangten Ausgabe; dadurch scheiterten alle drei Aufgaben mit striktem Format an der ursprünglichen Prüfung. Bei der nachträglichen Sichtung waren die Inhalte von zwei Antworten passend, aber die dritte Antwort blieb in einem nicht geschlossenen Denkblock und lässt sich nicht verlässlich als Antwort werten.
Ein Parserfehler ist immerhin sichtbar: Er landet im Log und lässt sich gezielt untersuchen. V4-Pro zeigte in der langen Log-Aufgabe das Gegenstück: sechs Runden Dateizugriffe und am Ende keine Antwortzeile. Das sind unterschiedliche beobachtete Fehlerbilder, aber aus je einem kleinen Ausschnitt folgt keine allgemeine Rangfolge der Fehlerrisiken.
Die gewichteten Werte von 0,850 und 0,950 fassen die ursprünglichen Prüfergebnisse dieser 19 Aufgaben zusammen. Sie zeigen weder, dass eine der drei Formatantworten nach Bereinigung sicher bestanden hätte, noch, welches Modell insgesamt zuverlässiger ist.
Dabei wäre der Aufwand gering. Für eine Fehlerarten-Statistik braucht man genau zwei zusätzliche Felder pro Datensatz: den Abbruchgrund und die Anzahl der tatsächlich gelieferten Zeichen. Beides steht in jeder API-Antwort, ohne Zusatzaufruf. Dass es in praktisch keiner Vergleichstabelle auftaucht, liegt nicht daran, dass es schwierig wäre, sondern daran, dass die Tabelle nach Trefferquote sortiert ist.
Wie man stille Ausfälle sichtbar macht
Ein stiller Ausfall ist kein Modellproblem, das man wegkonfigurieren kann. Es ist ein Überwachungsproblem. Drei Dinge reichen.
Erstens: Leere Antworten separat zählen. Nicht als Fehlschlag, sondern als eigene Kategorie. Ein Fehlschlag sagt „hat nicht geklappt". Ein leerer Erfolg sagt „ist durchgelaufen und hat nichts produziert" – das ist ein anderer Alarm.
Zweitens: Rundenlimit und Stop-Grund gemeinsam protokollieren. Ein Turn-Limit schützt vor endlosen Schleifen und zeigt, wenn ein Modell innerhalb des Budgets nicht fertig wurde. Logge finish_reason wie tool_calls zusammen mit dem Erreichen der Grenze, getrennt von einer falschen Antwort.
Drittens: Die Rechnung als Signal nutzen. Wenn eine Aufgabe ein Mehrfaches des üblichen Token-Verbrauchs kostet und trotzdem kein Ergebnis liefert, ist das ein Muster, kein Zufall. Ein Verhältnis aus Ausgabe-Token zu verbrauchten Token, das gegen null geht, ist ein messbarer stiller Ausfall.
Was das für die Auswahl heißt
Wenn du ein Team für API-Betrieb oder SRE leitest, sagt dieser Test nicht, welches Modell insgesamt zuverlässiger ist. Er zeigt aber, welche Prüfungen in deinen Produktionspfad gehören: leere Antworten zählen, stop-Grund und Turn-Limit loggen und eine Ausführung mit tool_calls am Rundenlimit nicht als fertige Antwort behandeln.
Für ein Produkt, das strikte JSON-Ausgaben braucht, ist V4-Pro der bessere Kandidat für einen ersten Pilot: Es bestand hier alle drei Formatprüfungen. Für nächtliche Batch-Verarbeitung mit engem Budget ist M3 einen eigenen Kostentest wert; in diesem Lauf lag die Gesamtrechnung rund 17,6 Prozent niedriger. Beide Hinweise stammen aus 19 einmalig ausgeführten Aufgaben und sind keine allgemeine Rangliste.
Für lange Logs und Dokumente gibt es hier keinen Sieger. Beide Modelle bestanden jeweils eine von zwei Aufgaben, und zwar unterschiedliche. Wer solche Dokumente verarbeitet, sollte ein eigenes Set typischer Fälle mehrfach testen und Kosten pro verwertbarem Ergebnis vergleichen.
Drei Felder, die ich ab jetzt mitschreibe
Der Aufwand dafür ist minimal, der Unterschied groß:
- Den Abbruchgrund jeder Antwort – nicht nur „hat geklappt" oder „hat nicht geklappt"
- Die Anzahl gelieferter Zeichen – auch dann, wenn die Antwort als erfolgreich gilt
- Ob das Rundenlimit erreicht wurde – getrennt von einem inhaltlichen Fehlschlag
Diese drei Felder kosten keinen zusätzlichen Aufruf. Zusammen machen sie sichtbar, ob eine Ausführung eine Antwort geliefert, das Rundenlimit erreicht oder nur weitere Werkzeuge angefordert hat.
Die Trefferquote sagt dir, wie gut ein Modell ist. Sie sagt dir nicht, ob du es merkst, wenn es aufhört zu funktionieren.
Hinweis: Zahlen aus einem Durchlauf am 20. Oktober 2026 mit 19 Aufgaben und zwei Modellen. Der Beitrag vergleicht keine Trefferquoten, sondern Fehlermodi.
Top comments (0)