GLM-5.3 پرچم "thinking: disabled" را حذف کرده است، بنابراین هر یکپارچه‌سازی که از {"thinking":{"type":"disabled"}} استفاده می‌کرد، اکنون به جای پاسخ، با خطا مواجه می‌شود. این تغییر ده‌ها مجموعه تست را یک‌شبه از کار انداخت و توسعه‌دهندگان را مجبور می‌کند برای حفظ پایداری برنامه‌های خود، تنها یک خط کد را بازنویسی کنند.

چرا این تغییر اهمیت دارد

در GLM-5.2، رابط برنامه‌نویسی (API) به فراخوان‌کنندگان اجازه می‌داد حالت تفکر (thinking mode) را برای درخواست‌های ساده خاموش کنند. این گزینه الگوی رایجی در اسکریپت‌های خودکارسازی، خط لوله‌های پردازش دسته‌ای (batch-processing pipelines) و ربات‌های با تأخیر کم (low-latency bots) بود. GLM-5.3 این پرچم را به‌طور کامل حذف کرد و سه سطح تلاش (effort levels) معرفی کرد: low، high و max که حالت max پیش‌فرض است. مدل جدید همیشه یک ردپای استدلال (reasoning trace) تولید می‌کند؛ دیگر نمی‌توان آن را به‌طور کامل خاموش کرد.

چه چیزی از کار افتاد و چگونه منتشر می‌شود

وقتی بدنه درخواست شامل "type":"disabled" باشد، سرور محتوا (payload) را رد کرده و یک پاسخ خطای عمومی برمی‌گرداند. هیچ خطای احراز هویت یا خطای سینتکسی (syntax error) ظاهر نمی‌شود، بنابراین تشخیص مشکل دشوار است مگر اینکه یک اجرای کاملِ رگرسیون (regression run) با شکست مواجه شود. از آنجایی که این پرچم در بسیاری از پایگاه‌های کد در یک تابع کمکی (helper function) واحد و قابل استفاده مجدد قرار داشت، تأثیر آن هم در مجموعه‌ تست‌های بزرگ و هم در نقاط پایانی (endpoints) عملیاتی پخش شد.

تغییر دقیق کد

محتوای قدیمی را جایگزین کنید:

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

با نسخه سازگار با GLM-5.3:

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

کلید "type":"enabled" موتور استدلال را دوباره فعال می‌کند، در حالی که "effort":"low" تا حد امکان سرعت حالت غیرفعال قبلی را شبیه‌سازی می‌کند.

پیامدهای عملکردی

اجرای همان درخواست‌های بازبینی کد (code-review) با تنظیمات low-effort، نتایجی را ارائه می‌دهد که «به سرعت قدیمی نزدیک است» اما دقیقاً همان نیست. مدل همچنان یک ردپای استدلال تولید می‌کند که باعث اضافه شدن چند توکن اضافی و افزایش اندک تأخیر (latency) می‌شود. در حجم کاری‌های با توان عملیاتی بالا یا حساس به تأخیر، باید داده‌های خود را بنچمارک کنید تا مطمئن شوید این سربار (overhead) قابل قبول است.

چرا با وجود هزینه، مهاجرت کنیم

GLM-5.3 معماری ۷۴۴ میلیارد پارامتری پیشین خود را حفظ کرده اما تمرکز خود را بر وظایف کدنویسی و عامل‌محور (agentic tasks) معطوف کرده است. بنچمارک‌های مستقل (Terminal-Bench 3.0) جهش قابل توجهی در امتیازات نشان می‌دهند و تست‌های داخلی، تشخیص بهتر خطاهای منطقی را در چندین فایل گزارش کرده‌اند. برای تیم‌هایی که برای تحلیل پیچیده کد به این مدل متکی هستند، بهبود عملکرد می‌تواند بر افزایش اندک مصرف توکن غلبه کند.

مصالحه‌ای که نمی‌توانید نادیده بگیرید

اگر یک برنامه واقعاً به پاسخ‌های بدون تفکر نیاز دارد (مثلاً یک سرویس صرفاً برای تکمیل توکن)، اکنون در GLM-5.3 هیچ گزینه بومی برای آن وجود ندارد. توسعه‌دهندگان یا باید خروجی استدلال اضافی را بپذیرند یا به مدل دیگری سوئیچ کنند که هنوز حالت غیرفعال (disabled mode) را ارائه می‌دهد.

آنچه باید در ادامه زیر نظر داشت

  • مانیتورینگ تأخیر: پس از تغییر محتوا، زمان پاسخ‌دهی و تعداد توکن‌ها را دنبال کنید تا رگرسیون‌ها را زود تشخیص دهید.
  • تنظیم سطح تلاش (Effort tuning): برخی از حجم‌های کاری ممکن است از سطح "high" بدون جریمه کامل بهره‌مند شوند، بنابراین فراتر از تنظیمات low را آزمایش کنید.
  • حذف‌های احتمالی در آینده: حذف یک پرچم واحد نشان می‌دهد که API ممکن است شاهد ادغام‌های بیشتری باشد؛ اخبار مربوط به نسخه‌های جدید (release notes) را دنبال کنید.

خلاصه کلام: به‌روزرسانی محتوای thinking به {"type":"enabled","effort":"low"} سازگاری با GLM-5.3 را بازیابی می‌کند. تأخیر و میزان مصرف توکن را در خط لوله‌های خود بررسی کنید و تصمیم بگیرید که آیا قابلیت‌های بهبودیافته کدنویسی، ردپای استدلال اجتناب‌ناپذیر را توجیه می‌کند یا خیر.

بحث و پشتیبانی جامعه در کانال تلگرام GyaanSetu AI در دسترس است.