So sánh Kimi K3.1 Pro và Claude Fable 5.2 trên cùng 19 câu hỏi: năng lực hòa nhau, hóa đơn chênh 3,3 lần

Mình ngồi đọc bảng xếp hạng gần một tiếng, rồi nhận ra không có con số nào trả lời được câu mình cần: việc này giao cho model nào thì đỡ phải sửa lại. Nên mình bỏ nửa ngày, dựng một bộ 19 câu, chạy cả hai model trên cùng một endpoint, cùng một máy, chỉ đổi chuỗi model.

Kết quả là 18 so với 17. Nhưng điểm không phải chỗ đáng nói. Bảy nhóm, năm nhóm hòa tuyệt đối; hai câu bị trượt đều là lỗi thao tác, không phải lỗi hiểu. Thứ thực sự khác nhau nằm ở cấu trúc token, và đó mới là chỗ quyết định hóa đơn của bạn.

Bài này viết theo hướng làm lại được: điều kiện, bộ câu hỏi, cách chấm, rồi kết quả. Cuối bài có ba bước để bạn tự đo trong hai mươi phút.

Điều kiện cố định trước khi chạy

Mình chấm bằng script vì một lý do rất thực dụng: nếu tự đọc rồi tự cho điểm, câu trả lời nào mình thấy hay sẽ được điểm cao hơn. Mỗi câu có một điều kiện đạt kiểm tra được bằng máy — chạy bộ test ẩn, parse JSON rồi so trường và kiểu dữ liệu, so chuỗi chính xác, đếm số dòng bảng. Phần giải thích của model không được tính điểm, chỉ tính thứ nộp ra cuối cùng.

19 câu gồm những gì

• Sửa code (3). Một hàm parse duration có ba lỗi cùng lúc: đầu vào sai không trả None, chuỗi thiếu đơn vị ở cuối, đơn vị bị lặp. Một hàm phân trang lệch một đơn vị ở biên. Một phép so sánh thời gian nổ khi gặp datetime aware.
• Viết từ đầu (3). LRU cache, gộp log, token bucket. Cả ba đều có bộ test ẩn do mình viết.
• Bố trí công cụ (3). Tra thời tiết, tìm trong tài liệu, chạy SQL. Mỗi câu phải chọn đúng công cụ và đúng tham số.
• Hỏi đáp repo (3). Đưa vào ba file, hỏi những câu buộc phải đọc chéo mới trả lời được.
• Tuân thủ hướng dẫn (3). JSON thuần, không bọc code block; một đoạn 140–160 ký tự với ba điểm bán hàng bắt buộc và bốn từ bị cấm; một bảng ba dòng hai cột.
• Chống gây nhiễu (2). Một câu khẳng định sai về list trong Python; một câu xin thông số của một model không tồn tại.
• Ngữ cảnh dài (2). Khóa giấu ở dòng 287 trong file log 400 dòng; hằng số LAST_RETRY = 43 nằm gần cuối module 800 dòng.

Kết quả

Sáu câu code của hai nhóm đầu, cả hai model đều qua ngay vòng đầu, test ẩn không trượt câu nào. Code của Fable ngắn hơn khoảng ba mươi phần trăm, và ở câu token bucket nó viết thêm chú thích về ngữ nghĩa thời gian — test vẫn qua.

Hỏi đáp repo và ngữ cảnh dài sạch. Ở câu model không tồn tại, cả hai đều không bịa thông số; Fable từ chối rồi dán thêm một bảng giá của model cũ, có ghi là tham khảo và chưa kiểm chứng — mình vẫn tính là đạt, chỉ ghi lại chỗ đó.

Hai câu bị trượt, và vì sao đừng đọc thành "yếu hơn"

Câu SQL. "Tính tổng tiền đơn hàng tháng trước." Kimi gọi search_docs và đi tìm trong tài liệu. Fable gọi run_sql nhưng câu lệnh truy vấn information_schema chứ không phải bảng đơn hàng. Cả hai sai, sai theo hai kiểu khác nhau — nghĩa là đây không phải phép so sánh hai trình độ, mà là hai chỗ hỏng khác nhau của cùng một kỹ năng.

Câu viết. Khung 140–160 ký tự, ba điểm bán hàng bắt buộc, bốn từ bị cấm. Lần này Kimi vượt khung nên bị tính là trượt; Fable qua. Nhưng chính câu này ở lần chạy thử trước, Kimi viết 155 ký tự và qua. Vì vậy mình đọc đây là dao động đầu ra, không phải giới hạn năng lực, và không lấy nó làm kết luận.

Cả hai kiểu trượt đều không tạo ra lỗi ở production. Chúng tạo ra việc phải làm lại.

Chỗ tiền thực sự đi: cấu trúc token

Đây là phần mình muốn bạn nhớ nhất.

84% đầu ra của Kimi là suy luận. Tiền của nó đi vào chỗ "nghĩ", không đi vào chỗ "viết". Fable không có token suy luận, nên mỗi token bạn trả tiền đều là token đọc được.

Đổi cách tính sang phần chữ đọc được thì kết luận đảo chiều: Kimi khoảng $63,3 cho một triệu token chữ, Fable khoảng $40,0. Model đắt gấp bốn lần về giá niêm yết lại rẻ hơn nếu bạn chỉ tính phần đọc được — vì không có phần nào bị giấu đi.

Hình dạng hai bên ngược nhau hẳn: Kimi vào ít, ra nhiều, nghĩ nhiều, tổng thời gian dài; Fable vào nhiều, ra toàn chữ, nghĩ bằng không, tổng thời gian ngắn. Việc của bạn nặng ở đầu nào thì đáp án nghiêng về bên đó.

Ngữ cảnh dài: đạt, nhưng chưa chạm trần

Hai câu vật liệu: tìm khóa ở dòng 287 trong log 400 dòng, tìm hằng số ở gần cuối module 800 dòng. Cả hai model tìm đúng: KX9-2077 và 43, đầu ra chỉ vài token.

Nhưng vật liệu chỉ khoảng 14 nghìn token. Kimi công bố cửa sổ 1.048.576 token, trang sản phẩm của Fable 5.2 không ghi con số nào. Nghĩa là hai câu này chỉ nói được một điều: ở mức 14 nghìn token, cả hai không đọc sót. Nó không nói gì về khả năng "một triệu token". Muốn kiểm tra trần thì phải dựng đầu vào sát trần, lần này mình không làm.

Bốn cái bẫy chỉ lộ ra khi tích hợp

Phần này không liên quan đến việc chọn ai, mà đến việc bạn gắn nó vào hệ thống thì có nổ hay không. Mình thử luôn trên sáu model trong cùng một buổi.

temperature không phải tham số dùng chung. Kimi trả 400 khi gửi 0.7, và thông báo lỗi không nêu tên trường nào. gpt-6.1-terra bắt buộc phải bằng 1. Tuyến Claude nhận cả 2 rồi lặng lẽ bỏ qua. Gemini trả 429 khi gửi 5, trông y như bị giới hạn tần suất. DeepSeek trả 400 rõ ràng. Sáu model, năm kiểu phản ứng.

200 mà thân bài rỗng. Đặt max_tokens 1200, Kimi trả 200, finish_reason là length, nội dung 0 ký tự, 1197 token dồn hết vào suy luận. Điều kiện kiểm tra phải là finish_reason cộng độ dài nội dung, không phải mã trạng thái.

Đầu ra có cấu trúc cũng có phương ngữ riêng. Tuyến Claude không nhận json_object, trả 400, phải đổi sang json_schema; các nhà còn lại nhận json_object.

Gọi công cụ không phải mặc định. gpt-6.1-terra ba lần trả "dịch vụ tạm thời không khả dụng". Gemini buộc phải đặt tool_choice: required; để auto thì bốn trong năm lần trả thân bài rỗng kèm content_filter.

Chọn theo việc, không theo điểm

Hóa đơn: vì sao 3,3 lần chứ không phải 4

Giá niêm yết chênh bốn lần, nhưng hóa đơn chỉ chênh 3,3 lần, vì lượng token chạy ngược chiều nhau: Fable vào nhiều hơn 33% và đắt gấp bốn ở đầu vào, trong khi đầu ra của nó không có token suy luận nên chỉ đắt hơn khoảng 2,3 lần.

Ba mức tải điển hình theo giá niêm yết: bot chăm sóc khách hàng 100 nghìn lượt (800 vào / 300 ra) khoảng $460 so với $1.840; xử lý 1.000 tài liệu (8k vào / 1,5k ra) khoảng $31 so với $124; trợ lý code cho một lập trình viên mỗi tháng (2M vào / 400k ra) khoảng $8 so với $32.

Một endpoint cho cả hai model

Mình không tạo hai tài khoản. Cả hai model nằm sau một endpoint tương thích OpenAI của Crazyrouter, cùng một khóa, cùng một định dạng request; đổi model chỉ là đổi một trường trong body.

https://api.crazyrouter.com/v1

Danh sách model đang mở và định dạng request nằm trong tài liệu: https://docs.crazyrouter.com/llms.txt

Với cách chạy này, việc so sánh mới có nghĩa: giữ nguyên mọi thứ trừ model, nên chênh lệch đo được mới quy về model chứ không quy về SDK, về khóa, hay về việc bên này bị giới hạn tần suất còn bên kia thì không.

Giới hạn, và cách bạn tự kiểm trong hai mươi phút

19 câu, hai model, một ngày. Vậy là đủ để thấy hướng, không đủ để kết luận. Ba thứ mình chưa đo: ngữ cảnh dài hơn, gọi công cụ nhiều lượt, và giá của Fable 5.2 ngoài mức $8/$40 cùng giá đọc cache $0,20.

Nếu muốn số của chính bạn, ba bước:

1. Lấy câu bạn hỏi nhiều nhất, hỏi mười lần, ghi lại trung vị và lần chậm nhất. Con số đó quan trọng hơn mọi bảng xếp hạng.
2. Lấy một bài thật sắp đăng, để model viết theo đúng quy định của nền tảng bạn đăng, rồi đếm số chỗ bạn phải sửa. Đây là phép đo sát công việc nhất.
3. Đặt max_tokens ở hai mức, mỗi mức chạy ba lần, đếm xem bao nhiêu lần finish_reason là length. Chỗ này hay bị bỏ qua nhất, và nó là nguồn của những lần "200 mà rỗng".

Ba bước chưa tới hai mươi phút. Số bạn tự đo sẽ đáng tin hơn bài này.