Sau một thời gian vận hành mô hình thai-chat (qwen38) trên máy của đội, câu hỏi cần được trả lời bằng số liệu là "nó có đủ tốt để thay thế z.ai không". Câu trả lời không có số liệu thì không có giá trị, nên chúng tôi đã tổ chức bộ kiểm tra đầy đủ 50 trường hợp trong 5 danh mục, chạy song song cả hai hệ thống, rồi cho mô hình chấm điểm mà không biết câu nào đến từ ai.

Phương pháp kiểm tra

  • Phía bomLLM: mô hình thai-chat qua llm.siam2r.com (router LiteLLM trên máy của chúng tôi)
  • Phía cloud: glm-4.5-flash trực tiếp qua API của z.ai (tắt thinking, max_tokens 2000 theo ngân sách)
  • 5 danh mục, mỗi danh mục 10 trường hợp: LINE Q&A tiếng Thái, tóm tắt tín hiệu (RAGSA), phân loại danh mục, dịch thuật, và các edge case với định dạng nghiêm ngặt
  • Người chấm chính: mô hình qwen38 chấm điểm 1-10 cho mỗi trường hợp, và có Gemini 2.5 Flash làm người chấm chéo (cross-grader) trong 18 trường hợp còn hạn ngạch

Kết quả tổng hợp

Danh mục bomLLM z.ai Tỉ lệ
LINE Q&A (Thái) 8,93 6,33 1,41
Tóm tắt tín hiệu RAGSA 8,53 5,80 1,47
Phân loại danh mục 1,00 (độ chính xác) 1,00 Hòa
Dịch thuật 9,63 8,50 1,13
Edge case (JSON nghiêm ngặt) 8,10 8,47 0,96
Tổng 50 trường hợp 7,24 6,02 1,20

Về tốc độ, khoảng cách còn lớn hơn: bomLLM p50 = 5,19 giây (p95 = 19,9) trong khi z.ai p50 = 35,1 giây (p95 = 85,6) — nhanh hơn khoảng 7 lần tại giá trị trung vị. Tỷ lệ lỗi của bomLLM là 2/50 trường hợp (cả hai đều là định dạng nghiêm ngặt với thời gian chạy vượt quá 30 giây).

Những điều cần trung thực với bản thân

Benchmark này có những điểm cần đọc kỹ trước khi dùng để ra quyết định lớn:

  1. Người chấm và người thi cùng dòng — qwen38 chấm câu trả lời của qwen38 thì tất nhiên có lợi. Con số subset mà Gemini tự chấm giảm còn tỉ lệ 1,28, vẫn thắng nhưng không áp đảo như 1,44
  2. Prompt kiểm tra ngắn (~310 tokens) — Công việc thực tế gửi context dài hàng nghìn tokens là chuyện khác. Chúng tôi đã gặp trường hợp thực tế prompt 7.000 tokens khiến máy local chậm vượt quá ngưỡng 90 giây của EA, buộc phải quay lại dùng cloud (đọc bài viết về prompt 6.928 tokens để tham khảo)
  3. Edge case là điểm yếu thực sự — Trường hợp JSON nghiêm ngặt và pha trộn ngôn ngữ là danh mục duy nhất thua (0,96). Công việc định dạng cố định nên được route sang fallback

Kết luận cho đội của chúng tôi

Đối với các tác vụ chat tiếng Thái, tóm tắt tín hiệu và dịch thuật — bomLLM trên máy của chúng tôi vượt trội rõ ràng cả về chất lượng lẫn tốc độ, mà không có chi phí theo token. Còn đối với công việc prompt dài quá 3-4K tokens hoặc định dạng nghiêm ngặt không được sai, con đường an toàn nhất hiện nay là cloud + fallback, chuyển đổi theo loại công việc — đây chính là kiến trúc chúng tôi đã thiết lập trên router.

Quyết định di chuyển hệ thống thực tế, tôi luôn là người chốt — benchmark chỉ có nhiệm vụ đưa ra số liệu thực tế để thấy rõ, chứ không phải thay bạn nhấn nút.