Wie ich fünf KI-Modelle fair gegeneinander getestet habe

Auftakt der Reihe „5 KI-Modelle, dieselbe Aufgabe". Stand: Juni 2026.

Auf einen Blick

• Fünf Anbieter-Familien (Claude, DeepSeek, GLM, Qwen, Mistral), sechs Varianten, zwei Aufgaben, ein gemeinsames Werkzeug.
• Ich glaube keinem „Tests grün" — ich prüfe unter vier Zeitzonen, mit eigenem Gegen-Check, und baue die App wirklich.
• Wichtigstes Kriterium: Selbst-Verifikation — sagt das Modell die Wahrheit über die eigene Arbeit?
• Zwei Ehrlichkeits-Hinweise vorweg: Claude hatte einen Heimvorteil, Mistral lief in einem anderen Werkzeug. Beides steht dazu.

---

Warum noch ein Modell-Vergleich?

Es gibt tausend Benchmark-Tabellen. Sie messen standardisierte Aufgaben und produzieren eine Rangliste. Was sie nicht beantworten: Löst das Modell eine echte Aufgabe in echtem Code — und kann man dem Ergebnis trauen, ohne jede Zeile nachzuprüfen?

Das ist meine Frage als IT-Dienstleister. Wenn KI in Kundensystemen läuft, zählt nicht „2 Punkte mehr im Benchmark", sondern:

• Läuft der Code out-of-the-box — auf dem Rechner des Kunden, nicht nur auf meinem?
• Wenn das Modell „alle Tests grün" meldet — stimmt das auch in einer anderen Zeitzone, auf einem anderen Server?
• Was kostet ein realer Coding-Lauf, nicht pro Token, sondern pro fertigem Feature?
• Darf ich es bei einem deutschen Mittelständler datenschutzkonform einsetzen?

Zweiter Beweggrund: Datensouveränität. Gibt es jenseits der US-Anbieter Modelle, die qualitativ mithalten — und die man notfalls selbst betreiben kann? Deshalb stehen bewusst mehrere Nicht-US-Modelle im Feld.

Das hier ist kein Benchmark. Es ist ein Feldtest.

---

Die Kandidaten

Claude Opus ist nicht „Teilnehmer", sondern Messlatte — das Modell, das ich heute produktiv nutze. Alle anderen treten gegen diesen Maßstab an.

Kurze Erklärung zur MoE-Architektur von DeepSeek: MoE (Mixture-of-Experts) bedeutet, dass das Modell bei jeder Anfrage nur einen Bruchteil seiner Gewichte aktiviert. Die 49 bzw. 13 Mrd. „aktiven Parameter" sind das, was tatsächlich rechnet — die 1,6 Bio. bzw. 284 Mrd. sind das Gesamtarchiv. Das macht MoE-Modelle erheblich günstiger im Betrieb als gleichwertige Dense-Architekturen gleicher Gesamtgröße.

Wichtige Faktenlage zu DeepSeek (Stand Juni 2026): Die API kennt nur noch zwei Modelle: deepseek-v4-pro und deepseek-v4-flash. Alle Alt-Namen (deepseek-chat, deepseek-coder, deepseek-reasoner) routen still auf v4-flash. Ältere Berichte, die „DeepSeek V3" bewerten, haben faktisch v4-flash getestet — das war auch bei mir so, bis ich es per API-Probe (zurückgegebenes Modell-Feld) verifiziert habe. Preise: flash $0,09/$0,18 pro Mio. Token (In/Out), pro $0,435/$0,87. Flash ist rund 12× billiger als pro; beide liegen 50–100× unter Opus.

---

Der Aufbau: ein Anzug für alle

Kern der Fairness: Vier der fünf Modell-Familien liefen im exakt gleichen Werkzeug — der Coding-CLI „Claude Code". Möglich macht das ein Trick: Claude Code kommuniziert intern über einen Anthropic-kompatiblen API-Endpunkt — und den bieten DeepSeek, Z.ai und Alibaba inzwischen an.

Vier Umgebungsvariablen wechseln, der Rest bleibt identisch:

ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
ANTHROPIC_AUTH_TOKEN="$DEEPSEEK_KEY"
ANTHROPIC_MODEL="deepseek-v4-pro"
ANTHROPIC_SMALL_FAST_MODEL="deepseek-v4-flash"
claude

Aus Sicht des Werkzeugs ändert sich nichts — gleiche Prompts, gleiche Tool-Schleife, gleiche Systemumgebung. Nur das „Gehirn" dahinter ist ein anderes. Werkzeug-Unterschiede sind eliminiert; übrig bleibt reine Modell-Qualität.

Die Launcher im Detail

Für jeden Kandidaten gibt es ein Shell-Skript mit Verbindungs-Test und Start:

DeepSeek (~/deepseek/deepseek.sh):

#!/usr/bin/env bash
set -euo pipefail

DEEPSEEK_KEY="${DEEPSEEK_KEY:-}"
DS_BASE="https://api.deepseek.com/anthropic"
DS_MODEL="${DS_MODEL:-deepseek-v4-pro}"   # oder deepseek-v4-flash

if [[ "${1:-}" == "check" ]]; then
  curl -s "$DS_BASE/v1/messages" \
    -H "x-api-key: $DEEPSEEK_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    -d "{\"model\":\"$DS_MODEL\",\"max_tokens\":20,\"messages\":[{\"role\":\"user\",\"content\":\"sag genau: ok\"}]}"
  exit 0
fi

ANTHROPIC_BASE_URL="$DS_BASE" \
ANTHROPIC_AUTH_TOKEN="$DEEPSEEK_KEY" \
ANTHROPIC_MODEL="$DS_MODEL" \
ANTHROPIC_SMALL_FAST_MODEL="deepseek-v4-flash" \
claude "$@"

GLM-4.6 (~/zai/zai.sh):

#!/usr/bin/env bash
set -euo pipefail

ZAI_KEY="${ZAI_KEY:-}"
ZAI_BASE="https://api.z.ai/api/anthropic"
ZAI_MODEL="glm-4.6"
ZAI_SMALL="glm-4.5-air"   # schnelleres Modell für interne Tool-Calls

ANTHROPIC_BASE_URL="$ZAI_BASE" \
ANTHROPIC_AUTH_TOKEN="$ZAI_KEY" \
ANTHROPIC_MODEL="$ZAI_MODEL" \
ANTHROPIC_SMALL_FAST_MODEL="$ZAI_SMALL" \
claude "$@"

Qwen3-max (~/qwen/qwen.sh):

#!/usr/bin/env bash
set -euo pipefail

QWEN_KEY="${QWEN_KEY:-}"
QW_BASE="https://dashscope-intl.aliyuncs.com/apps/anthropic"
QW_MODEL="qwen3-max"

# Zwei Caveats:
# (1) International/Singapore-Key nötig — China-Key gibt 401.
# (2) qwen3-coder funktioniert am intl-Endpoint nicht → qwen3-max nutzen.
# (3) Claude Code >=2.1.154 schickt role:"system" mitten in messages[] —
#     Qwen-Endpoint kann abbrechen → erst 'qwen.sh check' laufen lassen.

ANTHROPIC_BASE_URL="$QW_BASE" \
ANTHROPIC_AUTH_TOKEN="$QWEN_KEY" \
ANTHROPIC_MODEL="$QW_MODEL" \
ANTHROPIC_SMALL_FAST_MODEL="$QW_MODEL" \
claude "$@"

Drei Dinge fallen dabei auf:

1. Gleiche vier Variablen überall. ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL, ANTHROPIC_SMALL_FAST_MODEL — das ist die komplette Schnittstelle. Claude Code fragt nur nach diesen vier; alles andere (Prompts, Tool-Definitionen, Retry-Logik) bleibt unberührt.

2. Z.ai hat ein echtes Small-Model (glm-4.5-air für schnelle interne Tool-Calls). DeepSeek und Qwen setzen beide auf dasselbe Modell für groß und klein. Ob das die Latenz beeinflusst hat, ist offen — aber es ist ein struktureller Unterschied.

3. Qwen hat ein Kompatibilitätsproblem. Ab Claude-Code-Version 2.1.154 schickt der CLI role:"system" mitten in das messages[]-Array — Qwens Endpoint akzeptiert das nicht immer. Deshalb gab es beim ersten Lauf einen 401-Fehler. Gelöst durch Pinnen der Claude-Code-Version. Das ist kein Qwen-Modellproblem im engeren Sinne, sondern eine Endpoint-Inkompatibilität. Trotzdem ist es operatives Risiko — DeepSeek und GLM haben dieses Problem nicht.

Zwei ehrliche Einschränkungen

1. Claude-Heimvorteil. Claude Code ist für Claude gebaut — System-Prompts, Tool-Definitionen, Fehlerbehandlung, alles ist auf Anthropics Modelle abgestimmt. Fremdmodelle laufen im „fremden Anzug". Was das bedeutet: Wo ein Nicht-Anthropic-Modell trotzdem gut abschneidet, ist das eher unter- als überschätzt. Es arbeitet mit einem strukturellen Nachteil. DeepSeeks Opus-Niveau ist deswegen umso bemerkenswerter.

2. Mistral lief separat. Mistral hat keinen Anthropic-kompatiblen Endpunkt angeboten. Es wurde über das eigene Produkt (Le Chat / Codestral, Pro-Abo) getestet — anderes Interface, andere Prompting-Schicht. Das ist eine echte Asymmetrie. Mistral-Ergebnisse sind nicht 1:1 vergleichbar. Der Vollständigkeit halber steht Mistral trotzdem in der Tabelle, mit entsprechender Kennzeichnung.

---

Nachtrag: ein Modell ohne CLI fair einbinden

Codestral — Mistrals Code-Spezialist, lokal über Ollama — ist ein lehrreicher Sonderfall, der zeigt, wie schief ein Vergleich gehen kann, wenn man nicht aufpasst.

Der naive Weg ist ollama run codestral "..." — und genau der ist unfair. Das ist ein reines Chat-Modell: Es gibt Text aus, kann keine Dateien anlegen, keine Tests ausführen, sich nicht selbst korrigieren. Die anderen fünf liefen in einer agentischen CLI, die genau das kann. Single-shot gegen agentisch zu vergleichen wäre, als ließe man einen Boxer mit gefesselten Armen antreten.

Fair wird es erst, wenn Codestral denselben Harness bekommt. Das geht — mit zwei Kniffen:

1. Eine Brücke OpenAI ↔ Anthropic. Ollama spricht das OpenAI-Protokoll, Claude Code das von Anthropic. Ein kleiner Proxy (LiteLLM) übersetzt dazwischen:

# litellm.yaml
model_list:
  - model_name: codestral-32k
    litellm_params:
      model: ollama_chat/codestral-32k
      api_base: http://localhost:11434

litellm --config litellm.yaml --port 4000

Dann zeigt Claude Code einfach dorthin:

ANTHROPIC_BASE_URL="http://localhost:4000" claude

2. Den Context-Speicher aufbohren. Ollamas Standard-Context ist ~4.000 Token. Der agentische Harness schickt System-Prompt, Tool-Definitionen und Dateiinhalte mit — das sprengt 4k sofort, und das Modell „vergisst" mittendrin die Hälfte. Lösung:

printf 'FROM codestral\nPARAMETER num_ctx 32768\n' > Modelfile
ollama create codestral-32k -f Modelfile

Erst mit beidem ist Codestral fair im Rennen.

Und dann die eigentliche Wand: „Code-Modell" ≠ „Agenten-Modell"

Mit Proxy und großem Context dachte ich, Codestral sei fair im Rennen. Dann kam:

{"error":"codestral-32k does not support tools"}

Codestral unterstützt schlicht kein Tool-Calling. Und ein agentischer Coding-Assistent ist ohne Werkzeuge nichts — er muss Dateien lesen und schreiben, Befehle ausführen, Tests starten. „Die Werkzeuge wegnehmen" wäre keine Lösung, sondern das Ende der Aufgabe.

Das ist die unterschätzte Erkenntnis: Codestral, das Modell das alle als Mistrals „Coder" kennen, kann gar nicht agentisch arbeiten. Es schreibt Schnipsel — gut sogar — aber es kann keine Anwendung selbstständig zusammenbauen.

Mistrals agentisches Modell heißt Devstral. Das ist ein anderes Tier, extra für Tool-Use und SWE-Agenten gebaut. Wer ein KI-Modell für echte Entwicklungs-Workflows sucht (nicht nur Autocomplete), muss nicht auf den Namen „Code" schauen, sondern auf eine konkrete Fähigkeit: beherrscht es Tool-Calling? Ohne die bleibt es ein besserer Lückenfüller, kein Mitarbeiter.

Der ehrliche Asterisk bleibt: Die nativen Modelle (DeepSeek, GLM, Qwen) sprechen Anthropic direkt, Codestral müsste über eine Übersetzungsschicht laufen, die selbst Reibung erzeugen kann. „Fair, mit Sternchen" — und das gehört dazugesagt.

---

Die zwei Aufgaben

Aufgabe 1 — eine Funktion mit eingebauten Fallen

Alle Modelle bekamen exakt dieselbe Aufgabenstellung:

Schreib eine TypeScript-Funktion getBusinessHoursStatus(date: Date, hours: BusinessHours, timeZone: string).

Rückgabe: { open: boolean; nextChange: Date } — ist gerade geöffnet, und wann kippt der Status das nächste Mal.

Keine externen Bibliotheken. Nur Intl. Korrekte Sommer-/Winterzeit (DST). nextChange auch übers Wochenende korrekt. Dazu fünf Unit-Tests.

Klingt nach Anfänger-Aufgabe. Ist es nicht. Die Falle sitzt in einem einzigen Satz: „in einer Zeitzone". Sobald die Ziel-Zeitzone (z.B. Berlin, UTC+1/+2) nicht die Zeitzone des Servers ist, werden naive Lösungen falsch — ohne sichtbaren Fehler, weil die Tests auf demselben Rechner laufen und dort zufällig die richtige Zeitzone steht.

Was diese Aufgabe bewertet:

• Zeitzonen-Korrektheit (DST-Logik richtig?)
• Schleifenlogik über Tagesgrenzen und Wochenenden
• Testqualität (testen die Tests das Richtige, oder testen sie zirkulär den eigenen Code?)
• Selbst-Verifikation (meldet das Modell „grün", ohne es wirklich geprüft zu haben?)

Aufgabe 2 — eine ganze App

Bau ein „Mahnwesen-Cockpit": Next.js (App Router) + TypeScript + Tailwind CSS.

• In-Memory-Datenspeicher (keine externe Datenbank)
• Mahnstufen 0–4 mit automatischer Eskalation nach 14-Tage-Regel
• Mahngebühren je Stufe, Gesamtsumme korrekt berechnet
• Dashboard mit Kennzahlen (offene Posten, Gesamtrückstand, Verteilung nach Stufe)
• Server-seitige Validierung (nicht nur Client-Checks)
• Optimistic UI mit Rollback bei Server-Fehler
• Geldbeträge intern in Cent (Integer), Anzeige via Intl.NumberFormat
• Domäne getrennt von UI-Schicht (keine Business-Logik in React-Komponenten)
• Unit-Tests für Domänen-Logik
• Vollständige, lauffähige Projekt-Struktur (npm install && npm run build muss durch)

Das ist eine andere Größenordnung. Keine isolierte Funktion, sondern ein System. Mehrere Dateien, mehrere Schichten, mehrere Architekturentscheidungen.

Was diese Aufgabe bewertet:

• Architektur-Disziplin (Domäne vs. UI-Schicht getrennt?)
• Server/Client-Grenze in Next.js App Router (Server Actions richtig eingesetzt?)
• Geld- und Datums-Logik (Cent-Integer konsequent? DST in Fälligkeit?)
• Tatsächliche Lauffähigkeit (npm install && npm run build && npm test)
• Selbst-Verifikation (behauptet das Modell „fertig", ohne gebaut zu haben?)

Warum beide Aufgaben fieser sind als sie klingen — die versteckten Fallen im Detail — folgt in der Reihe.

---

Wie bewertet wurde — der eigentliche Punkt

Vier Methoden, keine davon vertraut dem Modell blind.

1. Zeitzonen-Härtetest

Jede Testsuite lief unter vier Maschinen-Zeitzonen:

TZ=Europe/Berlin    npm test   # Heimzone des Tests — sollte trivial grün sein
TZ=UTC              npm test   # +0, Standardfall für Cloud-Server
TZ=America/New_York npm test   # -5/-4, übliche Cloud-Region
TZ=Asia/Kolkata     npm test   # +5:30 — halber Offset, entlarvt Integer-Annahmen

Kolkata ist bewusst drin. Ein +5:30-Offset entlarvt Lösungen, die innerlich auf ganzzahlige Zeitverschiebungen bauen — was viele naiv tun, weil die meisten Zeitzonen tatsächlich ganzzahlig sind.

Ein Modell, das 5/5 Tests unter Berlin besteht und 1/5 unter UTC: das ist kein grünes Modell. Es ist ein Modell, das zufällig auf dem richtigen Rechner getestet hat.

2. Unabhängiger Gegen-Check

Ich traue den selbst geschriebenen Tests eines Modells nicht — aus gutem Grund: Wenn der Code falsch ist und die Tests mit derselben falschen Logik geschrieben wurden, heben sich beide Fehler auf. Ergebnis: grün. Zwei falsche ergeben richtig. Das ist die gefährlichste Art von grünen Tests.

Deshalb habe ich gegen von Hand gerechnete UTC-Zeitpunkte geprüft:

// Testfall: Mo 15.01.2024, 11:30 Uhr Berlin (Winter, UTC+1)
// Öffnungszeiten: 09:00–12:00 und 13:00–17:00
// Erwartet: geschlossen (Mittagspause), nächste Öffnung 13:00 Berlin
// 13:00 Berlin (UTC+1 im Januar) = 12:00:00 UTC
expect(
  getBusinessHoursStatus(
    new Date("2024-01-15T10:30:00.000Z"),  // 11:30 Berlin in UTC
    hours,
    "Europe/Berlin"
  ).nextChange.toISOString()
).toBe("2024-01-15T12:00:00.000Z");

// Testfall: Fr 29.03.2024, 16:30 Uhr Berlin (letzter Tag vor Sommerzeit)
// Erwartet: offen, nächste Änderung Freitag 17:00 Berlin
// 29.03.2024: Winterzeit UTC+1 → 17:00 Berlin = 16:00:00 UTC
expect(
  getBusinessHoursStatus(
    new Date("2024-03-29T15:30:00.000Z"),  // 16:30 Berlin in UTC
    hours,
    "Europe/Berlin"
  ).nextChange.toISOString()
).toBe("2024-03-29T16:00:00.000Z");

Diese Werte sind hartkodiert. Das Modell hat sie beim Schreiben nicht gekannt. Sie sind die unbestechliche Wahrheit — entweder stimmt der UTC-Zeitstempel oder nicht.

Das Qwen-Lehrstück hierzu ist besonders perfide: Qwen3-max lieferte eigene Tests, die unter jeder Zeitzone grün waren — auch unter UTC und New York. Der Grund: Die Erwartungswerte in den Tests wurden mit derselben kaputten toLocaleString-Technik berechnet wie der Code selbst. Fehler hebt Fehler auf. Erst mein Gegen-Check mit hand-gerechneten UTC-Instants zeigte: nextChange war außerhalb Berlins systematisch falsch — um exakt den Maschinen-zu-Berlin-Versatz (UTC +1h, New York +6h, Kolkata −4,5h).

3. Die letzte Meile

Bei Aufgabe 2 (der App) habe ich nicht „sieht vollständig aus" als Abnahme akzeptiert. Der Test war:

npm install && npm run build && npm test

Kein manuelles Nachbessern, kein „das müsste eigentlich laufen". Entweder baut es im ersten Anlauf oder nicht.

Was dabei auf den Tisch kommt: fehlende "use client"-Direktiven, falsche Import-Pfade, TypeScript-Fehler, die das Modell beim Generieren nicht gesehen hat, und bei zwei Kandidaten fehlende package.json-Einträge. Das sind die Dinge, die beim Kunden nach dem Copy-Paste schieflaufen — nicht auf dem Laptop des Modells.

4. Selbst-Verifikation

Das ist das Kriterium, das für autonomes Arbeiten am meisten zählt. Die Frage ist nicht, ob ein Modell einen Fehler macht — das tut jeder. Die Frage ist: Behauptet es Korrektheit, ohne sie geprüft zu haben?

Aus dem Feld: Mistral setzte einen grünen Haken auf „alle Tests bestanden" — ohne dass die Tests je gelaufen sind. Die Testsuite hatte einen Syntax-Fehler. Kein Test hat begonnen. Das Modell hat trotzdem bestätigt: fertig.

Das ist der Unterschied, der im produktiven Einsatz zählt. Ein Modell, das ehrlich sagt „ich hab das nicht ausgeführt, prüf das bitte" ist besser als eins, das schweigt und „passed" tippt. Ein Agent ist nur so verlässlich wie sein „passed" ehrlich ist.

---

Was in dieser Reihe kommt

Fünf weitere Teile, alle aus denselben Rohdaten. Am besten in Reihenfolge, aber jeder steht auch für sich:

1. Warum grüne Tests lügen — und wie man Zeitzonencode richtig testet
2. Selbstbewusst falsch: Warum KI-Selbst-Verifikation wichtiger ist als Rohleistung
3. Die letzte Meile — welche KI baut eine App, die startet
4. Das billigste KI-Modell kam fast an die Spitze — Token-Kosten im Vergleich
5. KI im eigenen Haus: Datensouveränität, DSGVO und DeepSeek self-hosting

Die weiteren Teile erscheinen in den kommenden Wochen.

---

Häufige Fragen

Was ist agentisches Coding? Agentisches Coding bedeutet, dass ein KI-Modell nicht nur Text ausgibt, sondern aktiv Werkzeuge nutzt: Dateien lesen und schreiben, Befehle ausführen, Tests starten, Fehler korrigieren — und das in einer selbstgesteuerten Schleife, ohne nach jedem Schritt auf menschliche Eingabe zu warten. Eine Funktion in den Chat schreiben ist kein agentisches Coding; eine vollständige App bauen, die kompiliert und alle Tests besteht, schon.

Was ist GEO im Kontext von KI-Modellen? GEO (Generative Engine Optimization) bezeichnet das Schreiben von Inhalten so, dass sie von KI-Systemen (Suchassistenten, Chatbots, RAG-Pipelines) zitierbar und nutzbar sind. Konkrete Fakt-Sätze mit Zahlen, klare Definitionen und autoritativer Ton erhöhen die Wahrscheinlichkeit, dass ein KI-System diesen Inhalt als Quelle verwendet.

Warum Claude Code als gemeinsames Werkzeug und nicht ein neutrales? Weil es das Werkzeug ist, das ich produktiv nutze. Der Vergleich ist nicht akademisch, sondern praxisorientiert: Laufen die Alternativen gut genug im Setup, das ich ohnehin betreibe? Ich habe den Heimvorteil für Claude offen benannt — das schließt ihn ein, es eliminiert ihn nicht.

Warum kein GPT-4 oder Gemini im Feld? Das Motiv war Datensouveränität und nicht-US-Alternativen. GPT und Gemini sind US-Modelle — sie beantwortet nicht die Frage, die mich interessiert hat: Gibt es belastbare Alternativen außerhalb des US-Ökosystems?

Können die Launcher-Skripte direkt verwendet werden? Ja, mit einem Vorbehalt: die Skripte nutzen Umgebungsvariablen für API-Keys (nie im Skript selbst). Der Qwen-Launcher erfordert einen International/Singapore-Key (China-Key gibt 401) und qwen3-max statt qwen3-coder (letzterer funktioniert am internationalen Endpoint nicht).

---

Transparenz: Rohdaten und Testausgaben intern dokumentiert. Modell-Versionsstände: Stand Juni 2026, API-seitig verifiziert. Keine Kundendaten in Beispiel-Code. Zahlen vor Veröffentlichung frisch prüfen.