GLM-5.3 loại bỏ cờ “thinking: disabled”, vì vậy bất kỳ tích hợp nào trước đây truyền {"thinking":{"type":"disabled"}} giờ đây sẽ trả về lỗi thay vì phản hồi. Thay đổi này đã làm hỏng hàng chục bộ kiểm thử chỉ sau một đêm và buộc các nhà phát triển phải viết lại một dòng mã duy nhất để duy trì hoạt động của ứng dụng.

Tại sao sự thay đổi này lại quan trọng

Trong GLM-5.2, API cho phép người gọi tắt chế độ suy nghĩ (thinking mode) đối với các câu lệnh (prompts) đơn giản. Tùy chọn đó là một mô hình phổ biến trong các kịch bản tự động hóa, quy trình xử lý hàng loạt và các bot có độ trễ thấp. GLM-5.3 đã loại bỏ hoàn toàn cờ này và giới thiệu ba mức độ nỗ lực (effort levels)—low, high và max—với max là mặc định. Mô hình mới luôn tạo ra một vết suy luận (reasoning trace); nó không còn có thể bị tắt hoàn toàn được nữa.

Điều gì đã bị hỏng và cách nó lan rộng

Khi thân yêu cầu (request body) chứa "type":"disabled", máy chủ sẽ từ chối payload và trả về một phản hồi lỗi chung chung. Không có lỗi xác thực hay lỗi cú pháp nào xuất hiện, vì vậy vấn đề có thể khó phát hiện cho đến khi một đợt chạy kiểm thử hồi quy (regression run) đầy đủ bị thất bại. Vì cờ này nằm trong một hàm bổ trợ (helper function) duy nhất và có thể tái sử dụng trong nhiều cơ sở mã (codebases), tác động của nó đã lan rộng qua cả các bộ kiểm thử lớn lẫn các điểm cuối (endpoints) đang chạy trên môi trường production.

Thay đổi mã chính xác

Thay thế payload cũ:

extra_body = {"thinking": {"type": "disabled"}}

bằng phiên bản tương thích với GLM-5.3:

extra_body = {"thinking": {"type": "enabled", "effort": "low"}}

Khóa "type":"enabled" sẽ kích hoạt lại công cụ suy luận, trong khi "effort":"low" mô phỏng tốc độ của chế độ "disabled" trước đây sát nhất có thể trong phạm vi cho phép của mô hình mới.

Các tác động về hiệu suất

Chạy cùng các câu lệnh đánh giá mã (code-review prompts) với cài đặt mức nỗ lực thấp (low-effort) sẽ cho kết quả “gần với tốc độ cũ” nhưng không hoàn toàn giống hệt. Mô hình vẫn phát ra một vết suy luận, điều này làm tăng thêm một vài token và gây ra một sự gia tăng độ trễ nhẹ. Trong các khối lượng công việc có thông lượng cao hoặc yêu cầu khắt khe về độ trễ, bạn nên thực hiện đo kiểm (benchmark) trên dữ liệu của chính mình để xác nhận rằng mức chi phí phát sinh (overhead) là có thể chấp nhận được.

Tại sao nên chuyển đổi bất chấp chi phí

GLM-5.3 vẫn giữ kiến trúc 744 tỷ tham số của phiên bản tiền nhiệm nhưng tập trung lại vào các tác vụ lập trình và tác vụ đại lý (agentic tasks). Các bài kiểm tra độc lập (Terminal-Bench 3.0) cho thấy sự nhảy vọt đáng kể về điểm số, và các thử nghiệm nội bộ báo cáo khả năng phát hiện lỗi logic tốt hơn trên nhiều tệp tin. Đối với các đội ngũ dựa vào mô hình để phân tích mã phức tạp, lợi ích về hiệu suất có thể lớn hơn sự gia tăng nhỏ trong việc tiêu thụ token.

Sự đánh đổi mà bạn không thể bỏ qua

Nếu một ứng dụng thực sự cần các phản hồi không suy luận—ví dụ: một dịch vụ hoàn thiện token thuần túy—thì hiện tại nó không còn tùy chọn gốc nào trong GLM-5.3. Các nhà phát triển phải chấp nhận đầu ra suy luận bổ sung hoặc chuyển sang một mô hình khác vẫn còn cung cấp chế độ "disabled".

Những điều cần lưu ý tiếp theo

  • Giám sát độ trễ: Sau khi thay đổi payload, hãy theo dõi thời gian phản hồi và số lượng token để phát hiện sớm các lỗi hồi quy.
  • Tinh chỉnh mức nỗ lực: Một số khối lượng công việc có thể hưởng lợi từ mức nỗ lực “high” mà không phải chịu hình phạt quá lớn, vì vậy hãy thử nghiệm vượt ra ngoài cài đặt "low".
  • Các thay đổi loại bỏ trong tương lai: Việc loại bỏ một cờ duy nhất cho thấy API có thể sẽ có thêm nhiều sự hợp nhất khác; hãy chú ý đến các ghi chú phát hành sắp tới.

Tóm lại: Cập nhật payload thinking thành {"type":"enabled","effort":"low"} sẽ khôi phục khả năng tương thích với GLM-5.3. Hãy xác minh độ trễ và mức sử dụng token trong các pipeline của bạn, và quyết định xem liệu khả năng lập trình được cải thiện có xứng đáng với vết suy luận không thể tránh khỏi hay không.

Thảo luận và hỗ trợ cộng đồng có sẵn tại kênh Telegram GyaanSetu AI.