Kimi K3 im Vergleich zu Claude Opus 4.8: Mathematik, Physik und Programmierung auf Graduiertenniveau
Auf derselben Crazyrouter OpenAI-compatible API werden Kimi K3 und Claude Opus 4.8 anhand von Aufgaben zu Markov-Ketten mit Ersttrefferzeit auf Graduiertenniveau, dem Frequenzgang gekoppelter gedämpfter Oszillatoren und einem Abhängigkeits-Scheduling-Algorithmus verglichen; dokumentiert werden Ausgabevollständigkeit, Korrektheit, Latenz und unabhängige Abnahmeergebnisse.

Kimi K3 im Vergleich zu Claude Opus 4.8: Praxistest zu Mathematik, Physik und Programmierung auf Graduiertenniveau#


Bei einfachen Kopfrechenaufgaben liefern große Modelle oft schon sehr ordentliche Antworten. Den eigentlichen Unterschied sieht man aber bei anderen Dingen: Endet die Herleitung innerhalb des Ausgabelimits? Sind Matrizen und Randbedingungen korrekt? Erzeugt das Programm tatsächlich Code, der die Semantik der Aufgabe erfüllt?
Diesmal habe ich die Aufgaben deutlich auf das Niveau einer Bachelorarbeit oder eines Graduiertenkurses angehoben und kimi-k3 sowie claude-opus-4-8 mit demselben Prompt-Set getestet:

- Mathematik: stationäre Verteilung, Erstankunftszeit sowie erste und zweite Momente einer Markow-Kette mit drei Zuständen;
- Physik: Zweifreiheitsgrad-Oszillator mit geerdeter Dämpfung und Kopplungsdämpfung, gesucht sind ungedämpfte Moden und der komplexe Frequenzgang;
- Programmierung: exakter Scheduling-Algorithmus mit Abhängigkeitsabschluss, Zeitfenstern, Tageskapazitäten und einer dreistufigen Zielfunktion.
Vorweg das Fazit:
claude-opus-4-8hat in allen drei Aufgaben innerhalb des Budgets vollständig geantwortet, bei allen drei Aufgaben warfinish_reasonjeweilsstop;kimi-k3musste auftemperature=1gesetzt werden, und unter dem6000-Completion-Token-Limit endeten alle drei Aufgaben mitfinish_reason=length; in allen drei Fällen war die sichtbarecontent-Länge0;- Die mathematische und physikalische Antwort von Opus 4.8 wurde unabhängig numerisch verifiziert;
- Der Scheduling-Code von Opus 4.8 bestand seine eigenen 13 Assertions, aber ein zusätzliches unabhängiges Prüfskript für „Vorgänger muss vor Nachfolger fertig sein“ zeigte: Es stellt nur sicher, dass abhängige Aufgaben gemeinsam ausgewählt werden, nicht aber, dass der Vorgänger vor dem Nachfolger liegt;
- Die durchschnittliche Latenz erfolgreicher Requests in diesem Durchlauf lag bei Opus 4.8 bei etwa
70.59 Sekunden, bei Kimi K3 bei etwa225.47 Sekunden. Dieser Unterschied beschreibt nur Routing- und Prompt-Bedingungen dieses Laufs und ist nicht direkt als langfristiges SLA interpretierbar.
Testumgebung und Parametergrenzen#
Die Tests wurden am 18. bis 19. Juli 2026, Beijing-Zeit, ausgeführt. Zuerst wurde über /v1/models geprüft, dass beide Modell-IDs sichtbar sind:
kimi-k3
claude-opus-4-8

Alle Requests liefen über die OpenAI-compatible API von Crazyrouter:
POST https://cn.crazyrouter.com/v1/chat/completions
Gemeinsame Bedingungen:
gleiches system prompt
gleiche Benutzeraufgabe
keine Tools und kein Webzugriff
Die Modellparameter konnten nicht völlig identisch sein, weil es upstream für Kimi K3 eine harte Vorgabe gibt:
| Modell | temperature | max_tokens | Ergebnis |
|---|---|---|---|
kimi-k3 | 1 (sonst HTTP 400) | 6000 | alle drei Aufgaben length |
claude-opus-4-8 | 0.1 | 9000 | alle drei Aufgaben stop |
Beim ersten Fehlversuch mit temperature=0.1 für Kimi K3 lieferte die Schnittstelle ausdrücklich:
Parameter temperature must be 1 for this model.
Daher wird diese Parameterbeschränkung hier als Testfakt festgehalten und der Fehler nicht als „Modell nicht verfügbar“ verschleiert. Wer Ergebnisse produktiv für die Modellauswahl nutzt, sollte modellabhängige Parametergrenzen in der Konfiguration abbilden, statt davon auszugehen, dass alle Modelle dieselben Sampling-Parameter akzeptieren.
Ergebnistabelle#
| Aufgabe | Kimi K3 | Claude Opus 4.8 | Unabhängige Bewertung |
|---|---|---|---|
| Markow-Kette: Erstankunftszeit | 235.420 s, 6000 completion, 5997 reasoning, length, content leer | 57.870 s, 4764 completion, stop | Opus vollständig und korrekt, Kimi lieferte keine sichtbare Antwort |
| Zweifreiheitsgrad-gekoppelter Oszillator | 204.568 s, 6000 completion, 5997 reasoning, length, content leer | 64.966 s, 5284 completion, stop | Opus vollständig und numerisch verifiziert |
| Scheduling-Algorithmus mit Abhängigkeiten | 236.434 s, 6000 completion, 5997 reasoning, length, content leer | 88.934 s, 6857 completion, stop | Opus-Implementierung lauffähig, aber die Reihenfolgebedingung der Abhängigkeiten fehlt |
Das gemeinsame Muster bei Kimi in allen drei Aufgaben war sehr konsistent: Die Schnittstelle lieferte Modellname und usage, aber message.content enthielt keine finale, nutzbare Antwort. Für Anwendungen, die das Ergebnis direkt an Nutzer ausgeben oder an einen Compiler weiterreichen müssen, ist das als „Aufgabe nicht abgeschlossen“ zu werten, nicht als „Modell hat korrekt geantwortet, nur das Log fehlt“.
Mathematik: Erstankunftszeit und Varianz einer endlichen Markow-Kette#
Die Aufgabe verwendet die Übergangsmatrix:
Zielzustand ist 3, definiert ist:
Das ist keine Aufgabe, die man nur durch Einsetzen in eine Formel erledigt. Mindestens müssen stationäre Verteilung, transienter Teilmatrix, erster und zweiter Moment der Erstankunftszeit sauber behandelt werden, und die Zielzustands-Randbedingungen t_3=s_3=0 müssen explizit gesetzt sein.
Ergebnis von Opus 4.8#
Opus 4.8 gab für die stationäre Verteilung an:
und überprüfte komponentenweise πP=π.
Mit {1,2} als transienten Zuständen ergibt sich:
Die Gleichung für den ersten Moment lautet:
also:
Für den zweiten Moment wird verwendet:
woraus folgt:
Ich habe die Gleichung separat mit Fraction nachgerechnet; das Ergebnis stimmt exakt mit Opus überein. Auch das Einsetzen von t und s in die beiden First-Step-Gleichungen funktionierte. Die Mathematikaufgabe gilt damit als „vollständig bestanden“.
Ergebnis von Kimi K3#
Kimi K3 lief mit temperature=1 und max_tokens=6000 etwa 235 Sekunden, die usage zeigte completion_tokens=6000, reasoning_tokens=5997, finish_reason=length, und die sichtbare content war leer.
Das bedeutet: Aus dieser Ausführung lässt sich nicht ableiten, ob Kimi diese Markow-Ketten-Aufgabe grundsätzlich lösen kann. Sicher feststellbar ist nur, dass es unter der aktuellen Schnittstelle, dem Prompt und dem Budget keine sichtbare Endantwort gab.
Physik: Matrix und Frequenzgang eines gekoppelten gedämpften Oszillators#
Die zweite Aufgabe behandelt ein Zweimassensystem mit zwei Freiheitsgraden:
m1=1.5 kg,m2=1.0 kg
k1=120 N/m,k2=80 N/m,k3=150 N/m
c1=1.2 N·s/m,c2=0.8 N·s/m,c3=1.5 N·s/m
F(t)=10 cos(8t) N
k2 und c2 sind die Kopplungselemente zwischen den beiden Massen, c1 und c3 sind die jeweiligen geerdeten Dämpfer. Gefordert sind zuerst die ungedämpften Eigenmoden und dann die komplexe Antwort bei ω=8 rad/s; deshalb darf man nicht einfach alle Dämpfungsterme in eine Diagonalmatrix pressen.
Korrekte Matrizen#
Opus 4.8 hat geschrieben:
Die ungedämpfte charakteristische Gleichung liefert die Eigenkreisfrequenzen:
Die zugehörigen Modenverhältnisse X2/X1 sind 0.6173 und -2.4298 und stehen für gleich- bzw. gegenphasige Moden.
Komplexer Frequenzgang bei ω=8#
Die komplexe dynamische Steifigkeitsmatrix lautet:
Eine unabhängige komplexe Rechnung ergibt:
| Größe | Referenzwert |
|---|---|
| ` | X1 |
∠X1 | -12.1524° |
| ` | X2 |
∠X2 | -13.9035° |
| ` | X2/X1 |
| Phasendifferenz | ungefähr -1.7511° |
Auch die Energiekontrolle von Opus 4.8 stimmt: Die mittlere dissipierte Leistung beträgt etwa 1.2574 W und entspricht innerhalb des Rundungsfehlers der Eingangsleistung der Kraft. Es wurde außerdem korrekt erklärt: Wenn man c2 fälschlich als geerdete Dämpfung behandelt, werden die nichtdiagonalen Dämpfungsterme C12=C21=-0.8 fälschlicherweise zu null gesetzt, und damit ändern sich Energieübertragung und Phasenlage.
Ergebnis von Kimi K3#
Kimi K3 hat nach etwa 204.6 Sekunden die 6000 Token ausgeschöpft und endete ebenfalls mit finish_reason=length; auch hier war die content leer. Da keine Endgleichungen und keine Zahlen geliefert wurden, lässt sich die physikalische Modellierung nicht bewerten. Der Lauf ist daher lediglich als „innerhalb des Budgets nicht ausgeliefert“ zu protokollieren.
Programmieraufgabe: Abhängigkeitsabschluss, Zeitfenster und exaktes Scheduling#
Die Programmieraufgabe verlangt die Implementierung von:
schedule_jobs(jobs, dependencies, capacity_by_day)
Jeder Job besitzt duration, release_day, deadline_day und value; ein Job muss vollständig an einem Tag eingeplant werden, jeder Tag hat eine Kapazitätsobergrenze, und Abhängigkeiten bedeuten, dass Vorgängeraufgaben vor dem Start der Nachfolger abgeschlossen sein müssen. Die Zielfunktion wird in folgender Reihenfolge verglichen:
- maximaler Gesamtwert;
- kleinere Gesamtdauer;
- lexikographisch kleinere sortierte Liste der Job-IDs.
Diese Aufgabe ist deutlich schwieriger als ein normales „Knapsack + Sortierung“, weil gleichzeitig Folgendes verarbeitet werden muss:
- direkter und indirekter Abhängigkeitsabschluss;
- unbekannte Abhängigkeiten und Zyklen;
- Tageskapazität und Zeitfenster der Jobs;
- exaktes Packing zulässiger Teilmengen;
- mehrstufige Tie-Break-Regeln.
Verhalten der Implementierung von Opus 4.8#
Opus lieferte eine vollständige bitmask- und memoized-DFS-Implementierung samt 13 Assertions. Wir extrahierten beide Python-Codeblöcke und führten sie unter Python 3.11 aus; alle vom Modell mitgelieferten Assertions bestanden:
all assertions passed
Damit deckte es korrekt leere Eingaben, zu geringe Kapazität, direkte und indirekte Abhängigkeiten, unbekannte Abhängigkeiten, zyklische Abhängigkeiten und den dreistufigen Zielvergleich ab.
Allerdings prüften die eingebauten Assertions nicht, ob der Vorgänger vor dem Nachfolger abgeschlossen wird. Ich ergänzte deshalb ein unabhängiges Probe-Szenario:
jobs = [
{"id": "A", "duration": 4, "release_day": 1,
"deadline_day": 1, "value": 1},
{"id": "B", "duration": 4, "release_day": 0,
"deadline_day": 0, "value": 10},
]
result = schedule_jobs(jobs, [("A", "B")], {0: 4, 1: 4})
Nach korrekter Semantik ist A der Vorgänger von B, aber A kann nur an Tag 1 eingeplant werden und B nur an Tag 0; beide sollten also nicht gleichzeitig gewählt werden. Der Modellcode gab jedoch zurück:
selected_ids: ['A', 'B']
assignment: {'A': 1, 'B': 0}
Das zeigt: Die Implementierung prüft nur, dass bei der Auswahl von B auch A mit ausgewählt wird, aber nicht:
assignment[A] < assignment[B]
Daher kann die Programmieraufgabe nicht als vollständig bestanden gelten. Präziser gesagt: Das Algorithmusgerüst und die Eingabevalidierung sind recht vollständig, und die Ressourcen-Packlogik ist lauffähig, aber die zentrale Fachsemantik lässt die zeitliche Reihenfolge der Abhängigkeiten aus. Für ein produktives Planungssystem ist das ein zwingend zu behebender Korrektheitsfehler, kein Formatproblem.
Ergebnis von Kimi K3#
Kimi K3 lief etwa 236.4 Sekunden und endete mit length; die 6000 Token gingen vollständig in reasoning auf, die content blieb leer, und lauffähiger Code wurde nicht ausgeliefert.
Latenz, Ausgabebudget und sichtbare Antworten#
Durchschnittliche Latenz über drei Aufgaben:
Kimi K3: (235.420 + 204.568 + 236.434) / 3 = 225.474 Sekunden
Claude Opus: (57.870 + 64.966 + 88.934) / 3 = 70.590 Sekunden
Die drei Kimi-Requests waren in der usage alle sehr ähnlich:
completion_tokens = 6000
reasoning_tokens = 5997
content.length = 0
finish_reason = length
Diese Daten zeigen, dass der aufrufende Dienst nicht nur HTTP-Status und model-Feld beobachten darf. Mindestens sollten zusätzlich folgende Werte protokolliert werden:
choice.finish_reason
response.usage
response.choices[0].message.content
Wenn finish_reason length ist, sollte der Request auch bei HTTP 200 in einen Retry-, Fallback- oder manuellen Review-Pfad gehen.
So lässt sich das Experiment reproduzieren#
Unten ist die kleinste sinnvolle Variante eines Aufrufs mit dem OpenAI Python SDK. In der eigentlichen Messung sollten die vollständigen Aufgaben aus dem Artikel sowie die zum Modell passenden Parameter verwendet werden:
from openai import OpenAI
client = OpenAI(
api_key="YOUR_CRAZYROUTER_API_KEY",
base_url="https://cn.crazyrouter.com/v1",
)
response = client.chat.completions.create(
model="claude-opus-4-8",
temperature=0.1,
max_tokens=9000,
messages=[
{"role": "system", "content": "Strenges Benchmarking, nur verifizierbare Schlussfolgerungen."},
{"role": "user", "content": "Ersetze durch die vollständige Graduierten-Testaufgabe"},
],
)
print(response.model)
print(response.choices[0].finish_reason)
print(response.usage)
print(response.choices[0].message.content)
Beim Aufruf von Kimi K3 muss temperature auf 1 gesetzt werden, und für längeres reasoning sollte ausreichend Zeit eingeplant werden; selbst mit 6000 Token wurde in diesem Durchlauf keine sichtbare Antwort erzeugt.
Empfehlung für den produktiven Einsatz#
Fälle, in denen Claude Opus 4.8 zuerst getestet werden sollte#
- Es muss in einem einzelnen Request eine vollständige Herleitung oder ein vollständiger Codeblock zurückkommen;
- Die Aufgabe enthält Matrizen, Randbedingungen und numerische Verifikation;
- Das Produkt reagiert empfindlich auf Time-to-first-output und Lieferbarkeit;
- Für erzeugten Code können zusätzliche Tests und semantische Prüfungen ergänzt werden.
Fälle, in denen Kimi K3 weiter evaluiert werden kann#
- Mehrminütige Latenz ist akzeptabel;
- Die Aufrufschicht kann modellabhängige Sampling-Parameter verarbeiten;
- Aufgaben dürfen aufgeteilt, das Budget erhöht oder asynchrone Workflows verwendet werden;
- Der Fokus liegt eher auf dem reasoning-Prozess als auf der sofortigen Auslieferung des Endtexts in einem einzelnen Request.
Auf Basis dieser Daten lässt sich Kimi K3 in diesem Lauf aber nicht als „hat alle drei Aufgaben gelöst, nur das Ergebnis wurde im Log verborgen“ beschreiben. Die tatsächliche Beobachtung ist: In allen drei Läufen gab es keine sichtbare finale Antwort.
FAQ#
1. Warum gilt diese Aufgabe als Bachelor-/Graduiertenniveau?#
Die Mathematikaufgabe verlangt stationäre Verteilung, Fundamentalsmatrix und den zweiten Moment der Erstankunftszeit; die Physikaufgabe verlangt Matrixmodellierung, Modalanalyse, komplexen Frequenzgang und Energiebilanz; die Programmieraufgabe verlangt Abhängigkeitsabschluss, exaktes Packing, Zyklenprüfung und mehrstufige Optimierung. Das entspricht inhaltlich der Schwierigkeit von Übungs- und Projektaufgaben aus Wahrscheinlichkeitstheorie/Stochastik, Klassischer Mechanik und Schwingungslehre sowie Algorithmen- und Systementwurf.
2. Unterstützt Kimi K3 temperature=0.1 nicht?#
In diesem Lauf verlangte die Schnittstelle für Kimi K3 ausdrücklich, dass temperature 1 sein muss. Das ist eine modellbezogene Parametergrenze des aktuellen Routings; der Aufrufer sollte die Fehlermeldung auslesen und mit passender Modellkonfiguration erneut versuchen.
3. Bedeutet length bei Kimi K3, dass das Modell diese Aufgaben sicher nicht kann?#
Nein. Es bedeutet nur, dass es unter diesem Prompt, dem Ausgabelimit und den Routing-Bedingungen keine sichtbare Endantwort erzeugt hat. Ohne sichtbare Antwort kann keine Korrektheit bewertet werden, aber daraus folgt auch nicht, dass das Modell die Aufgaben unter allen Einstellungen nicht lösen kann.
4. Kann die Programmierantwort von Opus 4.8 direkt in Produktion gehen?#
Nicht direkt. Die eigenen Assertions bestanden zwar alle, aber der unabhängige Probe-Check zeigte, dass die zeitliche Reihenfolge der Abhängigkeiten fehlt. Erzeugter Code muss also um fachliche Semantiktests ergänzt werden, nicht nur um die vom Modell mitgelieferten Tests.
5. Warum sollte bei der Physikaufgabe die Energieabfuhr geprüft werden?#
Weil bei gekoppelter Dämpfung nichtdiagonale Terme sehr leicht falsch modelliert werden. Dass Eingangsleistung und dissipierte Leistung übereinstimmen, ist ein unabhängiger Beleg dafür, dass komplexe Amplituden, Phasen und Dämpfungsmatrix gleichzeitig korrekt sind.
6. Kann diese Latenz als Leistungsversprechen verstanden werden?#
Nein. Upstream-Kanal, Caching, Parallelität und Retries verändern die Latenz. In einer Produktionsumgebung sollte mindestens mehrfach gesampelt und über P50, P95, P99, Abbruchrate und Kosten pro erfolgreicher Aufgabe berichtet werden.
Abschließendes Fazit#
Verglichen wurde hier nicht einfach ein abstraktes „Intelligenz-Ranking“ ohne Bezug zu Aufrufbedingungen, sondern zwei sehr unterschiedliche Arten von Auslieferungsverhalten:
- Claude Opus 4.8 lieferte in allen drei Graduiertenaufgaben sichtbare Antworten; die mathematische und physikalische Herleitung wurde unabhängig verifiziert;
- Der Code-Ansatz von Opus ist stark, lässt aber noch die wichtige fachliche Nebenbedingung aus, dass abhängige Aufgaben zeitlich in der richtigen Reihenfolge abgeschlossen werden müssen;
- Kimi K3 verbrauchte unter der erzwungenen Bedingung
temperature=1in allen drei Aufgaben die 6000 Token vollständig, endete mitfinish_reason=lengthund lieferte keine sichtbare Antwort; - Wenn das Geschäftsziel darin besteht, in einem einzigen Request eine vollständige mathematische Herleitung, physikalische Berechnung oder lauffähigen Code zu erhalten, ist Opus 4.8 im aktuellen Testfenster deutlich lieferfähiger;
- Unabhängig vom gewählten Modell müssen
finish_reason, usage, unabhängige numerische Verifikation und semantische Code-Tests Teil der Abnahme sein.
Dateien zur Reproduktion des Experiments:
- Testskript: kimi_k3_vs_opus48_graduate_test.py
- Kimi-Ergebnis: kimi-k3-graduate-results.json
- Vergleichsergebnis: kimi-k3-vs-opus48-graduate-results.json
Empfohlene Lektüre:




