Kimi K3 oder DeepSeek V4-Pro? 10 Tests, ein Endpunkt – und die Falle bei Code-Aufgaben

Gleiche Trefferquote, dreifache Wartezeit – und bei Code dreht sich das Verhältnis um

Konzeptgrafik zu diesem Vergleich, kein Produkt-Screenshot.

Ich wollte das Standardmodell für meine tägliche Entwicklungsarbeit austauschen und habe Kimi K3 und DeepSeek V4-Pro deshalb durch zehn identische Aufgaben geschickt. Das Ergebnis vorweg: die Trefferquote ist identisch, die Antwortzeit unterscheidet sich um den Faktor drei – und ausgerechnet bei Code-Aufgaben kehrt sich der Vorteil um.

Das Problem mit vorhandenen Vergleichen

Zuerst habe ich nach bestehenden Auswertungen gesucht. Die widersprechen sich allerdings deutlich: denselben Coding-Benchmark habe ich auf zwei Seiten mit 37 Punkten Unterschied gefunden. Die üblichen Ursachen sind nicht abgeglichene Thinking-Modi, unterschiedliche Test-Scaffolds und das Vermischen von Preisklassen.

Also selbst gemessen, am 15. Oktober 2026.

Aufbau

Der wichtigste Teil, weil er über die Aussagekraft entscheidet.

Mein erster Durchlauf war ein Fehlschlag: separate Zugänge bei beiden Anbietern, zwei Skripte, Zeiten vergleichen. Das habe ich verworfen. Gateway-Standort, Rate-Limits und Queueing unterscheiden sich pro Anbieter – wenn ein Aufruf zwei Sekunden länger braucht, lässt sich nicht trennen, ob das vom Modell oder von der Leitung kommt. Dazu kamen abweichende Default-Parameter in den beiden Skripten.

Der zweite Aufbau lief über einen einzigen Endpunkt. Beide Modelle sind über die Coding-Modellübersicht von Crazyrouter direkt erreichbar, das Protokoll ist OpenAI-kompatibel, und zwischen den Modellen wechselt man über das model-Feld – sonst ändert sich nichts.

Parameter	Wert
Datum	15. Oktober 2026
Modelle	kimi-k3 / deepseek-v4-pro
Protokoll	OpenAI-kompatibel
Request-Parameter	für beide Modelle identisch, Defaults unverändert
Streaming	deaktiviert
Stichprobe	ein Durchlauf pro Aufgabe
Bewertung	automatisch, nicht manuell

Zehn Aufgaben in sechs Kategorien: strukturierte Ausgabe, Instruction Following, Logik, Arithmetik, Code sowie eine Aufgabe, in deren Fragestellung ich eine falsche Prämisse eingebaut habe.

Ein Durchlauf pro Aufgabe reicht für eine Richtungsaussage, nicht für Fehlerraten. Entsprechend steht unten keine.

Ergebnis 1: Trefferquote identisch

Neun von neun, bei beiden Modellen.

Das ist selbst ein Befund. Bei Aufgaben dieses Schwierigkeitsgrads trennen Benchmark-Tabellen genau das nicht, worauf es in der Praxis ankommt.

Ergebnis 2: DeepSeek V4-Pro antwortet etwa dreimal schneller

	Kimi K3	DeepSeek V4-Pro
Median	14,95 s	4,75 s
Summe über 10 Aufgaben	242,6 s	105,1 s

In acht von zehn Aufgaben lag V4-Pro zwischen Faktor 2,3 und 8,3 vorn. Für alles, worauf jemand wartet, ist das die eigentliche Entscheidung.

Ergebnis 3: Der größte Teil der Abrechnung ist unsichtbar

Hier wurde es interessant.

Eine Aufgabe lautete sinngemäß: Ein Seerosenblatt verdoppelt täglich seine Fläche und bedeckt den Teich an Tag 48 – an welchem Tag ist der Teich halb bedeckt? Nur die Zahl ausgeben.

V4-Pro antwortete korrekt mit 47. In der Usage-Abrechnung standen 80 Output-Tokens, davon 78 Reasoning-Tokens. Die zweistellige Zahl, die ich wollte, machte 2,5 Prozent des Abgerechneten aus.

	Kimi K3	DeepSeek V4-Pro
Output-Tokens gesamt	4.067	5.345
davon Reasoning	3.222 (79,2 %)	4.742 (88,7 %)

Erstellt aus den Messdaten dieses Durchlaufs, 15. Oktober 2026.

Bei den vier Aufgaben, in denen ich ausdrücklich „nur die Zahl" oder „nur ein Wort" verlangt habe, lag der Reasoning-Anteil zwischen 78,0 und 97,9 Prozent. V4-Pro hat über diese vier Aufgaben hinweg zehn Tokens sichtbaren Inhalt erzeugt; abgerechnet wurden 286.

Das Muster läuft gegen die Intuition: je strikter man „nur die Antwort" verlangt, desto höher der unsichtbare Anteil. Kurze Antwort, größerer Anteil fürs Denken.

Das Feld liegt eine Ebene unter dem Completion-Zähler und wird dort separat geführt:

"completion_tokens": 62,
"completion_tokens_details": {
  "reasoning_tokens": 60
}

Beim erneuten Durchlauf derselben Aufgabe kamen 62/60 statt 80/78 heraus – die Denklänge schwankt zwischen Aufrufen. Einzelne Messpunkte taugen also für die Größenordnung, nicht als exakter Wert. Aus Neugier habe ich noch nach 1+1 gefragt, Ziffern only: Antwort 2, dafür 32 Reasoning-Tokens.

Ergebnis 4: Bei Code kippt es

Die beiden Ausnahmen von Ergebnis 2 sind beides Code-Aufgaben.

Aufgabe	Kimi K3	DeepSeek V4-Pro
Intervall-Merge-Funktion schreiben	15,4 s / 265 Tokens	24,6 s / 1.677 Tokens
Bug in einem Snippet finden	28,0 s / 433 Tokens	39,4 s / 2.100 Tokens

Erstellt aus den Messdaten dieses Durchlaufs. Code-Aufgaben farblich abgesetzt.

Für die Merge-Funktion verbrauchte V4-Pro 1.677 Output-Tokens, davon 1.579 fürs Denken. K3 kam mit 265 aus. Bei der Fehlersuche waren es 2.100 Tokens mit 96 Prozent Reasoning – auf eine Frage, die auf „was ist hier falsch" hinauslief.

Beide Antworten waren korrekt. Aber dasselbe richtige Ergebnis über etwa den sechsfachen Umweg.

Das ist der Satz, den ich aus dem ganzen Durchlauf mitnehme: Der relevante Unterschied liegt nicht darin, ob die Modelle ankommen, sondern wie weit der Weg dorthin ist.

Wo der längere Weg sich auszahlt

Eine Dimension dreht sich um. In der Aufgabe mit der falschen Prämisse behauptete ich, Pythons sort liefere eine sortierte Kopie zurück, und fragte, ob das None-Ergebnis ein Versionsfehler sei.

Beide Modelle sind nicht darauf eingestiegen; beide haben korrigiert. K3 ergänzte aber ungefragt, dass in Python grundsätzlich alle Methoden, die das Objekt selbst verändern – sort, append, extend, reverse – None zurückgeben. Aus einem Einzelfakt wurde eine Regel. V4-Pro war knapper, genauso richtig, ohne diesen Absatz. K3 brauchte dafür 91 Sekunden und 1.951 Tokens, V4-Pro war nach 11 Sekunden fertig.

In einer V4-Pro-Antwort ist mir außerdem ein Artefakt aufgefallen: In einem Code-Kommentar stand zuerst ein falscher Wert, in derselben Zeile korrigiert, beide blieben stehen. Für die Korrektheit unerheblich – nicht unerheblich, wenn man Modellausgaben direkt in Dokumentation übernimmt.

Fazit und Einordnung

Laut den veröffentlichten Angaben beider Anbieter skaliert K3 nach oben: 2,8 Billionen Parameter, tragfähig gemacht durch einen gemischt-linearen Attention-Mechanismus namens KDA, der das Verhältnis von Textlänge zu Rechenaufwand von quadratisch auf linear bringt. V4-Pro verkleinert dagegen den einzelnen Aufruf: 1,6 Billionen Parameter als Mixture-of-Experts, von denen pro Inferenz rund 49 Milliarden aktiv werden – etwa drei Prozent.

Ein Lizenzunterschied gehört dazu: Beide gelten als offen, DeepSeek steht aber unter einer klaren MIT-Lizenz, Kimi K3 unter einer modifizierten MIT mit Namensnennungsklausel. Wer Gewichte ins eigene Produkt holen will, sollte beide Lizenztexte selbst lesen – auch diese Zusammenfassung nicht ungeprüft übernehmen.

Meine Aufteilung: Alltagsentwicklung und alles Interaktive über DeepSeek V4-Pro. Wenn die Ausgabe direkt an einen Menschen geht – Dokumentation, Kundenantwort, Schulungsmaterial – Kimi K3. Bei überwiegend Code-Arbeit beide selbst testen, denn genau dort zeigt mein Durchlauf in die unerwartete Richtung, und Code-Aufgaben streuen zwischen Codebasen zu stark, als dass zwei Stichproben etwas entscheiden sollten.

Nicht abgedeckt: ein Durchlauf pro Aufgabe, also keine Aussage zu Fehlerraten oder Stabilität. Long-Context komplett ungetestet. Alles Single-Turn, also kein Tool-Calling, keine Mehrfach-Korrektur, keine Retry-Kosten – nach der Logik des Reasoning-Befunds vermutlich genau der Bereich mit dem größten Unterschied. Flash-Stufe nicht getestet. Architektur- und Parameterangaben sind zitiert, nicht selbst verifiziert.

Eine Frage an euch

Falls ihr eines der beiden Modelle produktiv einsetzt, interessiert mich vor allem eines: Wie hoch ist euer Reasoning-Anteil?

Zieht das Feld einmal für das Modell, das ihr gerade bezahlt. Es sagt nichts darüber, welches Modell besser ist – aber es sagt, womit euer Aufruf tatsächlich beschäftigt war.