42 KI-Modelle im Vergleich, Teil 4: Misst der Benchmark das Modell — oder den Anbieter?

Der verdächtige Befund

Im großen Vergleich tauchte eine Zahl auf, die nicht zusammenpasste: Das Modell Qwen3.5-35B-A3B erreichte lokal auf eigener Hardware 22,0 von 25 Punkten — über die Cloud nur 12,5. Gleiches Modell, gleiche Fragen, gleiche Daten. Ein Abstand von 9,5 Punkten bei identischen Modellgewichten ergibt keinen Sinn. Quantisierung erklärt vielleicht Bruchteile eines Punktes, niemals das.

Fast hätten wir die falsche Schlagzeile geschrieben

Die verlockende Story lag auf der Hand: „Lokale KI schlägt die Cloud um 9,5 Punkte.“ Sie wäre falsch gewesen — gleich doppelt. Bevor wir sie aufschrieben, sind wir den Rohdaten nachgegangen, und dabei sind uns zwei eigene Denkfehler aufgefallen.

Denkfehler eins: „Lokal gegen Cloud“ war nie ein Hardware-Vergleich. Lokal lief das Modell ohne Reasoning-Modus und ohne enges Antwortlimit; in der Cloud mit beidem. Wir verglichen also zwei Konfigurationen, nicht zwei Maschinen. Denkfehler zwei kam erst später ans Licht — dazu am Ende.

Das eigentliche Problem zeigte sich in den Cloud-Antworten: Bei zwei von vier Fragen kam gar nichts zurück, bei den anderen nur ein abgeschnittener Rest. Das Modell hatte sein Antwort-Budget fürs interne „Nachdenken“ verbraucht. Aber war das reproduzierbar? Lag es am Budget, am Reasoning, am Anbieter? Die alten Testdaten konnten es nicht sagen — sie speicherten nur die Antwort, nicht wie sie zustande kam. Also haben wir sauber nachgemessen.

Was wir gebaut haben

Ein instrumentiertes Test-Skript, das pro Anfrage die entscheidenden Felder mitschneidet, die vorher fehlten:

• finish_reason — wurde die Antwort sauber beendet (stop) oder hart vom Limit gekappt (length)?
• provider — welcher Backend-Anbieter hat die Anfrage tatsächlich bearbeitet?
• reasoning_tokens — wie viel des Budgets ging fürs interne Denken drauf?
• Länge von sichtbarer Antwort und Reasoning, getrennt.

Damit haben wir vier Experimente gefahren: Ist es reproduzierbar? Liegt es am Budget? Liegt es am Reasoning? Liegt es am Anbieter?

Experiment A — Ist es reproduzierbar?

Sechs Modelle, jede Frage fünfmal wiederholt. Ergebnis: stabil — und es trifft ausschließlich die Modelle mit Reasoning-Modus.

Modell	Läufe	davon leer	Anbieter im selben Test
Qwen3.5-35B-A3B	20	15	6 verschiedene
Qwen3.6-35B-A3B	20	16	5 verschiedene
GPT-5-Pro	20	20	1
Gemini 2.5 Pro	20	0 (aber alle gekappt)	1
GPT-4o (Kontrolle, kein Reasoning)	20	0	2

Zwei Dinge stechen heraus. Erstens: Das Nicht-Reasoning-Kontrollmodell GPT-4o ist völlig unauffällig — das Problem hängt am Reasoning-Modus. Zweitens: Bei Qwen3.5 schwankte das Ergebnis innerhalb desselben Modells, je nachdem welcher von sechs Anbietern die Anfrage bekam. Ein erster Fingerzeig.

Experiment B — Liegt es am Token-Budget?

Dasselbe Modell, nur das Antwortlimit hochgedreht: 500 → 2.000 → 8.000 → 32.000 Tokens.

Modell	500	2.000	8.000	32.000
Qwen3.5-35B-A3B (leere von 4)	3	2	0	0
Qwen3.6-35B-A3B (leere von 4)	4	0	0	0
GPT-5-Pro (leere von 4)	4	0	—	—

Eine saubere Dosis-Wirkungs-Kurve: Budget rauf, Leere weg. Ab 8.000 Tokens liefert Qwen3.5 jede Antwort vollständig. Sogar GPT-5-Pro — im großen Vergleich auf dem letzten Platz — erholt sich schon bei 2.000 Tokens komplett. Damit ist klar: Die niedrigen Werte waren ein Budget-Artefakt, kein Qualitätsdefizit.

Experiment C — Liegt es am Reasoning-Modus?

Gegenprobe: Budget knapp bei 500 lassen, aber den Reasoning-Modus abschalten.

Modell	Reasoning AN	Reasoning AUS
Qwen3.5-35B-A3B	3 von 4 leer	0 von 4 leer
Qwen3.6-35B-A3B	4 von 4 leer	0 von 4 leer
GPT-4o (Kontrolle)	0 von 4	0 von 4

Eindeutig: Schaltet man das Denken ab, füllen sich die Antworten — selbst beim knappen 500-Token-Budget. Das interne Nachdenken hatte schlicht den Platz für die eigentliche Antwort weggegessen.

Experiment D — Liegt es am Anbieter?

Jetzt der entscheidende Test. Über Aggregatoren wie OpenRouter verbirgt sich hinter einem Modellnamen oft ein Dutzend austauschbarer Backend-Anbieter. Wir haben denselben Modell-Endpoint (Qwen3.5, festes 500-Token-Limit) gezielt auf je einen Anbieter gepinnt:

Gepinnter Anbieter	leere Antworten	Ø Output-Tokens	Verhalten
DeepInfra	4 von 4	500	hält das Limit ein → leer
Parasail	4 von 4	500	hält das Limit ein → leer
AkashML	4 von 4	500	hält das Limit ein → leer
Alibaba	0 von 4	3.615	ignoriert das Limit → volle Antworten

Gleiches Modell, gleiche Frage, gleiche Vorgabe. Der einzige Unterschied ist der Anbieter, den das Routing auswählt. Drei von vier halten unser Limit ein und liefern deshalb nichts; einer ignoriert es und liefert deshalb alles.

Der zweite Denkfehler — und die ehrliche Lesart

Hier lauerte unser zweiter Trugschluss. Die naheliegende Überschrift wäre jetzt: „Die Anbieter sind schuld.“ Aber das ist falsch herum gedacht. Wir haben ein Limit von 500 Tokens verlangt. DeepInfra, Parasail und AkashML haben genau das geliefert — sie verhalten sich korrekt. Bei einem Reasoning-Modell, das 450 Tokens fürs Denken braucht, ist eine leere Antwort die logisch zwingende Folge unserer eigenen, widersprüchlichen Anfrage. Ausgerechnet Alibaba, das uns „rettete“, hat unsere Vorgabe verletzt.

Der wahre Befund ist also kein Schuldiger, sondern eine Konstellation aus drei Dingen:

1. Reasoning-Tokens zählen ins Antwort-Budget — bei knappem Budget bleibt für den sichtbaren Text nichts übrig.
2. Unsere Vorgabe (Reasoning-Modell + 500 Tokens) war in sich widersprüchlich — ein Fehler im Testaufbau, nicht im Modell.
3. Die Anbieter legen dieselbe Vorgabe gegensätzlich aus — manche kappen hart, manche ignorieren das Limit. Diese Uneinigkeit macht das Ergebnis unreproduzierbar.

Was das für jeden Benchmark bedeutet

Die größere Lehre reicht weit über unser Motorrad-Projekt hinaus. Wer Sprachmodelle über einen Aggregator vergleicht und dabei nicht den Anbieter festpinnt und nicht finish_reason mitschneidet, der misst am Ende die Bereitstellung — die Kombination aus Routing, Anbieter-Eigenheiten und eigener Parameterwahl — und nicht das Modell. Ein Ranking, das so entsteht, sagt mehr über das Serving-Setup als über die Fähigkeiten der KI.

Drei praktische Konsequenzen ziehen wir daraus:

• Budget großzügig wählen, sobald ein Modell überhaupt einen Reasoning-Modus hat — sonst misst man Abbruch statt Antwort.
• Anbieter festpinnen oder erzwingen, dass nur Backends genutzt werden, die die eigenen Parameter respektieren — für Reproduzierbarkeit.
• finish_reason immer protokollieren. Eine leere oder abgeschnittene Antwort ist kein Qualitätsurteil, sondern ein Warnsignal für den Testaufbau.

Und für unseren großen Vergleich? Die hinteren Plätze von Qwen3.5 Cloud, Gemini 2.5 Pro und GPT-5-Pro stehen damit unter Vorbehalt — sie messen eine kaputte Konfiguration, nicht die Modellqualität. Genau das hatten wir in Teil 2 vermutet. Jetzt ist es belegt — und wir haben gleich zwei eigene Denkfehler dazugelernt. Auch das gehört zu einem ehrlichen Benchmark.