Kimi K3 so với Claude Opus 4.8: Thử nghiệm thực tế về toán, vật lý và lập trình cấp độ sau đại học

So sánh Kimi K3 với Claude Opus 4.8: thực đo toán, vật lý và lập trình ở mức sau đại học#

Ở các bài toán số học đơn giản, mọi mô hình lớn đều có thể cho ra câu trả lời đẹp. Thứ thực sự tạo ra khoảng cách thường là: phép suy diễn có kịp kết thúc trong ngân sách đầu ra hay không, ma trận và điều kiện biên có viết đúng không, chương trình sinh ra có thật sự thỏa mãn ngữ nghĩa đề bài hay không.

Lần này tôi nâng độ khó của đề bài lên mức đồ án tốt nghiệp đại học hoặc môn học cao học, rồi dùng cùng một bộ prompt để test kimi-k3 và claude-opus-4-8:

• Toán: phân phối dừng, thời gian chạm đầu tiên, moment bậc một và bậc hai của chuỗi Markov hữu hạn 3 trạng thái;
• Vật lý: dao động tử 2 bậc tự do với giảm chấn nối đất và giảm chấn ghép, tìm mode không giảm chấn và đáp ứng tần số phức;
• Lập trình: thuật toán lập lịch chính xác có bao đóng phụ thuộc, cửa sổ thời gian, năng lực mỗi ngày và hàm mục tiêu 3 tầng.

Kết luận trước:

• claude-opus-4-8 trả về đầy đủ trong ngân sách lần này cho cả 3 bài, và cả 3 lần finish_reason đều là stop;
• kimi-k3 bắt buộc phải đặt temperature thành 1, và với giới hạn 6000 completion token thì cả 3 bài đều kết thúc bằng finish_reason=length, đồng thời độ dài content hiển thị đều bằng 0;
• Câu trả lời toán và vật lý của Opus 4.8 đã qua kiểm tra số học độc lập;
• Mã lập lịch của Opus 4.8 đi qua 13 assertion do chính nó đi kèm, nhưng khi thêm một probe độc lập về “nhiệm vụ tiền đề phải hoàn thành trước”, tôi phát hiện nó chỉ đảm bảo các nhiệm vụ phụ thuộc được chọn cùng lúc, chứ không đảm bảo tác vụ trước nằm trước tác vụ sau;
• Độ trễ trung bình của các yêu cầu thành công lần này: Opus 4.8 khoảng 70.59 giây, Kimi K3 khoảng 225.47 giây. Khác biệt này chỉ phản ánh route và điều kiện prompt của lần chạy này, không thể coi trực tiếp là SLA dài hạn.

Môi trường test và giới hạn tham số#

Thời gian test là từ ngày 18 đến 19 tháng 7 năm 2026 theo giờ Bắc Kinh, trước hết xác nhận qua /v1/models rằng cả hai model ID đều hiển thị:

kimi-k3
claude-opus-4-8

Tất cả request đều đi qua OpenAI-compatible API của Crazyrouter:

POST https://cn.crazyrouter.com/v1/chat/completions

Điều kiện chung:

Cùng system prompt
Cùng đề bài người dùng
Không bật tool và không truy cập mạng

Tham số mô hình không thể hoàn toàn giống nhau, vì upstream có ràng buộc cứng với Kimi K3:

Lần đầu vô tình dùng temperature=0.1 để gọi Kimi K3, API trả về rất rõ:

Parameter temperature must be 1 for this model.

Vì vậy bài viết này ghi nhận giới hạn tham số đó như một факт test, chứ không che thất bại đi thành “mô hình không khả dụng”. Khi đem kết quả vào chọn mô hình cho production, cũng nên đưa năng lực tham số riêng của từng model vào tầng cấu hình, thay vì mặc định rằng mọi model đều chấp nhận cùng một bộ sampling parameter.

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

Dạng kết quả của Kimi ở cả 3 bài gần như giống hệt nhau: API trả về model name và usage, nhưng message.content không có đáp án cuối cùng nào để giao. Với các ứng dụng cần hiển thị kết quả trực tiếp cho người dùng hoặc đẩy sang compiler, điều này phải được xem là “nhiệm vụ chưa hoàn thành”, chứ không phải “mô hình đã trả lời đúng nhưng log không ghi lại”.

Bài toán toán học: thời gian chạm đầu tiên và phương sai của chuỗi Markov hữu hạn#

Đề bài dùng ma trận chuyển trạng thái:

trạng thái mục tiêu là 3, định nghĩa:

$\tau=\min\{n\ge 0:X_n=3\}。$

Đây không phải dạng bài chỉ cần thay xác suất vào công thức là xong; ít nhất phải xử lý phân phối dừng, ma trận con tạm thời, moment bậc một và bậc hai của thời gian chạm đầu tiên, và nêu rõ điều kiện biên ở trạng thái đích t_3=s_3=0.

Kết quả của Opus 4.8#

Mô hình cho phân phối dừng:

và kiểm tra theo từng thành phần rằng πP=π.

Với {1,2} là các trạng thái tạm thời, ta có:

Phương trình moment bậc một là:

nên:

Moment bậc hai dùng:

suy ra:

Tôi đã dùng Fraction để giải phương trình độc lập, và kết quả hoàn toàn khớp với Opus; thay t và s ngược lại vào hai phương trình first-step thì cũng đều đúng. Bài toán toán học được đánh giá là “qua hoàn toàn”.

Kết quả của Kimi K3#

Kimi K3 chạy với temperature=1 và max_tokens=6000 trong khoảng 235 giây, usage hiển thị completion_tokens=6000, reasoning_tokens=5997, finish_reason=length, còn content hiển thị thì rỗng.

Điều đó có nghĩa là trong lần chạy này, không thể dựa vào output của Kimi để biết nó có giải được bài Markov chain này hay không. Điều chắc chắn duy nhất là: với API, prompt và ngân sách hiện tại, nó không thu gọn được suy luận thành đáp án cuối cùng hiển thị được.

Bài toán vật lý: ma trận và đáp ứng tần số của dao động tử ghép có giảm chấn#

Bài thứ hai dùng hệ 2 bậc tự do với hai khối lượng:

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 và c2 là phần tử ghép giữa hai khối lượng, còn c1 và c3 là giảm chấn nối đất của từng nhánh. Đề yêu cầu trước tiên tìm mode riêng không giảm chấn, rồi tại ω=8 rad/s tìm biên độ phức, nên không thể gộp toàn bộ giảm chấn vào ma trận đường chéo một cách đơn giản.

Ma trận đúng#

Opus 4.8 viết:

Phương trình đặc trưng của hệ không giảm chấn cho hai tần số riêng:

Tỷ số mode tương ứng X2/X1 là 0.6173 và -2.4298, lần lượt biểu thị mode cùng pha và ngược pha.

Đáp ứng phức tại ω=8#

Ma trận độ cứng động phức:

Tính số phức độc lập cho ra:

Kiểm tra năng lượng của Opus cũng qua: công suất tiêu tán trung bình khoảng 1.2574 W, khớp với công suất đầu vào của ngoại lực trong sai số làm tròn. Nó cũng giải thích đúng rằng: nếu nhầm c2 thành giảm chấn nối đất thì phần tử giảm chấn ngoài đường chéo C12=C21=-0.8 sẽ bị triệt về 0 sai, dẫn đến truyền năng lượng và kết quả pha đều thay đổi.

Kết quả của Kimi K3#

Kimi K3 sau khoảng 204.6 giây lại cạn mất 6000 token, vẫn là finish_reason=length và content rỗng. Vì không có phương trình và con số cuối cùng, không thể đánh giá mô hình hóa vật lý của nó có đúng hay không; lần này chỉ có thể ghi là “hết ngân sách mà chưa giao được”.

Bài toán lập trình: bao đóng phụ thuộc, cửa sổ thời gian và lập lịch chính xác#

Bài lập trình yêu cầu cài đặt:

schedule_jobs(jobs, dependencies, capacity_by_day)

Mỗi nhiệm vụ có duration, release_day, deadline_day và value; nhiệm vụ phải được sắp xếp hoàn chỉnh trong một ngày, mỗi ngày có giới hạn năng lực, còn phụ thuộc biểu thị rằng nhiệm vụ tiền đề phải hoàn thành trước khi nhiệm vụ hậu đề bắt đầu. Mục tiêu được so sánh theo thứ tự sau:

1. Tổng giá trị lớn nhất;
2. Tổng thời lượng nhỏ hơn;
3. Danh sách ID đã sắp xếp theo thứ tự từ điển nhỏ hơn.

Bài này khó hơn kiểu “knapsack + sort” thông thường, vì phải đồng thời xử lý:

• bao đóng phụ thuộc trực tiếp và gián tiếp;
• phụ thuộc chưa biết và phát hiện chu trình;
• năng lực từng ngày và cửa sổ thời gian của nhiệm vụ;
• đóng gói chính xác cho mọi tập con khả thi;
• tie-break nhiều tầng.

Hiệu quả triển khai của Opus 4.8#

Opus đưa ra một triển khai đầy đủ bằng bitmask + DFS có nhớ, kèm 13 assertion. Tôi tách hai code block Python ra và chạy bằng Python 3.11; toàn bộ assertion do mô hình tự viết đều qua:

all assertions passed

Nó bao phủ đúng các trường hợp input rỗng, năng lực không đủ, phụ thuộc trực tiếp/gián tiếp, phụ thuộc không tồn tại, phụ thuộc vòng và so sánh mục tiêu ba tầng.

Tuy nhiên, bộ assertion tự kèm không kiểm tra “nhiệm vụ tiền đề phải hoàn thành trước nhiệm vụ hậu đề”. Tôi bổ sung một probe độc lập:

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})

Theo ngữ nghĩa đúng, A là nhiệm vụ tiền đề của B, nhưng nó chỉ có thể xếp vào ngày 1, còn B chỉ có thể xếp vào ngày 0, nên hai nhiệm vụ này không nên cùng được chọn. Thế nhưng code của mô hình lại trả về:

selected_ids: ['A', 'B']
assignment: {'A': 1, 'B': 0}

Điều này cho thấy implementation chỉ kiểm tra “khi chọn B thì phải kéo theo chọn A”, chứ không kiểm tra:

assignment[A] < assignment[B]

Vì vậy bài lập trình không thể được kết luận là qua hoàn toàn. Đánh giá chính xác hơn là: khung thuật toán và kiểm tra input khá đầy đủ, logic đóng gói tài nguyên chạy được, nhưng ngữ nghĩa nghiệp vụ cốt lõi lại bỏ sót ràng buộc thứ tự thời gian của phụ thuộc. Với hệ thống lập lịch production, đây là lỗi đúng/sai bắt buộc phải sửa, không phải lỗi định dạng.

Kết quả của Kimi K3#

Kimi K3 chạy khoảng 236.4 giây rồi kết thúc bằng length, toàn bộ 6000 token bị tiêu hết cho reasoning, content rỗng, và không giao được code thực thi.

Độ trễ, ngân sách đầu ra và đáp án hiển thị#

Độ trễ trung bình của 3 bài:

Kimi K3:       (235.420 + 204.568 + 236.434) / 3 = 225.474 秒
Claude Opus:   (57.870 + 64.966 + 88.934) / 3 = 70.590 秒

Ba lần usage của Kimi đều rất sát nhau:

completion_tokens = 6000
reasoning_tokens  = 5997
content.length    = 0
finish_reason     = length

Bộ dữ liệu này cho thấy bên gọi không thể chỉ nhìn HTTP status code và trường model. Ít nhất cũng phải ghi nhận đồng thời:

choice.finish_reason
response.usage
response.choices[0].message.content

Nếu finish_reason là length, thì dù HTTP vẫn trả về 200, hệ thống cũng nên đi vào quy trình retry, degrade hoặc review thủ công.

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

Dưới đây là cách gọi tối thiểu bằng OpenAI Python SDK. Khi test thực tế, nên dùng đầy đủ đề bài như trong bài viết và tham số khớp với từng model:

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": "严格基准测试，只给可验证结论。"},
        {"role": "user", "content": "替换为完整研究生级测试题"},
    ],
)

print(response.model)
print(response.choices[0].finish_reason)
print(response.usage)
print(response.choices[0].message.content)

Khi gọi Kimi K3, cần đổi temperature thành 1, đồng thời dành đủ thời gian cho reasoning dài hơn; lần này dù đã cho tới 6000 token vẫn không nhận được đáp án hiển thị.

Khuyến nghị chọn mô hình cho production#

Nên ưu tiên thử Claude Opus 4.8 khi#

• Cần một request duy nhất cho ra đầy đủ phép suy diễn hoặc toàn bộ code;
• Tác vụ có chứa ma trận, điều kiện biên và kiểm tra số học;
• Bài toán nhạy hơn với độ trễ hiển thị đầu tiên và khả năng giao nộp;
• Có thể gắn thêm test độc lập và kiểm tra ngữ nghĩa cho code sinh ra.

Nên tiếp tục đánh giá Kimi K3 khi#

• Có thể chấp nhận độ trễ ở mức vài phút;
• Tầng gọi có thể xử lý tham số sampling riêng của model;
• Cho phép tách bài toán, tăng ngân sách hoặc dùng workflow bất đồng bộ;
• Tập trung vào quá trình reasoning hơn là đòi văn bản cuối cùng ngay trong một request.

Nhưng với dữ liệu của lần này, Kimi K3 không thể được mô tả là “đã giải xong 3 bài nhưng output bị log che mất”. Quan sát thực tế là cả 3 lần đều không có đáp án cuối cùng hiển thị.

FAQ#

1. Vì sao lần này được xem là mức đại học tốt nghiệp hoặc sau đại học?#

Bài toán toán yêu cầu phân phối dừng, ma trận cơ bản và moment bậc hai của thời gian chạm đầu tiên; bài vật lý yêu cầu mô hình ma trận, phân tích mode, đáp ứng tần số phức và cân bằng năng lượng; bài lập trình yêu cầu bao đóng phụ thuộc, đóng gói chính xác, phát hiện chu trình và tối ưu đa mục tiêu. Những phần này lần lượt tương ứng với độ khó bài tập tổng hợp của các môn xác suất/quá trình ngẫu nhiên, cơ học cổ điển và dao động, thuật toán và thiết kế hệ thống.

2. Kimi K3 có phải không hỗ trợ temperature=0.1 không?#

Trong lần test này, API yêu cầu rõ ràng temperature của Kimi K3 phải là 1. Đây là ràng buộc tham số của model tại route hiện tại; phía gọi nên đọc lỗi và retry theo cấu hình riêng của model.

3. length của Kimi K3 có thể chứng minh nó chắc chắn không làm được các bài này không?#

Không. Nó chỉ cho thấy rằng với prompt, giới hạn đầu ra và điều kiện route của lần chạy này, mô hình không tạo ra được câu trả lời cuối cùng có thể nhìn thấy. Không có đáp án hiển thị thì không thể chấm đúng sai, nhưng cũng không thể từ đó suy ra rằng ở mọi thiết lập nó đều không giải được.

4. Câu trả lời lập trình của Opus 4.8 có thể đem dùng trực tiếp trong production không?#

Không thể dùng trực tiếp. Mặc dù toàn bộ assertion do nó tự kèm đều qua, probe độc lập phát hiện nó bỏ sót ràng buộc thứ tự thời gian của phụ thuộc. Code sinh ra cần có test về ngữ nghĩa nghiệp vụ, chứ không chỉ chạy bộ test mô hình tự viết.

5. Vì sao bài vật lý của Opus 4.8 cần kiểm tra tiêu tán năng lượng?#

Vì phần tử giảm chấn ghép rất dễ bị viết sai ở phần tử ngoài đường chéo. Việc công suất đầu vào khớp với công suất tiêu tán là một bằng chứng độc lập cho thấy biên độ phức, pha và ma trận giảm chấn đều đúng cùng lúc.

6. Độ trễ của lần này có thể dùng làm cam kết hiệu năng không?#

Không. Kênh upstream, cache, mức độ song song và retry đều có thể làm thay đổi độ trễ. Trong môi trường production, ít nhất cần lấy mẫu lặp lại, thống kê P50, P95, P99, tỷ lệ bị cắt cụt và chi phí cho mỗi tác vụ thành công.

Kết luận cuối cùng#

Điều thực sự được so sánh trong lần này không phải là một “bảng xếp hạng trí tuệ” tách rời điều kiện gọi, mà là hai kiểu hành vi giao nộp hoàn toàn khác nhau:

1. Claude Opus 4.8 trong 3 tác vụ mức sau đại học lần này đều cho ra đáp án hiển thị được, và phần suy diễn toán học lẫn vật lý đã qua kiểm tra độc lập;
2. Khung code của Opus khá mạnh, nhưng vẫn bỏ sót ràng buộc quan trọng là nhiệm vụ phụ thuộc phải hoàn thành theo đúng thứ tự thời gian;
3. Kimi K3 trong điều kiện bắt buộc temperature=1 đã dùng hết 6000 token cho cả 3 bài, finish_reason=length, không có đáp án hiển thị;
4. Nếu mục tiêu business là lấy ngay trong một request toàn bộ suy diễn toán học, tính toán vật lý hoặc code chạy được, thì trong cửa sổ test hiện tại Opus 4.8 có khả năng giao nộp tốt hơn rõ rệt;
5. Dù chọn model nào, cũng phải đưa finish_reason, usage, kiểm tra số học độc lập và test ngữ nghĩa code vào quy trình nghiệm thu.

Tệp để tái hiện thí nghiệm:

• Script test: kimi_k3_vs_opus48_graduate_test.py
• Kết quả Kimi: kimi-k3-graduate-results.json
• Kết quả so sánh: kimi-k3-vs-opus48-graduate-results.json

Bài đọc thêm:

• Kimi K3 对比 GPT-5.6-SOL：数学、物理与编程高难度实测
• Kimi K3 对比 Claude Fable 5：复杂推理实测
• Crazyrouter 注册