GLM 5.2 so với Opus
(techstackups.com)- Khi được giao tạo một game platform 3D WebGL thuần bằng cùng một prompt one-shot, Opus cho kết quả nhanh hơn và hoàn thiện hơn, còn GLM-5.2 có lợi thế về chi phí thấp và open-weight
- GLM-5.2 là mô hình open-weight giấy phép MIT của Z.ai với ngữ cảnh 1M token và mức suy luận High/Max, nhưng do chỉ hỗ trợ văn bản nên bị hạn chế trong việc tự kiểm chứng dựa trên hình ảnh
- Chi phí thử nghiệm thực tế là $5.39 với GLM-5.2 và khoảng $21.92 với Opus; thời gian build lần lượt là 1 giờ 10 phút 40 giây và 33 phút 30 giây, cho thấy sự đánh đổi giữa tốc độ và chi phí
- Sản phẩm của GLM-5.2 gặp các lỗi cơ bản như thiếu texture, spike không hoạt động, không có điều kiện chiến thắng và còn sót overlay debug; Opus sạch hơn nhưng vẫn còn va chạm hơi rộng ở bệ trên không và trigger chiến thắng ở quá xa
- Trong benchmark và các đánh giá bên ngoài, GLM-5.2 được xem là một mô hình open-weight mạnh, nhưng Opus vẫn dẫn trước trong nhiều tác vụ coding và agent; tiêu chí lựa chọn là chi phí, độ mở và khả năng đánh giá trực quan
Khác biệt lộ rõ trong cùng một bài toán
- GLM-5.2 là ví dụ mới cho thấy tiềm năng của mô hình mở, nhưng trong cùng một bài toán thực chiến, Claude Opus 4.8 cho ra kết quả nhanh hơn và chính xác hơn
- Bài test cho cả hai mô hình cùng một prompt one-shot, yêu cầu tạo game platform 3D cho trình duyệt bằng raw WebGL từ đầu, không dùng game engine hay thư viện dựng hình 3D như Three.js
- Cả hai kết quả và mã nguồn đều được công khai
- Cả hai game đều dùng asset miễn phí CC0 Kenney Platformer Kit
Đặc tính và cách tiếp cận của GLM-5.2
- GLM-5.2 là mô hình flagship mới nhất của Z.ai và được phát hành dưới dạng open-weight giấy phép MIT
- Có thể tải xuống để tự chạy hoặc gọi qua API của Z.ai
- Weight đã có trên Hugging Face và ModelScope, không bị giới hạn khu vực
- Có thể self-host cục bộ bằng các framework như vLLM, SGLang và Transformers
- Mô hình này hướng tới các tác vụ long-horizon như công việc agent coding nhiều bước kéo dài
- Cung cấp cửa sổ ngữ cảnh 1M token
- Có các mức suy luận High và Max; trong bài test dùng mức High
- Hạn chế mang tính quyết định là nó chỉ hỗ trợ văn bản
- GLM-5.2 không đọc được hình ảnh
- Với workflow cần trực tiếp kiểm tra screenshot hoặc sơ đồ, sẽ cần mô hình đa phương thức như Claude Opus
Giá và chi phí chạy thực tế
- Theo tài liệu của nhà cung cấp, giá trên mỗi 1M token của GLM-5.2 thấp hơn Opus
- Claude Opus 4.8: input $5, cache read $0.50, output $25
- GLM-5.2: input $1.4, cache read $0.26, output $4.4
- Tính theo output token, GLM-5.2 có giá chưa đến 1/5 của Opus
- Nhưng trong bài test tạo game thực tế, thời gian và chi phí lại đi theo hai hướng khác nhau
| Chỉ số | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| Thời gian build thực tế | 1 giờ 10 phút 40 giây | 33 phút 30 giây |
| Output token | 131,000 | 216,809 |
| Mức dùng ngữ cảnh tối đa | 16% của 1M | 19% của 1M |
| Lượt gọi công cụ | 128 | 153 |
| Chi phí | $5.39 thực tế bị tính phí | khoảng $21.92 ước tính |
- Opus hoàn thành trong khoảng một nửa thời gian, còn GLM-5.2 hoàn tất công việc với chi phí thấp hơn rất nhiều
Bài test: game platform 3D raw WebGL
- Bài toán này có cấu trúc phức tạp hơn nhiều so với việc tạo một landing page đơn giản
- Trình phân tích mô hình GLB
- Toán học ma trận và vector
- Shader GLSL
- Hoạt ảnh xương có skinning
- Vòng lặp fixed timestep
- Xử lý va chạm
- Camera bám theo
- Hai mô hình nhận cùng prompt, cùng asset, và chỉ có một lần thử duy nhất không gợi ý thêm
- Điều kiện hoàn thành gồm
- 3D engine và renderer dựa trên raw WebGL
- Loader cho nhân vật 3D và world model được cung cấp
- Di chuyển và nhảy của nhân vật có trọng lực và va chạm
- Camera bám theo và điều khiển bằng bàn phím
- Toàn bộ game có thể chạy trong trình duyệt bằng một lệnh duy nhất
- Cả hai mô hình đều tự triển khai đáng kể các thành phần như parser nhị phân GLB, toán học ma trận/quaternion, renderer WebGL2, shader skinning GLSL và va chạm AABB theo substep
- Nhật ký build cũng đã được công khai
Kết quả chơi thử và các lỗi còn lại
- Cả hai game đều có hình thức của một game platform 3D góc nhìn người thứ ba
- Di chuyển bằng WASD hoặc phím mũi tên
- Space để nhảy
- Shift để chạy
- Kéo chuột để xoay camera
- Con lăn để zoom
- Mục tiêu là thu thập coin, tránh spike và chạm cờ đích
- Nếu rơi khỏi bản đồ sẽ quay lại điểm bắt đầu
-
Kết quả của GLM-5.2
- Game do GLM-5.2 tạo ra nhìn chung có độ hoàn thiện còn thô
- Một số material của nhân vật bị thiếu, và nhân vật đi trong khi quay mặt ngược hướng di chuyển
- Bẫy spike không giết hoặc reset nhân vật, và chạm cờ cũng không kích hoạt điều kiện chiến thắng
- Khi camera di chuyển thì đầu nhân vật biến mất, và overlay debug vẫn còn hiện trên màn hình
- Phần đạp vào lò xo để bật sang nền tiếp theo hoạt động tốt
- Mô hình Kenney tham chiếu đến bảng màu dùng chung ở một file riêng, nhưng renderer của GLM-5.2 không tải file này nên bị thay bằng màu phẳng
-
Kết quả của Opus
- Game của Opus sạch hơn và hoạt động tốt hơn
- Camera và bộ điều khiển hoạt động, logic spike giết người chơi cũng chạy đúng
- Texture được áp đúng, hoạt ảnh mượt, và có thể chiến thắng khi chạm cờ
- Các lỗi còn lại gần với edge case hơn là lỗi chức năng nền tảng
- Nhân vật có thể đứng tạm thời trên không bên cạnh mép nền, do thời gian nới coyote-time cho phép nhảy ngay sau khi rời mép được đặt quá rộng
- Điều kiện chiến thắng có thể kích hoạt dù vẫn còn cách cờ khá xa
Khác biệt đa phương thức trong tự kiểm chứng
- Cả hai mô hình đều được yêu cầu xác minh kết quả trước khi kết thúc công việc
- Opus là mô hình đa phương thức nên sau khi render game, nó trực tiếp kiểm tra screenshot đã chụp
- Nó phát hiện dấu debug còn sót trên màn hình và xóa đi trước khi hoàn tất
- Ở cảnh cuối, nó kiểm tra các block, bậc thang, coin, gem, spike, cờ, nhân vật, HUD điểm số, ánh sáng và hình học
- GLM-5.2 không đọc được hình ảnh nên không thể trực tiếp xem screenshot
- Thay vào đó, nó dùng cách vòng vo là đọc dữ liệu pixel thô và kiểm tra xem màu sắc có gần với giá trị kỳ vọng hay không
- Nó kiểm tra trong ảnh lưu lại các điều kiện màu như grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black
- Cách này bỏ sót các vấn đề trên màn hình thực tế
- Nhân vật hiển thị màu xám và bị thiếu texture
- Overlay debug vẫn còn nằm trên màn hình
- Với các tác vụ mà đầu ra trực quan là quan trọng, kiểm chứng đa phương thức có khả năng hiểu hình ảnh tạo ra khác biệt chất lượng thực tế
Vị trí thể hiện qua benchmark
- Trong benchmark trên model card của Z.ai, GLM-5.2 thường đứng ngay sau các mô hình đóng hàng đầu, và ở một số benchmark suy luận còn vượt lên
- Các chỉ số chính như sau
- HLE: GLM-5.2 40.5, Opus 4.8 49.8
- HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
- AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
- IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
- SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
- NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
- ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
- SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
- MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
- Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
- Kết quả chạy độc lập của ArtificialAnalysis cũng đánh giá GLM-5.2 là một mô hình open-weight mạnh
- Điểm Intelligence Index v4.1 là 51
- Cao hơn MiniMax-M3 44, DeepSeek V4 Pro 44 và Kimi K2.6 43
- TerminalBench v2.1 là 78%, dùng harness khác với mức 81 hoặc 82.7 trong model card
- Output token mỗi tác vụ khoảng 43k, nhiều hơn mức 26k của GLM-5.1
- Diễn biến benchmark cũng tương tự bài test thực chiến
- GLM-5.2 thuộc nhóm dẫn đầu trong các mô hình open-weight và có năng lực cạnh tranh ở một số bài suy luận
- Opus dẫn trước ở nhiều benchmark về coding và agent
Phản ứng bên ngoài
- Simon Willison đánh giá GLM-5.2 là “có lẽ là LLM open-weight chỉ-văn-bản mạnh nhất”
- Trong bài test SVG của ông, GLM-5.2 tạo được một con bồ nông đi xe đạp với hoạt ảnh hoàn chỉnh và không bị lỗi
- Nhưng bài test con thú có túi đi scooter lại kém hơn GLM-5.1 trước đó, cho thấy hiệu năng chưa đồng đều
- Artificial Analysis đánh giá GLM-5.2 là mô hình open-weight dẫn đầu trong Intelligence Index của họ
- Họ xem đây là mô hình rẻ nhất ở cùng mặt bằng năng lực, nằm trên frontier về tỷ lệ chi phí/độ thông minh
- Tuy vậy, nó cũng được ghi nhận là mô hình tiêu tốn token mạnh, dùng khoảng 43k output token cho mỗi tác vụ
- Nathan Lambert cho rằng theo bảng xếp hạng LMArena, GLM-5.2 thậm chí có thể được xem là agent tốt hơn Gemini, và với một mô hình mở giấy phép MIT thì đây là một “serious accomplishment”
- Ông nhấn mạnh rằng các mô hình Mỹ hàng đầu vẫn dẫn trước tổng thể, nhưng các phòng thí nghiệm Trung Quốc đang đạt điểm số cao với ít compute hơn
Nên chọn mô hình nào
- GLM-5.2 là một mô hình open-weight có hiệu năng mạnh với chi phí chỉ bằng một phần của Opus
- Phù hợp khi chi phí và độ mở là quan trọng, và công việc chủ yếu xoay quanh văn bản và logic
- Weight có thể tải về sẽ không bị đột ngột ngừng cung cấp hoặc hạn chế như mô hình đóng
- Opus trong bài test cho kết quả nhanh hơn, sạch hơn và chính xác hơn
- Có thể trực tiếp nhìn và xác minh đầu ra trực quan
- Phù hợp hơn cho các tác vụ cần độ chính xác, policy, khả năng đánh giá trực quan và chấp nhận được chi phí cao hơn
- GLM-5.2 phù hợp không hẳn như mô hình chủ lực để thay thế Opus, mà gần hơn với một mô hình phụ trợ mạnh, rẻ và luôn có thể truy cập
1 bình luận
Ý kiến trên Hacker News
Thật sự tôi không hiểu vì sao one-shot prompting lại gây ồn ào lớn đến vậy
Theo đúng định nghĩa thì một prompt duy nhất không thể chứa hết độ phức tạp của một dự án phần mềm. Cuối cùng mô hình chỉ đưa ra kết quả bằng cách dựa vào mã có sẵn trong tập dữ liệu huấn luyện và tự đặt ra nhiều giả định
Tôi thà được thấy một coding agent bám chính xác theo các bước trong file kế hoạch, đồng thời tuân thủ guardrail của đặc tả đã được con người rà soát và các quy ước coding còn hơn. Cũng cần xác minh xem vòng lặp agent có hoàn thành mục tiêu do con người đặt ra mà không chệch khỏi guardrail hay không
Ngoài ra, một chỉ số có giá trị hơn nhiều là khả năng nắm bắt ngữ cảnh của ca sử dụng định xây dựng, tìm lỗi hoặc cơ hội cải thiện hiệu năng trong mã hiện có, rồi đề xuất refactor
Nó gần với việc xem đầu ra có nhất quán nội tại hay không hơn là một benchmark kiểm tra đầu ra có khớp đầu vào không. Nếu là game thì sẽ là kiểu xem nó có kết thúc khi đạt mục tiêu không, có chết khi chạm gai không, và khi di chuyển có phát sinh ca biên kỳ quặc nào không
Tuy vậy, tôi nghĩ đáng ra cũng nên dùng cùng một môi trường chạy và lặp lại thí nghiệm nhiều lần để xem độ phân tán của kết quả
Trước đây tôi hay trêu những kỹ sư thử một framework trên project rỗng theo README rồi kết luận “framework này là tốt nhất cho ứng dụng production 10 năm tuổi của chúng ta”. Tư duy greenfield vừa là lời giải cho mọi vấn đề, vừa là vấn đề của mọi lời giải
Năng lực one-shot cũng là một chỉ số tự đo lường quan trọng nên vẫn cần đo, nhưng phải nhắm vào codebase quy mô lớn đã ổn định
Lý do Claude Code và Opus được chú ý mạnh là vì môi trường thực thi đã được cải thiện, giúp chúng tự sửa được nhiều lỗi mà không cần đầu vào từ người dùng. Về dài hạn, có lẽ các cải tiến lớn nhất sắp tới sẽ nằm ở mức tự chủ theo nhiều giờ và khả năng tự chỉnh sửa
Việc tạo ra hàng triệu token chỉ từ vài token đầu vào theo tôi không truyền tải được nhiều ý nghĩa
Muốn đánh giá mô hình tốt hơn thì chỉ cần thêm yêu cầu vào tác vụ. Dù không phải ca sử dụng thực tế, tôi vẫn thấy đây là một cách hữu ích
Tất nhiên, nếu có kỹ sư phần mềm điều khiển thì mô hình có thể cho kết quả tốt hơn nhiều. Tùy kỹ sư mà cũng có thể tệ hơn
Kiểu chạy one-shot đơn lẻ như “đem cùng một one-shot prompt cho Claude Opus 4.8 đấu trực diện: tạo một game platform 3D bằng raw WebGL từ đầu” thì vừa không phải benchmark, vừa không đại diện cho cách dùng ngoài thực tế
Phần lớn việc dùng agent mang tính cộng tác, nên cần kiểm tra độ tin cậy như giao việc xong nó có hoàn thành mà không bịa kết quả test hay không, và khả năng điều khiển như nó có làm theo chỉ dẫn của tôi hay tự làm theo ý mình
Bài test này cho thấy cả hai mô hình có thể làm gì khi được giao một tác vụ one-shot vừa lâu vừa khó về mặt kỹ thuật
Những bài test theo kiểu xem xét cộng tác, giao việc, hoàn thành, test-driven development và khả năng điều khiển chắc chắn rất đáng thử trong tương lai
Nghĩ lại thì phần lớn công việc agent tôi làm đều là các sub-agent chạy bằng prompt riêng trong phiên chính. Những cái đó cũng có thể xem là phiên bản ngắn của công việc hoàn toàn tự chủ
Bài viết cũng có đề cập các nội dung đó, và bản thân nó không hề được định làm benchmark chính thức. Benchmark chính thức thì đã có quá nhiều rồi
Anthropic cứ liên tục trả về 529 Overloaded, nên hôm qua tôi đăng ký GLM 5.2 để dùng thử
Tôi khá thích nó, nhưng chỉ với một phiên duy nhất có 2 prompt ở chế độ xhigh của GLM 5.2 mà đã ăn 22% hạn mức gói lite trong cửa sổ reset 5 giờ
Kết quả làm tôi hài lòng và chất lượng cũng ổn. Tôi muốn dùng cả hai, nên sẽ rất hay nếu có gói thuê bao tích hợp cho phép dùng chung Anthropic và GLM
Cảm nhận của tôi sau khi dùng GLM 5.2 cho một vài project là nó mất khá lâu mới bắt đầu viết code, và tuyệt nhiên không phải mô hình nhanh
Nó đi lạc nhiều ở giai đoạn khám phá và lập kế hoạch rồi mới tự sửa lại, và không dễ điều khiển. Nó còn hallucinate cả những điều về sau chính nó cũng không làm theo. Dù vậy, chất lượng đầu ra khá tốt
Ví dụ, tôi đã tối ưu phần rendering trong một codebase Swift+Zig nhưng bị kẹt ở 5.000 mục dữ liệu. GLM 5.2 dành 20 phút để tạo benchmark và trích dữ liệu; tôi bực quá nên chặn quyền truy cập mọi công cụ ngoài editor rồi bỏ đi. Khoảng 30 phút sau quay lại, nó đã tối ưu xong 3 điểm nghẽn dựa trên benchmark tạo sẵn cùng vài “kết luận”, và còn nói rằng cần thêm dữ liệu vì không thể xác minh nghi ngờ của mình
Phần triển khai hoạt động tốt, đúng kiểu idiomatic và không xâm lấn. Tôi thậm chí có thể nói nó idiomatic hơn kết quả do GPT 5.5 tạo ra trên cùng repository. Tôi muốn dùng nó nhiều hơn, nhưng GPT thường hoàn thành cùng một yêu cầu nhanh hơn 5 lần
Nhờ GLM 5.2 mà tôi bắt đầu chuẩn bị cấu hình chạy song song nhiều tác vụ bên trong container cô lập và workspace JJ
Đó là bài toán chặn left-click trên thanh menu macOS, rồi khiến Ctrl+click hoặc right-click mở menu như left-click gốc nhưng chỉ hoạt động có điều kiện
Giữa phiên xử lý sự cố, tôi chuyển mô hình sang GLM-5.2, thậm chí không prompt lại mà thay ngay giữa lúc đang suy luận, và vài phút sau vấn đề được sửa xong. Tôi dùng nó từ quota thuê bao của OpenCode Go, mà những bài như vậy có thể đốt sạch hạn mức Opus trong cửa sổ 5 giờ hiện tại, thậm chí cả hạn mức tuần
Có thể dừng lại và chỉnh khi thấy mô hình đi chệch hướng hoặc phát hiện thứ gì đó tôi chưa nói ra. Hoặc cũng có thể học được vì sao nó đưa ra lựa chọn như vậy, để sau này đỡ phải thắc mắc
Cũng khá giống với trải nghiệm của tôi. Tôi đang dùng trên Pi; nó thông minh và đầu ra cũng tốt, nhưng quá trình để đi đến đó thì không hiệu quả lắm
Có đoạn viết rằng “GLM-5.2 không thể đọc hình ảnh nên vấn đề phát sinh ở đây. Vì nó không phải multimodal. Vì vậy, thay vì nhìn ảnh chụp màn hình, tôi đã dùng mẹo viết một script đọc dữ liệu pixel thô và kiểm tra xem màu sắc có ra gần như mong đợi hay không”, nhưng cách tốt hơn là dùng https://github.com/openbmb/MiniCPM-V
Nếu thật sự muốn, bạn cũng có thể để nó gọi Opus cho phần hình ảnh, và như vậy có lẽ vẫn tiết kiệm chi phí
Tôi đã đăng ký Ollama để thử nghiệm các mô hình mã nguồn mở
Trong 3 tháng qua thì chủ yếu vẫn là mức thử nghiệm và dùng thử liên tục, nhưng GLM là mô hình đầu tiên tôi dùng hằng ngày cho công việc lập trình thực tế cùng với Claude. Nó khá tốt đến mức ngày nào tôi cũng dùng hết hạn mức của Ollama
GLM dùng ít token hơn và cũng gọi công cụ ít hơn, nhưng lại mất hơn gấp đôi thời gian để hoàn tất
Nếu thời gian đó không nằm ở chính hoạt động của mô hình, thì nó đang bị tiêu tốn ở đâu?
Có phải từng lần gọi công cụ phức tạp hơn nên lâu hơn, hay là mô hình phải tính toán nhiều hơn trên mỗi token nên số token mỗi giây thấp hơn?
Ngoài ra, một số mô hình open-weight như GLM 5.2 hay DeepSeek v4 Pro có tốc độ sinh token chậm hơn hẳn, nên ảnh hưởng đến độ trễ cảm nhận được. Dù vậy, cũng khó gọi GLM 5.2 là một mô hình chậm; ví dụ như hiện tại trong Notion thì nó là một trong những mô hình nhanh nhất
Một khả năng khác là Opus dùng cách như Mixture of Experts, nên phần mô hình phải nạp vào bộ nhớ cùng lúc có thể nhỏ hơn GLM
Có một vấn đề lớn đang hạn chế thành công thực sự của GLM 5.2, đó là giá trị của gói đăng ký cho lập trình
Nếu chỉ nhìn giá API thì GLM 5.2 thắng các đối thủ. Nhưng dùng tính phí API cho công việc lập trình chủ yếu là các doanh nghiệp lớn, và với họ, những sản phẩm đăng ký được trợ giá mạnh ngày càng ít đi
Đồng thời, các công ty như vậy sẽ không để nhân viên dùng API của Trung Quốc
Với cá nhân và đội nhóm nhỏ, gói đăng ký lập trình của Z.ai kém hơn Anthropic và OpenAI. Có thể bạn sẽ có mức sử dụng tương tự Claude, nhưng Codex rõ ràng cho lượng sử dụng nhiều hơn so với số tiền phải trả
Có thể tranh luận về việc Z.ai đã bắt kịp GPT5.5 và Opus 4.8 đến đâu, nhưng nếu trong một thế giới mà mọi thứ đều cùng giá và tôi có thể tự do chọn, thì tôi sẽ không chọn GLM
Vì vậy, câu hỏi quan trọng là ở GLM 5.3 hay 6, sản phẩm của Z.ai sẽ tốt lên đến mức nào, và trong tương lai gần OpenAI với Anthropic sẽ siết chặt các sản phẩm hiện tại đến đâu
Xây dựng hạ tầng xoay quanh AI mà họ sẽ không thể bị tước mất bất cứ lúc nào có giá trị tức thì với các công ty như vậy. Những nước khác ngoài châu Âu còn nhạy cảm về giá hơn, và cũng không có cùng nỗi e ngại khi làm việc với doanh nghiệp Trung Quốc
Đồng thời, nếu “các công ty này sẽ không để nhân viên dùng API của Trung Quốc”, thì tôi tò mò Amazon Bedrock đang nhắm đến ai khi cung cấp GLM
Cá nhân có lẽ sẽ chọn các nhà cung cấp Mỹ rẻ hơn như DeepInfra. GLM có cache input là $0.18 cho mỗi 1 triệu token còn Opus là $0.50. Fireworks AI cũng là một lựa chọn
Nhân viên và sinh viên đã quen với việc lập trình bằng cách tiêu thụ số token trị giá hàng nghìn đô la trên các gói 20 hoặc 100 đô sẽ thúc đẩy chi tiêu ở cấp doanh nghiệp
Việc xuất hiện mô hình Trung Quốc có tính cạnh tranh sẽ không thay thế khoản chi đó, nhưng các mô hình mở được lưu trữ tại Mỹ hoặc EU thì có thể
Sự tồn tại của GLM 5.2 tạo ra một mức trần cho mức giá mà OpenAI và Anthropic có thể áp lên quyền truy cập API
Tôi đoán phần lớn công việc đang diễn ra trong gói lập trình
Tuy nhiên, việc các gói này quá hạn chế ngoài giới hạn sử dụng cũng khá khó chịu. Tôi hiểu, nhưng vẫn bất tiện. Trên thực tế, chỉ Anthropic và có lẽ cả Google là thật sự nghiêm ngặt
Anthropic từng khiến người ta e ngại bằng chính sách có thể tính phí lại theo mức giá API nếu họ cho rằng cách sử dụng không phù hợp với điều khoản dịch vụ. Có thể đó là nỗi lo không có cơ sở, nhưng tôi có cảm giác họ thực sự có thể làm vậy nên đã tránh dùng
Nhưng hạ tầng bên đó rõ ràng đang quá tải nên 100% yêu cầu chat 5.2 đều bị timeout. Khi hạ tầng bắt kịp hiệu năng của mô hình thì sau này tôi sẽ thử lại, rồi lúc đó mới đánh giá được liệu gói đăng ký có đáng giá hay không
Hôm nay tôi đã rất bất ngờ vì GLM-5.2 vượt xa GPT-5.5 về gu thẩm mỹ và các tác vụ UI
Tạm thời tôi vẫn sẽ giữ cấu hình Claude/Codex qua Conductor, nhưng vì mô hình này mà tôi đã thiết lập OpenCode và tải ứng dụng desktop xuống, rồi làm phần lớn công việc hôm nay ở đó
Khi đọc những câu như “GLM-5.2 rẻ hơn rất nhiều. Opus hoàn thành trong một nửa thời gian và cho ra một trò chơi gọn gàng hơn” thì tôi lập tức cảm nhận được đúng văn phong kiểu LLM
Có vẻ mọi mô hình đều đang hội tụ về kiểu viết này, và dù hiệu năng có tốt hơn thì phần đó cũng không thay đổi nhiều
Ngành viết kỹ thuật hiện đang chịu cú đánh rất lớn. Các công ty đòi hỏi nhiều việc hơn trong thời gian ngắn hơn, trong khi chất lượng giảm sút đáng kể, nên thời gian để trau chuốt chất lượng câu chữ trong bài viết hằng ngày ngày càng ít đi
Chúng tôi đang làm việc ngay ở tuyến đầu của sự thay đổi này nên chịu ảnh hưởng nặng nề nhất, nhưng đồng thời việc được thử nghiệm thay đổi sớm hơn cũng vừa kích thích vừa vô cùng bức bối