DEV Community: Jenny Met

Kimi K3 so với GPT-5.6-SOL: thử sức thực chiến mức khó cao về toán, vật lý và lập trình

Jenny Met — Sat, 18 Jul 2026 01:17:19 +0000

Kimi K3 so với GPT-5.6-SOL: thử sức thực chiến mức khó cao về toán, vật lý và lập trình

Lần này mình không test mấy câu hỏi đáp đơn giản, mà chốt hẳn ba bài cần suy luận nhiều bước: một bài xác suất có mẫu chồng lấp và moment bậc hai, một bài vật lý có mô-men quán tính của ròng rọc và chuyển trạng thái do dây chùng sau khi chạm đất, và một bài Python phụ thuộc vào closure, dung lượng nhiều ngày và tie-break ba tầng. Hai model dùng cùng một interface, cùng prompt và mức output cap gần tương đương, không bật tool và không dùng internet.

Kết luận ngắn gọn trước:

gpt-5.6-sol trả lời trọn vẹn ở cả ba bài, và kết quả tham chiếu cho toán lẫn vật lý đều đúng.
kimi-k3 ở mức trần 6500 token vòng đầu thì cả toán và vật lý đều kết thúc với finish_reason=length, phần nhìn thấy trống rỗng; riêng bài toán, tăng trần lên 10000 vẫn bị cắt cụt. Bài lập trình thì sau khoảng 245 giây bị đọc timeout.
Phần triển khai lập trình của GPT-5.6-SOL vượt qua các kiểm tra bổ sung độc lập về closure phụ thuộc, dung lượng, tie-break, dependency không hợp lệ và vòng lặp phụ thuộc, nhưng chính nó lại kèm một assert mẫu đầu tiên có expected value sai. Điều này cho thấy “thân code đúng” và “mọi test ví dụ đều đúng” là hai việc phải kiểm riêng.

Độ trễ trong bài viết này là giá trị quan sát được của lần request này, không đại diện cho SLA cố định. Ở lượt đồng thời đầu tiên, request toán và vật lý của GPT từng nhận HTTP 408, sau đó mình chuyển sang retry tuần tự; vì vậy tốc độ chỉ dùng để quan sát trải nghiệm gọi API, không dùng để tuyên bố xếp hạng tuyệt đối.

Thiết lập test

Thời điểm test là từ giờ Bắc Kinh 2026-07-17 đến 2026-07-18, interface là:

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

Lượt đầu tiên dùng thống nhất: toán và vật lý max_tokens=6500, lập trình max_tokens=7500. Mỗi bài đều yêu cầu model đưa ra suy diễn có thể kiểm tra lại hoặc code có thể chạy, đồng thời ghi lại finish_reason, completion/reasoning token, độ trễ request, độ đúng số học và việc code có chạy độc lập được trong Python 3.11 hay không.

Bảng tổng kết kết quả

Task	kimi-k3	gpt-5.6-sol	Kết luận
Toán: kỳ vọng và phương sai của HHTH	`length`, 186.98 s, 6500 tokens; nội dung nhìn thấy trống	Retry tuần tự `stop`, 236.07 s, 6872 tokens	GPT trả lời đầy đủ; Kimi vòng đầu chưa ra được đáp án
Vật lý: ròng rọc, chạm đất, lò xo	`length`, 202.05 s, 6500 tokens; nội dung nhìn thấy trống	Retry tuần tự `stop`, 156.29 s, 4501 tokens	GPT đầy đủ và đúng số
Lập trình: dependency closure knapsack	Sau 245.54 s `TimeoutError`	`stop`, 87.96 s, 4514 tokens	GPT code chạy được; Kimi chưa trả về code hoàn chỉnh
Kimi test lại môn toán	`length`, 286.99 s, 10000 tokens	—	Tăng budget vẫn chưa xong

Trong các request toán và vật lý của Kimi, reasoning token do API báo cáo lần lượt gần 6497; ở bài toán test lại, reasoning token gần 9997. Điều này không có nghĩa là Kimi không có năng lực suy luận, mà chỉ cho thấy với prompt của bài này và routing hiện tại, budget suy luận rất dễ bị hút cạn, khiến bên gọi không nhận được đáp án cuối.

Bài toán: chồng lấp mẫu không chỉ ảnh hưởng kỳ vọng, mà còn ảnh hưởng cả phương sai

Đề bài là: xác suất mặt ngửa p=3/5, xác suất mặt sấp q=2/5, tung liên tục cho đến khi lần đầu xuất hiện HHTH, cho phép chồng lấp mẫu, hãy tìm E[T] và Var(T).

Automaton tiền tố đúng có các trạng thái S0=tiền tố rỗng, S1=H, S2=HH, S3=HHT, S4=HHTH (trạng thái hấp thụ). Chuyển trạng thái quan trọng là S2 --H--> S2: khi đã có HH mà lại ra H, hậu tố dài nhất vẫn là HH, không được sai mà quay về trạng thái rỗng.

GPT-5.6-SOL lập hệ phương trình moment bậc nhất là:

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

Tiếp tục lập hệ phương trình moment bậc hai, ta được:

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

Kỳ vọng còn có thể kiểm chứng độc lập bằng công thức biên. HHTH có biên thực sự không rỗng duy nhất là một ký tự H, nên E[T] = 1/p + 1/(p³q) = 715/54. Câu trả lời đầy đủ của GPT bao gồm cả chuyển trạng thái, khai triển moment bậc hai và sanity check. Kimi ở cả mức 6500 lẫn 10000 đều không xuất ra phần suy diễn nhìn thấy được, nên lần này không thể chấm độ đúng toán của nó, chỉ có thể ghi nhận là “chưa hoàn thành trong budget”.

Bài vật lý: sau khi chạm đất, ràng buộc bị ngắt, không thể bê nguyên phương trình năng lượng cũ

Đề bài đặt như sau: m_A=4.0 kg nằm trên mặt phẳng nghiêng nhám 25°, μ_k=0.18; m_B=3.0 kg treo; ròng rọc có M_p=1.2 kg, R=0.10 m; B đi xuống 1.50 m rồi chạm đất; dây ngay lập tức chùng; A trượt lên thêm 0.10 m thì chạm lò xo k=250 N/m; g=9.8 m/s².

Trước khi chạm đất, dây căng và không trượt, khối lượng quán tính tương đương của ròng rọc là I/R²=(1/2)M_p=0.60 kg. Ghép phương trình động lực học của hai vật và phương trình quay của ròng rọc, ta được:

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

Sau khi chạm đất, vận tốc của B bị thay đổi do va chạm với mặt đất, A vẫn còn vận tốc hướng lên dọc mặt phẳng nghiêng, và ròng rọc cũng có thể tiếp tục quay; hơn nữa đề đã nói rõ dây ngay lập tức chùng, nên không thể tiếp tục dùng v_A=v_B=Rω. Giai đoạn sau chỉ nên phân tích riêng A:

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 còn kiểm tra cả đơn vị, khoảng dừng khi không có lò xo, và sự khớp giữa năng lượng đàn hồi với tổn hao do ma sát/trọng lực, số liệu tự nhất quán. Kimi ở lượt đầu không tạo ra đáp án nhìn thấy được nên không thể so sánh chất lượng mô hình hóa trung gian.

Bài lập trình: thân thuật toán qua kiểm độc lập, nhưng sample test của model có bug

Bài lập trình yêu cầu cài optimize_release_plan(items, capacity_by_day, dependencies), xử lý dung lượng theo ngày, ngày không cấu hình thì dung lượng bằng 0, closure phụ thuộc trực tiếp và gián tiếp, dependency không hợp lệ và phát hiện chu trình, cùng tie-break ba tầng value → risk → danh sách id đã sắp xếp. items <= 18, nên brute-force bằng bitmask là baseline hợp lý.

GPT-5.6-SOL dùng cache closure phụ thuộc và duyệt 2^n tập con. Mình tách code ra và kiểm tra độc lập trong Python 3.11: closure phụ thuộc, ví dụ dung lượng nhiều ngày, tie-break ba tầng value/risk/id, dung lượng ngày chưa cấu hình, dependency không tồn tại và dependency vòng lặp, tổng cộng 6 nhóm kiểm tra đều qua.

Nhưng ở cuối code, model lại kèm theo assert đầu tiên bị fail: nó viết A -> B -> C, đồng thời lại đưa thêm X có giá trị 11. Với dung lượng đã cho, tổng giá trị của B + C + X là 13, cao hơn A + B + C là 12, nên hàm trả về ['B', 'C', 'X'] mới là đúng; assert viết ['A', 'B', 'C'] là sai ở fixture test.

Chi tiết này khá điển hình: làm bài code không thể chỉ nhìn thân hàm, cũng không thể vì “kèm 8 assert” mà mặc nhiên tin bộ test đó. Dữ liệu test do model sinh ra cũng cần được người viết hoặc reference implementation kiểm lại. Request lập trình của Kimi K3 thì sau khoảng 245 giây bị đọc timeout, không lấy được code hoàn chỉnh.

Đánh giá tổng hợp

Khía cạnh	kimi-k3	gpt-5.6-sol
Độ đầy đủ ở bài toán	`6500/10000` token đều bị cắt, không thể nghiệm thu	Kỳ vọng, moment bậc hai, phương sai và sanity check đều đầy đủ
Mô hình hóa vật lý	Bị cắt ở vòng đầu	Xử lý đúng quán tính ròng rọc, dây chùng và giai đoạn lò xo
Bàn giao code	Lượt này timeout	Thân code qua kiểm độc lập, nhưng kèm một assert sai
Độ ổn định đầu ra	Tốn reasoning nhiều, dễ không có phần nhìn thấy	Cả ba bài retry tuần tự đều `stop`
Tốc độ phản hồi	Khoảng 187–246 s, lại còn bị cắt/timeout	Request thành công khoảng 88–236 s; lượt đầu đồng thời có 408

Kết luận chính xác hơn không phải là “model nào chắc chắn thông minh hơn”, mà là:

Với routing và budget của lần test này, GPT-5.6-SOL dễ thu gọn suy luận phức tạp thành đáp án cuối hơn, hợp với workflow cần ngay lời giải hoặc code đọc được.
Vấn đề lớn nhất của Kimi K3 là hiệu quả chuyển từ reasoning budget sang output nhìn thấy; dù tăng toán lên 10000 token, nó vẫn chưa kết thúc.
Code của GPT-5.6-SOL cũng không thể tin mù quáng. Logic hàm đã qua kiểm độc lập, nhưng bộ test đi kèm có lỗi tính giá trị.
Khi chọn cho production, nên ghi đồng thời finish_reason, reasoning token, độ trễ và kết quả test nội bộ; không thể chỉ nhìn câu cuối cùng kiểu “đáp án đúng”.

Cách tái hiện thí nghiệm

Script test và kết quả retry theo thứ tự của lần này được lưu tại (tóm tắt của lượt đồng thời đầu tiên cũng đã được ghi vào output của script):

.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

Khi chạy lại, nên cố định model ID, prompt, temperature, max_tokens và mức độ đồng thời, rồi lưu riêng từng output thành file độc lập. Tải upstream, cache hit và trạng thái rate limit đều có thể ảnh hưởng đến độ trễ; trong bài này, mình ghi nhận cả HTTP 408, length và đọc timeout như một phần của kết quả test, chứ không giấu chúng đi.

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

Jenny Met — Sat, 18 Jul 2026 01:15:52 +0000

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:

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.
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.
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.
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.

Kimi K3 と GPT-5.6-SOL の比較：数学・物理・プログラミングの高難度実測

Jenny Met — Sat, 18 Jul 2026 01:14:30 +0000

Kimi K3 と GPT-5.6-SOL の比較：数学・物理・プログラミングの高難度実測

今回は簡単なQ&Aではなく、連続推論が必要な3問に固定しました。具体的には、パターン重なりと二次モーメントを含む確率問題、滑車の回転慣性と糸のたるみへの切り替えが入る物理問題、そして closure、多日容量、3段階の tie-break に依存する Python 問題です。両モデルには同じインターフェース、同じプロンプト、近い出力上限を使い、ツールもネット接続も有効化していません。

先に結論だけまとめます。

gpt-5.6-sol は3問すべてで完全な可視回答を返し、数学と物理の参照結果も正しかったです。
kimi-k3 は初回の 6500 token 上限では、数学と物理のどちらも finish_reason=length で終了し、可視回答は空でした。数学は上限を 10000 に上げてもなお途中で切れました。プログラミング問題は約 245 秒後に read timeout になりました。
GPT-5.6-SOL のプログラミング実装は、依存関係の閉包、多日容量、tie-break、無効な依存、循環依存の独立追加チェックをすべて通過しましたが、自身が添付した最初の assert サンプルには期待値の誤りがありました。つまり、「コード本体が正しい」ことと「サンプルテストも全部正しい」ことは分けて評価する必要があります。

なお、ここでの遅延は今回のリクエストで観測された値であり、固定SLAを意味しません。初回の並列リクエストでは GPT の数学と物理が HTTP 408 を返したため、その後は順次リトライに切り替えました。したがって速度はあくまで呼び出し体験の観測値であり、絶対的な順位づけには使っていません。

テスト設定

テスト日時は北京時間 2026-07-17 から 2026-07-18、インターフェースは以下です。

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

初回は共通で、数学と物理は max_tokens=6500、プログラミングは max_tokens=7500 としました。各問題では、検算可能な導出または実行可能コードの提示を求め、finish_reason、completion/reasoning token、リクエスト遅延、数値の正しさ、そしてコードが Python 3.11 で独立実行できるかを記録しました。

結果サマリー

タスク	kimi-k3	gpt-5.6-sol	判定
数学：HHTH の期待値と分散	`length`，186.98 s，6500 tokens；可視内容は空	順次リトライ `stop`，236.07 s，6872 tokens	GPT は完全回答；Kimi は初回で答案形成に至らず
物理：滑車、着地、ばね	`length`，202.05 s，6500 tokens；可視内容は空	順次リトライ `stop`，156.29 s，4501 tokens	GPT は完全で数値も正確
プログラミング：依存閉包バックパック	245.54 s 後に `TimeoutError`	`stop`，87.96 s，4514 tokens	GPT のコードは実行可能；Kimi は完全なコードを返さず
Kimi 数学再測定	`length`，286.99 s，10000 tokens	—	予算を増やしても終了せず

Kimi の数学と物理のリクエストでは、インターフェース上の reasoning token がそれぞれ 6497 前後でした。数学再測定では reasoning token が 9997 前後でした。これは Kimi に推論力がないという意味ではなく、この問題設定と現在のルーティングでは推論予算を使い切りやすく、呼び出し側が最終答案を受け取れないことを示しています。

数学問題：パターン重なりは期待値だけでなく分散にも効く

問題は、正面確率 p=3/5、裏面確率 q=2/5 のコインを投げ続け、HHTH が初めて現れるまでの回数を T としたときの E[T] と Var(T) を求めるものです。パターン重なりは許されます。

正しい前方オートマトンの状態は S0=空前缀、S1=H、S2=HH、S3=HHT、S4=HHTH（吸収状態） です。重要なのは S2 --H--> S2 という遷移で、HH の後にさらに H が出ても、最長接尾辞は依然として HH であり、誤って空状態へ戻してはいけません。

GPT-5.6-SOL が立てた一次モーメント方程式は次のとおりです。

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

さらに二次モーメント方程式を立てると、次が得られます。

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

期待値は境界公式でも独立に検算できます。HHTH の非空真の境界は単一文字 H なので、E[T] = 1/p + 1/(p³q) = 715/54 です。GPT の完全回答は、状態遷移、二次モーメントの展開、sanity check まで一通り含んでいました。Kimi は 6500 と 10000 のどちらの上限でも可視的な導出を出せなかったため、今回は数学の正確性を採点できず、「予算内で未完了」と記録しています。

物理問題：着地後は拘束が切れるので、同じエネルギー方程式をそのまま延長してはいけない

設定は次のとおりです。m_A=4.0 kg は 25° の粗い斜面上、μ_k=0.18。m_B=3.0 kg は吊り下げ。滑車は M_p=1.2 kg、R=0.10 m。B が 1.50 m 下降したあとに地面へ接触し、糸は直ちにたるみます。その後 A はさらに 0.10 m だけ斜面上方へ滑って k=250 N/m のばねに接触します。g=9.8 m/s² です。

着地前は、糸は張っていて滑りなしなので、滑車の等価慣性質量は I/R²=(1/2)M_p=0.60 kg です。2物体と滑車の回転方程式を連立すると、次のようになります。

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

着地後は、B の速度は地面との衝突で変化し、A はなお斜面上向きの速度を持ち、滑車も回転を続ける可能性があります。しかし問題文では糸が直ちにたるむと明記されているため、v_A=v_B=Rω はもう使えません。以後は A のみを解析すべきです。

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 は、次元整合性、ばねなしでの停止距離、ばねのエネルギーと摩擦・重力損失の和まで確認しており、数値的にも整合していました。Kimi は初回で可視回答を出せなかったため、中間のモデリング品質は比較できませんでした。

プログラミング問題：アルゴリズム本体は独立検証で通過、ただしモデル付属サンプルにバグあり

この問題は optimize_release_plan(items, capacity_by_day, dependencies) を実装し、日別容量、未設定日の容量は 0、直接・間接依存の閉包、無効な依存と循環検出、さらに value → risk → ソート済み id 列表 の3段階 tie-break を扱う必要があります。items <= 18 なので、bitmask 総当たりは妥当なベースラインです。

GPT-5.6-SOL は依存閉包キャッシュと 2^n の部分集合列挙を使っていました。コードを抽出し、Python 3.11 で独立検査を行ったところ、依存閉包、多日容量サンプル、value/risk/id の3段階 tie-break、未設定日の容量、依存なしケース、循環依存の6組すべてが通過しました。

ただし、モデルがコード末尾に付けた最初の assert は失敗しました。そこでは A -> B -> C を前提にしつつ、価値 11 の X も入れていました。与えられた容量では、B + C + X の総価値は 13 で、A + B + C の 12 より大きいので、関数が ['B', 'C', 'X'] を返すのが正解です。['A', 'B', 'C'] と書かれた assert はテストフィクスチャの誤りです。

この点はかなり示唆的です。コード問題は関数本体だけ見ればよいわけでもなく、逆に「8個のassertが付いているからテストも正しい」とは限りません。モデル生成のテストデータも、人手または参照実装で検証する必要があります。Kimi K3 のプログラミングリクエストは約 245 秒後に read timeout となり、完全なコードは取得できませんでした。

総合評価

観点	kimi-k3	gpt-5.6-sol
数学の完全性	`6500/10000` token ともに途中終了、検収不可	期待値、二次モーメント、分散、sanity check が揃っている
物理モデリング	初回で途中終了	滑車慣性、糸のたるみ、ばね段階を正しく処理
プログラミング納品	今回は timeout	コード本体は独立検査を通過したが、付属の assert に誤りあり
出力安定性	reasoning 消費が大きく、可視回答を得にくい	3問すべて順次リトライで `stop`
応答速度	約 187–246 s で、しかも途中終了/timeout あり	成功したリクエストは約 88–236 s；並列初回は 408 あり

より正確に言うと、結論は「どちらか一方が絶対的に賢い」という話ではありません。

今回のルーティングと予算では、GPT-5.6-SOL のほうが複雑な推論を最終答案までまとめやすく、すぐ読める導出やコードが必要なワークフローに向いています。
Kimi K3 の主な課題は、推論予算を可視出力へ変換する効率です。数学問題で 10000 token に増やしても、なお完了しませんでした。
GPT-5.6-SOL のコードも盲信は禁物です。関数ロジックは独立検査を通っても、付属テストフィクスチャに価値計算ミスがありました。
本番導入の選定では、finish_reason、reasoning token、遅延、ローカルテスト結果を併記して記録すべきで、最後の一文が「答えは正しい」だけでは不十分です。

再現実験

今回のテストスクリプトと順次リトライ結果は以下に保存しています（並列初回の要約もスクリプト出力に書き込んであります）。

.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

再測定時は、モデル ID、プロンプト、temperature、max_tokens、並列度を固定し、毎回の出力を別ファイルとして保存するのがおすすめです。上流の負荷、キャッシュヒット、レート制限の状態は遅延に影響します。本記事では HTTP 408、length、read timeout をいずれもテスト結果の一部として記録し、意図的に隠していません。

Kimi K3 对比 GPT-5.6-SOL：数学、物理与编程高难度实测

Jenny Met — Sat, 18 Jul 2026 01:13:07 +0000

Kimi K3 对比 GPT-5.6-SOL：数学、物理与编程高难度实测

这次不测简单问答，而是固定三道需要连续推理的题：带模式重叠和二阶矩的概率题、带滑轮转动惯量与绳松弛切换的物理题，以及依赖闭包、多日容量和三层 tie-break 的 Python 题。两个模型使用同一接口、同一提示词和相近的输出上限，不启用工具和联网。

先给结论：

gpt-5.6-sol 在三道题上都拿到了完整可见回答，数学和物理的参考结果正确。
kimi-k3 在首轮 6500 token 上限下，数学和物理都以 finish_reason=length 结束，可见答案为空；数学题把上限提高到 10000 后仍然截断。编程题则在约 245 秒后读超时。
GPT-5.6-SOL 的编程实现通过了独立补充的依赖闭包、容量、tie-break、非法依赖和循环依赖检查，但它自己附带的第一条断言样例有预期值错误。这说明“代码主体正确”和“示例测试全对”需要分开验收。

本文的延迟是本次请求的观测值，不代表固定 SLA。首轮并发请求中 GPT 的数学和物理请求收到过 HTTP 408，随后改为顺序重试；因此速度只用于观察调用体验，不用于宣称绝对排名。

测试设置

测试时间为北京时间 2026-07-17 至 2026-07-18，接口为：

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

第一轮统一使用：数学和物理 max_tokens=6500，编程 max_tokens=7500。每道题都要求模型给出可复核推导或可运行代码，并记录 finish_reason、completion/reasoning token、请求延迟、数值正确性和代码能否在 Python 3.11 中独立运行。

结果总表

任务	kimi-k3	gpt-5.6-sol	判定
数学：HHTH 的期望与方差	`length`，186.98 s，6500 tokens；可见内容为空	顺序重试 `stop`，236.07 s，6872 tokens	GPT 完整作答；Kimi 首轮未形成答案
物理：滑轮、碰地、弹簧	`length`，202.05 s，6500 tokens；可见内容为空	顺序重试 `stop`，156.29 s，4501 tokens	GPT 完整且数值正确
编程：依赖闭包背包	245.54 s 后 `TimeoutError`	`stop`，87.96 s，4514 tokens	GPT 代码可运行；Kimi 未返回完整代码
Kimi 数学复测	`length`，286.99 s，10000 tokens	—	增加预算仍未结束

Kimi 的数学和物理请求中，接口报告的 reasoning token 分别接近 6497；数学复测的 reasoning token 接近 9997。这不是说 Kimi 没有推理能力，而是说明在本题提示词和当前路由下，推理预算很容易被耗尽，调用方拿不到最终答案。

数学题：模式重叠不仅影响期望，也影响方差

题目是：正面概率 p=3/5、反面概率 q=2/5，不断投掷直到第一次出现 HHTH，允许模式重叠，求 E[T] 和 Var(T)。

正确的前缀自动机状态为 S0=空前缀、S1=H、S2=HH、S3=HHT、S4=HHTH（吸收态）。关键转移是 S2 --H--> S2：已有 HH 后再次出现 H，最长后缀仍是 HH，不能错误地退回空状态。

GPT-5.6-SOL 建立的一阶矩方程为：

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

继续建立二阶矩方程，得到：

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

期望还可用边界公式独立复核。HHTH 的非空真边界是单字符 H，所以 E[T] = 1/p + 1/(p³q) = 715/54。GPT 的完整回答同时覆盖了状态转移、二阶矩展开和 sanity check。Kimi 在 6500 和 10000 上限下都没有输出可见推导，因此本轮无法对其数学正确性打分，只能记录为“预算内未完成”。

物理题：碰地后约束断开，不能继续套同一套能量方程

题目设置为：m_A=4.0 kg 位于 25° 粗糙斜面，μ_k=0.18；m_B=3.0 kg 悬挂；滑轮 M_p=1.2 kg、R=0.10 m；B 下降 1.50 m 后碰地，绳立即松弛；A 再上滑 0.10 m 接触 k=250 N/m 弹簧；g=9.8 m/s²。

碰地前，绳绷紧且无滑动，滑轮的等效惯性质量为 I/R²=(1/2)M_p=0.60 kg。联立两块物体和滑轮转动方程，得到：

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

碰地后，B 的速度被地面碰撞改变，A 仍有沿斜面向上的速度，滑轮也可能继续转动；题目又明确绳立即松弛，所以不能继续使用 v_A=v_B=Rω。后续应只分析 A：

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 还检查了量纲、无弹簧停止距离以及弹簧能量与摩擦/重力损失之和，数值自洽。Kimi 在首轮没有形成可见答案，因此无法比较中间建模质量。

编程题：算法主体通过独立检查，但模型自带样例有 bug

编程题要求实现 optimize_release_plan(items, capacity_by_day, dependencies)，处理每天容量、未配置日期容量为 0、直接和间接依赖闭包、非法依赖与循环检测，以及 value → risk → 排序后的 id 列表 三层 tie-break。items <= 18，所以 bitmask 穷举是合理基线。

GPT-5.6-SOL 使用依赖闭包缓存和 2^n 子集枚举。我们把代码提取出来，在 Python 3.11 中做了独立检查：依赖闭包、多日容量样例、value/risk/id 三层 tie-break、未配置日期容量、不存在依赖和循环依赖，共 6 组检查全部通过。

但模型在代码末尾附带的第一条断言失败：它写的是 A -> B -> C，同时还放入了价值为 11 的 X。在给定容量下，B + C + X 的总价值为 13，高于 A + B + C 的 12，因此函数返回 ['B', 'C', 'X'] 才是正确的，断言写成 ['A', 'B', 'C'] 是测试夹具错误。

这个细节很有代表性：代码题不能只看函数主体，也不能因为“附带了 8 个断言”就默认测试可信。模型生成的测试数据同样需要人工或参考实现复核。Kimi K3 的编程请求在约 245 秒后读超时，未能拿到完整代码。

综合评价

维度	kimi-k3	gpt-5.6-sol
数学完整性	`6500/10000` token 均截断，无法验收	期望、二阶矩、方差和 sanity check 完整
物理建模	首轮截断	正确处理滑轮惯性、绳松弛和弹簧阶段
编程交付	本轮超时	代码主体通过独立检查，但自带一条错误断言
输出稳定性	高 reasoning 占用，容易拿不到可见答案	三道题顺序重试均 `stop`
响应速度	约 187–246 s，且有截断/超时	成功请求约 88–236 s；并发首轮有 408

更准确的结论不是“某个模型绝对更聪明”，而是：

在本次路由和预算下，GPT-5.6-SOL 更容易把复杂推理收束成最终答案，适合需要立即拿到可读推导或代码的工作流。
Kimi K3 的主要问题是推理预算和可见输出之间的转换效率；即使数学题提高到 10000 token，仍未结束。
GPT-5.6-SOL 的代码也不能盲信。它的函数逻辑通过了独立检查，但随附测试夹具存在价值计算错误。
对生产选型，应该同时记录 finish_reason、reasoning token、延迟和本地测试结果，不能只看最终一句“答案正确”。

复现实验

本次测试脚本和顺序重试结果保存在（并发首轮的摘要也已写入脚本输出）：

.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

复测时建议固定模型 ID、提示词、temperature、max_tokens 和并发度，并把每次输出另存为独立文件。上游渠道负载、缓存命中和限流状态都会影响延迟；本文把 HTTP 408、length 和读超时都作为测试结果的一部分记录，而没有将其隐去。

Kimi K3 so với Claude Fable 5: mô hình nào phù hợp hơn cho tác vụ cần kiểm chứng?

Jenny Met — Fri, 17 Jul 2026 17:11:18 +0000

Kimi K3 so với Claude Fable 5: mô hình nào phù hợp hơn cho tác vụ cần kiểm chứng?

Trong hệ thống thật, một phản hồi thành công chưa chắc là một kết quả dùng được. Bài test này kiểm tra cả bước tính trung gian, finish_reason và khả năng chạy của mã Python.

Khác biệt chính

Fable 5 có độ trễ trung bình 37,1 giây, trong khi Kimi K3 là 108,0 giây. Đổi lại, Kimi K3 tạo chuỗi kiểm chứng toán học nhất quán hơn.

Lập trình: ngân sách đầu ra quyết định tính hoàn chỉnh

Hàm Python phải gộp retry theo request_id, đọc thời gian ISO-8601, lọc khoảng nửa kín [start,end), tổng hợp token và độ trễ, rồi sắp xếp theo nhiều khóa.

Round 1, max_tokens=4000:
Kimi K3 finish_reason=length
Fable 5 finish_reason=length

Retry, max_tokens=7000:
Kimi K3: 145.2 s, 5199 completion tokens, 8/8 assertions
Fable 5: 46.6 s, 3710 completion tokens, 8/8 assertions

Ở mức 4.000 tokens, cả hai kết thúc với length. Khi tăng lên 7.000, hai chương trình Python đều vượt qua tám assert giống nhau.

Thiết kế bài test

Test date: 2026-07-17
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: kimi-k3, claude-fable-5
temperature: 0.2
Round 1 max_tokens: 4000
Coding retry max_tokens: 7000

Hai mô hình nhận cùng prompt và cùng tiêu chí nghiệm thu. HTTP 200 không được xem là đủ: chúng tôi kiểm tra giá trị cuối, trạng thái trung gian, finish_reason, Python có thể chạy và cùng một bộ assertion.

Kết quả tổng hợp

Tác vụ	Kimi K3	Claude Fable 5
Xác suất HHTH	Đạt	Kết quả cuối đúng; sai số học ở bước trung gian
Va chạm và lò xo	Đạt	Đạt
Tổng hợp Python	Bị cắt ở 4k; đạt ở 7k	Bị cắt ở 4k; đạt ở 7k
Lịch ràng buộc	Đạt	Đạt

Độ trễ trung bình — Kimi K3: 108.0 s
Độ trễ trung bình — Claude Fable 5: 37.1 s

Bài toán: đáp án cuối đúng chưa đủ

Bài toán đồng xu lệch yêu cầu tính số lần tung kỳ vọng trước lần xuất hiện đầu tiên của HHTH, với P(H)=3/5 và cho phép chồng lấn. Kết quả đúng là:

E[T] = 715/54 ≈ 13.2407407407
E1 = 625/54
E2 = 475/54
E3 = 170/27

Kimi K3 đối chiếu phương trình trạng thái với hai cách kiểm tra độc lập. Fable 5 có đáp án cuối đúng nhưng hai giá trị trung gian không khớp với chính phương trình của nó.

Vật lý: cả hai mô hình đều đúng

Bài vật lý kết hợp va chạm hoàn toàn không đàn hồi, ma sát và nén lò xo. Cả hai mô hình đều cho:

Post-collision speed: 2.4 m/s
Energy lost in collision: 21.6 J
Maximum compression: about 0.2212 m

Cả hai tính được độ nén lò xo khoảng 0,2212 m và lịch duy nhất Eli, Bo, Ada, Cici, Deng.

Ý nghĩa của reasoning tokens khi vận hành

Kimi K3 completion tokens: 13,975
Kimi K3 reasoning tokens: about 12,500
Fable 5 completion tokens: 10,187

Kimi K3 báo cáo khoảng 12.500 reasoning tokens. Việc suy luận sâu hơn đi cùng độ trễ cao hơn và ít không gian hơn cho mã hiển thị.

Suy luận ràng buộc: cùng một nghiệm duy nhất

Cả hai mô hình đều tìm được lịch làm việc duy nhất:

Thứ hai	Thứ ba	Thứ tư	Thứ năm	Thứ sáu
Eli	Bo	Ada	Cici	Deng

Cả hai tính được độ nén lò xo khoảng 0,2212 m và lịch duy nhất Eli, Bo, Ada, Cici, Deng.

Gợi ý định tuyến mô hình

Dùng Fable 5 trước cho mã có thể test tự động
Giữ Kimi K3 cho suy luận toán chính xác
Luôn kiểm tra finish_reason và chạy test

Giới hạn của phép thử

Đây là mẫu thử nhỏ, không phải bảng xếp hạng phổ quát. Đánh giá production nên lặp mỗi nhóm 20–50 lần và đo tỷ lệ thành công, tỷ lệ bị cắt, thời gian tới token đầu tiên, P50/P95/P99, completion tokens và chi phí cho mỗi kết quả được chấp nhận.

Kết luận

Trong lần thử này, Fable 5 là tuyến phản hồi nhanh; Kimi K3 là tuyến thận trọng hơn cho các bước toán trung gian.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://cn.crazyrouter.com/v1")
response = client.chat.completions.create(
    model="kimi-k3",
    temperature=0.2,
    max_tokens=4000,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)
print(response.model, response.choices[0].finish_reason, response.usage)

Bài đầy đủ: https://crazyrouter.com/vi/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-vi

API: https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=kimi_k3_fable5_multilingual_20260718&utm_content=kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-vi__body_cta&utm_term=kimi-k3+claude-fable-5+benchmark

Kimi K3 vs. Claude Fable 5: Ein API-Test zu Prüfbarkeit, Code-Abbruch und Latenz

Jenny Met — Fri, 17 Jul 2026 17:10:29 +0000

Kimi K3 vs. Claude Fable 5: Ein API-Test zu Prüfbarkeit, Code-Abbruch und Latenz

Ein belastbarer Modelltest muss mehr prüfen als die letzte Antwortzeile. Deshalb wurden Zwischenwerte zurück in Gleichungen eingesetzt, generierter Code ausgeführt und abgeschnittene Antworten separat bewertet.

Versuchsaufbau

Test date: 2026-07-17
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: kimi-k3, claude-fable-5
temperature: 0.2
Round 1 max_tokens: 4000
Coding retry max_tokens: 7000

Beide Modelle erhielten identische Prompts und Abnahmekriterien. HTTP 200 allein galt nicht als Erfolg: Endwerte, Zwischenzustände, finish_reason, ausführbares Python und dieselben Assertions wurden geprüft.

Das technische Spannungsfeld

Fable 5 antwortete im Mittel nach 37,1 Sekunden, Kimi K3 nach 108,0 Sekunden. Kimi K3 lieferte jedoch die konsistentere mathematische Verifikation.

Messwerte im Überblick

Aufgabe	Kimi K3	Claude Fable 5
HHTH-Wahrscheinlichkeit	Bestanden	Endwert korrekt; Zwischenrechnung fehlerhaft
Kollision und Feder	Bestanden	Bestanden
Python-Aggregation	Bei 4k gekürzt; bei 7k bestanden	Bei 4k gekürzt; bei 7k bestanden
Dienstplanlogik	Bestanden	Bestanden

Mittlere Latenz — Kimi K3: 108.0 s
Mittlere Latenz — Claude Fable 5: 37.1 s

Mathematik: Konsistenz der Zwischenwerte

Die Aufgabe zur verzerrten Münze fragte nach der erwarteten Zahl der Würfe bis zum ersten HHTH bei P(H)=3/5 und erlaubter Überlappung. Das korrekte Ergebnis lautet:

E[T] = 715/54 ≈ 13.2407407407
E1 = 625/54
E2 = 475/54
E3 = 170/27

Kimi K3 prüfte den Zustandsautomaten mit zwei unabhängigen Methoden. Fable 5 fand das richtige Endergebnis, meldete aber zwei Zwischenwerte, die nicht zu den eigenen Gleichungen passten.

Physik: korrekte Trennung der Energiephasen

Die Physikaufgabe kombinierte einen vollständig unelastischen Stoß mit Reibung und Federkompression. Beide Modelle erhielten:

Post-collision speed: 2.4 m/s
Energy lost in collision: 21.6 J
Maximum compression: about 0.2212 m

Beide Modelle berechneten etwa 0,2212 m Federkompression und denselben eindeutigen Dienstplan.

Code: ein Output-Limit ist ein Qualitätsparameter

Die Python-Funktion musste Retries nach request_id zusammenführen, ISO-8601-Zeitstempel verarbeiten, das Halbintervall [start,end) filtern, Token und Latenz aggregieren und mehrstufig sortieren.

Round 1, max_tokens=4000:
Kimi K3 finish_reason=length
Fable 5 finish_reason=length

Retry, max_tokens=7000:
Kimi K3: 145.2 s, 5199 completion tokens, 8/8 assertions
Fable 5: 46.6 s, 3710 completion tokens, 8/8 assertions

Bei 4.000 Tokens wurden beide Antworten mit length beendet. Mit 7.000 Tokens bestanden beide Python-Programme dieselben acht Assertions.

Reasoning-Tokens und sichtbare Ausgabe

Kimi K3 completion tokens: 13,975
Kimi K3 reasoning tokens: about 12,500
Fable 5 completion tokens: 10,187

Kimi K3 meldete rund 12.500 Reasoning-Tokens. Das verbessert in diesem Beispiel die Kontrolle, erhöht aber Latenz und Kürzungsrisiko bei langem Code.

Empfohlene Aufgabenverteilung

Fable 5 für häufige, automatisiert testbare Aufgaben
Kimi K3 für exakte Herleitungen und Zwischenwert-Audits
Langen Code nur mit finish_reason- und Laufzeittest akzeptieren

Constraint-Reasoning: identische eindeutige Lösung

Beide Modelle fanden denselben eindeutig bestimmten Wochenplan:

Montag	Dienstag	Mittwoch	Donnerstag	Freitag
Eli	Bo	Ada	Cici	Deng

Beide Modelle berechneten etwa 0,2212 m Federkompression und denselben eindeutigen Dienstplan.

Grenzen des Tests

Dies ist ein kleiner Test und keine allgemeine Rangliste. Für den Betrieb sollten alle Kategorien 20–50 Mal wiederholt und Erfolgsrate, Abbruchrate, Time-to-first-token, P50/P95/P99-Latenz, completion tokens und Kosten pro akzeptiertem Ergebnis erfasst werden.

Fazit

Fable 5 war der schnelle Ausführungspfad; Kimi K3 war in diesem kleinen Test der sorgfältigere mathematische Prüfpfad.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://cn.crazyrouter.com/v1")
response = client.chat.completions.create(
    model="kimi-k3",
    temperature=0.2,
    max_tokens=4000,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)
print(response.model, response.choices[0].finish_reason, response.usage)

Vollständiger Artikel: https://crazyrouter.com/de/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-de

API: https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=kimi_k3_fable5_multilingual_20260718&utm_content=kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-de__body_cta&utm_term=kimi-k3+claude-fable-5+benchmark

Kimi K3 と Claude Fable 5 を実測比較：差が出たのは推論力より出力予算と検証性

Jenny Met — Fri, 17 Jul 2026 17:09:34 +0000

Kimi K3 と Claude Fable 5 を実測比較：差が出たのは推論力より出力予算と検証性

モデル比較で見落とされやすいのは、HTTP 200 と成果物の完成が同じではない点です。本稿では最終回答だけでなく、finish_reason、途中計算、実行可能コードまで確認しました。

運用上の差はどこに出たか

Fable 5 の平均応答は 37.1 秒、Kimi K3 は 108.0 秒でした。一方、確率問題の途中計算は Kimi K3 の方が一貫していました。

検証条件

Test date: 2026-07-17
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: kimi-k3, claude-fable-5
temperature: 0.2
Round 1 max_tokens: 4000
Coding retry max_tokens: 7000

両モデルには同じプロンプトと検証条件を与えました。HTTP 200 だけを成功とはせず、最終値、途中状態、finish_reason、実行可能な Python、同じ assert を確認しました。

4000 tokens では両方が打ち切り

Python 関数では request_id ごとのリトライ統合、ISO-8601 時刻、半開区間 [start,end)、token と遅延の集計、多段ソートを扱いました。

Round 1, max_tokens=4000:
Kimi K3 finish_reason=length
Fable 5 finish_reason=length

Retry, max_tokens=7000:
Kimi K3: 145.2 s, 5199 completion tokens, 8/8 assertions
Fable 5: 46.6 s, 3710 completion tokens, 8/8 assertions

max_tokens=4000 では両方とも length で終了しました。7000 に増やすと、両方の Python 実装が同じ8個の assert を通過しました。

結果一覧

課題	Kimi K3	Claude Fable 5
HHTH 確率問題	通過	最終値は正しいが、途中計算に誤り
衝突とばね	通過	通過
Python 集計	4000で打ち切り、7000で通過	4000で打ち切り、7000で通過
勤務表推論	通過	通過

平均応答 — Kimi K3: 108.0 s
平均応答 — Claude Fable 5: 37.1 s

数式では最終値より途中状態を確認

偏ったコインで P(H)=3/5、パターンの重複を許し、HHTH が初めて現れるまでの期待投数を求めました。正しい結果は次の通りです。

E[T] = 715/54 ≈ 13.2407407407
E1 = 625/54
E2 = 475/54
E3 = 170/27

Kimi K3 は状態方程式、border 公式、公平なコインの特殊例を照合しました。Fable 5 は最終値は正しいものの、2つの途中状態に算術的不整合がありました。

reasoning tokens と可視出力の関係

Kimi K3 completion tokens: 13,975
Kimi K3 reasoning tokens: about 12,500
Fable 5 completion tokens: 10,187

Kimi K3 は初回に約 12,500 reasoning tokens を報告しました。検証は厚い一方、待ち時間と長いコードの可視出力に影響します。

物理問題は両モデルが正解

物理問題は完全非弾性衝突、摩擦、ばね圧縮の2段階で構成しました。両モデルの結果は次の通りです。

Post-collision speed: 2.4 m/s
Energy lost in collision: 21.6 J
Maximum compression: about 0.2212 m

物理問題の最大圧縮量は約 0.2212 m、勤務表の一意解は Eli、Bo、Ada、Cici、Deng でした。

制約推論は同じ一意解

両モデルは同じ一意の平日スケジュールを導きました。

月曜	火曜	水曜	木曜	金曜
Eli	Bo	Ada	Cici	Deng

物理問題の最大圧縮量は約 0.2212 m、勤務表の一意解は Eli、Bo、Ada、Cici、Deng でした。

実装時のモデル振り分け

高速な検証可能コードは Fable 5 から試す
厳密な数式展開には Kimi K3 を残す
長い生成では finish_reason と実行テストを必須にする

小規模テストとしての注意点

これは小規模な実測であり、普遍的なランキングではありません。実運用では各カテゴリを20〜50回繰り返し、成功率、途中打ち切り率、初回 token 時間、P50/P95/P99 遅延、completion tokens、採用結果あたりのコストを計測する必要があります。

結論

本テストでは Fable 5 が高速な実務ルート、Kimi K3 が数式の途中整合性を重視するルートという違いが見えました。

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://cn.crazyrouter.com/v1")
response = client.chat.completions.create(
    model="kimi-k3",
    temperature=0.2,
    max_tokens=4000,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)
print(response.model, response.choices[0].finish_reason, response.usage)

サイト内原文： https://crazyrouter.com/ja/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-ja

API エンドポイント： https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=kimi_k3_fable5_multilingual_20260718&utm_content=kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-ja__body_cta&utm_term=kimi-k3+claude-fable-5+benchmark

Kimi K3 对比 Claude Fable 5：数学更稳，还是响应更快？

Jenny Met — Fri, 17 Jul 2026 17:08:51 +0000

Kimi K3 对比 Claude Fable 5：数学更稳，还是响应更快？

这不是一篇只看最终答案的模型排行榜。四道题分别检查数学中间状态、物理阶段划分、可执行 Python 和约束推理，并把输出截断与模型能力分开判断。

先看工程结论

本轮 Fable 5 的平均延迟约为 37.1 秒，Kimi K3 约为 108.0 秒。Kimi K3 在概率题中给出了完全一致的状态回代；Fable 5 最终值正确，但两个中间状态存在算术错误。

测试方法

Test date: 2026-07-17
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: kimi-k3, claude-fable-5
temperature: 0.2
Round 1 max_tokens: 4000
Coding retry max_tokens: 7000

两个模型使用完全相同的提示词和验收标准。HTTP 200 只能说明请求完成，本文还检查最终数值、中间状态、finish_reason、可执行 Python 和相同的断言。

结果总览

任务	Kimi K3	Claude Fable 5
HHTH 概率题	通过	最终值通过；中间算术错误
碰撞与弹簧	通过	通过
Python 日志聚合	4000 截断；7000 通过	4000 截断；7000 通过
排班推理	通过	通过

平均延迟 — Kimi K3: 108.0 s
平均延迟 — Claude Fable 5: 37.1 s

数学题揭示了中间验证的重要性

偏置硬币题要求计算在 P(H)=3/5、允许模式重叠时首次出现 HHTH 的期望投掷次数。正确结果为：

E[T] = 715/54 ≈ 13.2407407407
E1 = 625/54
E2 = 475/54
E3 = 170/27

Kimi K3 同时用状态方程、模式 border 和公平硬币特例交叉验证。Fable 5 的最终答案虽然正确，但局部回代不一致，因此需要外部校验。

代码题首先考验的是输出预算

Python 函数需要按 request_id 去重重试，解析 ISO-8601 时间，过滤半开区间 [start,end)，汇总 token 与延迟，并执行多级排序。

Round 1, max_tokens=4000:
Kimi K3 finish_reason=length
Fable 5 finish_reason=length

Retry, max_tokens=7000:
Kimi K3: 145.2 s, 5199 completion tokens, 8/8 assertions
Fable 5: 46.6 s, 3710 completion tokens, 8/8 assertions

max_tokens 为 4000 时两者都以 length 结束；提高到 7000 后，两份代码均通过八个断言。HTTP 200 不能替代完整性检查。

物理题两者都正确拆分阶段

物理题包含完全非弹性碰撞、摩擦和弹簧压缩两个阶段。两款模型都得到：

Post-collision speed: 2.4 m/s
Energy lost in collision: 21.6 J
Maximum compression: about 0.2212 m

碰撞压簧题的最大压缩量约为 0.2212 米；排班题的唯一顺序为 Eli、Bo、Ada、Cici、Deng。两款模型均通过。

文本约束题得到同一唯一解

两款模型都找到了同一个唯一的工作日排班：

周一	周二	周三	周四	周五
Eli	Bo	Ada	Cici	Deng

碰撞压簧题的最大压缩量约为 0.2212 米；排班题的唯一顺序为 Eli、Bo、Ada、Cici、Deng。两款模型均通过。

延迟与 reasoning token 的工程含义

Kimi K3 completion tokens: 13,975
Kimi K3 reasoning tokens: about 12,500
Fable 5 completion tokens: 10,187

Kimi K3 第一轮报告约 12,500 个 reasoning tokens，这与更长延迟和代码可见输出空间不足同时出现。

如何选择和路由

高频可测试代码优先评估 Fable 5
精确数学推导保留 Kimi K3
所有长代码检查 finish_reason 并执行测试

测试边界

这是一组小样本测试，不是通用排行榜。正式评估应将每类任务重复 20–50 次，并统计成功率、截断率、首 token 时间、P50/P95/P99 延迟、completion tokens 和每个通过结果的成本。

结论

更准确的判断不是谁全面胜出，而是 Fable 5 更适合速度敏感的可验证任务，Kimi K3 更适合允许较长等待、重视推导一致性的任务。

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://cn.crazyrouter.com/v1")
response = client.chat.completions.create(
    model="kimi-k3",
    temperature=0.2,
    max_tokens=4000,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)
print(response.model, response.choices[0].finish_reason, response.usage)

站内原文： https://crazyrouter.com/zh/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026

API 入口： https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=kimi_k3_fable5_multilingual_20260718&utm_content=kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026__body_cta&utm_term=kimi-k3+claude-fable-5+benchmark

Why High-Concurrency AI Apps Should Care About Gemini 2.5 Flash-Lite, Not Only the Strongest Model

Jenny Met — Thu, 09 Jul 2026 07:34:34 +0000

Why High-Concurrency AI Apps Should Care About Gemini 2.5 Flash-Lite, Not Only the Strongest Model

The short answer: if you are only building a demo, choosing the strongest model for every request is fine. Once the product reaches production traffic, the question changes.

You no longer ask only:

Which model gives the best single answer?

You start asking:

Can the API absorb traffic spikes?
What happens when requests per minute go up?
Do lightweight steps really need the most expensive model?
How much do retries add to the bill?
Can the application switch models without rewriting business logic?

That is why I care about gemini-2.5-flash-lite and gemini-2.5-flash. They are not interesting only because they are Gemini models. They are interesting because they fit a production routing pattern: cheap high-frequency steps first, stronger models only where they are actually needed.

The cost of an AI product is often hidden in small steps

Take a customer-support assistant. A user sends one message:

I want to cancel my order, but can I keep the coupon?

From the user's point of view, this is one question. From the backend's point of view, it may become several model calls:

Detect language
Classify intent
Check whether this is an order-cancellation case
Decide whether a human agent is needed
Generate an internal summary
Retrieve policy context
Draft the reply
Run a lightweight risk check

If every step uses the strongest model, cost grows fast. A more practical design is:

High-frequency lightweight steps: gemini-2.5-flash-lite
Medium-generation steps: gemini-2.5-flash
Rare complex tasks: stronger reasoning or coding models

This is not about sacrificing quality blindly. It is about matching task difficulty to model cost and throughput.

Flash-Lite is not for every task. It is for many small tasks.

gemini-2.5-flash-lite is best used for work such as:

Text classification
Intent detection
Short summaries
Query rewriting
Tag extraction
Structured field extraction
Agent intermediate decisions
Low-risk content pre-screening

These jobs usually have four traits:

High volume
Short input
Short output
Limited reasoning depth

The failure mode in this layer is rarely "the answer was not poetic enough." The real problems are:

Queueing under concurrency
More 429s
Retry amplification
Higher P95 latency
Unpredictable monthly cost

Flash-Lite is valuable because it can sit in front of the workflow and absorb these repeated, lightweight operations.

Flash belongs one layer higher

gemini-2.5-flash is better suited for:

Reply drafts
Medium-length summaries
Multi-paragraph merging
Content rewriting
Light code explanation
Main responses in conversational flows
Longer context understanding

A simple routing table can start like this:

Layer	Model	Tasks
Lightweight high-frequency layer	`gemini-2.5-flash-lite`	Classification, short summaries, extraction, routing
Medium-generation layer	`gemini-2.5-flash`	Draft replies, medium summaries, rewriting
Specialist layer	Stronger reasoning/code models	Deep reasoning, long code, high-risk decisions

Many teams do not have a model problem. They have a routing problem: every task goes to the same model.

Why RPM matters

RPM, or requests per minute, does not matter much in a manual demo. It matters a lot in production.

A real AI application has:

User concurrency
Background batch jobs
Multi-step agents
Retries after transient failures
Scheduled jobs firing at the same time
Multiple model calls per user action

When this happens, model choice affects the entire system:

Queue time
429 rate
5xx recovery
P95 latency
Retry count
Total workflow cost

So I evaluate models together with endpoint compatibility, routing flexibility, unit cost, and observed reliability.

Current endpoint shape and pricing snapshot

At the time this article was prepared, Crazyrouter listed both gemini-2.5-flash and gemini-2.5-flash-lite with openai and gemini endpoint support.

Model	supported_endpoint_types	public_endpoint_types
`gemini-2.5-flash`	`gemini`, `openai`	`gemini`, `openai`
`gemini-2.5-flash-lite`	`gemini`, `openai`	`gemini`, `openai`

The pricing API snapshot used in the original Chinese article returned:

Model	model_ratio	completion_ratio	cache_ratio	cache_creation_ratio	discount
`gemini-2.5-flash-lite`	0.05	4	0.25	1.25	0.55
`gemini-2.5-flash`	0.15	8.3333	0.2667	1.25	0.55

This is a publication-time snapshot, not a permanent price promise. Always check current pricing before a large deployment.

OpenAI-compatible request example

If your stack already uses an OpenAI-compatible client, the lightweight classification step can look like this:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-flash-lite",
    "messages": [
      {
        "role": "system",
        "content": "You are a high-throughput classifier. Return JSON only."
      },
      {
        "role": "user",
        "content": "Classify this support message: I want to cancel my order but keep the coupon."
      }
    ],
    "temperature": 0.1,
    "max_tokens": 200
  }'

Then use gemini-2.5-flash for the user-facing draft:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-flash",
    "messages": [
      {
        "role": "system",
        "content": "You are a support assistant. Keep the answer concise and actionable."
      },
      {
        "role": "user",
        "content": "The user wants to cancel an order but keep the coupon. Draft a reply."
      }
    ],
    "temperature": 0.3,
    "max_tokens": 500
  }'

The important idea is not the exact prompt. It is the routing pattern:

Structured judgment: Lite
Natural language draft: Flash
Complex cases: upgrade only when needed

Cost should be calculated per workflow

Many teams estimate AI cost by asking:

How much is one API call?

In production, the better question is:

How many model calls does one user action trigger?
Which model handles each step?
How many tokens does each step use?
How many retries happen?
Did the workflow eventually succeed?

If one user action triggers five model calls and three of them are lightweight, moving those three calls to Flash-Lite can make the total workflow cost much healthier.

Common mistakes

The first mistake is using the strongest model for everything. It is simple, but expensive at scale.

The second mistake is using the cheapest model for everything. This often increases retries and manual correction.

The third mistake is not logging finish_reason, token usage, latency, and retry count. Without those fields, you cannot tell whether the cost problem comes from the model, the task design, or retry behavior.

The fourth mistake is having no fallback. If one model is rate-limited or degraded, the application has no operational room.

Where Crazyrouter fits

Crazyrouter is useful here as a unified API gateway when you need:

High RPM
Low-cost routing
OpenAI-compatible access
Gemini endpoint support
Multiple models behind one integration layer
Future model switching without changing business logic everywhere

Try it here:

https://crazyrouter.com/register?utm_source=devto&utm_medium=article&utm_campaign=gemini_flash_lite_high_rpm_20260709&utm_content=gemini-25-flash-lite-high-rpm-production-ai-routing-en_devto

API base URL:

https://cn.crazyrouter.com/v1

Final judgment

If you only call an AI model occasionally, Flash-Lite may not look special. If your application has high volume, many workflow steps, many lightweight tasks, and cost pressure, it becomes very relevant.

gemini-2.5-flash-lite handles the high-frequency layer. gemini-2.5-flash handles medium-generation work. Stronger models should be reserved for the small set of tasks that actually need them.

High-concurrency AI model selection is not about choosing the strongest model for every prompt. It is about building a routing system that can keep quality, throughput, and cost under control.

GLM-5.2 vs Claude Fable 5: presupuesto de salida, reasoning_tokens y discount 0.8

Jenny Met — Mon, 06 Jul 2026 16:13:18 +0000

GLM-5.2 vs Claude Fable 5: la diferencia estuvo en el presupuesto de salida

Este no es un ranking genérico de modelos. En esta prueba real de API, GLM-5.2 resolvió las tareas de razonamiento cuando se aumentó el presupuesto de salida, pero con límites bajos podía devolver HTTP 200 sin contenido visible. Claude Fable 5 fue más estable con presupuestos bajos y más fiable en la tarea de HTML largo.

Por qué importa esta prueba

The test used the Crazyrouter OpenAI-compatible API rather than a chat UI. That matters because the result was not judged only by prose quality. Each response was checked with operational metadata:

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: glm-5.2, claude-fable-5
temperature: 0.2
Test date: 2026-07-06

The important fields were max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible content length, whether the generated HTML was closed, and whether the animation actually moved in a browser.

Diseño de la prueba

The benchmark deliberately mixed three task types:

Task	Purpose	Reference result
`MATH-003`	State-based expectation reasoning	Expected flips until HH = `6`
`PHYS-003`	Momentum plus energy accounting	`V = 3.0 m/s`, `x ≈ 0.148 m`
`CODE-003-ANIM`	Long runnable artifact generation	Complete 800x500 Canvas animation HTML

The first two tasks measured reasoning. The third task measured whether a model can produce a complete artifact, not merely a convincing partial code block.

Resultados observados

Task	`glm-5.2`	`claude-fable-5`
Math, original budget	`finish_reason=length`, `completion_tokens=1601`, `reasoning_tokens=1600`, visible body empty	`finish_reason=stop`, complete and correct
Math, retest	Correct after `max_tokens=3200`	Retest not needed
Physics, original budget	`finish_reason=length`, visible body empty	Complete and correct
Physics, retest	Correct after `max_tokens=8000`	Retest not needed
Animation, original budget	Empty visible HTML at `max_tokens=3200`	Partial HTML, truncated
Animation, retest	Still truncated at `max_tokens=8000`	Complete HTML; browser validation passed

The most important observation is that GLM-5.2 was not failing the reasoning itself. In the math and physics tasks, it produced correct answers after a larger output budget. The problem was visibility and completion: a request could return HTTP 200 while the user-facing content was empty or incomplete.

For the long Canvas animation, the difference was sharper. GLM-5.2 produced a visible HTML fragment at max_tokens=8000, but it stopped inside JavaScript and did not close the file. Claude Fable 5 completed the HTML at max_tokens=8000; browser validation showed no console errors, an 800x500 canvas, controls, a speed slider, and changedPixels=55090 after 700 ms.

Lectura de coste-beneficio

En el momento de escribir, la pricing API de Crazyrouter lista glm-5.2 con discount: 0.8. Eso la vuelve muy interesante en coste si tu aplicación puede asignar más presupuesto de salida y registrar reasoning_tokens correctamente.

This is the practical tradeoff:

Workload	Better fit from this test
Short reasoning with enough output budget	GLM-5.2 can be a cost-effective option
Low-budget reasoning responses	Claude Fable 5 was steadier
Long single-file code generation	Claude Fable 5 was stronger in this run
Batch evaluations where metadata is logged	GLM-5.2 becomes easier to operate safely

Do not treat the 0.8 multiplier as a permanent universal price. It is a pricing-data snapshot from Crazyrouter at publication time and should be checked again before a large deployment.

Notas de integración

Minimal request:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {
        "role": "user",
        "content": "Solve the HH expected-flips problem with state equations."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 3200
  }'

To compare Claude Fable 5, keep the same payload and change only the model:

{
  "model": "claude-fable-5"
}

For production-style evaluations, log this shape for every request:

{
  "model": "glm-5.2",
  "max_tokens": 3200,
  "finish_reason": "length",
  "completion_tokens": 3200,
  "reasoning_tokens": 3178,
  "visible_content_chars": 0,
  "html_closed": false,
  "browser_validation": "not_run_incomplete_html"
}

API endpoints should stay clean. Do not add UTM parameters to https://cn.crazyrouter.com/v1. Use tracking only on human-facing article or registration links.

Puedes ejecutar la misma solicitud compatible con OpenAI en Crazyrouter y comparar los modelos con tus propios prompts.

https://crazyrouter.com/register?utm_source=devto&utm_medium=article&utm_campaign=glm52_fable5_budget_cost_20260706&utm_content=devto_glm-52-vs-claude-fable-5-output-budget-cost-es_20260706__bottom&utm_term=glm-5.2+claude+fable+5+benchmark

FAQ

Did GLM-5.2 fail the reasoning tasks?

No. In this run, GLM-5.2 solved the math task after max_tokens=3200 and the physics task after max_tokens=8000. The issue was that lower budgets were consumed mostly by reasoning tokens before visible content appeared.

Why not score HTTP 200 as success?

Because HTTP 200 only means the API call returned. A benchmark answer can still be unusable if finish_reason=length, visible content is empty, or generated code is incomplete.

Why was the animation task included?

Long code generation exposes a different failure mode. A model can write a convincing first half of a file and still fail if the HTML or JavaScript is cut off.

Is GLM-5.2 still worth testing?

Yes. The current 0.8 discount multiplier makes it attractive for workloads where you can allocate enough output budget and monitor response metadata.

What should be recorded in future comparisons?

At minimum: max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible output length, artifact completeness, and runtime validation.

Final verdict

La conclusión práctica: GLM-5.2 puede ser muy rentable y razonar bien, pero necesita control estricto de salida. Claude Fable 5 fue más seguro para respuestas compactas y para entregar un HTML completo.

GLM-5.2 vs Claude Fable 5: orçamento de saída, reasoning_tokens e discount 0.8

Jenny Met — Mon, 06 Jul 2026 16:12:29 +0000

GLM-5.2 vs Claude Fable 5: a diferença apareceu no orçamento de saída

Este texto não é um ranking genérico de modelos. No teste real via API, o GLM-5.2 resolveu as tarefas de raciocínio depois que aumentamos o orçamento de saída, mas em limites baixos podia retornar HTTP 200 sem conteúdo visível. O Claude Fable 5 foi mais estável em orçamentos menores e melhor na entrega de um HTML longo e executável.

Por que este teste importa

The test used the Crazyrouter OpenAI-compatible API rather than a chat UI. That matters because the result was not judged only by prose quality. Each response was checked with operational metadata:

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: glm-5.2, claude-fable-5
temperature: 0.2
Test date: 2026-07-06

Como o teste foi desenhado

The benchmark deliberately mixed three task types:

Task	Purpose	Reference result
`MATH-003`	State-based expectation reasoning	Expected flips until HH = `6`
`PHYS-003`	Momentum plus energy accounting	`V = 3.0 m/s`, `x ≈ 0.148 m`
`CODE-003-ANIM`	Long runnable artifact generation	Complete 800x500 Canvas animation HTML

The first two tasks measured reasoning. The third task measured whether a model can produce a complete artifact, not merely a convincing partial code block.

Resultados observados

Task	`glm-5.2`	`claude-fable-5`
Math, original budget	`finish_reason=length`, `completion_tokens=1601`, `reasoning_tokens=1600`, visible body empty	`finish_reason=stop`, complete and correct
Math, retest	Correct after `max_tokens=3200`	Retest not needed
Physics, original budget	`finish_reason=length`, visible body empty	Complete and correct
Physics, retest	Correct after `max_tokens=8000`	Retest not needed
Animation, original budget	Empty visible HTML at `max_tokens=3200`	Partial HTML, truncated
Animation, retest	Still truncated at `max_tokens=8000`	Complete HTML; browser validation passed

Leitura de custo-benefício

No momento da publicação, a pricing API da Crazyrouter retorna discount: 0.8 para glm-5.2. Isso torna o modelo bem competitivo em custo quando sua aplicação consegue monitorar reasoning_tokens, finish_reason e ajustar max_tokens corretamente.

This is the practical tradeoff:

Workload	Better fit from this test
Short reasoning with enough output budget	GLM-5.2 can be a cost-effective option
Low-budget reasoning responses	Claude Fable 5 was steadier
Long single-file code generation	Claude Fable 5 was stronger in this run
Batch evaluations where metadata is logged	GLM-5.2 becomes easier to operate safely

Do not treat the 0.8 multiplier as a permanent universal price. It is a pricing-data snapshot from Crazyrouter at publication time and should be checked again before a large deployment.

Notas de integração

Minimal request:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {
        "role": "user",
        "content": "Solve the HH expected-flips problem with state equations."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 3200
  }'

To compare Claude Fable 5, keep the same payload and change only the model:

{
  "model": "claude-fable-5"
}

For production-style evaluations, log this shape for every request:

{
  "model": "glm-5.2",
  "max_tokens": 3200,
  "finish_reason": "length",
  "completion_tokens": 3200,
  "reasoning_tokens": 3178,
  "visible_content_chars": 0,
  "html_closed": false,
  "browser_validation": "not_run_incomplete_html"
}

API endpoints should stay clean. Do not add UTM parameters to https://cn.crazyrouter.com/v1. Use tracking only on human-facing article or registration links.

Você pode rodar a mesma chamada compatível com OpenAI na Crazyrouter e comparar os modelos nos seus próprios prompts.

https://crazyrouter.com/register?utm_source=devto&utm_medium=article&utm_campaign=glm52_fable5_budget_cost_20260706&utm_content=devto_glm-52-vs-claude-fable-5-output-budget-cost-pt_20260706__bottom&utm_term=glm-5.2+claude+fable+5+benchmark

FAQ

Did GLM-5.2 fail the reasoning tasks?

Why not score HTTP 200 as success?

Because HTTP 200 only means the API call returned. A benchmark answer can still be unusable if finish_reason=length, visible content is empty, or generated code is incomplete.

Why was the animation task included?

Long code generation exposes a different failure mode. A model can write a convincing first half of a file and still fail if the HTML or JavaScript is cut off.

Is GLM-5.2 still worth testing?

Yes. The current 0.8 discount multiplier makes it attractive for workloads where you can allocate enough output budget and monitor response metadata.

What should be recorded in future comparisons?

At minimum: max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible output length, artifact completeness, and runtime validation.

Final verdict

Conclusão prática: GLM-5.2 é atraente em custo e pode raciocinar bem, mas exige controle de orçamento de saída. Claude Fable 5 foi mais previsível para respostas curtas e para gerar um HTML completo.

GLM-5.2 против Claude Fable 5: лимит вывода, reasoning_tokens и коэффициент discount 0.8

Jenny Met — Mon, 06 Jul 2026 16:11:49 +0000

GLM-5.2 vs Claude Fable 5: главным фактором оказался лимит вывода

Это не универсальный рейтинг моделей. В этом тесте GLM-5.2 справлялась с задачами на рассуждение после увеличения бюджета вывода, но при низком max_tokens видимая часть ответа могла быть пустой. Claude Fable 5 чаще завершала ответ компактно и лучше справилась с длинным HTML-артефактом.

Почему этот тест важен

The test used the Crazyrouter OpenAI-compatible API rather than a chat UI. That matters because the result was not judged only by prose quality. Each response was checked with operational metadata:

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: glm-5.2, claude-fable-5
temperature: 0.2
Test date: 2026-07-06

Что проверялось

The benchmark deliberately mixed three task types:

Task	Purpose	Reference result
`MATH-003`	State-based expectation reasoning	Expected flips until HH = `6`
`PHYS-003`	Momentum plus energy accounting	`V = 3.0 m/s`, `x ≈ 0.148 m`
`CODE-003-ANIM`	Long runnable artifact generation	Complete 800x500 Canvas animation HTML

The first two tasks measured reasoning. The third task measured whether a model can produce a complete artifact, not merely a convincing partial code block.

Наблюдаемые результаты

Task	`glm-5.2`	`claude-fable-5`
Math, original budget	`finish_reason=length`, `completion_tokens=1601`, `reasoning_tokens=1600`, visible body empty	`finish_reason=stop`, complete and correct
Math, retest	Correct after `max_tokens=3200`	Retest not needed
Physics, original budget	`finish_reason=length`, visible body empty	Complete and correct
Physics, retest	Correct after `max_tokens=8000`	Retest not needed
Animation, original budget	Empty visible HTML at `max_tokens=3200`	Partial HTML, truncated
Animation, retest	Still truncated at `max_tokens=8000`	Complete HTML; browser validation passed

Стоимость и практическая выгода

На момент публикации pricing API Crazyrouter возвращает для glm-5.2 значение discount: 0.8. Поэтому модель выглядит очень конкурентной по цене, если в вашей интеграции есть контроль reasoning_tokens, finish_reason и достаточного max_tokens.

This is the practical tradeoff:

Workload	Better fit from this test
Short reasoning with enough output budget	GLM-5.2 can be a cost-effective option
Low-budget reasoning responses	Claude Fable 5 was steadier
Long single-file code generation	Claude Fable 5 was stronger in this run
Batch evaluations where metadata is logged	GLM-5.2 becomes easier to operate safely

Do not treat the 0.8 multiplier as a permanent universal price. It is a pricing-data snapshot from Crazyrouter at publication time and should be checked again before a large deployment.

Интеграционные заметки

Minimal request:

curl https://cn.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {
        "role": "user",
        "content": "Solve the HH expected-flips problem with state equations."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 3200
  }'

To compare Claude Fable 5, keep the same payload and change only the model:

{
  "model": "claude-fable-5"
}

For production-style evaluations, log this shape for every request:

{
  "model": "glm-5.2",
  "max_tokens": 3200,
  "finish_reason": "length",
  "completion_tokens": 3200,
  "reasoning_tokens": 3178,
  "visible_content_chars": 0,
  "html_closed": false,
  "browser_validation": "not_run_incomplete_html"
}

API endpoints should stay clean. Do not add UTM parameters to https://cn.crazyrouter.com/v1. Use tracking only on human-facing article or registration links.

Тот же OpenAI-compatible запрос можно запустить через Crazyrouter и проверить обе модели на своих задачах.

https://crazyrouter.com/register?utm_source=devto&utm_medium=article&utm_campaign=glm52_fable5_budget_cost_20260706&utm_content=devto_glm-52-vs-claude-fable-5-output-budget-cost-ru_20260706__bottom&utm_term=glm-5.2+claude+fable+5+benchmark

FAQ

Did GLM-5.2 fail the reasoning tasks?

Why not score HTTP 200 as success?

Because HTTP 200 only means the API call returned. A benchmark answer can still be unusable if finish_reason=length, visible content is empty, or generated code is incomplete.

Why was the animation task included?

Long code generation exposes a different failure mode. A model can write a convincing first half of a file and still fail if the HTML or JavaScript is cut off.

Is GLM-5.2 still worth testing?

Yes. The current 0.8 discount multiplier makes it attractive for workloads where you can allocate enough output budget and monitor response metadata.

What should be recorded in future comparisons?

At minimum: max_tokens, completion_tokens, reasoning_tokens, finish_reason, visible output length, artifact completeness, and runtime validation.

Final verdict

Практический вывод: GLM-5.2 интересна по стоимости и способна решать задачи, но требует внимательного контроля бюджета вывода. Claude Fable 5 оказалась стабильнее для коротких ответов и полного HTML-файла.