इस लेख में
- Tencent Hy4: 770B का ओपन-वेट मॉडल और आपके व्यवसाय के लिए इसका अर्थ
- असल में क्या घोषित किया गया
- Apache 2.0 लाइसेंस कोई छोटा कानूनी विवरण क्यों नहीं है
- हार्डवेयर का हिसाब जिसे सुर्खियाँ आमतौर पर छोड़ देती हैं
- डिज़ाइन को तकनीकी रूप से दिलचस्प क्या बनाता है
- आपके व्यवसाय के लिए तीन व्यावहारिक रास्ते
- वे सवाल जो निर्णय तय करते हैं
- Origami में हम इसे कैसे संभालते हैं
- स्रोत
Tencent Hy4: 770B का ओपन-वेट मॉडल और आपके व्यवसाय के लिए इसका अर्थ
सीधा जवाब: 28 अगस्त 2026 को Tencent ने Hy4 preview को Apache 2.0 लाइसेंस के तहत ओपन-वेट मॉडल के रूप में प्रकाशित किया, जिसमें कुल 770 अरब पैरामीटर हैं, जिनमें से प्रति टोकन केवल 49 अरब सक्रिय होते हैं, और जिसकी कॉन्टेक्स्ट विंडो दस लाख टोकन तक है। व्यवहार में इसका मतलब है कि कोई भी कंपनी मॉडल डाउनलोड करके उसे अपने इन्फ्रास्ट्रक्चर पर, बिना वेंडर की अनुमति और बिना प्रति-कॉल शुल्क के चला सकती है। इसका मतलब यह नहीं कि आप इसे अपने ऑफ़िस के किसी सर्वर पर चला सकते हैं। इन दो वाक्यों के बीच का अंतर ही तय करता है कि यह खबर आपसे जुड़ी है या नहीं।
असल में क्या घोषित किया गया
किसी भी विश्लेषण से पहले, प्रकाशित तथ्यों को व्याख्या से अलग करना उपयोगी है। Tencent ने मॉडल की आधिकारिक रिपॉज़िटरी में जो जारी किया उसमें शामिल है:
- आकार और सक्रियण: कुल 770 अरब पैरामीटर, प्रति टोकन 49 अरब सक्रिय, मिक्सचर-ऑफ़-एक्सपर्ट्स आर्किटेक्चर में।
- आंतरिक संरचना: 78 लेयर, पहली डेंस और बाकी मिक्सचर-ऑफ़-एक्सपर्ट्स, जिनमें 256 रूटेड एक्सपर्ट और एक साझा एक्सपर्ट हैं, और प्रति टोकन आठ एक्सपर्ट चुने जाते हैं।
- कॉन्टेक्स्ट विंडो: दस लाख टोकन, शब्दावली का आकार 120,832।
- लाइसेंस: Apache 2.0, एक उदार लाइसेंस जो व्यावसायिक उपयोग, संशोधन और पुनर्वितरण की अनुमति देता है।
- क्वांटाइज़्ड संस्करण: पूर्ण-प्रिसिज़न मॉडल के साथ एक FP8 संस्करण भी उपलब्ध है।
- इन्फ़रेंस त्वरण: एक बिल्ट-इन मल्टी-टोकन प्रेडिक्शन लेयर जो स्पेक्युलेटिव डिकोडिंग को सपोर्ट करती है।
- घोषित फ़ोकस: मॉडल सामान्य चैट के बजाय कोडिंग, ऑफ़िस उत्पादकता, गेम डेवलपमेंट और वैज्ञानिक शोध को लक्ष्य करता है।
जो घोषित नहीं किया गया, और जिसे मान भी नहीं लेना चाहिए, वह है आपके विशेष मामले में बंद मॉडलों से श्रेष्ठता का कोई भी वादा। सार्वजनिक बेंचमार्क पर प्रकाशित तुलनाएँ आपके दस्तावेज़ों, आपके ग्राहकों की भाषा और आपके क्षेत्र के संदर्भ में प्रदर्शन के बारे में कुछ भी भरोसेमंद नहीं बतातीं। यह जवाब केवल आपके अपने डेटा पर आंतरिक परीक्षण से मिलता है।
Apache 2.0 लाइसेंस कोई छोटा कानूनी विवरण क्यों नहीं है
ओपन मॉडलों पर अधिकांश चर्चा आउटपुट की गुणवत्ता पर केंद्रित रहती है, जबकि व्यवसाय-मालिक के लिए असली मूल्य लाइसेंस की शर्त में है। उदार लाइसेंस के तीन व्यावहारिक अर्थ हैं: अपने इन्फ्रास्ट्रक्चर में मॉडल चलाने के लिए किसी की मंज़ूरी नहीं चाहिए, अपने डेटा पर इसे संशोधित और ट्यून करने की अनुमति है, और आपकी सेवा की निरंतरता इस पर निर्भर नहीं करती कि कोई वेंडर इसे देता रहे या अपनी कीमतें स्थिर रखे।
यह आखिरी बिंदु ही असल मुद्दा है। जिस कंपनी ने अपनी पूरी ग्राहक सेवा एक ही API पर बनाई है, वह एक खामोश जोखिम उठाती है: कीमत में बदलाव, बंद किया गया संस्करण या उपयोग नीति में बदलाव उसे शुरुआती बिंदु पर वापस भेज सकता है। ओपन-वेट मॉडल इस जोखिम को खत्म नहीं करता, लेकिन आपको एक निकास देता है: आपने जो कॉपी डाउनलोड की, वह आपकी ही रहती है।
हार्डवेयर का हिसाब जिसे सुर्खियाँ आमतौर पर छोड़ देती हैं
यहीं उत्साह आँकड़ों में बदलता है। FP8 प्रिसिज़न पर 770 अरब पैरामीटर का मतलब लगभग प्रति पैरामीटर एक बाइट है, यानी किसी और चीज़ से पहले केवल मॉडल के वेट के लिए 700 गीगाबाइट से अधिक। इसमें बातचीत की लंबाई के साथ बढ़ने वाली कॉन्टेक्स्ट मेमोरी जोड़ें, और दस लाख टोकन की विंडो का मतलब असली उपयोग में काफ़ी अतिरिक्त मेमोरी है; फिर रिडंडेंसी जोड़ें ताकि एक नोड के विफल होने पर सेवा ठप न हो।
निष्कर्ष यह है कि यह डेटा-सेंटर का मॉडल है, ऑफ़िस-सर्वर का नहीं। इसे सेल्फ-होस्ट करना एक ऐसा निर्णय है जिसके लिए विशेष हार्डवेयर और ऐसी ऑपरेशंस टीम चाहिए जो मॉडल को कई GPU में बाँटना और लेटेंसी व उपयोग की निगरानी करना जानती हो। यह एक स्थिर लागत है जो आपका उपयोग घटने पर कम नहीं होती, जबकि API में आप उतना ही भुगतान करते हैं जितना उपयोग करते हैं।
व्यावहारिक नियम: सेल्फ-होस्टिंग केवल दो में से किसी एक स्थिति में समझदारी है। या तो आपका उपयोग बड़ा और स्थिर है जिससे स्थिर लागत परिवर्तनशील खपत से सस्ती पड़ती है, या आप किसी नियामकीय या अनुबंध संबंधी आवश्यकता का सामना कर रहे हैं जो डेटा को एक तय सीमा से बाहर जाने से रोकती है। इन दो स्थितियों के बाहर, सेल्फ-होस्टिंग आमतौर पर आर्थिक नहीं बल्कि भावनात्मक निर्णय होता है।
डिज़ाइन को तकनीकी रूप से दिलचस्प क्या बनाता है
Hy4 में चौंकाने वाला आँकड़ा 770 अरब नहीं, बल्कि 49 अरब है। मिक्सचर-ऑफ़-एक्सपर्ट्स आर्किटेक्चर का मतलब है कि मॉडल की क्षमता विशाल है, फिर भी वह प्रति टोकन अपना केवल एक छोटा हिस्सा सक्रिय करता है, इसलिए आपको फ़्लैगशिप स्तर की गुणवत्ता मध्यम आकार के मॉडल के करीब की कंप्यूट लागत पर मिलती है। यही आर्किटेक्चरल दिशा पिछले दो वर्षों में ओपन मॉडलों को बंद मॉडलों के करीब ले आई है।
इसके साथ एक स्पार्स अटेंशन तंत्र है जो लेयरों के बीच स्पार्सिटी इंडेक्स का दोबारा उपयोग करता है, और एक बिल्ट-इन मल्टी-टोकन प्रेडिक्शन लेयर है जो जनरेशन का समय घटाने के लिए स्पेक्युलेटिव डिकोडिंग संभव बनाती है। व्यावसायिक भाषा में: ये विवरण प्रति टोकन लागत और लेटेंसी घटाते हैं, और यही दो कारक तय करते हैं कि कोई फ़ीचर हज़ारों उपयोगकर्ताओं तक पहुँचाया जा सकता है या आंतरिक प्रयोग ही बना रहता है।
आपके व्यवसाय के लिए तीन व्यावहारिक रास्ते
- बंद मॉडल पर मैनेज्ड API: लॉन्च का सबसे तेज़ रास्ता, कोई परिचालन बोझ नहीं, और उपयोग के साथ बढ़ने वाली परिवर्तनशील लागत। किसी भी उत्पाद के पहले छह महीनों के लिए डिफ़ॉल्ट रास्ता।
- आपके लिए होस्ट करने वाले प्रदाता के ज़रिए Hy4: आपको लाइसेंस की लचीलापन और बिना हार्डवेयर खरीदे प्रदाताओं के बीच जाने की क्षमता मिलती है। यह वह व्यावहारिक बीच का रास्ता है जिसे बहुत लोग नज़रअंदाज़ करते हैं।
- पूर्ण सेल्फ-होस्टिंग: अधिकतम नियंत्रण और अधिकतम लागत। तब उचित है जब आप पर सख्त डेटा रेज़िडेंसी की आवश्यकता हो या आप बड़ा, स्थिर परिचालन वॉल्यूम चलाते हों।
वे सवाल जो निर्णय तय करते हैं
इस रास्ते पर एक भी रियाल खर्च करने से पहले चार सवालों का ईमानदारी से जवाब दें। मॉडल से किस तरह का डेटा गुज़रेगा, और क्या कोई नियामकीय या अनुबंध संबंधी दायित्व उसे बाहर जाने से रोकता है? छह महीने बाद, न कि पहले हफ़्ते में, अपेक्षित मासिक वॉल्यूम कितना है? क्या आपके पास, या आपके तकनीकी साझेदार के पास, चौबीसों घंटे की वास्तविक परिचालन क्षमता है? और क्या आपने अपने एप्लिकेशन में ऐसी एब्स्ट्रैक्शन लेयर बनाई है जो उत्पाद को दोबारा लिखे बिना मॉडल बदलने दे?
अगर आखिरी सवाल का जवाब नहीं है, तो किस मॉडल का उपयोग करें इस पर किसी भी चर्चा से पहले यही आपकी प्राथमिकता है। लचीली कंपनी और फँसी हुई कंपनी के बीच का अंतर सही मॉडल चुनने में नहीं, बल्कि ऐसी प्रणाली बनाने में है जो बाद में उचित लागत पर विकल्प बदलने की गुंजाइश रखे। अगर रेज़िडेंसी आपकी मुख्य वजह है, तो स्थानीय क्लाउड रीजन और डेटा रेज़िडेंसी पर हमारा लेख देखें।
Origami में हम इसे कैसे संभालते हैं
हम क्लाइंट एप्लिकेशन इस तरह बनाते हैं कि मॉडल एक एकीकृत आंतरिक इंटरफ़ेस के पीछे बदला जा सकने वाला घटक हो, और हम असली क्लाइंट मामलों का एक मूल्यांकन सेट रखते हैं जिसे किसी भी संभावित मॉडल को अपनाने से पहले उस पर चलाते हैं। इससे Hy4 के जारी होने जैसी खबर एक तकनीकी सुर्खी से एक मापने योग्य निर्णय बन जाती है: मूल्यांकन सेट चलाएँ, गुणवत्ता, लागत और लेटेंसी की तुलना करें, फिर धारणाओं के बजाय आँकड़ों पर निर्णय लें।
स्रोत
- Tencent की Hunyuan टीम की Hy4 preview की आधिकारिक रिपॉज़िटरी: github.com/Tencent-Hunyuan/Hy4-preview
- Apache 2.0 लाइसेंस का पाठ: apache.org/licenses/LICENSE-2.0
- सऊदी व्यक्तिगत डेटा संरक्षण कानून (PDPL) और उसका पर्यवेक्षी प्राधिकरण: sdaia.gov.sa
सामान्य प्रश्न
ओपन-वेट का असल में क्या मतलब है?
इसका मतलब है कि मॉडल की फ़ाइलें खुद प्रकाशित की जाती हैं और उन्हें बिना वेंडर की अनुमति और बिना प्रति-कॉल शुल्क के डाउनलोड करके आपके अपने इन्फ्रास्ट्रक्चर पर चलाया जा सकता है। Apache 2.0 जैसे उदार लाइसेंस के साथ व्यावसायिक उपयोग और संशोधन की भी अनुमति होती है। इसका मतलब यह नहीं कि इसे चलाना मुफ़्त है, क्योंकि हार्डवेयर और संचालन की लागत आप पर आ जाती है।
क्या मैं Hy4 को अपनी कंपनी के सर्वरों पर चला सकता हूँ?
सामान्य ऑफ़िस सेटअप पर आमतौर पर नहीं। 770 अरब पैरामीटर पर केवल वेट को ही FP8 प्रिसिज़न में 700 गीगाबाइट से अधिक चाहिए, कॉन्टेक्स्ट मेमोरी और रिडंडेंसी की गुंजाइश से पहले ही। यह कई GPU और एक विशेषज्ञ ऑपरेशंस टीम वाला डेटा-सेंटर का क्षेत्र है, ऑफ़िस का एक अकेला सर्वर नहीं।
सेल्फ-होस्टिंग कब API से सस्ती होती है?
दो में से किसी एक स्थिति में: बड़ा और स्थिर उपयोग, जिससे हार्डवेयर की स्थिर लागत परिवर्तनशील खपत से कम हो जाए, या कोई नियामकीय या अनुबंध संबंधी दायित्व जो डेटा को एक तय सीमा से बाहर जाने से रोकता हो। इन दोनों के अलावा, मैनेज्ड API सस्ता और कम जोखिम वाला रहता है।
किसी एक AI वेंडर पर निर्भरता (लॉक-इन) से कैसे बचें?
अपने एप्लिकेशन में एक आंतरिक एब्स्ट्रैक्शन लेयर बनाएँ ताकि मॉडल एक बदला जा सकने वाला घटक बने, और असली ग्राहक मामलों का एक मूल्यांकन सेट रखें जिसे आप हर संभावित मॉडल पर चलाएँ। इससे प्रदाता बदलना दोबारा निर्माण की परियोजना के बजाय आँकड़ों पर आधारित निर्णय बन जाता है।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








