DeepSeek ने V4 Pro general-availability (GA) मॉडेल रिलीज केले आहे. सुरुवातीच्या मोजमापांनुसार, preview build च्या तुलनेत हे मॉडेल reasoning-token चा वापर १८% ते ६२% ने कमी करते. जे लोक प्रति टोकन पैसे देतात त्यांच्यासाठी हे महत्त्वाचे आहे: आता तेच प्रॉम्प्ट्स (prompts) वापरून तितकेच परिणाम मिळवता येतात, पण त्यासाठी खर्च लक्षणीयरीत्या कमी होतो.

या तुलनेची गरज का भासली

GA रिलीज कोणत्याही ब्लॉग पोस्ट किंवा changelog शिवाय आले, त्यामुळे डेव्हलपर्सना स्वतःहून त्यातील फरक शोधून घ्यावे लागले. एका कम्युनिटी टेस्टमध्ये दोन्ही व्हर्जनवर सारखीच कामे करून पाहिली आणि त्यातून सर्वात मोठा बदल समोर आला—उत्तर देण्यापूर्वी मॉडेल "विचार" (thinking) करण्यासाठी वापरत असलेल्या टोकन्समध्ये मोठी घट झाली आहे. साध्या माहितीच्या शोधासाठी (trivial look-ups) GA मॉडेलने ६२% कमी reasoning tokens वापरले; तर अधिक जटिल प्रश्नांसाठी ही घट १८% होती.

टोकन कार्यक्षमता आणि तिचा प्रभाव

एका सामान्य extraction workflow मध्ये, preview build ने प्रॉम्प्टमधून काही ठराविक माहिती काढण्यासाठी १५९ reasoning tokens खर्च केले होते. "thinking" फीचर बंद करून GA build वापरल्यास हा आकडा केवळ ४० टोकन्सपर्यंत खाली आला. metered plans वापरणाऱ्या युजर्ससाठी, विशेषतः मोठ्या प्रमाणावर (at scale) काम करताना, ही बचत थेट कमी बिलाच्या स्वरूपात दिसून येते.

JSON extraction: एक सुप्त अडचण

जेव्हा "thinking" मोड सुरू असतो, तेव्हा दोन्ही builds मध्ये अडचण येते: ते JSON schema चेक पास करतात पण चुकीची संख्यात्मक मूल्ये (numeric values) टाकतात. केवळ GA व्हर्जनमध्ये जेव्हा "thinking" बंद असते, तेव्हाच अचूक JSON मिळते. ज्या टीम्सना structured output हवे आहे, त्यांनी extraction कामांसाठी thinking flag बंद केला पाहिजे, अन्यथा त्यांना syntactically योग्य पण संख्यात्मकदृष्ट्या चुकीचा डेटा मिळू शकतो.

नकार देण्याच्या पद्धतीत झालेला बदल

Preview मॉडेल ज्या प्रश्नाचे उत्तर देता येणार नाही असे त्याला वाटले, त्या प्रश्नाला "मला माहित नाही" (I do not know) असे उत्तर देऊन नकार देऊ शकत होते. GA मॉडेल आता असे करत नाही. त्याऐवजी, ते उत्तर न देताच आपला टोकन बजेट संपवते किंवा स्वतःहून चुकीचे उत्तर (fabricate) तयार करते. या बदलामुळे टोकन कार्यक्षमता सुधारली असली तरी, अज्ञात विषयांवर मॉडेलने चुकीची माहिती (hallucinating) देऊ नये यासाठी असलेली सुरक्षा यंत्रणा (safety net) निघून गेली आहे.

विश्वासार्हतेत वाढ

Preview build मध्ये एक धोकादायक लूप होता—जो मर्यादित "thinking" बजेटमुळे सक्रिय व्हायचा—त्यामुळे मॉडेल ८,१९२-टोकन विंडो भरेपर्यंत तोच मजकूर पुन्हा पुन्हा लिहू शकत असे. GA रिलीजने हा बग (bug) फिक्स केला आहे, ज्यामुळे पूर्वी होणारी अनावश्यक पुनरावृत्ती थांबली आहे, ज्यामुळे पूर्वी रिक्वेस्ट विंडो संपण्याचा आणि खर्च वाढण्याचा धोका होता.

युजर्सनी कोणत्या गोष्टींकडे लक्ष द्यावे

  • कमी टोकन वापरासाठी GA build वापरा. कामाच्या जटिलतेनुसार टोकनमधील ही घट दिसून येते.
  • कोणत्याही JSON किंवा structured-data extraction साठी “thinking” बंद ठेवा. यामुळे अचूक मूल्ये मिळतात आणि टोकनचा वापरही कमी राहतो.
  • इन-बिल्ट नकार देण्याच्या (refusals) क्षमतेवर अवलंबून राहू नका. जर प्रॉम्प्टमध्ये पडताळणी न करता येणाऱ्या डेटाची मागणी केली असेल, तर GA मॉडेल तरीही उत्तर देऊ शकते, त्यामुळे पुढील पडताळणी (downstream validation) करणे आवश्यक आहे.
  • पीक-अवर (peak-hour) बिलिंगवर लक्ष ठेवा. नवीन किंमत नियमांमुळे, ट्रॅफिक जास्त असलेल्या काळात होणारा टोकन वापर पूर्वीपेक्षा एकूण खर्चावर अधिक परिणाम करू शकतो.

थोडक्यात सांगायचे तर

DeepSeek चे V4 Pro GA मॉडेल स्पष्ट कार्यक्षमता प्रदान करते—६२% पर्यंत कमी reasoning tokens—आणि एका महत्त्वाच्या पुनरावृत्तीच्या (repetition) बगलावर उपाय करते. तथापि, स्पष्ट नकार देण्याच्या प्रतिसादांचा अभाव आणि अचूक JSON आउटपुटसाठी 'thinking' बंद करण्याची गरज या नवीन गोष्टी विचारात घेणे आवश्यक आहे. ज्या टीम्स त्यांच्या पाइपलाइनमध्ये (pipelines) हे बदल करतील, त्या कार्यक्षमता न गमावता खर्च कमी करू शकतील.

स्रोत: https://dev.to/synthorai/deepseek-v4-pro-ga-vs-preview-measured-18-62-less-thinking-539l