Shannon 3.1
उही तर्क लूप, हाम्रो आफ्नै GPU क्लस्टर मा सारिएको: 32% बढी बुद्धिमान्, 10-15 गुणा छिटो, र 196,608-टोकन को सन्दर्भ विन्डो।
संक्षेपमा
Shannon 3.1 ले Shannon 3 लाई प्रयोगयोग्य बनाउने सबै कुरा — पुनरावृत्तीय तर्क लूप, अस्वीकृति तहको अभाव, आउटपुट फिल्टरिङको अभाव — कायम राख्छ, र यो कहाँ तथा कसरी चल्छ भन्ने कुरा मात्र बदल्छ। मोडेल अब तेस्रो-पक्ष इन्फरेन्स होस्टको साटो हाम्रो आफ्नै GPU क्लस्टर बाट सेवा दिन्छ। Shannon Lab को मूल्याङ्कनले Shannon 3.0 विरुद्ध बुद्धिमत्तामा 32% सुधार र 10-15 गुणा छिटो जवाफ नापेको छ। सन्दर्भ विन्डो 32,768 बाट 196,608 टोकन पुगेको छ। 3.0 को आउटपुटलाई जानाजानी सुस्त बनाउने गति-नियन्त्रण तह हटाइएको छ: 3.1 इन्जिनको पूर्ण गतिमा स्ट्रिम गर्छ। मोडेल आईडीहरू shannon-3.1 र shannon-3.1-pro हुन्, जुन च्याटमा र तीनै API डायलेक्ट मा उपलब्ध छन्।
धेरैजसो मोडेल रिलिजहरूले तपाईंलाई क्षमताको दाबी विश्वासमा स्वीकार्न र बहस टुंग्याउने बेन्चमार्क तालिका पर्खन भन्छन्। यो जाँच्न सजिलो छ: दुई ट्याब खोल्नुहोस्, 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-बिट NVFP4 |
| डिकोडिङ | मानक | स्पेक्युलेटिभ |
| तर्क लूप | सोच → मस्यौदा → समीक्षा → सुधार | अपरिवर्तित |
| अस्वीकृति तह | छैन | छैन |
| मोडेल आईडी | 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-टोकनको विश्लेषण, जेनेरेट गरिएको कोडको फाइल — तपाईंले याद गर्ने सुधारको अधिकांश हिस्सा यही एउटैले ल्याउँछ।
एउटा इमानदार परिणाम: स्ट्रिम अब झट्केदार छ। स्पेक्युलेटिभ डिकोडिङ (तल) ले स्वीकृत टोकनहरू छोटा शृङ्खलामा पठाउँछ, त्यसैले पाठ एक-एक शब्दको नियमित लयमा नआएर देखिने गुच्छाहरूमा आउन सक्छ। तपाईंले 3.0 को सहज लयको वरिपरि UI बनाउनुभएको छ भने त्यो अझै काम गर्छ — टोकनको क्रम र सामग्रीमा कुनै असर पर्दैन — तर टाइपराइटरको रूप मन पर्थ्यो भने तपाईंले आफ्नै क्लाइन्ट-साइड इजिङ फेरि थप्न चाहनुहुन सक्छ। हामीलाई लाग्छ, धेरैजसो मानिस समय फिर्ता पाउन नै रुचाउँछन्।
इन्जिन आफैं छिटो भयो
गेट हटाउनुको फाइदा गेटपछाडिको कुरा छिटो भएमा मात्र हुन्छ। दोस्रो योगदान भनेको खण्ड 03 मा वर्णन गरिएको सर्भिङ स्ट्याक हो: हाम्रो आफ्नै क्लस्टरमा रहेका वर्तमान पुस्ताका, FP4-नेटिभ एक्सेलेरेटरहरूमा 4-बिट NVFP4 वेट र स्पेक्युलेटिभ डिकोडिङ। यी दुवैले गेट हटाउँदा उजागर हुने सीमालाई नै माथि उठाउँछन्।
सापेक्षिक अन्त्यदेखि अन्त्यसम्मको जवाफ ढिलाइ, Shannon Lab आन्तरिक मूल्याङ्कन, सेप्टेम्बर 2026। दायराले प्रम्प्टको लम्बाइ र तह झल्काउँछ: Lite मा छोटा प्रम्प्ट तल्लो छेउतिर पर्छन्, Pro मा लामा जेनेरेसन माथिल्लो छेउतिर।
03स्पेक्युलेटिभ डिकोडिङले वास्तवमा के गर्छ
"स्पेक्युलेटिभ डिकोडिङ इन्फरेन्स" लाई मार्केटिङ शब्दका रूपमा प्रयोग गरिन्छ, त्यसैले यहाँ यसको संयन्त्र सोझै राखिएको छ।
भाषा मोडेलले सामान्यतया प्रति फर्वार्ड पास एउटा टोकन उत्पादन गर्छ। त्यो पासमा गणित होइन, मेमोरी ब्यान्डविथ हावी हुन्छ — केही गणना गर्न वेटहरू पढ्नुपर्छ, र तिनलाई पढ्न गणितलाई भन्दा धेरै लामो समय लाग्छ। GPU ले आफ्नो अधिकांश समय कम्प्युट युनिट निष्क्रिय राखेर मेमोरी पर्खनमै बिताउँछ। 500 टोकन जेनेरेट गर्नु भनेको त्यो ढिलाइ क्रमशः 500 पटक तिर्नु हो।
स्पेक्युलेटिभ डिकोडिङले त्यही क्रमिक हिस्सामाथि प्रहार गर्छ। एउटा सानो, सस्तो ड्राफ्ट मोडेल ले सम्भावित अर्का टोकनहरूको छोटो शृङ्खला — मानौं चार वा आठ — प्रस्ताव गर्छ। त्यसपछि मुख्य मोडेलले त्यो पूरै शृङ्खलालाई एउटै ब्याच फर्वार्ड पासमा मूल्याङ्कन गर्छ, जसको लागत एउटै टोकन मूल्याङ्कन गर्नुभन्दा मुस्किलले बढी हुन्छ, किनभने महँगो हिस्सा (वेट पढ्ने काम) जे भए पनि एकैपटक हुन्छ। मुख्य मोडेल सहमत भएको हरेक प्रस्तावित टोकन स्वीकार गरिन्छ र तुरुन्तै पठाइन्छ। पहिलो असहमतिमै शृङ्खला काटिन्छ र त्यहाँबाट सामान्य डिकोडिङ पुनः सुरु हुन्छ।
महत्त्वपूर्ण गुण
स्पेक्युलेटिभ डिकोडिङ आउटपुट-संरक्षक हो। प्रमाणीकरण चरण यसरी बनाइएको छ कि स्वीकृत अनुक्रमको वितरण मुख्य मोडेलको आफ्नै स्याम्पलिङले दिने वितरणसँग ठ्याक्कै मिल्छ। तपाईंले ड्राफ्ट मोडेलको जवाफ पाइरहनुभएको छैन, न त ठूलो मोडेलको जवाफको अनुमान नै। तपाईंले मुख्य मोडेलकै आउटपुट पाउनुहुन्छ, कम क्रमिक चरणमा पुगिएको। ड्राफ्ट मोडेलले गति मात्र प्रभावित पार्न सक्छ, सामग्री कहिल्यै होइन।
काम गर्ने कुरा स्वीकृति दर हो। पूर्वानुमानयोग्य पाठमा — बोइलरप्लेट, कोडको संरचना, तर्कलाई जोड्ने भाग — ड्राफ्ट मोडेलले राम्रो अनुमान लगाउँछ र लामा शृङ्खला एकैचोटि आइपुग्छन्। साँच्चै कठिन टोकनहरूमा स्वीकृति घट्छ र प्रणाली सहजै सामान्य एक-एक टोकनको डिकोडिङमा फर्कन्छ। तपाईंलाई चाहिने असमानता यही हो: यसले सजिला भागहरूलाई तीव्र बनाउँछ र कठिनहरूलाई छुँदैन।
4-बिट वेट किन उही अनुच्छेदमा पर्छन्
अवरोध मेमोरी ब्यान्डविथ भएकाले, वेटहरू सानो बनाउनु सिधै गतिको लिभर हो, केवल मेमोरी खपतको मात्र होइन। NVFP4 भनेको सूक्ष्म-स्तरको प्रति-ब्लक स्केलिङ सहितको 4-बिट फ्लोटिङ-पोइन्ट ढाँचा हो, र त्यही कुराले पुराना 4-बिट इन्टिजर क्वान्टाइजेसन योजनाहरूले गुमाउने ठाउँमा यसलाई शुद्धता कायम राख्न दिन्छ। प्रति फर्वार्ड पास पढ्नुपर्ने बाइटहरू झन्डै चौथाइ हुनुको अर्थ मेमोरी पर्खनमा त्यही अनुपातमा कम समय, र 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 सीमामा थिचिनुको साटो विन्डोभित्रै साँच्चै चल्ने ठाउँ पाउँछ।
तपाईंका लागि सबैभन्दा उपयोगी बेन्चमार्क तपाईंकै हो। आफ्नो वास्तविक कामबाट एउटा प्रम्प्ट लिनुहोस् — पहेली होइन, वास्तविक — र त्यसलाई shannon-3 मा अनि shannon-3.1 मा चलाउनुहोस्। जवाफ तुलना गर्नुहोस्, र समय नाप्नुहोस्। हाम्रा अङ्कहरूले एउटा सुइटभरिको औसत वर्णन गर्छन्; सुधार हुनैपर्ने चाहिँ तपाईंको प्रम्प्ट हो।
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 लाइनकै अडान हो र हाम्रो आफ्नै क्लस्टरमा सर्दा पनि यो बदलिएको छैन — बरु, सर्भिङ स्ट्याक नियन्त्रण गर्नाले यसको ग्यारेन्टी दिन सजिलो हुन्छ, किनभने मोडेल र तपाईंबीच आफ्नै नीति भएको कुनै बिचौलिया होस्ट रहँदैन।
पूरै आउटपुट बाटो बदल्ने रिलिजबारे मानिसले सोध्ने स्पष्ट प्रश्न भएकाले यो सोझै भन्न लायक छ: गति-नियन्त्रण तह हटाउनुको अर्थ त्यसको ठाउँमा मोडरेसन तह घुसाउनु थिएन। कुनै पनि कुराले स्ट्रिमको निरीक्षण, पुनर्लेखन वा नियन्त्रण गर्दैन। मोडेलले जे उत्पादन गर्छ, त्यही आइपुग्छ। हामीलाई थाहा भएसम्म, यति ठूलो सन्दर्भ विन्डो भएको उपलब्ध मध्ये Shannon 3.1 सबैभन्दा छिटो सेन्सर नगरिएको AI मोडेल हो — र यी दुई गुण सम्बन्धित छन्, किनभने दुवै अरू कसैबाट अनुपालन-आकारको क्षमता भाडामा लिनुको साटो हाम्रै पूर्वाधार चलाउनुबाट आउँछन्।
सेन्सर नगरिएको भनेको उत्तरदायित्वविहीन भन्ने होइन। प्रयोग हाम्रो जिम्मेवार प्रयोग नीति ले निर्देशित गर्छ, र कठिन सामग्रीसँग जुध्ने मोडेलले ल्याउने दायित्व भनेको तपाईंले त्यससँग जिम्मेवारीपूर्वक जुध्नु हो।
10तुलना आफैं चलाउनुहोस्
यहाँका हरेक दाबी करिब दुई मिनेटमा जाँच्न सकिन्छ, र हामी तपाईंले हामीलाई पत्याउनुभन्दा जाँच्नुभएको नै रुचाउँछौं।
- तपाईंले साँच्चै गर्ने कामबाट एउटा प्रम्प्ट छान्नुहोस्। लामो भए राम्रो — यसले विन्डो र स्ट्रिमिङ दुवैलाई परीक्षण गर्छ।
- त्यसलाई
shannon-3मा चलाउनुहोस्। पहिलो टोकन आउन कति समय लाग्यो र जवाफ पूरा हुन कति लाग्यो, टिप्नुहोस्। - त्यही उही प्रम्प्ट
shannon-3.1मा चलाउनुहोस्। उही दुई अङ्क टिप्नुहोस्। - अनि घडी बिर्सेर दुवै जवाफ पढ्नुहोस्, र तपाईंलाई कुन चाहिन्थ्यो भनी निर्णय गर्नुहोस्।
गतिको फरक तत्काल र स्पष्ट हुनेछ। बसेर विचार गर्न लायक चाहिँ गुणस्तरको फरक हो — त्यो लामा इनपुटमा सबैभन्दा स्पष्ट देखिन्छ, जहाँ 3.0 ले तपाईंले सोचेभन्दा कम सामग्रीसँग चुपचाप काम गरिरहेको थियो।
11बारम्बार सोधिने प्रश्नहरू
Shannon 3.1 के हो?
Shannon 3.1 भनेको Shannon 3 परिवारको हालको रिलिज हो। यसले उही पुनरावृत्तीय तर्क लूप — सोच्ने, मस्यौदा बनाउने, आफैं समीक्षा गर्ने, सुधार्ने — कायम राख्छ, तर त्यसलाई तेस्रो-पक्ष इन्फरेन्स होस्टको साटो हाम्रो आफ्नै GPU क्लस्टरमा नेटिभ रूपमा चलाउँछ। Shannon Lab को आफ्नै मूल्याङ्कनले Shannon 3.0 को तुलनामा बुद्धिमत्तामा 32% सुधार र 10-15 गुणा छिटो जवाफ नापेको छ, र सन्दर्भ विन्डो 32,768 बाट 196,608 टोकनमा बढाइएको छ।
Shannon 3.1 Shannon 3.0 भन्दा कति छिटो छ?
Shannon Lab को आफ्नै मूल्याङ्कन अनुसार, अन्त्यदेखि अन्त्यसम्मको जवाफमा 10 देखि 15 गुणा छिटो। यसका दुई कारण छन्। Shannon 3.0 को आउटपुट एउटा गति-नियन्त्रण तहबाट जान्थ्यो, जसले जानाजानी स्ट्रिमको दर सीमित गर्थ्यो; Shannon 3.1 मा कुनै गति गेट र कुनै रिभिल पेसिङ छैन, त्यसैले इन्जिनले उत्पादन गरेजति छिटो टोकनहरू तपाईंसम्म आइपुग्छन्। इन्जिन आफैं पनि छिटो छ: हाम्रो आफ्नै GPU क्लस्टरमा 4-बिट NVFP4 वेट र स्पेक्युलेटिभ डिकोडिङ।
Shannon 3.1 को सन्दर्भ विन्डो कति ठूलो छ?
196,608 टोकन — Shannon 3.0 मा उपलब्ध 32,768 टोकनभन्दा 6 गुणा बढी। यो झन्डै 400-500 पृष्ठ पाठ, वा मध्यम आकारको कोडबेस बराबर हो, जुन चङ्किङ वा रिट्रिभलविनै एउटै कुराकानीमा राख्न सकिन्छ।
स्पेक्युलेटिभ डिकोडिङ के हो र यहाँ यसको महत्त्व किन छ?
एउटा सानो, छिटो ड्राफ्ट मोडेलले सम्भावित अर्का टोकनहरूको एक शृङ्खला प्रस्ताव गर्छ र मुख्य मोडेलले तिनलाई एउटै ब्याच पासमा प्रमाणित गर्छ। स्वीकृत टोकनहरू तुरुन्तै पठाइन्छन्; अस्वीकृत भएकाहरू सामान्य डिकोडिङमा फर्कन्छन्। आउटपुट त्यही हो जुन मुख्य मोडेलले आफैं उत्पादन गर्थ्यो, तर प्रति प्रमाणीकरण चरण एउटाको साटो धेरै टोकन आउन सक्छन्। यसैले पूर्ण गतिमा स्ट्रिमिङ लागतको समस्या नभई किफायती बन्छ।
के Shannon 3.1 सेन्सर नगरिएको हो?
हो। बाँकी Shannon लाइनजस्तै, Shannon 3.1 मा कुनै अस्वीकृति तह छैन र यसको आउटपुटमा कुनै सामग्री फिल्टरिङ लागू हुँदैन। गति-नियन्त्रण तह हटाउँदा त्यसको ठाउँमा कुनै मोडरेसन तह थपिएको छैन — तपाईंले पाउने स्ट्रिम मोडेलको आउटपुट नै हो।
मोडेल आईडीहरू के-के हुन् र म Shannon 3.1 कहाँ प्रयोग गर्न सक्छु?
shannon-3.1 Lite तह हो र shannon-3.1-pro Pro तह हो। दुवै च्याटमा र तीनै API डायलेक्टमा उपलब्ध छन्: /v1/chat/completions (OpenAI-आकारको), /v1/messages (Anthropic-आकारको), र /v1/responses। स्ट्रिमिङ तीनै ठाउँमा काम गर्छ।
shannon-3.1 र shannon-3.1-pro बीच के फरक छ?
Lite ले तर्क लूपको एउटै पास चलाउँछ: यसले सोच्छ, अनि जवाफ दिन्छ। Pro ले पूरा लूप चलाउँछ — सोच्ने, मस्यौदा बनाउने, आफैं समीक्षा गर्ने, सुधार्ने — मस्यौदा बनाउनुअघि ज्ञान सङ्कलन चरण सहित। धेरैजसो कामका लागि Lite नै सही डिफल्ट हो; पहिलो जवाफ सामान्यतया सबैभन्दा राम्रो नहुने प्रश्नहरूका लागि Pro हो।
Shannon 3.1 प्रयोग गरी हेर्नुहोस्
उही तर्क लूप। छ गुणा विन्डो। कुनै गति गेट छैन।
च्याट सुरु गर्नुहोस् API कागजात पढ्नुहोस्shannon-3.1 · shannon-3.1-pro · तीनै डायलेक्टमा स्ट्रिमिङ
यस लेखका कार्यसम्पादन र बुद्धिमत्ता सम्बन्धी आँकडा Shannon Lab को आफ्नै आन्तरिक मूल्याङ्कनबाट लिइएका हुन् (सेप्टेम्बर 2026), र तेस्रो-पक्ष बेन्चमार्क नतिजा नभई उत्पादन आँकडाका रूपमा प्रस्तुत गरिएका छन्। सन्दर्भ विन्डो, मोडेल आईडी र API उपलब्धता उत्पादन विनिर्देश हुन्। Shannon AI लाई Shannon Lab LLC, न्यू मेक्सिको, USA ले सञ्चालन गर्छ। सम्बन्धित पठन: Shannon 3 · Shannon अनुसन्धान सूचकाङ्क · API कागजात.