Model chạy trăm vòng không bỏ cuộc — đáng thử?
GLM-5.1 tự nhận sai, đổi chiến thuật qua hàng trăm vòng lặp. MIT license, benchmark ấn tượng — nhưng cái giá thật sự là gì?
Bụi WireGiả sử bạn giao một bài toán khó cho junior dev...
Bạn brief rõ ràng, junior ngồi code 2 tiếng, rồi quay lại nói: "Em thử 3 cách rồi, không được anh/chị ơi." Bực không? Hơi bực. Nhưng ít nhất bạn biết giới hạn.
Giờ hình dung một junior khác. Cũng bài toán đó, nhưng bạn này ngồi lì 12 tiếng, thử 200 cách khác nhau, tự nhận ra ngõ cụt, tự xoay chiến thuật — rồi cuối cùng submit một bản chạy được. Ấn tượng? Chắc chắn. Nhưng câu hỏi đầu tiên của mình là: hóa đơn cloud tháng này bao nhiêu?
Đó đại khái là câu chuyện của GLM-5.1 — model mới từ Zhipu AI (Trung Quốc), vừa release dưới MIT license, được thiết kế đặc biệt cho các tác vụ coding dài hơi, phức tạp.
Khoan — chuyện không đơn giản như benchmark đẹp
GLM-5.1 đạt kết quả vượt GPT-5.4 và Claude Opus 4.6 trên SWE-Bench Pro — một benchmark chuyên đo khả năng giải quyết lỗi phần mềm thực tế. Nghe hoành tráng.
Nhưng đây là phần mà nhiều người đọc headline sẽ bỏ qua: trên các bài test về reasoning và kiến thức tổng quát, GLM-5.1 thua rõ so với model của Google và OpenAI. Chính Zhipu AI cũng thừa nhận đây chỉ là "bước đầu tiên."
Dịch sang tiếng dev: model này như một VĐV marathon — không nhanh nhất trên đường sprint 100m, nhưng ở km thứ 35 khi đối thủ đã kiệt sức, nó vẫn còn chiến thuật dự phòng. Điểm mạnh cốt lõi không phải "thông minh hơn" mà là bền hơn — biết tự đánh giá lại chiến thuật khi bí, thay vì lặp đi lặp lại cùng một cách tiếp cận thất bại.
Zhipu AI demo một kịch bản: tối ưu vector database để tăng throughput mà không mất accuracy. Với 50 vòng thử tiêu chuẩn, Claude Opus 4.6 đạt 3.547 queries/giây (theo số liệu của Zhipu AI). GLM-5.1 được cho chạy không giới hạn vòng — và nó tự quyết định khi nào submit, khi nào đổi hướng.
Lưu ý quan trọng: tất cả demo đều do Zhipu AI tự chạy. Chưa có đánh giá độc lập nào xác nhận.
Hai kịch bản thực tế — khi nào model "trâu bò" thắng model "nhanh nhẹn"
Kịch bản 1: Team backend đang refactor monolith
Giả sử team bạn 4 người, đang tách một service xử lý đơn hàng ra khỏi monolith Rails. Bug xuất hiện ở những chỗ không ai ngờ — race condition khi hai service cùng ghi vào shared database. Kiểu task này, model thông thường thử 3–5 approach rồi đứng hình. Một model biết tự nhận "approach này không triển vọng, thử hướng khác" có thể là trợ thủ đắc lực — đặc biệt khi chạy qua đêm, sáng ra review kết quả.
Kịch bản 2: Tối ưu pipeline ML inference
Bạn cần squeeze thêm throughput từ serving layer mà không đổi hardware. Đây là bài toán có hàng chục biến: batch size, quantization level, thread pool config... Model thử-sai kiên nhẫn qua hàng trăm tổ hợp, tự ghi nhận cái nào đã fail và vì sao, rõ ràng có lợi thế hơn model "thử 5 lần rồi kết luận."
Bẫy mà mình thấy từ xa: "cứ để nó chạy"
Mình hình dung thế này: bạn thấy GLM-5.1 chạy 200 vòng vẫn chưa xong, nghĩ "kệ, để nó tự xử lý, mai review." Sáng hôm sau mở lên thấy 847 tool calls, code đã bị sửa theo 14 hướng khác nhau, và cái commit cuối cùng... hoạt động được, nhưng không ai hiểu vì sao.
Đây là mặt trái của persistence không có guardrail. Khi model biết tự xoay chiến thuật, bạn cần đặt rào:
- Giới hạn số vòng lặp (budget cap) — không phải vì model dở, mà vì bạn cần kiểm soát chi phí và review được output
- Checkpoint sau mỗi N vòng — yêu cầu model tóm tắt: "đã thử gì, fail vì đâu, hướng tiếp theo là gì"
- Diff review bắt buộc — đừng merge code mà model tự iterate 200 lần mà không ai đọc
Bài học cốt lõi từ agent orchestration (như mình từng chia sẻ ở các bài trước): autonomy mà không có observability thì chỉ là chaos có license MIT.
Thử ngay chiều nay — 3 bước đánh giá GLM-5.1
Model đã public, MIT license, nên bạn hoàn toàn có thể test:
Bước 1: Đọc technical report từ Zhipu AI — đặc biệt phần limitations mà họ tự khai. Đây là model hiếm hoi mà nhà phát triển nói thẳng "cái gì chưa tốt."
Bước 2: Chuẩn bị một task coding thật từ repo của team bạn — đừng dùng toy example. Lý tưởng nhất là một bug đã fix xong, để bạn có ground truth so sánh.
Bước 3: Chạy song song GLM-5.1 và model bạn đang dùng (Claude, GPT, hay Llama) trên cùng task đó. So sánh:
- Số vòng lặp trước khi ra kết quả
- Chất lượng code output (có readable không, có test không)
- Token cost / compute time
Nếu GLM-5.1 cho kết quả tốt hơn trên task dài hơi nhưng kém trên task ngắn — đó đúng là tradeoff mà Zhipu AI mô tả, và bạn có data thật để quyết định khi nào dùng model nào.
Open-weight, MIT license — và điều đó quan trọng thế nào
MIT license nghĩa là bạn có thể self-host, fine-tune, thậm chí thương mại hóa. Trong bối cảnh các model mạnh nhất thường đóng sau API có giá, đây là điểm cộng lớn.
Nhưng "open-weight" không đồng nghĩa "dễ chạy." Bạn vẫn cần infrastructure đủ mạnh để serve model cỡ này. Nếu team bạn đã quen với Ollama hay vLLM để self-host, thì đáng thử. Nếu chưa, chi phí setup ban đầu có thể vượt quá giá trị nhận được — ít nhất là cho đến khi community tối ưu xong.
Một takeaway duy nhất
GLM-5.1 không phải model "giỏi nhất" — và Zhipu AI cũng không claim vậy. Nó là model dai nhất, được thiết kế cho những task mà sự kiên nhẫn quan trọng hơn sự brilliance. Nếu workflow của bạn có những bài toán mà developer cũng phải ngồi cả ngày thử đi thử lại — đây có thể là công cụ đáng đưa vào shortlist.
Còn nếu bạn chỉ cần model trả lời nhanh một câu hỏi — thì đây như thuê VĐV marathon đi giao hàng same-day. Được, nhưng overkill.
---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng