Kimi K3 im Vergleich zu GPT-5.6-SOL: Praxistest bei schweren Aufgaben aus Mathematik, Physik und Programmierung

Diesmal geht es nicht um einfache Q&A, sondern um drei fest definierte Aufgaben, die mehrstufiges Schlussfolgern verlangen: eine Wahrscheinlichkeitsaufgabe mit Musterüberlappung und zweitem Moment, eine Physikaufgabe mit Trägheitsmoment der Rolle und Umschalten durch Seilentspannung sowie eine Python-Aufgabe mit Closure, mehrtägigen Kapazitäten und dreistufigem Tie-Break. Beide Modelle liefen über dieselbe Schnittstelle, mit demselben Prompt und vergleichbaren Ausgabelimits, ohne Tools und ohne Internetzugriff.

Vorab das Ergebnis:

• gpt-5.6-sol lieferte bei allen drei Aufgaben vollständige sichtbare Antworten; die Referenzwerte in Mathematik und Physik waren korrekt.
• kimi-k3 endete unter dem ersten 6500-Token-Limit bei Mathematik und Physik jeweils mit finish_reason=length; die sichtbare Antwort blieb leer. Selbst nach Erhöhung des Limits auf 10000 bei der Matheaufgabe wurde der Output wieder abgeschnitten. Die Programmieraufgabe lief nach rund 245 Sekunden in einen Read-Timeout.
• Die Programmierimplementierung von GPT-5.6-SOL bestand unabhängige Zusatzprüfungen zu Dependency-Closure, Kapazität, Tie-Break, ungültigen Abhängigkeiten und Zyklen. Allerdings war die erste mitgelieferte Assertions-Beispielprüfung mit einem falschen Erwartungswert versehen. Das zeigt: „Kernlogik korrekt“ und „alle Beispieltests korrekt“ sind getrennt zu bewerten.

Die hier gemessene Latenz ist der beobachtete Wert dieser Anfrage und kein fester SLA-Wert. In den ersten parallelen Requests erhielt GPT für Mathematik und Physik zunächst HTTP 408; danach wurde sequenziell erneut versucht. Daher dient die Geschwindigkeit hier nur der Beobachtung der Nutzungserfahrung, nicht als absoluter Rangvergleich.

Testaufbau

Getestet wurde vom 2026-07-17 bis 2026-07-18 (Beijing-Zeit), über:

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

In der ersten Runde galten einheitlich: Mathematik und Physik max_tokens=6500, Programmierung max_tokens=7500. Jede Aufgabe verlangte entweder eine überprüfbare Herleitung oder ausführbaren Code. Zusätzlich wurden finish_reason, completion/reasoning tokens, Request-Latenz, numerische Korrektheit sowie die eigenständige Ausführbarkeit in Python 3.11 protokolliert.

Gesamtergebnis-Tabelle

Aufgabe	kimi-k3	gpt-5.6-sol	Beurteilung
Mathematik: Erwartungswert und Varianz von HHTH	length, 186.98 s, 6500 tokens; sichtbarer Inhalt leer	sequenzieller Retry stop, 236.07 s, 6872 tokens	GPT vollständig; Kimi in Runde 1 ohne Antwort
Physik: Rolle, Bodenkontakt, Feder	length, 202.05 s, 6500 tokens; sichtbarer Inhalt leer	sequenzieller Retry stop, 156.29 s, 4501 tokens	GPT vollständig und numerisch korrekt
Programmierung: Dependency-Closure-Rucksackproblem	nach 245.54 s TimeoutError	stop, 87.96 s, 4514 tokens	GPT-Code lauffähig; Kimi gab keinen vollständigen Code zurück
Kimi Mathe-Repeat	length, 286.99 s, 10000 tokens	—	Auch mit höherem Budget kein Abschluss

Bei Kimi meldete die Schnittstelle für Mathematik und Physik jeweils einen reasoning token-Wert nahe 6497; beim Mathe-Repeat lag er nahe 9997. Das heißt nicht, dass Kimi keine Schlussfolgerungsfähigkeit hat, sondern dass unter diesem Prompt und über diesen Router das Reasoning-Budget sehr leicht aufgebraucht wird und der Auftraggeber am Ende keine finale Antwort erhält.

Mathematikaufgabe: Musterüberlappung beeinflusst nicht nur den Erwartungswert, sondern auch die Varianz

Die Aufgabe lautet: Bei Kopf-Wahrscheinlichkeit p=3/5 und Zahl-Wahrscheinlichkeit q=2/5 wird so lange geworfen, bis erstmals HHTH erscheint, wobei Überlappungen erlaubt sind. Gesucht sind E[T] und Var(T).

Die korrekten Präfix-Automat-Zustände sind S0=leeres Präfix, S1=H, S2=HH, S3=HHT, S4=HHTH (absorbierender Zustand). Der entscheidende Übergang ist S2 --H--> S2: Nach HH bleibt bei erneutem H der längste Suffix weiterhin HH; man darf also nicht fälschlich auf den Leerzustand zurückfallen.

Die von GPT-5.6-SOL aufgestellten Gleichungen für das erste Moment waren:

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

Nach Aufstellen der Gleichungen für das zweite Moment ergibt sich:

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

Der Erwartungswert lässt sich außerdem unabhängig über die Randformel gegenprüfen. Die nichtleeren echten Ränder von HHTH bestehen aus dem Einzelzeichen H, daher gilt E[T] = 1/p + 1/(p³q) = 715/54. Die vollständige GPT-Antwort deckte Zustandsübergänge, die Herleitung des zweiten Moments und den Sanity Check ab. Kimi lieferte weder bei 6500 noch bei 10000 Tokens eine sichtbare Herleitung, daher lässt sich die mathematische Korrektheit in dieser Runde nicht bewerten; es bleibt bei „innerhalb des Budgets nicht abgeschlossen“.

Physikaufgabe: Nach dem Bodenkontakt reißt die Zwangsbedingung, dieselbe Energiebilanz gilt dann nicht mehr

Gegeben sind: m_A=4.0 kg auf einer rauen Ebene mit 25°, μ_k=0.18; m_B=3.0 kg hängt frei; die Rolle hat M_p=1.2 kg, R=0.10 m; nach dem Absenken um 1.50 m trifft B auf den Boden und das Seil wird sofort locker; A gleitet danach noch 0.10 m nach oben und trifft auf eine Feder mit k=250 N/m; g=9.8 m/s².

Vor dem Bodenkontakt ist das Seil gespannt und es gibt kein Schlupfen. Die äquivalente Trägheitsmasse der Rolle ist I/R²=(1/2)M_p=0.60 kg. Aus der gemeinsamen Bewegung von beiden Massen und der Rotationsgleichung der Rolle folgt:

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

Nach dem Bodenkontakt ändert sich die Geschwindigkeit von B durch den Aufprall am Boden, A besitzt weiterhin eine Geschwindigkeit entlang der schiefen Ebene nach oben, und auch die Rolle kann sich noch weiterdrehen. Da die Aufgabe ausdrücklich sagt, dass das Seil sofort locker wird, darf man v_A=v_B=Rω nicht einfach weiterverwenden. Danach ist nur noch A separat zu betrachten:

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL prüfte zusätzlich die Dimensionen, die Stoppstrecke ohne Feder sowie die Konsistenz zwischen Federenergie und den Verlusten durch Reibung und Gewichtskraft. Die Zahlen stimmen in sich. Kimi erzeugte in der ersten Runde keine sichtbare Antwort, daher gibt es keinen Vergleich der Zwischenschritte.

Programmieraufgabe: Der Algorithmuskern ist nach unabhängiger Prüfung ok, aber das Modell brachte einen fehlerhaften eigenen Test mit

Die Programmieraufgabe verlangte die Implementierung von optimize_release_plan(items, capacity_by_day, dependencies). Berücksichtigt werden mussten Tageskapazitäten, Kapazität 0 für nicht konfigurierte Tage, transitive Dependency-Closure, ungültige Abhängigkeiten und Zyklenerkennung sowie ein dreistufiger Tie-Break über value → risk → sortierte id-Liste. Da items <= 18 ist, ist eine Bitmasken-Enumeration ein vernünftiger Ausgangspunkt.

GPT-5.6-SOL verwendete gecachte Dependency-Closure und eine 2^n-Teilmenge-Enumeration. Wir haben den Code herausgelöst und in Python 3.11 unabhängig geprüft: Dependency-Closure, Mehrtages-Kapazitätsbeispiele, die dreistufige Tie-Break-Reihenfolge value/risk/id, nicht konfigurierte Tageskapazität, nicht vorhandene Abhängigkeiten und Zyklusabhängigkeiten – alle 6 Prüfungen bestanden.

Allerdings schlug die erste im Code angehängte Assertion fehl: Dort stand A -> B -> C, gleichzeitig war aber noch X mit Wert 11 enthalten. Unter der gegebenen Kapazität beträgt der Gesamtwert von B + C + X 13 und liegt damit über A + B + C mit 12. Daher ist ['B', 'C', 'X'] korrekt; die Assertion mit ['A', 'B', 'C'] war ein Fehler im Test-Setup.

Dieses Detail ist sehr typisch: Bei Codeaufgaben darf man nicht nur auf die Funktionslogik schauen, und man sollte auch nicht allein wegen „8 beigefügten Assertions“ die Tests für vertrauenswürdig halten. Auch vom Modell erzeugte Testdaten brauchen eine manuelle oder referenzbasierte Gegenprüfung. Der Programmier-Request von Kimi K3 lief nach rund 245 Sekunden in einen Read-Timeout, sodass kein vollständiger Code vorlag.

Gesamtbewertung

Dimension	kimi-k3	gpt-5.6-sol
Mathematische Vollständigkeit	bei 6500/10000 Token jeweils abgeschnitten, keine Abnahme möglich	Erwartungswert, zweites Moment, Varianz und Sanity Check vollständig
Physikalisches Modellieren	in Runde 1 abgeschnitten	Rolle mit Trägheit, Seilentspannung und Federphase korrekt behandelt
Code-Lieferung	in dieser Runde Timeout	Kernlogik bestand unabhängige Prüfung, aber eine beigefügte Assertion war falsch
Ausgabe-Stabilität	hoher Reasoning-Verbrauch, sichtbare Antwort oft nicht verfügbar	bei allen drei Aufgaben sequenzieller Retry mit stop
Reaktionsgeschwindigkeit	ca. 187–246 s, dazu Abschneiden/Timeout	erfolgreiche Requests ca. 88–236 s; in der ersten parallelen Runde HTTP 408

Die treffendere Schlussfolgerung lautet also nicht „ein Modell ist generell klüger“, sondern:

1. Unter diesem Router und Budget bringt GPT-5.6-SOL komplexes Reasoning eher bis zu einer finalen Antwort und eignet sich damit besser für Workflows, die sofort lesbare Herleitungen oder Code benötigen.
2. Das Hauptproblem von Kimi K3 liegt in der Umwandlung von Reasoning-Budget in sichtbare Ausgabe; selbst bei 10000 Tokens in der Matheaufgabe kam kein Abschluss zustande.
3. Auch GPT-5.6-SOL darf man beim Code nicht blind vertrauen. Die Funktionslogik war unabhängig korrekt, aber das mitgelieferte Test-Setup hatte einen Fehler bei der Wertberechnung.
4. Für eine belastbare Produktionsentscheidung sollten finish_reason, reasoning tokens, Latenz und lokale Testergebnisse immer gemeinsam erfasst werden. Es reicht nicht, nur den letzten Satz „Antwort ist korrekt“ zu betrachten.

Reproduktion

Die Testskripte und die Ergebnisse der sequenziellen Retries sind hier abgelegt (inklusive des in der ersten parallelen Runde erzeugten Summaries im Skript-Output):

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

Für eine erneute Messung empfiehlt es sich, Modell-ID, Prompt, temperature, max_tokens und Parallelitätsgrad zu fixieren und jede Ausgabe separat zu speichern. Last auf dem Upstream-Kanal, Cache-Treffer und Rate-Limiting-Zustand beeinflussen die Latenz; in diesem Artikel wurden HTTP 408, length und Read-Timeout ausdrücklich als Teil des Testergebnisses protokolliert und nicht ausgeblendet.