Kimi K3 so với GPT-5.6-SOL: Thử nghiệm độ khó cao về toán, vật lý và lập trình

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ả#

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#

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à:

1. 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.
2. 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.
3. 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ị.
4. 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.