Google का निष्पादन-केंद्रित AI मॉडल एक आर्किटेक्चर संबंधी सवाल उठाता है: क्या किसी एप्लिकेशन को पूरे वर्कफ़्लो में एक ही सक्षम मॉडल इस्तेमाल करना चाहिए, या काम को अलग-अलग ताकत वाले मॉडलों में बाँट देना चाहिए?
कल्पना कीजिए कि आप किसी AI कोडिंग असिस्टेंट से मौजूदा एप्लिकेशन में रोल-बेस्ड एक्सेस कंट्रोल जोड़ने को कहते हैं। उसे ऑथेंटिकेशन कोड ढूँढना होगा, समझना होगा कि कौन-सी सेवाएँ अनुमतियाँ लागू करती हैं, बदलाव की योजना बनानी होगी, कोड लिखना होगा और जाँचना होगा कि सामान्य उपयोगकर्ता प्रशासनिक कार्य नहीं कर सकते।
एक सक्षम मॉडल यह सब करने की कोशिश कर सकता है। लेकिन किसी सुरक्षा सीमा को समझना, पहले से तय कोड बदलाव को लागू करने या मौजूदा टेस्ट चलाने से अलग काम है। क्या हर चरण के लिए एक जैसी तर्क-क्षमता चाहिए, और क्या उसकी कीमत भी एक जैसी होनी चाहिए?
Google की 12 नवंबर 2026 की घोषणा, जिसमें Gemini 4 Hydrogen पेश किया गया, इस सवाल को सामने लाती है। Google Hydrogen को तेज़ कोडिंग और एजेंटिक निष्पादन के लिए रखता है, जबकि उसके Gemini 4 Carbon और Argon मॉडल कठिन तर्क पर केंद्रित हैं। उसका Antigravity Orchestrator वर्कफ़्लो के दौरान मॉडल बदल सकता है। Google की घोषणा इस तरीके का वर्णन करती है, लेकिन किसी उत्पाद का प्रदर्शन इस बात का प्रमाण नहीं है कि यही हर एप्लिकेशन के लिए सबसे अच्छा आर्किटेक्चर है।
व्यावहारिक सवाल यह है: एक अतिरिक्त मॉडल कब इतना मदद करता है कि एक और सीमा, एक और कॉल और सिस्टम के विफल होने का एक और रास्ता जोड़ना उचित ठहरे?
सिर्फ़ एक AI मॉडल कई बार काफ़ी क्यों नहीं होता
डेवलपमेंट टीम अक्सर तर्क-क्षमता, कोडिंग क्षमता, प्रतिक्रिया-समय, संदर्भ के आकार और कीमत को परखकर कोई AI मॉडल चुनती है। फिर वह पूरे एप्लिकेशन के लिए वही मॉडल इस्तेमाल करती है। यह एक समझदारी भरा डिफ़ॉल्ट है: इंटीग्रेशन सरल रहता है, निगरानी के लिए कम हिस्से होते हैं, और मॉडल एक सुसंगत कार्य-संदर्भ बनाए रख सकता है।
फिर भी असली वर्कफ़्लो में अलग-अलग तरह के काम होते हैं। हमारे कोडिंग असिस्टेंट को आवश्यकता की व्याख्या करनी होती है, प्रासंगिक फ़ाइलें खोजनी होती हैं, तय करना होता है कि ऑथराइज़ेशन कहाँ होना चाहिए, कॉम्पोनेंट बदलने होते हैं और टेस्ट की विफलताओं को समझना होता है। आर्किटेक्चर का फ़ैसला फ़ाइल खोजने जैसा नहीं है। कठिन तर्क में मज़बूत मॉडल नियमित निष्पादन के लिए ज़रूरत से ज़्यादा महँगा हो सकता है, जबकि सस्ता मॉडल तेज़ होकर भी किसी ज़रूरी निर्भरता को नज़रअंदाज़ कर सकता है।
इससे टास्क-स्तर पर मॉडल आवंटन की संभावना खुलती है: कठिन फ़ैसलों के लिए अधिक सक्षम मॉडल और सीमित निष्पादन के लिए दूसरा मॉडल। इसका मतलब कई मॉडलों को एक साथ चलाना ज़रूरी नहीं है। इसमें केवल तभी मॉडल बदलना शामिल हो सकता है जब कोई टास्क तय जटिलता या अनिश्चितता की सीमा पार करे।
यह स्पष्ट बचत एक ज़िम्मेदारी के साथ आती है: एप्लिकेशन को फिर भी सही नतीजा देना है, केवल सस्ते अलग-अलग जवाब नहीं।
Google ने Gemini 4 Hydrogen के साथ क्या पेश किया
Google Hydrogen को बार-बार दोहराई जाने वाली कोडिंग, डीबगिंग, टूल उपयोग और मल्टीमॉडल ज्ञान-कार्य के लिए निष्पादन-केंद्रित मॉडल बताता है। इसका मॉडल कार्ड कहता है कि इसे Gemini 4 Carbon से अनुकूलित किया गया है। यह टेक्स्ट, इमेज, ऑडियो और वीडियो स्वीकार करता है, और इसकी संयुक्त संदर्भ विंडो एक मिलियन टोकन तक है। डिफ़ॉल्ट सिंक्रोनस आउटपुट 64,000 टोकन तक सीमित है, जबकि Google का बैकग्राउंड लॉन्ग-डिकोड विकल्प एक मिलियन तक जाता है। ये सामान्य API आउटपुट के बारे में आपस में बदले जा सकने वाले दावे नहीं हैं।
Hydrogen चार थिंकिंग स्तर देता है (low, medium, high और xhigh), और Google मानक API दरें US$1.50 प्रति मिलियन इनपुट टोकन और US$7.50 प्रति मिलियन आउटपुट टोकन बताता है। Google के अनुसार यह Gemini API, AI Studio, Antigravity और Google के अन्य उत्पादों के ज़रिए उपलब्ध है। वास्तविक पहुँच, कोटा और लागू व्यावसायिक शर्तों को उस उत्पाद और खाते के लिए जाँचना चाहिए जिसका उपयोग हो रहा है।
Antigravity में Google के अनुसार Orchestrator एक ही डेवलपमेंट सेशन में Carbon और Hydrogen जैसे मॉडलों के बीच बदल सकता है। कठिन योजना Carbon संभाल सकता है, जबकि Hydrogen क्रियान्वयन या सत्यापन के चरण करता है। Google Terminal-Bench 4.0 पर Carbon के क़रीब टास्क सफलता की रिपोर्ट करता है, औसतन 24% कम कोटा खर्च और 19% तेज़ पूर्णता के साथ। Google यह नहीं बताता कि उसने कौन-सा थिंकिंग स्तर या सेटअप इस्तेमाल किया, या कितने टास्क थे। ये Google के अपने नतीजे हैं, और कोटा का आँकड़ा अपने आप किसी संगठन के बिल में 24% की कमी नहीं है। Orchestrator Google Antigravity का हिस्सा है, जिसे Google सशुल्क Google AI Pro और Ultra ग्राहकों को उपलब्ध कराता है। लॉन्च की घोषणा।
मॉडल रूटिंग और विशेषीकृत एजेंट पहले से स्थापित डिज़ाइन पैटर्न थे। इस आर्किटेक्चर में Hydrogen एक नया विकल्प है, मल्टी-मॉडल AI का आविष्कार नहीं।
एक मॉडल बनाम कई मॉडल: एक व्यावहारिक उदाहरण
रोल-बेस्ड एक्सेस-कंट्रोल फ़ीचर पर लौटते हैं। अनुरोध यह है कि प्रशासक भूमिकाएँ प्रबंधित कर सकें, लेकिन सामान्य उपयोगकर्ता प्रशासनिक एंडपॉइंट न चला सकें।
एक-मॉडल वर्कफ़्लो। कोडिंग असिस्टेंट रिपॉज़िटरी पढ़ता है, प्रभावित फ़ंक्शन पहचानता है, बदलाव सुझाता और लागू करता है, टेस्ट चलाता है और विफलताओं की जाँच करता है। इसका फ़ायदा निरंतरता है: एक मॉडल और एक मुख्य निष्पादन इतिहास। इसका नुकसान सरल उप-कार्यों पर महँगी तर्क-क्षमता का उपयोग हो सकता है। यह लागत तभी मायने रखती है जब वर्कलोड इतना बार-बार और इतना महँगा हो कि ऑप्टिमाइज़ेशन उचित ठहरे।
प्लानर-वर्कर वर्कफ़्लो। एक अधिक सक्षम मॉडल ऑथराइज़ेशन नियम, प्रभावित API हैंडलर, बैकग्राउंड वर्कर और डेटा निर्भरताएँ पहचानता है। वह एक सीमित टास्क (अनुमत फ़ाइलों, सुरक्षा अपरिवर्तनीय शर्तों और टेस्ट अपेक्षाओं सहित) निष्पादन मॉडल को सौंपता है। वर्कर बदलाव लागू करता है। वेरिफ़ायर नतीजे की जाँच करता है, और अप्रत्याशित डिज़ाइन प्रश्न चुपचाप वर्कर के तय करने के बजाय प्लानर के पास लौटते हैं।
इस चित्र का सुलभ पाठ विकल्प
एक मॉडल: रिपॉज़िटरी पढ़ना, बदलाव की योजना, कोड संपादित करना, एक्सेस टेस्ट चलाना, पास हों तो मंज़ूरी.
प्लानर, वर्कर और वेरिफ़ायर: प्लानर नियम तय करता है, वर्कर कोड संपादित करता है, वेरिफ़ायर नतीजा जाँचता है, एक्सेस टेस्ट चलाना, पास हों तो मंज़ूरी.
दोनों डिज़ाइन डिटरमिनिस्टिक एक्सेस-कंट्रोल टेस्ट पर समाप्त होते हैं। तीन भूमिकाएँ ज़रूरी नहीं कि तीन अलग मॉडल हों।
यह दूसरा वर्कफ़्लो कुशल हो सकता है, लेकिन यह एक ख़तरनाक विफलता का तरीका भी लाता है। मान लीजिए प्लानर भूल जाता है कि एक बैकग्राउंड जॉब भी अनुमतियाँ लागू करता है। वर्कर लिखित टास्क को पूरी तरह लागू कर सकता है और जॉब को असुरक्षित छोड़ सकता है। उसी अधूरे ब्रीफ़ का उपयोग करने वाला वेरिफ़ायर इसे मंज़ूर कर सकता है।
समाधान केवल एक और AI समीक्षक नहीं है। एप्लिकेशन को प्रामाणिक आवश्यकताएँ और डिटरमिनिस्टिक एक्सेस-कंट्रोल टेस्ट चाहिए, जिनमें नेगेटिव टेस्ट भी हों जो दिखाएँ कि अनधिकृत उपयोगकर्ताओं को रोका जाता है। AI बदलाव सुझाने और जाँचने में मदद कर सकता है, लेकिन अनुमतियों को लागू करना सॉफ़्टवेयर और उसके डिप्लॉयमेंट नियंत्रणों की ज़िम्मेदारी है।
मल्टी-मॉडल ऑर्केस्ट्रेशन कैसे काम करता है
ऑर्केस्ट्रेटर टास्क सौंपता है, प्रासंगिक संदर्भ देता है, टूल कॉल का समन्वय करता है, नतीजे दर्ज करता है और तय करता है कि कब दोबारा कोशिश करनी है, एस्केलेट करना है या रुकना है। एक आम पैटर्न में तीन भूमिकाएँ होती हैं:
- प्लानर: अनुरोध की व्याख्या करता है, निर्भरताओं की जाँच करता है और क्रियान्वयन की सीमाएँ तय करता है।
- वर्कर: कोड संपादित करने, प्रमाण जुटाने या टेस्ट विफलता की जाँच करने जैसी सीमित गतिविधियाँ करता है।
- वेरिफ़ायर: आउटपुट को टास्क के सामने जाँचता है और अनुपस्थित प्रमाण या खामियों की रिपोर्ट करता है।
ये भूमिकाएँ हैं, ज़रूरी नहीं कि तीन अलग मॉडल हों। एक ही मॉडल कई भूमिकाएँ निभा सकता है, और टेस्ट या पॉलिसी इंजन AI मॉडल के बिना भी महत्वपूर्ण सत्यापन कर सकते हैं।
कुछ उपयोगी विविधताएँ हैं। सीक्वेंशियल रूटिंग में एक चरण काम अगले चरण को सौंपता है। पैरेलल एक्ज़ीक्यूशन में स्वतंत्र वर्कर अलग-थलग वर्कस्पेस में काम करते हैं और नतीजे बाद में जोड़े जाते हैं। एस्केलेशन रूटिंग में कम लागत वाला मॉडल नियमित अनुरोध संभालता है लेकिन अनिश्चित मामलों को अधिक सक्षम मॉडल को भेज देता है।
इससे भी सरल विकल्प यह है कि एक ही मॉडल रखें और उसका थिंकिंग प्रयास बदलें। Hydrogen के चार स्तर इसे एक स्पष्ट विकल्प बनाते हैं। ऑर्केस्ट्रेटर बनाने से पहले परखें कि क्या नियमित काम के लिए कम थिंकिंग स्तर काफ़ी है और कठिन मामलों के लिए high स्तर।
यह लेख टास्क-स्तर के ऑर्केस्ट्रेशन की बात करता है। केंद्रीकृत क्रेडेंशियल, मॉडल की पात्रता, कोटा और प्रदाता नीतियों जैसे व्यापक सवालों के लिए TechiesJournal का API Gateway vs AI Gateway: Architecture, Design Patterns और Real-World Use Cases एक अलग आर्किटेक्चर सीमा को समझाता है। गेटवे यह नियंत्रित कर सकता है कि कोई एप्लिकेशन किन मॉडलों को कॉल कर सकता है। वह अपने आप यह तय नहीं करता कि एप्लिकेशन के टास्क की योजना और सत्यापन कैसे हो।
क्या कई मॉडल इस्तेमाल करने से सच में पैसे बचते हैं?
एक अकेले अनुरोध की कीमत किसी वर्कफ़्लो को पूरा करने की लागत नहीं होती। प्लानर-वर्कर डिज़ाइन कम महँगे अनुरोध भेज सकता है, लेकिन वह संदर्भ भी स्थानांतरित करता है, समन्वय में अतिरिक्त टोकन खर्च करता है, विफलताओं पर दोबारा कोशिश करता है और सत्यापन करता है।
एक काल्पनिक वर्कलोड पर विचार कीजिए जिसमें एक-मॉडल तरीके की लागत सफलतापूर्वक पूरे हुए प्रति टास्क $0.40 है। दूसरा आर्किटेक्चर प्लानिंग और वर्कर कॉल में देखने पर $0.25 का पड़ता दिखता है, लेकिन दोबारा कोशिश और समीक्षा का ओवरहेड अंतिम लागत को $0.38 कर देता है। उसकी 37.5% की स्पष्ट बचत घटकर 5% रह जाती है। ये संख्याएँ उदाहरण के लिए हैं, Hydrogen के माप नहीं।
लेटेंसी भी इसी तरह काम करती है। स्वतंत्र टास्क समानांतर चलें तो जल्दी पूरे हो सकते हैं। क्रमिक हैंडऑफ़ किसी टास्क को धीमा कर सकते हैं। उपयोगी पैमाने हैं: सही ढंग से पूरे हुए प्रति टास्क की लागत, शुरू से अंत तक लगा समय, विफलता दर और मानवीय हस्तक्षेप। केवल इनपुट/आउटपुट टोकन की कीमतें गिनने से महँगा दोबारा काम छिप सकता है।
थिंकिंग प्रयास भी अर्थशास्त्र बदलता है। Artificial Analysis के स्वतंत्र माप Hydrogen के लिए यह रिपोर्ट करते हैं, जैसा 13 नवंबर 2026 को सूचीबद्ध था (पेज माप की तारीख नहीं देते):
| थिंकिंग सेटिंग | Intelligence Index | प्रति मूल्यांकित टास्क लागत | प्रति मूल्यांकित टास्क समय |
|---|---|---|---|
| High | 51 | US$1.87 | 7.9 मिनट |
| Xhigh | 54 | US$3.16 | 13.7 मिनट |
ये समय और लागत Artificial Analysis Intelligence Index टास्क के लिए हैं, सामान्य कोडिंग अनुरोधों के लिए नहीं। Xhigh इंडेक्स को तीन अंक बढ़ाता है, जबकि मापी गई लागत लगभग 69% और समय लगभग 73% बढ़ा देता है। सही चुनाव इस पर निर्भर है कि अतिरिक्त तर्क एप्लिकेशन के नतीजे को सच में बेहतर करता है या नहीं। High का माप · Xhigh का माप।
Hydrogen अन्य विक्रेताओं के मॉडलों से कैसे तुलना करता है
अलग-अलग टास्क के लिए अलग मॉडल देने वाला Google अकेला नहीं है। विकल्पों में कोडिंग में सक्षम अन्य मॉडल और रूटिंग, एक्सट्रैक्शन और बार-बार होने वाले कम जोखिम वाले कार्यों के लिए उपयुक्त छोटे विकल्प शामिल हैं। नीचे की तालिका 13 नवंबर 2026 को देखी गई, US डॉलर में प्रति मिलियन इनपुट/आउटपुट टोकन की प्रकाशित मानक API दरें देती है। प्रदाता-विशिष्ट शर्तें, कैशिंग, टूल शुल्क, टोकनाइज़ेशन और सेवा स्तर वास्तविक लागत को प्रभावित कर सकते हैं।
| मॉडल और प्रदाता | इनपुट / आउटपुट | प्रासंगिक उपयोग या विशेषता |
|---|---|---|
| Gemini 4 Hydrogen (Google) | $1.50 / $7.50 | निष्पादन-केंद्रित कोडिंग, एजेंट, कॉन्फ़िगर किया जा सकने वाला थिंकिंग |
| GPT-6.1 Sol (OpenAI) | $2.00 / $10.00 | जटिल कामों के लिए Astra के क़रीब प्रदर्शन, कम लागत पर, OpenAI के अनुसार |
| Claude Sonnet 5.5 (Anthropic) | $2.00 / $10.00 | गति और बुद्धिमत्ता का संतुलन, Anthropic के अनुसार |
| Mistral Small 4 (Mistral) | $0.15 / $0.60 | हाइब्रिड तर्क और कोडिंग, Apache 2.0 लाइसेंस, ओपन वेट |
| DeepSeek V4.1 Flash 1017 (Mistral द्वारा होस्ट) | $0.30 / $1.20 | थर्ड-पार्टी होस्ट किया गया लंबे संदर्भ वाला कोडिंग मॉडल, पब्लिक प्रीव्यू |
दरें और भूमिकाएँ: Google, OpenAI, Anthropic, Mistral Small 4, Mistral द्वारा होस्ट किया गया DeepSeek। DeepSeek की पंक्ति Mistral की होस्टिंग कीमत है, सत्यापित सीधी DeepSeek API कीमत नहीं। ये पंक्तियाँ एक जैसे बेंचमार्क प्रदर्शन या समान सेवा शर्तों का संकेत नहीं देतीं।
OpenAI कठिन कामों के लिए GPT-6 Astra, लागत और क्षमता के संतुलन के लिए GPT-6.1 Sol और अधिक मात्रा वाले केंद्रित कामों के लिए GPT-6 Luna देता है। बाद वाला प्रति मिलियन टोकन $0.10 इनपुट और $0.50 आउटपुट पर सूचीबद्ध है, लेकिन कम कीमत यह साबित नहीं करती कि वह किसी अधिक सक्षम कोडिंग एजेंट की जगह ले सकता है। डेवलपर को टास्क-सफलता दरों की वास्तविक तुलना करनी चाहिए। OpenAI मॉडल कैटलॉग।
Anthropic भी इसी तरह Sonnet 5.5 को Haiku 5.5 से अलग करता है, जिसे Anthropic अधिक मात्रा वाले, लेटेंसी-संवेदनशील कार्यों, जैसे क्लासिफ़िकेशन, एक्सट्रैक्शन और रूटिंग, के लिए रखता है। Anthropic Haiku को प्रति मिलियन टोकन $0.10 इनपुट और $0.50 आउटपुट से शुरू होने वाला बताता है। अलग-अलग टोकनाइज़र और प्रयास सेटिंग केवल सूची-कीमत पर आधारित तुलनाओं को जटिल बनाते हैं। Anthropic मॉडल।
Mistral Small 4 एक अलग आयाम जोड़ता है: ओपन वेट और डिप्लॉयमेंट की लचीलापन। संगठन सेल्फ़-होस्टिंग का मूल्यांकन कर सकते हैं, लेकिन सर्वर, उपयोग दर, निगरानी और रखरखाव वास्तविक लागतें हैं। कम API कीमत और ओपन लाइसेंस कुल लागत कम होने की गारंटी के बराबर नहीं हैं। Mistral दस्तावेज़।
DeepSeek V4.1 Flash 1017 अपडेट किया गया 17 अक्टूबर का रिलीज़ है, जो DeepSeek की API में deepseek-flash के तहत उपलब्ध है, उसके चेंज लॉग के अनुसार। Mistral इसे Mistral के बदलावों के बिना थर्ड-पार्टी पब्लिक-प्रीव्यू मॉडल के रूप में भी देता है। इन पेशकशों की कीमतें और परिचालन शर्तें अलग हो सकती हैं। हमें DeepSeek द्वारा रिपोर्ट किए गए Terminal-Bench 4.0 नतीजे को किसी अन्य विक्रेता के Terminal-Bench 4.1 स्कोर से सीधे तुलनीय नहीं मानना चाहिए।
फ़ैसला यह नहीं है कि कौन-सा विक्रेता किसी सामान्य लीडरबोर्ड पर जीतता है। फ़ैसला यह है कि कोई विशेष मॉडल चुनी गई भूमिका को इच्छित टूल और सुरक्षा सीमाओं के साथ भरोसे से निभाता है या नहीं। कभी सबसे अच्छा डिज़ाइन एक ही प्रदाता और कई स्तरों का उपयोग करता है। कभी अलग विक्रेता मूल्य जोड़ता है। विक्रेताओं के आर-पार संचालन API, गोपनीयता, उपलब्धता और समस्या-निवारण की जटिलता भी जोड़ता है।
जहाँ मल्टी-मॉडल ऑर्केस्ट्रेशन विफल हो सकता है
दूसरा मॉडल टास्क की दूसरी व्याख्या लाता है। जब प्लानर मूल समस्या को ब्रीफ़ में सीमित कर देता है तो आवश्यकताएँ खो सकती हैं। वर्कर ऐसा कोड बना सकते हैं जो संगत दिखता है लेकिन छूटी हुई बाधा का उल्लंघन करता है। पैरेलल एजेंट परस्पर विरोधी इंटरफ़ेस संपादित कर सकते हैं, और समीक्षक कोड लिखने वाले की गलत धारणा साझा कर सकते हैं।
इसलिए ऑर्केस्ट्रेटर को स्पष्ट टास्क कॉन्ट्रैक्ट, सीमित अनुमतियाँ, हर टूल कार्रवाई का प्रमाण, एस्केलेशन नियम और टेस्ट किए जा रहे सटीक बदलावों को पहचानने का भरोसेमंद तरीका चाहिए। किसी मॉडल को केवल इसलिए अपनी प्रोडक्शन डिप्लॉयमेंट मंज़ूर करने की अनुमति नहीं मिलनी चाहिए कि उसकी बनाई व्याख्या विश्वसनीय लगती है।
Google का मॉडल कार्ड शेष हैलुसिनेशन, धीमेपन, टाइमआउट और बढ़े हुए टोकन उपयोग के जोखिम भी दर्ज करता है। Gemini 3.8 Flash की तुलना में आंतरिक स्वचालित सुरक्षा मूल्यांकनों में Google अनुचित इनकारों में 5.57 प्रतिशत-अंक की वृद्धि रिपोर्ट करता है। Google कहता है कि बाद की मैन्युअल समीक्षा में पाया गया कि चिह्नित अधिकांश नुकसान फ़ॉल्स पॉज़िटिव थे या गंभीर नहीं थे। दोनों हिस्से मायने रखते हैं: रिपोर्ट के अनुसार स्वचालित गिरावट वास्तविक है, लेकिन यह समतुल्य वास्तविक-दुनिया के नुकसान का प्रमाण नहीं है।
सक्षम एजेंटों को फिर भी स्वतंत्र जवाबदेही क्यों चाहिए, इस पर व्यापक चर्चा के लिए TechiesJournal का AI काम करने में बेहतर होता जा रहा है। लेकिन क्या वह नतीजे की ज़िम्मेदारी उठाने के लिए तैयार है? देखें। इस लेख का अधिक सीमित सवाल यह है कि टास्क का कौन-सा हिस्सा कौन-सा मॉडल करे, यह नहीं कि प्रोडक्शन के नतीजों का अंतिम स्वामी कौन है।
बेंचमार्क क्या स्थापित करते हैं और क्या नहीं
Google का मॉडल कार्ड cheating-adjusted Terminal-Bench 4.1 पर Hydrogen के लिए 57.0% रिपोर्ट करता है, जबकि Claude Sonnet 5.5 के लिए 63.9%। कुछ अन्य रिपोर्ट किए गए मूल्यांकनों में Hydrogen बेहतर है। Agents’ Last Exam v1.1 पर कार्ड Hydrogen के लिए 71.6% और Claude Sonnet 5.5 के लिए 60.4% सूचीबद्ध करता है, और Hydrogen चुनिंदा मल्टीमॉडल टास्क पर भी आगे है। कोई मॉडल एक वर्कलोड में आगे और दूसरे में पीछे हो सकता है, इसमें कोई विरोधाभास नहीं है। Google मॉडल कार्ड।
मेथडोलॉजी रिपोर्ट अलग-अलग मूल्यांकन हार्नेस और कॉन्फ़िगरेशन की पहचान कराती है। उदाहरण के लिए, Google का Terminal-Bench 4.1 नतीजा एक तय हार्नेस में प्रति टास्क पाँच कोशिशों का औसत लेता है, जबकि कई प्रतिस्पर्धी नतीजे सार्वजनिक लीडरबोर्ड या विक्रेता रिपोर्टों से आते हैं। जब कोई सुर्खी वाली संख्या परीक्षण की शर्तों के बिना पेश की जाए तो यह मायने रखता है।
Artificial Analysis Hydrogen की बुद्धिमत्ता, गति और लागत की कुछ विशेषताओं को स्वतंत्र रूप से मापता है, लेकिन वे माप भी एक तय बेंचमार्क को दर्शाते हैं, किसी निजी एप्लिकेशन रिपॉज़िटरी के बारे में गारंटी को नहीं।
प्रमाण एक अधिक सीमित निष्कर्ष का समर्थन करते हैं: निष्पादन-केंद्रित वर्कफ़्लो के लिए Hydrogen एक विश्वसनीय विकल्प है, और Google का ऑर्केस्ट्रेशन प्रयोग संभावित दक्षता लाभ का सुझाव देता है। यह यह साबित नहीं करता कि मॉडल रूटिंग हर जगह सस्ती, अधिक भरोसेमंद या अधिक सुरक्षित है। एप्लिकेशनों को फिर भी प्रतिनिधि टास्क पर अपना मूल्यांकन चाहिए।
डेवलपर आर्किटेक्चर कैसे चुनें
एक मॉडल और प्रतिनिधि टास्क के छोटे समूह से शुरू करें। हमारे रोल-बेस्ड एक्सेस-कंट्रोल परिदृश्य के लिए एक सामान्य क्रियान्वयन मामला रखें, एक छिपी निर्भरता वाला, और एक ऐसा जिसे अस्वीकार करना ज़रूरी है क्योंकि माँगा गया ऑपरेशन अनुमतियों से बाहर है। हर तुलना में वही कोडबेस, टूल, आवश्यकताएँ और सफलता मानदंड इस्तेमाल करें।
दर्ज करें कि असिस्टेंट ने प्रभावित सीमाएँ पहचानीं या नहीं, ऑथराइज़ेशन टेस्ट पास हुए या नहीं, कुल बीता समय, प्रदाता के वास्तविक शुल्क, दोबारा कोशिशें और कोई भी मानवीय सुधार। फिर किसी सीमित चरण पर कम तर्क सेटिंग या सस्ता मॉडल आज़माएँ। नतीजे उचित ठहराएँ तभी प्लानर-वर्कर हैंडऑफ़ जोड़ें।
| स्थिति | उचित शुरुआती तरीका |
|---|---|
| छोटा या कभी-कभार होने वाला टास्क | एक सक्षम मॉडल |
| अधिक मात्रा में एक्सट्रैक्शन या क्लासिफ़िकेशन | कम लागत वाला मॉडल, सटीकता के लिए परखा हुआ |
| जटिल योजना और पूर्वानुमेय क्रियान्वयन | प्लानर-वर्कर पृथक्करण का मूल्यांकन करें |
| नियंत्रित इंटरफ़ेस वाले स्वतंत्र टास्क | पैरेलल वर्कर पर विचार करें |
| सुरक्षा-संवेदनशील या प्रोडक्शन बदलने वाली कार्रवाइयाँ | डिटरमिनिस्टिक जाँचें और अनिवार्य ऑथराइज़ेशन, मॉडलों की संख्या चाहे जो हो |
| अनिश्चित आवश्यकताएँ या सीमित इंजीनियरिंग क्षमता | प्रमाण बदलाव के पक्ष में होने तक सरल आर्किटेक्चर रखें |
अगर रूटिंग लाई जाए, तो दर्ज करें कि किस मॉडल ने कौन-सा टास्क संभाला, उसे क्यों चुना गया और स्वीकृति को किस प्रमाण ने उचित ठहराया। नहीं तो लागत और भरोसेमंदी की समस्याओं का निदान मुश्किल हो जाता है।
डेवलपर आगे क्या करें
Hydrogen AI सिस्टम में एक वास्तविक दिशा दर्शाता है: डेवलपर सभी अनुरोधों को बराबर मानने के बजाय अलग-अलग तरह के काम के लिए मॉडल और तर्क सेटिंग चुन सकते हैं। Google ने निष्पादन-केंद्रित मॉडल और Antigravity Orchestrator के साथ इस विभाजन को अधिक स्पष्ट बनाया है।
लेकिन अधिक विकल्प इंजीनियर की अच्छी तरह चुनने की ज़िम्मेदारी को नहीं हटाते। जो मल्टी-मॉडल डिज़ाइन टोकन बचाता है लेकिन ज़रूरी आवश्यकताएँ खो देता है, वह सुधार नहीं है। जो एक मॉडल वर्कलोड को स्वीकार्य लागत पर भरोसे से पूरा करता है, वही बेहतर आर्किटेक्चर हो सकता है।
व्यावसायिक या इंजीनियरिंग टास्क से शुरू करें। मापने योग्य आधार रेखा तय करें, देखें कि तर्क का प्रयास कहाँ उपयोगी है और वह सबसे छोटा बदलाव परखें जो नतीजा सुधार सकता है। ऑर्केस्ट्रेशन तभी जोड़ें जब प्रमाण दिखाएँ कि अतिरिक्त सीमाएँ सार्थक हैं।
लक्ष्य अधिक AI मॉडल इस्तेमाल करना नहीं है। लक्ष्य सही क्षमता को सही काम में लगाना है, और हर जोड़ी गई परत को अपनी जगह कमाने देना है।
संदर्भ और आगे की पढ़ाई
- Google: Introducing Gemini 4 Hydrogen (12 November 2026): स्थिति, कीमतें और Orchestrator के दावे।
- Google DeepMind: Gemini 4 Hydrogen model card (12 November 2026): आर्किटेक्चर, संदर्भ, बेंचमार्क नतीजे, सीमाएँ और सुरक्षा डेटा।
- Google DeepMind: Hydrogen evaluation methodology (November 2026): हार्नेस, स्कोरिंग के तरीके और तुलना की सीमाएँ।
- Artificial Analysis: Hydrogen high और Hydrogen xhigh: स्वतंत्र बुद्धिमत्ता, लागत और अवधि के माप।
- OpenAI: API model catalog: आधिकारिक मॉडल स्थितियाँ और सूचीबद्ध टोकन कीमतें।
- Anthropic: Model overview: Claude के स्तर, वर्कलोड और कीमतें।
- Mistral: Small 4 specifications: मॉडल की क्षमताएँ, लाइसेंसिंग और कीमतें।
- DeepSeek: API change log और Mistral: hosted DeepSeek V4.1 Flash: संस्करण और होस्टिंग-विशिष्ट विवरण।
स्रोत 13 नवंबर 2026 को पढ़े गए थे। विक्रेताओं की कीमतें, मॉडल की शर्तें और उपलब्धता बदल सकती हैं।