GLM-5.3 “thinking: disabled” flag-ஐ நீக்கியுள்ளது, எனவே {"thinking":{"type":"disabled"}} என்பதைப் பயன்படுத்தும் எந்தவொரு ஒருங்கிணைப்பும் (integration) இப்போது பதிலுக்குப் பதிலாகப் பிழையைத் (error) திருப்பித் தருகிறது. இந்த மாற்றம் ஒரே இரவில் டஜன் கணக்கான சோதனைத் தொகுப்புகளை (test suites) பாதித்துள்ளதுடன், டெவலப்பர்கள் தங்கள் பயன்பாடுகளைத் தொடர்ந்து இயக்க ஒரு வரியைக் குறியீட்டை (code) மாற்ற வேண்டிய கட்டாயத்திற்குத் தள்ளுகிறது.

இந்த மாற்றம் ஏன் முக்கியமானது

GLM-5.2 இல், சாதாரணமான தூண்டுதல்களுக்கு (prompts) thinking mode-ஐ அணைக்க API அனுமதித்தது. தானியங்கி ஸ்கிரிப்ட்கள் (automation scripts), தொகுதி செயலாக்கப் குழாய்கள் (batch-processing pipelines) மற்றும் குறைந்த தாமதப் (low-latency) பாட்கள் ஆகியவற்றில் இந்த விருப்பம் ஒரு பொதுவான முறையாக இருந்தது. GLM-5.3 அந்த flag-ஐ முற்றிலுமாக நீக்கிவிட்டு, low, high மற்றும் max ஆகிய மூன்று முயற்சி நிலைகளை (effort levels) அறிமுகப்படுத்தியுள்ளது—இதில் max என்பது இயல்புநிலை (default) ஆகும். புதிய மாடல் எப்போதும் ஒரு reasoning trace-ஐ உருவாக்கும்; அதை இனி முழுமையாகத் தவிர்க்க முடியாது.

என்ன பாதிப்பு ஏற்பட்டது மற்றும் அது எவ்வாறு பரவுகிறது

கோரிக்கை உடல் (request body) "type":"disabled" என்பதைக் கொண்டிருக்கும்போது, சர்வர் அந்த payload-ஐ நிராகரித்து, ஒரு பொதுவான தோல்விப் பதிலைத் (generic failure response) திருப்பித் தருகிறது. இதில் அங்கீகாரம் (authentication) அல்லது தொடரியல் (syntax) பிழைகள் எதுவும் தெரியாது என்பதால், முழுமையான regression run தோல்வியடையும் வரை இந்தப் பிரச்சனையைத் தெரிந்துகொள்வது கடினமாக இருக்கலாம். பல குறியீட்டுத் தொகுப்புகளில் (codebases) இந்த flag ஒரு தனிப்பட்ட, மீண்டும் பயன்படுத்தக்கூடிய உதவியாளர் செயல்பாட்டில் (reusable helper function) இருந்ததால், இதன் தாக்கம் பெரிய சோதனைத் தொகுப்புகள் மற்றும் production endpoints ஆகிய இரண்டிலும் பரவியது.

துல்லியமான குறியீடு மாற்றம்

பழைய payload-ஐ மாற்றவும்:

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

GLM-5.3-க்கு இணக்கமான பதிப்பிற்கு மாற்றவும்:

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

"type":"enabled" என்ற சாவி (key) reasoning engine-ஐ மீண்டும் செயல்படுத்துகிறது, அதே சமயம் "effort":"low" என்பது புதிய மாடல் அனுமதிக்கும் அளவுக்குப் பழைய disabled mode-இன் வேகத்தைப் பிரதிபலிக்கிறது.

செயல்திறன் தாக்கங்கள்

low-effort அமைப்பைப் பயன்படுத்தி அதே code-review தூண்டுதல்களை இயக்குவது "பழைய வேகத்திற்கு நெருக்கமான" முடிவுகளைத் தருகிறது, ஆனால் அவை முற்றிலும் சமமானவை அல்ல. மாடல் இன்னும் ஒரு reasoning trace-ஐ வெளியிடுகிறது, இது சில கூடுதல் டோக்கன்களை (tokens) மற்றும் சிறிய தாமதத்தை (latency bump) ஏற்படுத்துகிறது. அதிகத் திறன் (high-throughput) அல்லது தாமதத்திற்கு முக்கியமான (latency-critical) வேலைப்பளுக்களில், இந்த கூடுதல் சுமை ஏற்றுக்கொள்ளத்தக்கதா என்பதை உறுதிப்படுத்த உங்கள் சொந்தத் தரவை பெஞ்ச்மார்க் (benchmark) செய்து பார்க்க வேண்டும்.

செலவு இருந்தபோதிலும் ஏன் மாற வேண்டும்

GLM-5.3 அதன் முந்தைய மாடலின் 744-பில்லியன் அளவுருக்களடங்கிய (parameter) கட்டமைப்பைப் பராமரிக்கிறது, ஆனால் coding மற்றும் agentic பணிகளில் அதிக கவனம் செலுத்துகிறது. சுயாதீன பெஞ்ச்மார்க்குகள் (Terminal-Bench 3.0) மதிப்பெண்களில் குறிப்பிடத்தக்க உயர்வைக் காட்டுகின்றன, மேலும் உள் சோதனைகள் பல கோப்புகளில் உள்ள தர்க்கப் பிழைகளை (logic errors) சிறப்பாகக் கண்டறிவதாகத் தெரிவித்துள்ளன. சிக்கலான குறியீடு பகுப்பாய்விற்கு (code analysis) இந்த மாடலை நம்பியிருக்கும் குழுக்களுக்கு, டோக்கன் நுகர்வு அதிகரிப்பை விட இந்த செயல்திறன் ஆதாயம் அதிகமாக இருக்கும்.

நீங்கள் தவிர்க்க முடியாத சமநிலை (trade-off)

ஒரு பயன்பாட்டிற்குத் தொடர்ச்சியாக zero-thinking பதில்கள் தேவைப்பட்டால்—உதாரணமாக, ஒரு தூய டோக்கன்-முழுமையாக்கல் சேவை (pure token-completion service)—GLM-5.3 இல் இப்போது அதற்கான இயல்பான விருப்பம் இல்லை. டெவலப்பர்கள் கூடுதல் reasoning வெளியீட்டை ஏற்க வேண்டும் அல்லது இன்னும் disabled mode-ஐ வழங்கும் வேறு ஒரு மாடலுக்கு மாற வேண்டும்.

அடுத்து கவனிக்க வேண்டியவை

  • தாமதத்தைக் கண்காணித்தல் (Latency monitoring): payload மாற்றத்திற்குப் பிறகு, பின்னடைவுகளை (regressions) முன்கூட்டியே கண்டறிய பதிலளிக்கும் நேரம் மற்றும் டோக்கன் எண்ணிக்கையைக் கண்காணிக்கவும்.
  • Effort tuning: சில வேலைப்பளுக்கள் முழுமையான பாதிப்பு இன்றி “high” effort மூலம் பயனடையலாம், எனவே low அமைப்பிற்கு அப்பால் பரிசோதனை செய்து பார்க்கவும்.
  • எதிர்கால நீக்கங்கள் (Future deprecations): ஒரு flag நீக்கப்பட்டிருப்பது, API இன்னும் பல ஒருங்கிணைப்புகளைக் (consolidations) காணக்கூடும் என்பதைக் குறிக்கிறது; வரவிருக்கும் release notes-களைக் கவனித்துக் கொண்டே இருங்கள்.

சுருக்கமாக: thinking payload-ஐ {"type":"enabled","effort":"low"} எனப் புதுப்பிப்பது GLM-5.3 உடன் இணக்கத்தன்மையை மீட்டெடுக்கிறது. உங்கள் குழாய்களில் (pipelines) தாமதம் மற்றும் டோக்கன் பயன்பாட்டைச் சரிபார்க்கவும், மேலும் மேம்படுத்தப்பட்ட குறியீட்டுத் திறன்கள் தவிர்க்க முடியாத reasoning trace-ஐ நியாயப்படுத்துகிறதா என்று முடிவு செய்யவும்.

விவாதம் மற்றும் சமூக ஆதரவு GyaanSetu AI Telegram சேனலில் கிடைக்கிறது.