GLM-5.3 ने “thinking: disabled” फ्लैग को हटा दिया है, इसलिए कोई भी इंटीग्रेशन जो {"thinking":{"type":"disabled"}} पास करता था, वह अब रिस्पॉन्स के बजाय एरर देता है। इस बदलाव ने रातों-रात दर्जनों टेस्ट सूट्स को खराब कर दिया है और डेवलपर्स को अपने एप्लिकेशन को चालू रखने के लिए कोड की एक लाइन फिर से लिखने के लिए मजबूर कर दिया है।

यह बदलाव क्यों महत्वपूर्ण है

GLM-5.2 में, API उपयोगकर्ताओं को मामूली प्रॉम्प्ट्स के लिए थिंकिंग मोड बंद करने की अनुमति देता था। ऑटोमेशन स्क्रिप्ट्स, बैच-प्रोसेसिंग पाइपलाइन्स और लो-लेटेंसी बॉट्स में यह एक सामान्य पैटर्न था। GLM-5.3 ने इस फ्लैग को पूरी तरह से हटा दिया है और तीन एफर्ट लेवल—low, high और max—पेश किए हैं, जिसमें max डिफ़ॉल्ट है। नया मॉडल हमेशा एक रीजनिंग ट्रेस (reasoning trace) जेनरेट करता है; इसे अब पूरी तरह से बंद नहीं किया जा सकता।

क्या खराब हुआ और यह कैसे फैलता है

जब रिक्वेस्ट बॉडी में "type":"disabled" होता है, तो सर्वर पेलोड को रिजेक्ट कर देता है और एक सामान्य फेलियर रिस्पॉन्स देता है। इसमें कोई ऑथेंटिकेशन या सिंटैक्स एरर दिखाई नहीं देता, इसलिए समस्या को तब तक पहचानना मुश्किल हो सकता है जब तक कि पूरा रिग्रेशन रन फेल न हो जाए। क्योंकि कई कोडबेस में यह फ्लैग एक ही, दोबारा इस्तेमाल होने वाले हेल्पर फंक्शन में था, इसलिए इसका प्रभाव बड़े टेस्ट सूट्स और प्रोडक्शन एंडपॉइंट्स दोनों पर समान रूप से पड़ा।

सटीक कोड परिवर्तन

पुराने पेलोड को इससे बदलें:

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

GLM-5.3-संगत वर्ज़न से:

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

"type":"enabled" की (key) रीजनिंग इंजन को फिर से सक्रिय कर देती है, जबकि "effort":"low" नए मॉडल की अनुमति के अनुसार पुराने डिसेबल्ड मोड की गति की यथासंभव नकल करता है।

प्रदर्शन पर प्रभाव

लो-एफर्ट सेटिंग के साथ वही कोड-रिव्यू प्रॉम्प्ट्स चलाने पर ऐसे परिणाम मिलते हैं जो "पुरानी गति के करीब" हैं लेकिन बिल्कुल समान नहीं हैं। मॉडल अभी भी एक रीजनिंग ट्रेस जारी करता है, जिससे कुछ अतिरिक्त टोकन और मामूली लेटेंसी (latency) बढ़ जाती है। हाई-थ्रूपुट या लेटेंसी-क्रिटिकल वर्कलोड में, आपको यह पुष्टि करने के लिए अपने डेटा का बेंचमार्क करना चाहिए कि यह ओवरहेड स्वीकार्य है या नहीं।

लागत के बावजूद माइग्रेट क्यों करें

GLM-5.3 अपने पूर्ववर्ती की 744-बिलियन-पैरामीटर आर्किटेक्चर को बरकरार रखता है लेकिन कोडिंग और एजेंटिक (agentic) कार्यों पर फिर से ध्यान केंद्रित करता है। स्वतंत्र बेंचमार्क (Terminal-Bench 3.0) स्कोर में उल्लेखनीय उछाल दिखाते हैं, और आंतरिक परीक्षणों में कई फाइलों में लॉजिक एरर का बेहतर पता लगाने की सूचना मिली है। उन टीमों के लिए जो जटिल कोड विश्लेषण के लिए मॉडल पर निर्भर हैं, प्रदर्शन में होने वाला लाभ टोकन खपत में मामूली वृद्धि से कहीं अधिक हो सकता है।

वह समझौता जिसे आप नज़रअंदाज़ नहीं कर सकते

यदि किसी एप्लिकेशन को वास्तव में ज़ीरो-थिंकिंग रिस्पॉन्स की आवश्यकता है—जैसे कि एक शुद्ध टोकन-कम्प्लीशन सर्विस—तो अब GLM-5.3 में इसके लिए कोई नेटिव विकल्प नहीं है। डेवलपर्स को या तो अतिरिक्त रीजनिंग आउटपुट स्वीकार करना होगा या किसी अन्य मॉडल पर स्विच करना होगा जो अभी भी डिसेबल्ड मोड प्रदान करता है।

आगे क्या देखें

  • लेटेंसी मॉनिटरिंग: पेलोड परिवर्तन के बाद, रिग्रेशन का जल्दी पता लगाने के लिए रिस्पॉन्स टाइम और टोकन काउंट को ट्रैक करें।
  • एफर्ट ट्यूनिंग: कुछ वर्कलोड को बिना किसी बड़े नुकसान के “high” एफर्ट से लाभ मिल सकता है, इसलिए लो सेटिंग से आगे प्रयोग करें।
  • भविष्य के डिप्रिकेशन (deprecations): एक सिंगल फ्लैग को हटाने से संकेत मिलता है कि API में और अधिक एकीकरण (consolidations) हो सकते हैं; आगामी रिलीज़ नोट्स पर नज़र रखें।

निष्कर्ष: thinking पेलोड को {"type":"enabled","effort":"low"} में अपडेट करने से GLM-5.3 के साथ कम्पैटिबिलिटी बहाल हो जाती है। अपनी पाइपलाइनों में लेटेंसी और टोकन उपयोग को सत्यापित करें, और तय करें कि क्या बेहतर कोडिंग क्षमताएं अपरिहार्य रीजनिंग ट्रेस को उचित ठहराती हैं।

चर्चा और सामुदायिक सहायता GyaanSetu AI टेलीग्राम चैनल पर उपलब्ध है।