E2E Blaze टोकन के हिसाब से बिल देगा, लेकिन दरें अभी सार्वजनिक नहीं

E2E Networks ने 2 नवंबर 2026 को Blaze की शुरुआत की। भारत में होस्ट की गई यह सेवा खुले AI मॉडल के जवाब एक OpenAI-संगत API से देती है और इस्तेमाल हुए टोकन के हिसाब से बिल बनाती है। छोटे दल को शुरुआती प्रयोग के लिए अलग GPU किराये पर लेने की जरूरत नहीं पड़ती, लेकिन केवल बिलिंग की पद्धति जानकर महीने का खर्च नहीं निकाला जा सकता।

कंपनी का Blaze सुविधा पृष्ठ भारतीय डेटा केंद्रों, INR में बिलिंग और अनुरोध पर API पहुँच का विवरण देता है; उस पर प्रति-टोकन दरों की सार्वजनिक तालिका नहीं है। DQ India की रिपोर्ट के अनुसार लॉन्च घोषणा में विस्तृत दरें, स्वतंत्र प्रदर्शन माप और Blaze के लिए विशिष्ट सेवा स्तर भी प्रकाशित नहीं किए गए थे। इस स्थिति में छोटे AI उत्पाद के लिए खर्च और जवाब की गति, दोनों का अनुमान अपने उपयोग से लगाना होगा।

Blaze तक पहुँच और मौजूदा अनुप्रयोग को जोड़ना

Blaze शुरू हो चुका है, पर उसका सार्वजनिक प्रवेश रास्ता पहुँच के लिए अनुरोध करना है। कंपनी उपयोग का विवरण मिलने पर API और कंसोल की पहुँच देने की बात करती है। इसलिए किसी दल के लिए वास्तविक परीक्षण की शुरुआत कुंजी और अपने काम के लिए उपलब्ध मॉडल मिलने के बाद होगी। सार्वजनिक उत्पाद पृष्ठ पर तुरंत स्वयं पंजीकरण करके अनुरोध भेजने का स्पष्ट विकल्प नहीं दिखता।

पहले से OpenAI के अनुरोध प्रारूप पर बना अनुप्रयोग Blaze से अपेक्षाकृत सीधे जुड़ सकता है। कंपनी के उदाहरण में क्लाइंट का आधार-पता Blaze के पते पर बदला जाता है और Blaze की API कुंजी लगाई जाती है; बातचीत वाले अनुरोध का प्रारूप परिचित रहता है। फिर भी सही मॉडल पहचानकर्ता, समर्थित क्षमता और जवाब का स्वरूप चुनना होगा। समान API प्रारूप अलग मॉडल से समान उत्तर, समान गति या समान खर्च की गारंटी नहीं देता।

Blaze के कैटलॉग में पाठ, आवाज़, लिखे हुए पाठ की पहचान यानी OCR, बहु-माध्यम और चित्र निर्माण के मॉडल शामिल हैं। कंपनी Gemma, Qwen, DeepSeek, GLM और भारतीय भाषाओं से जुड़े Sarvam मॉडल भी गिनाती है। कंसोल में मॉडल का API पहचानकर्ता, क्षमता, संदर्भ सीमा और अधिकतम उत्तर लंबाई दिखाई जाती है। किसी उत्पाद में इन विवरणों का असर सीधा है: दस्तावेज़ पढ़ने, बातचीत करने और आवाज़ से जवाब देने के काम एक ही तरह के अनुरोध या खर्च के आधार पर नहीं आँके जा सकते।

टोकन बिलिंग में छोटे दल के तीन लागत-दृश्य

टोकन आधारित सेवा में स्थायी GPU क्षमता जुटाने का शुरुआती काम प्रदाता संभालता है, जबकि ग्राहक का बिल उपयोग के साथ बदलता है। यह अनियमित माँग वाले उत्पाद के लिए उपयोगी संरचना हो सकती है, पर सस्ती होने का निष्कर्ष प्रकाशित दर के बिना नहीं निकलता। तुलना को ठोस बनाने के लिए नीचे तीन काल्पनिक उपयोग-दृश्य हैं। हर दृश्य में एक अनुरोध के लिए 1,000 इनपुट और 250 आउटपुट टोकन, एक ही मॉडल और कोई पुनः प्रयास नहीं माना गया है; ये Blaze के मापे हुए परिणाम नहीं हैं।

• अनियमित प्रयोग: महीने में 100 अनुरोध हों तो कुल 1,00,000 इनपुट और 25,000 आउटपुट टोकन बनेंगे। इस स्तर पर कुछ लंबे परीक्षण या बार-बार बदले गए निर्देश औसत अनुरोध से अधिक असर डाल सकते हैं। दल को कुल टोकन के साथ सफल जवाबों की संख्या भी देखनी होगी।
• रोज़ का मध्यम उपयोग: 30 दिन तक रोज़ 300 अनुरोध हों तो महीने में 90,00,000 इनपुट और 22,50,000 आउटपुट टोकन होंगे। एक ही औसत से व्यस्त दिन का खर्च और जवाब आने में लगने वाला समय छिप सकता है, इसलिए दैनिक उपयोग का फैलाव मायने रखता है।
• लगातार उत्पादन: 30 दिन तक रोज़ 3,000 अनुरोध हों तो 9,00,00,000 इनपुट और 2,25,00,000 आउटपुट टोकन बनेंगे। इस मात्रा पर प्रति अनुरोध थोड़ी अतिरिक्त खपत, पुनः प्रयास या लंबे जवाब मासिक बिल में स्पष्ट अंतर ला सकते हैं।

यदि Blaze किसी पाठ मॉडल की दर प्रति दस लाख इनपुट और आउटपुट टोकन अलग-अलग घोषित करता है, तो हर दृश्य की दोनों मात्राओं को उनकी अपनी दर से गुणा करके जोड़ना होगा। उदाहरण के पहले दृश्य में गुणक क्रमशः 0.1 और 0.025 होंगे; दूसरे में 9 और 2.25; तीसरे में 90 और 22.5। यह रुपये का अनुमान नहीं है, क्योंकि इन गुणकों पर लगाने के लिए Blaze की सार्वजनिक दर मौजूद नहीं है। आवाज़, OCR और चित्र वाले कामों की बिलिंग इकाई भी केवल पाठ टोकन मानकर नहीं चलनी चाहिए।

Blaze पर सीमित परीक्षण से कौन-से आँकड़े मिलेंगे

कंपनी Blaze कंसोल में टोकन उपयोग, प्रदर्शन और लागत का विश्लेषण उपलब्ध कराने की बात करती है। छोटे उत्पाद के लिए उस विश्लेषण को अपने अनुप्रयोग के सफल और असफल अनुरोधों से जोड़ना जरूरी होगा। उदाहरण के लिए, लंबे दस्तावेज़ से जवाब और छोटे सवाल से जवाब एक ही गिनती के अनुरोध हैं, लेकिन उनके इनपुट टोकन अलग हो सकते हैं। वास्तविक उपयोग के नमूने के बिना औसत खर्च जल्दी भ्रामक हो जाएगा।

• खपत: चुने हुए मॉडल और कार्य के अनुसार इनपुट, आउटपुट तथा दोबारा भेजे गए अनुरोध अलग दर्ज हों। तभी प्रति सफल जवाब की खपत और कुल बिल के बीच संबंध दिखेगा।
• विलंब और त्रुटि: सामान्य और व्यस्त समय में जवाब आने की अवधि, समय सीमा पार होने की घटनाएँ और पुनः प्रयास गिने जाएँ। कम टोकन खर्च वाला विकल्प धीमे या बार-बार असफल जवाबों के कारण उत्पाद के लिए कम उपयोगी हो सकता है।
• मॉडल बदलाव: तय मॉडल के परिणाम और Blaze के स्वचालित मॉडल चयन के परिणाम अलग रखे जाएँ। स्वचालित चयन में अलग अनुरोध अलग मॉडल तक जा सकते हैं, इसलिए गुणवत्ता, गति और खपत को एक स्थिर मॉडल का परिणाम मानना गलत होगा।
• मासिक सीमा: मापी गई दैनिक खपत को अपेक्षित व्यस्त और शांत दिनों से जोड़कर स्वीकार्य बजट से मिलाया जाए। खर्च अपने आप रोकने की सुविधा उपलब्ध है या नहीं, यह पहुँच मिलने पर स्पष्ट करना होगा।

इस माप से दल दर प्रकाशित होने या खाते में दिखाई देने पर अपने अनुरोधों का मासिक अनुमान बना सकेगा। स्वतंत्र प्रदर्शन आँकड़ों के अभाव में किसी दूसरे प्रदाता के मुकाबले गति या गुणवत्ता का दावा करना अभी संभव नहीं है। मूल्यांकन में एक ही काम, समान इनपुट और सफलता का समान मानदंड रखना होगा; केवल प्रति टोकन दर से उपयोगी जवाब की लागत नहीं निकलती।

भारतीय होस्टिंग का असर

Blaze भारत स्थित E2E Networks अवसंरचना पर चलता है और बिल INR में बनाता है। इससे भारतीय दल को मॉडल चलने की जगह और भुगतान की मुद्रा के बारे में स्पष्ट जानकारी मिलती है। सर्वर का स्थान अपने आप किसी खास डेटा नियम के अनुपालन या भेजे गए डेटा के पूरे व्यवहार को सिद्ध नहीं करता; संवेदनशील सामग्री वाले उत्पाद के लिए पहुँच की शर्तें और डेटा प्रबंधन अलग प्रश्न बने रहते हैं।

कंपनी मॉडल होस्टिंग, क्षमता और अनुरोधों के संचालन की जिम्मेदारी अपने मंच पर रखती है। दल के सामने अगला निर्णायक विवरण चुने हुए मॉडल की लागू दर और गैर-पाठ अनुरोधों की बिलिंग इकाई है। इन्हें अपने सीमित परीक्षण की खपत, विलंब और त्रुटियों के साथ जोड़ने पर ही समर्पित GPU किराये और Blaze के मासिक खर्च की अर्थपूर्ण तुलना बन सकेगी।

यह भी पढ़ें:

• AI-संवेदनशील शुरुआती नौकरियों में 19% अंतर—कारण अभी सिद्ध नहीं
• Windows Age API जन्मतिथि नहीं देगा—और अभी कॉल खाली लौट सकती है
• SageMaker का GPU-सचेत द्वार—82% तेज पहला टोकन AWS का अपना दावा