Shannon 3.1

बहुतेक मॉडेल रिलीज तुम्हाला क्षमतेचा दावा विश्वासावर स्वीकारायला सांगतात आणि बेंचमार्क तक्ता वाद मिटवेपर्यंत वाट पाहायला लावतात. हा तपासायला सोपा आहे: दोन टॅब उघडा, तोच प्रॉम्प्ट shannon-3 आणि shannon-3.1 मध्ये टाका, आणि पाहा. उत्तर किती वेगाने येते यातील फरक सूक्ष्म नाही, आणि ती रेंडरिंगची करामतही नाही. Shannon 3.0 जाणूनबुजून मर्यादित केले होते. Shannon 3.1 नाही.

01Shannon 3.1 मध्ये प्रत्यक्षात काय बदलले

या कुटुंबाची ओळख ठरवणारी गोष्ट Shannon 3.0 ने आणली: पुनरावृत्ती तर्क लूप. मॉडेल पहिल्याच विचारावर उत्तर देत नाही. ते विचार करते, मसुदा तयार करते, त्या मसुद्याची प्रश्नाशी तुलना करून तपासणी करते आणि सुधारणा करते. Lite त्या लूपचा एकच फेरा चालवते; Pro संपूर्ण लूप चालवते, ज्यात मसुद्याआधीचा ज्ञान संकलनाचा टप्पाही येतो. ही रचना Shannon 3 संशोधन लेखात सविस्तर वर्णन केली आहे, आणि 3.1 मध्ये त्यातले काहीही बदललेले नाही.

बदल झाला तो खालच्या यंत्रणेत. Shannon 3.0 तृतीय-पक्ष इन्फरन्स होस्टमार्फत दिले जात होते — मॉडेल लाँच करण्याचा हा समजूतदार मार्ग आहे, पण चालवण्याचा बंधनकारक मार्ग. तुम्हाला दुसऱ्याचे सर्व्हिंग कॉन्फिगरेशन, दुसऱ्याची रांग, दुसऱ्याची संदर्भ मर्यादा आणि तुम्हाला प्रति सेकंद किती टोकन मिळावेत याबद्दलची दुसऱ्याची कल्पना वारशाने मिळते. Shannon 3.1 आमच्या स्वतःच्या GPU क्लस्टरवर, आम्ही कॉन्फिगर केलेल्या सर्व्हिंग स्टॅकवर चालते, आणि या लेखातील प्रत्येक ठळक आकडा त्या एका निर्णयाचा परिणाम आहे.

	Shannon 3.0	Shannon 3.1
कुठे चालते	तृतीय-पक्ष होस्ट	आमचा स्वतःचा GPU क्लस्टर
संदर्भ विंडो	32,768	196,608
आउटपुट स्ट्रीमिंग	पेस्ड / दर-मर्यादित	पूर्ण इंजिन वेग
वेट्स	होस्ट डीफॉल्ट	4-bit NVFP4
डीकोडिंग	प्रमाणित	Speculative
तर्क लूप	विचार → मसुदा → तपासणी → सुधारणा	अपरिवर्तित
नकार स्तर	नाही	नाही
मॉडेल आयडी	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Shannon 3.1 10-15 पट वेगवान का वाटते

लोक सर्वात आधी वेगाचा आकडा विचारतात, त्यामुळे तो कुठून येतो याबद्दल अचूक असणे महत्त्वाचे आहे. दोन स्वतंत्र कारणे आहेत, आणि त्यातले मोठे कारण कमी आकर्षक आहे.

आम्ही वेग मर्यादा काढून टाकली

Shannon 3.0 चे आउटपुट एका पेसिंग स्तरातून जात असे. टोकन इंजिनमधून बाहेर पडत, थांबवली जात, आणि एका वेळापत्रकानुसार तुमच्या कनेक्शनवर सोडली जात. हा अपघात किंवा दोष नव्हता. जेव्हा सामायिक इन्फरन्स होस्ट हा अडथळा असतो, तेव्हा आउटपुटला पेस केल्याने भार समतोल राहतो, एखादे लांब जनरेशन एका स्लॉटवर कब्जा करत नाही, आणि स्ट्रीम झटक्यांऐवजी अंदाजयोग्य, वाचनीय लयीत येतो. ही समर्थनीय अभियांत्रिकी निवड आहे, आणि तिने प्रत्येक उत्तरावर प्रत्येक वापरकर्त्याचा खरा वेळ खर्ची घातला.

Shannon 3.1 मध्ये वेग मर्यादा नाही आणि रिव्हील पेसिंग नाही. इंजिन जशी टोकन तयार करते तशी ती तुमच्या स्ट्रीममध्ये लिहिली जातात. इंजिन वेगाने तयार करत असेल, तर तुम्हाला ते वेगाने तयार करताना दिसते. मॉडेल आणि तुमचे टर्मिनल, तुमची चॅट विंडो किंवा तुमचा SSE रीडर यांच्यामध्ये कोणताही स्मूदिंग बफर नाही. लांब उत्तरासाठी — 2,000-टोकनचे विश्लेषण, तयार केलेल्या कोडची फाइल — तुम्हाला जाणवणाऱ्या सुधारणेचा बहुतांश भाग एवढ्यानेच येतो.

एक प्रामाणिक परिणाम: स्ट्रीम आता झटक्यांचा आहे. Speculative decoding (खाली पाहा) स्वीकारलेली टोकन लहान मालिकांमध्ये पाठवते, त्यामुळे मजकूर एका-एका शब्दाच्या ठराविक लयीऐवजी दिसणाऱ्या तुकड्यांमध्ये येऊ शकतो. जर तुम्ही 3.0 च्या गुळगुळीत लयीभोवती UI बांधले असेल, तर ते तरीही चालेल — टोकनचा क्रम आणि आशय अबाधित आहेत — पण टाइपरायटरचा लुक आवडत असेल तर तुम्ही तुमचे स्वतःचे क्लायंट-साइड इझिंग पुन्हा आणू शकता. आमच्या मते बहुतेक लोकांना ते सेकंद परत मिळालेले आवडतील.

इंजिन स्वतःच अधिक वेगवान झाले

मर्यादा काढून टाकणे तेव्हाच उपयोगी ठरते जेव्हा त्या मर्यादेमागचे यंत्र वेगवान असते. दुसरे कारण म्हणजे विभाग 03 मध्ये वर्णन केलेला सर्व्हिंग स्टॅक: आमच्या स्वतःच्या क्लस्टरमधील सध्याच्या पिढीच्या, FP4-मूळ अ‍ॅक्सिलरेटरवर 4-bit NVFP4 वेट्स आणि speculative decoding. एकत्रितपणे ते मर्यादा काढल्यामुळे उघड झालेली कमाल पातळी वाढवतात.

सापेक्ष संपूर्ण उत्तर विलंब, Shannon Lab अंतर्गत मूल्यांकन, सप्टेंबर 2026. ही श्रेणी प्रॉम्प्टची लांबी आणि स्तर दर्शवते: Lite वरील छोटे प्रॉम्प्ट खालच्या टोकाजवळ, Pro वरील लांब जनरेशन वरच्या टोकाजवळ असतात.

03Speculative decoding प्रत्यक्षात काय करते

"Speculative decoding inference" हा शब्द जाहिरातीसारखा वापरला जातो, म्हणून इथे ती यंत्रणा सरळपणे मांडतो.

भाषा मॉडेल सामान्यतः प्रत्येक फॉरवर्ड पासमध्ये एक टोकन तयार करते. त्या पासवर गणिताचा नाही तर मेमरी बँडविड्थचा प्रभाव असतो — काहीही गणना करण्यासाठी वेट्स वाचावी लागतात, आणि ती वाचायला गणितापेक्षा कितीतरी जास्त वेळ लागतो. GPU आपला बहुतेक वेळ कंप्यूट युनिट्स रिकामी ठेवून मेमरीची वाट पाहण्यात घालवते. 500 टोकन तयार करणे म्हणजे तो विलंब 500 वेळा, क्रमाक्रमाने भरणे.

Speculative decoding या क्रमबद्ध भागावर हल्ला करते. एक लहान, स्वस्त ड्राफ्ट मॉडेल संभाव्य पुढील टोकनची छोटी मालिका सुचवते — समजा चार किंवा आठ. मग मुख्य मॉडेल ती संपूर्ण मालिका एकाच बॅच्ड फॉरवर्ड पासमध्ये तपासते, ज्याचा खर्च एका टोकनच्या तपासणीपेक्षा फारसा जास्त नसतो, कारण महागडा भाग (वेट्स वाचणे) दोन्ही बाबतीत एकदाच होतो. मुख्य मॉडेल ज्या-ज्या सुचवलेल्या टोकनशी सहमत होते ती स्वीकारून लगेच पाठवली जातात. पहिल्या असहमतीवर मालिका थांबवली जाते आणि तिथून सामान्य डीकोडिंग पुन्हा सुरू होते.

स्वीकृती दर हे काम करतो. अंदाजयोग्य मजकुरावर — बॉयलरप्लेट, कोड रचना, युक्तिवादाचा जोडणारा भाग — ड्राफ्ट मॉडेल चांगला अंदाज बांधते आणि लांब मालिका एकदम स्वीकारल्या जातात. खरोखर कठीण टोकनवर स्वीकृती घटते आणि प्रणाली सहजपणे सामान्य एका-एका टोकनच्या डीकोडिंगकडे परत जाते. ही विषमता तुम्हाला हवी तशीच आहे: ती सोपे भाग वेगवान करते आणि कठीण भागांना हात लावत नाही.

4-bit वेट्स याच परिच्छेदात का येतात

अडथळा मेमरी बँडविड्थ असल्यामुळे, वेट्स लहान करणे हा फक्त मेमरी वापराचा नव्हे तर थेट वेगाचा लीव्हर आहे. NVFP4 हा सूक्ष्म प्रति-ब्लॉक स्केलिंग असलेला 4-bit फ्लोटिंग-पॉइंट फॉरमॅट आहे, आणि त्यामुळेच जुन्या 4-bit इंटिजर क्वांटायझेशन योजनांनी गमावलेली अचूकता तो टिकवू शकतो. प्रत्येक फॉरवर्ड पासमध्ये वाचावे लागणारे बाइट साधारण एक चतुर्थांश असल्याने मेमरीची वाट पाहण्यात प्रमाणशीरपणे कमी वेळ जातो, आणि 196K विंडोसाठी लागणाऱ्या लांब-संदर्भ KV कॅशेसाठी खूप जास्त जागा उरते.

या दोन गोष्टी केवळ बेरीज होत नाहीत तर एकमेकींना गुणित करतात: प्रति पास कमी बाइट, आणि प्रति टोकन कमी पास. यामुळेच मर्यादाविरहित, पूर्ण-वेगाचे स्ट्रीमिंग देणे परवडणारे होते, अन्यथा तो खर्च आम्हाला पेसिंगद्वारे भरून काढावा लागला असता — आणि 3.0 वरील पेसिंग स्तर नेमके तेच करत होता.

04196,608 टोकन: 6 पट विंडो काय शक्य करते

Shannon 3.0 ची विंडो 32,768 टोकनची होती: एक कामाचे सत्र, दस्तऐवज नाही. साधारण 70-80 पानांचा मजकूर, त्यातून तर्क लूप स्वतःच्या विचारासाठी वापरतो तेवढा वजा, तुमचा सिस्टम प्रॉम्प्ट वजा, आतापर्यंतचे संभाषण वजा. खऱ्या कामात ही भिंत सतत लागत असे, आणि त्यावरचे उपाय — चंकिंग, सारांश, तुमच्याच सामग्रीवर रिट्रीव्हल — जे जपायचे होते त्यालाच कमकुवत करतात. 196,608 टोकन ही वेगळ्याच वर्गातील समस्या आहे.

ठोसपणे सांगायचे तर हे साधारण 400-500 पाने इंग्रजी मजकूर, किंवा चाचण्या आणि README सह एक मध्यम आकाराचा कोडबेस, किंवा एका प्रकल्पाच्या वर्षभराच्या बैठक नोंदी, किंवा सर्व परिशिष्टांसह संपूर्ण करार संच — एकाच संभाषणात, एकाच प्रश्नाने हाताळता येण्याजोगे, आणि तुमच्या व सामग्रीदरम्यान कोणताही चंकिंग स्तर नाही.

• संपूर्ण रेपॉझिटरीवरचे प्रश्न. तुम्हाला आधीच संशय असलेल्या तीन फायली पेस्ट करण्याऐवजी संपूर्ण कोड लोड करा आणि विचारा की एखादा बग प्रॉडक्शनपर्यंत का पोहोचतो. जी फाइल समाविष्ट करायचे तुमच्या मनातही आले नाही ती मॉडेल शोधू शकते.
• रिट्रीव्हलशिवाय लांब दस्तऐवजांचे विश्लेषण. रिट्रीव्हल हे एक हानिकारक पूर्व-फिल्टर आहे जे मॉडेलला काय पाहू द्यायचे हे ठरवते. 196K वर तुम्ही ते बरेचदा वगळून मॉडेलला सर्व काही वाचू देऊ शकता, ज्यामुळे योग्य उतारा कधी मिळालाच नाही अशा अपयशांचा संपूर्ण वर्ग नाहीसा होतो.
• सुसंगत राहणारी संभाषणे. लांब कामाचे सत्र आता स्वतःची सुरुवात गुपचूप विसरत नाही. तिसऱ्या संदेशात तुम्ही घातलेल्या अटी ऐंशीव्या संदेशातही लागू राहतात.
• तर्क लूपसाठी जागा. लूपचे स्वतःचे विचार, मसुदा आणि तपासणी संदर्भ वापरतात. 3.0 वर हे टप्पे तुमच्या सामग्रीशी अल्प बजेटसाठी स्पर्धा करत होते. 3.1 वर ते आरामात बसतात, आणि म्हणूनच गुणवत्तेतील वाढ आणि विंडोतील वाढ एकत्र आल्या.
• मोठे मिश्र इनपुट. प्रतिमा, दस्तऐवजातून काढलेला मजकूर आणि कोड एकाच वळणात, त्यातले कोणते समाविष्ट करणे परवडेल याची निवड न करता.

प्रत्येक लांब-संदर्भ मॉडेलला लागू होणारी एक प्रामाणिक सूचना, आमच्यासह: मोठी विंडो ही क्षमता आहे, तिच्या पूर्ण पसाऱ्यावर एकसमान लक्ष राहील याची हमी नाही. रचना अजूनही मदत करते. प्रश्न शेवटाजवळ ठेवणे, तुमच्या दस्तऐवजांना लेबल देणे, आणि मॉडेलला काय शोधायचे ते सांगणे — या गोष्टी 150K टोकनवर मोजण्याजोगी सुधारणा देतात, जी 5K वर मिळत नाही.

05Lite आणि Pro: shannon-3.1 आणि shannon-3.1-pro

दोन स्तरांमधील फरक ते तर्क लूपचा किती भाग चालवतात यात आहे, आणि निवडीसाठी महत्त्वाचा तेवढाच एक फरक आहे.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
तर्क	एकच फेरा	संपूर्ण लूप + ज्ञान संकलन
स्व-तपासणी	नाही	होय
संदर्भ विंडो	196,608	196,608
स्ट्रीमिंग	पूर्ण वेग, मर्यादाविरहित	पूर्ण वेग, मर्यादाविरहित
व्हिजन आणि दस्तऐवज	होय	होय
इमेज जनरेशन साधन	होय	होय
कशासाठी सर्वोत्तम	बहुतांश काम, मोठा वापर	कठीण प्रश्न, पहिला मसुदा अपुरा

डीफॉल्ट म्हणून Lite वापरा. चांगल्या तर्क मॉडेलचा एकच फेरा बहुसंख्य खऱ्या विनंत्या हाताळतो, आणि 3.1 वर तो इतका वेगवान आहे की लूपची वाट पाहतोय असे आता जाणवत नाही. Pro कडे वळा जेव्हा प्रश्न असा असतो की पहिले उत्तर सहसा बोधप्रद रीतीने चुकीचे असते: आर्किटेक्चरल तडजोडी, प्रतिकूल विश्लेषण, किंवा जिथे तुम्हाला एका सक्षम सहकाऱ्याने त्यावर एक रात्र विचार करावा असे वाटेल असे काहीही. Pro चा स्व-तपासणीचा टप्पा सजावट नाही — तुम्हाला शोधावे लागण्याआधीच मॉडेल स्वतःच्या चुका शोधते.

0632% बुद्धिमत्ता वाढ, आणि ती कशी वाचावी

Shannon Lab च्या स्वतःच्या मूल्यांकनानुसार Shannon 3.1 ला Shannon 3.0 पेक्षा बुद्धिमत्तेत 32% सुधारणा मिळते. ते काय आहे आणि काय नाही याबद्दल आम्हाला स्पष्ट राहायचे आहे.

हा आमचा आकडा आहे, आमच्या अंतर्गत मूल्यांकन संचातून, लोक प्रत्यक्षात या मॉडेलकडे जी कामे आणतात त्यांचे प्रातिनिधिक म्हणून आम्ही मानतो अशा कामांवर मोजलेला. हा तृतीय-पक्ष बेंचमार्क नाही, आणि आम्ही एका अंतर्गत एकत्रित आकड्याभोवती लीडरबोर्ड तक्ता उभारत नाही किंवा प्रति-बेंचमार्क विश्लेषण प्रकाशित करत नाही — असे विश्लेषण अंतर्गत संचाकडे नसलेल्या बाह्य तुलनात्मकतेचा भास निर्माण करते.

ही वाढ कुठून येते हे मात्र आम्ही सांगू, कारण तो भाग गूढ नाही. मोठी संदर्भ विंडो म्हणजे मॉडेल तर्क करण्याआधी कमी सामग्री टाकून द्यावी लागते, आणि लांब सत्रांमध्ये दिसणारी बरीचशी बुद्धिहीनता प्रत्यक्षात फक्त विस्मरण असते. आम्ही नियंत्रित करत असलेला सर्व्हिंग स्टॅक म्हणजे मॉडेल होस्टच्या डीफॉल्टऐवजी आम्ही ठरवलेल्या कॉन्फिगरेशनवर चालते. आणि तर्क लूप — रचनेत अपरिवर्तित — आता तुमच्या इनपुटसोबत वाटून घेतलेल्या 32K मर्यादेत कोंडला जाण्याऐवजी विंडोमध्ये खरोखर चालण्याइतकी जागा मिळवतो.

07व्हिजन, दस्तऐवज आणि इमेज जनरेशन

Shannon 3.1 प्रतिमा आणि दस्तऐवज वाचते. स्क्रीनशॉट, आकृत्या, छायाचित्रे, स्कॅन केलेली पाने, PDF आणि मजकूर दस्तऐवज संभाषणात टाकता येतात आणि इतर सर्व गोष्टींसोबत त्यांवर तर्क करता येतो. 196K विंडोसह एकत्रितपणे, यामुळेच संपूर्ण-दस्तऐवज कार्यप्रवाह व्यवहार्य होतात: एक लांब अहवाल आणि त्याचे आलेख एकाच वळणात, मॉडेलला कोणती पाने पाहू द्यायची हे आधीच ठरवण्याची गरज न ठेवता.

चॅटमध्ये इमेज जनरेशन आणि एडिटिंग एक साधन म्हणून उपलब्ध आहे. प्रतिमा मागा आणि मॉडेल त्याच संभाषणात, आतापर्यंत चर्चा झालेल्या सर्व संदर्भासह ते साधन तिथेच वापरते. एडिटिंगही तसेच चालते — प्रतिमा द्या, बदल सांगा. यासाठी वेगळ्या मोडमध्ये जावे लागत नाही आणि वेगळा इंटरफेस शिकावा लागत नाही.

08API मधून Shannon 3.1 कॉल करणे

Shannon 3.1 तिन्ही API बोलींवर उपलब्ध आहे, प्रत्येकावर स्ट्रीमिंगसह. तीच मॉडेल, तीन विनंती आकार — तुमच्याकडे आधीच असलेल्या SDK शी जुळेल तो निवडा.

एंडपॉइंट	आकार	स्ट्रीमिंग
/v1/chat/completions	OpenAI-सुसंगत	होय
/v1/messages	Anthropic-सुसंगत	होय
/v1/responses	Responses	होय

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

संपूर्ण तर्क लूप चालवण्यासाठी "shannon-3.1" ऐवजी "shannon-3.1-pro" टाका. तुम्ही आधीच shannon-3 कॉल करत असाल, तर स्थलांतर म्हणजे फक्त मॉडेल आयडी आणि दुसरे काहीही नाही: विनंती व प्रतिसादाचे आकार अपरिवर्तित आहेत, आणि सध्याचे स्ट्रीमिंग क्लायंट तसेच चालत राहतात. अपेक्षित असलेला एकच वर्तनातील फरक म्हणजे विभाग 02 मध्ये वर्णन केलेला झटक्यांचा स्ट्रीम — तीच टोकन, तोच क्रम, फक्त लवकर आणि कमी समान तुकड्यांत येणारी.

संपूर्ण पॅरामीटर संदर्भ, प्रमाणीकरण, एरर सिमँटिक्स आणि एक इंटरॅक्टिव्ह प्लेग्राउंड API दस्तऐवजीकरणात आहेत. इतर मॉडेल कार्ड आणि तांत्रिक लेख Shannon संशोधनात आहेत.

09अजूनही असेन्सॉर्ड, आणि त्या बाबतीत अपरिवर्तित

Shannon 3.1 मध्ये नकार स्तर नाही आणि आउटपुटवर कंटेंट फिल्टरिंग नाही. ही उर्वरित Shannon श्रेणीसारखीच भूमिका आहे आणि आमच्या स्वतःच्या क्लस्टरवर जाण्याने ती बदललेली नाही — उलट, सर्व्हिंग स्टॅक नियंत्रित केल्याने याची हमी देणे सोपे होते, कारण मॉडेल आणि तुमच्यामध्ये स्वतःचे धोरण असलेला कोणताही मध्यस्थ होस्ट नाही.

संपूर्ण आउटपुट मार्ग बदलणाऱ्या रिलीजबद्दल हा स्पष्ट प्रश्न पडतोच, म्हणून सरळ सांगणे योग्य: पेसिंग स्तर काढून टाकणे म्हणजे त्याजागी मॉडरेशन स्तर घालणे नव्हे. स्ट्रीमची कोणतीही तपासणी, पुनर्लेखन किंवा नियंत्रण होत नाही. मॉडेल जे तयार करते तेच पोहोचते. आमच्या माहितीनुसार, एवढ्या मोठ्या संदर्भ विंडोसह उपलब्ध असलेले सर्वात वेगवान असेन्सॉर्ड AI मॉडेल Shannon 3.1 आहे — आणि हे दोन्ही गुणधर्म एकमेकांशी जोडलेले आहेत, कारण दोन्ही दुसऱ्याकडून अनुपालन-आकाराची क्षमता भाड्याने घेण्याऐवजी आमची स्वतःची पायाभूत सुविधा चालवण्यातून येतात.

असेन्सॉर्ड म्हणजे उत्तरदायित्वहीन नाही. वापर आमच्या जबाबदार वापर धोरणाने नियंत्रित होतो, आणि कठीण सामग्रीशी संवाद साधणाऱ्या मॉडेलसोबत येणारे बंधन म्हणजे तुम्ही त्याच्याशी जबाबदारीने वागावे.

10तुलना स्वतः करून पाहा

इथला प्रत्येक दावा सुमारे दोन मिनिटांत तपासता येतो, आणि तुम्ही आमच्यावर विश्वास ठेवण्यापेक्षा तो तपासावा असे आम्हाला वाटते.

1. तुम्ही प्रत्यक्षात करत असलेल्या कामातला प्रॉम्प्ट निवडा. लांब असेल तर उत्तम — तो विंडो आणि स्ट्रीमिंग दोन्हीची परीक्षा घेतो.
2. तो shannon-3 वर चालवा. पहिले टोकन येईपर्यंत किती वेळ लागला आणि उत्तर पूर्ण होईपर्यंत किती वेळ लागला ते नोंदवा.
3. तोच प्रॉम्प्ट shannon-3.1 वर चालवा. तेच दोन आकडे नोंदवा.
4. मग घड्याळ बाजूला ठेवून दोन्ही उत्तरे वाचा आणि ठरवा तुम्हाला कोणते हवे होते.

वेगातील फरक लगेच आणि स्पष्ट दिसेल. गुणवत्तेतील फरक हा विचार करण्यासारखा आहे — तो लांब इनपुटवर सर्वात स्पष्टपणे दिसतो, जिथे 3.0 तुम्हाला वाटत होते त्यापेक्षा तुमच्या सामग्रीचा कमी भाग गुपचूप वापरत होते.

11वारंवार विचारले जाणारे प्रश्न

---

या लेखातील कामगिरी आणि बुद्धिमत्तेचे आकडे Shannon Lab ची स्वतःची अंतर्गत मूल्यांकनातील मोजमापे आहेत, सप्टेंबर 2026, आणि ती तृतीय-पक्ष बेंचमार्क निकाल नव्हे तर उत्पादन आकडे म्हणून मांडली आहेत. संदर्भ विंडो, मॉडेल आयडी आणि API उपलब्धता या उत्पादन विशिष्टता आहेत. Shannon AI चे संचालन Shannon Lab LLC, न्यू मेक्सिको, USA करते. संबंधित वाचन: Shannon 3 · Shannon संशोधन निर्देशिका · API दस्तऐवजीकरण.