Was ich protokolliere, bevor ich überhaupt über Modellwahl rede — und warum die Reihenfolge den Unterschied macht.
Ein Monat lang habe ich dieselben Aufgaben abwechselnd an vier Modelle gegeben: DeepSeek V4-Pro, Qwen3.8 Max, GLM-5 und Gemini 3.8 Flash. Alle vier hängen an demselben OpenAI-kompatiblen Endpunkt, der Wechsel ist ein String.
Am Anfang wollte ich eine Rangliste. Am Ende hatte ich eine Liste von Messgrößen — und die war deutlich nützlicher. Dieser Text beschreibt die Messgrößen, nicht die Rangliste.
Das Problem
Wenn man Modelle nach Gefühl vergleicht, passiert Folgendes: Man merkt sich den einen Fall, der hängen geblieben ist, und hält ihn für ein Muster.
Bei mir war das ein Modell, das „langsam" wirkte. Nach zwei Wochen mit Protokoll stellte sich heraus, dass es pro Antwort nicht langsamer war — es brauchte nur mehr Runden pro Aufgabe. Und jede Runde schickt den bisherigen Gesprächsverlauf erneut mit. Die gefühlte Langsamkeit war in Wahrheit eine Multiplikation.
Ohne Protokoll hätte ich weiter das falsche Modell beschuldigt.
Die Umgebung
| Punkt | Wert |
|---|---|
| Modelle | DeepSeek V4-Pro, Qwen3.8 Max, GLM-5, Gemini 3.8 Flash |
| Zugriff | Ein OpenAI-kompatibler Endpunkt, Modellwechsel über den Namen |
| Zeitraum | Oktober 2026 |
| Preise | Öffentliche, nutzungsbasierte Preise pro 1 Mio. Token |
Die Preise sind der einzige Teil, der sauber vergleichbar ist, weil ihn alle Anbieter veröffentlichen.
- DeepSeek V4-Pro: $0.67 Eingabe / $2.00 Ausgabe
- GLM-5: $1.00 / $3.20
- Gemini 3.8 Flash: $0.75 / $3.75
- Qwen3.8 Max: $2.00 / $6.00
Die Ausgabe kostet bei allen vier Modellen das Drei- bis Vierfache der Eingabe. Wer Token zu einer Summe addiert, versteckt genau den Anteil, der die Rechnung bestimmt.
Zwei Dinge fallen auf. Erstens: die Ausgabe ist drei- bis viermal so teuer wie die Eingabe — bei jedem der vier. Zweitens: der teuerste Ausgabepreis liegt beim Dreifachen des günstigsten. Das klingt viel, ist aber weniger, als die eigene Rundenzahl bewegen kann.
Bei wiederholten Fragen zum selben langen Dokument entscheidet der Cache-Treffer mehr als die Modellwahl.
Gecachte Eingabe liegt bei Gemini 3.8 Flash bei $0.075, also einem Zehntel. Bei Qwen3.8 Max kostet das Cache-Lesen $0.25. Wer dasselbe lange Dokument mehrfach befragt, für den ist die Cache-Trefferquote wichtiger als die Wahl zwischen diesen vier. Die aktuellen Sätze stehen in der Preisübersicht.
Die Schritte
Schritt 1: vier Felder protokollieren. Mehr braucht es nicht, um die meisten Fehlurteile zu vermeiden:
- Anzahl der Runden pro Aufgabe
- tatsächliche Zeichenzahl der sichtbaren Antwort
- Finish-Grund
- Anzahl der Reasoning-Token
Diese vier Spalten haben alles ergeben, was in diesem Text steht.
Schritt 2: die Einheit festlegen. Nicht „eine Antwort", sondern „eine abgeschlossene Aufgabe". Sonst vergleicht man Antworten, die unterschiedlich viel Arbeit enthalten.
Schritt 3: dieselbe echte Aufgabe mehrfach laufen lassen. Nicht eine Aufgabe, sondern mehrere Durchläufe. Eine einzelne Aufgabe liefert das Glück dieser einen Aufgabe.
Schritt 4: Geld pro abgeschlossener Aufgabe vergleichen. Nicht Token, nicht Tokenpreis.
Schritt 5: den Leerfall getrennt zählen. Eine Antwort mit Erfolgsstatus und Länge null gehört in eine eigene Zählung. In der allgemeinen Fehlerquote verschwindet sie zwischen echten Fehlern und echten Erfolgen — und genau dort ist sie unsichtbar.
Das klingt nach fünf Schritten, ist aber eine Stunde Arbeit. Der Aufwand liegt nicht im Messen, sondern darin, sich vorher zu einigen, was „abgeschlossen" bedeutet.
Die Verifikation
Was dabei herauskam, in der Reihenfolge, in der es mich überrascht hat.
Die Rundenzahl multipliziert. Ein Modell brauchte im Schnitt 4,1 Runden pro Aufgabe, ein anderes 2,9. Bei ähnlicher Pro-Antwort-Zeit ergibt das fast den Faktor 1,8 — und die Gesamtzeit wuchs um den Faktor 2,49. Die Runden sind der Hebel, nicht die Latenz einer Antwort.
Die Kostenlücke war kleiner als gedacht. Aus einer einzelnen Aufgabe hatte ich einmal „zehnmal teurer" abgeleitet. Über einen echten Stapel gemessen blieb ein Unterschied von 21 Prozent. Eine einzelne Messung ergibt keinen Multiplikator.
Ein stiller Ausfall. Eine Aufgabe verlangte, eine Zeile in einem 400-Zeilen-Log zu finden. Ein Modell lief sechs Runden, verbrauchte 42.766 Eingabe-Token und gab einen leeren String zurück. Die API meldete normalen Abschluss. Kein Fehler, keine Ausnahme, kein Retry, kein Alarm — nur die Rechnung.
Eine falsche Antwort erzeugt ein Ereignis, das jemand liest. Ein leerer Erfolg erzeugt eine Rechnung. Deshalb gehört „Erfolg mit Antwortlänge null" in eine eigene Alarmkategorie und nicht in die Fehlerquote, wo er weggemittelt wird.
Die Fehlersuche
Der Parser, der still kaputtgeht. Mein erster Filter nahm den Text zwischen schließendem und öffnendem Marker. Das liest sich richtig und versagt leise: Bei einer Antwort, die einen Block öffnet und nie schließt, behandelt der Parser die gesamte Antwort als Fließtext. Begründung und Antwort verschmelzen — schlechter als gar kein Filter.
Meiner tat das monatelang und schrieb irgendwann einen kompletten Begründungsblock in eine Datenbankspalte, die eine Antwort hätte enthalten sollen. Gefunden habe ich es durch Zufall.
Die Regel daraus: Ein nicht terminierter Marker muss einen lauten Fehler auslösen, niemals einen Fallback.
Der Fehler, der wie ein Ergebnis aussieht. Eine leere Antwort mit Erfolgsstatus sieht in jedem Dashboard wie eine schnelle, günstige Anfrage aus. Sie ist weder schnell noch günstig; sie hat nur nichts geliefert.
Die Diskussion
Was ich heute mache: erst prüfen, ob der eigene Code die Ausgabe überhaupt lesen kann, dann die Rundenzahl auf der eigenen Aufgabe messen, dann den Fehlerfall ansehen — und erst danach über Fähigkeiten reden.
Der wichtigste Effekt war übrigens nicht die Zahl, sondern die Reihenfolge. Solange ich mit einer Rangliste angefangen habe, habe ich jede Abweichung als Eigenschaft des Modells gelesen. Mit Protokoll wurde daraus eine Frage an meinen eigenen Aufruf: Warum sechs Runden statt zwei? Warum kein Abbruch bei leerer Antwort? Diese Fragen waren beantwortbar. „Welches Modell ist besser" war es nicht.
Was dieser Text nicht ist: eine Rangliste.
Von den vier Modellen lief nur eines in einem wiederholten, kontrollierten Durchlauf auf meiner Seite. Der Fall mit den sechs Runden und der leeren Antwort stammt aus diesem Lauf und ist eine echte Beobachtung. Alles andere ist, was mir im Alltag mit allen vier aufgefallen ist — schwächere Evidenz, und ich benenne sie als solche.
Die vier Protokollfelder übertragen sich unabhängig vom Modell. Sie sind billiger als jede Vergleichsstudie und liefern genau die Zahlen, die eine Modellentscheidung tatsächlich braucht. Die Frage, die vorher zu beantworten ist, lautet nicht „welches Modell ist besser", sondern „was messe ich eigentlich".
Top comments (0)