जानें कि WebAssembly और WebGPU को बेहतर बनाने की सुविधा, वेब पर मशीन लर्निंग की परफ़ॉर्मेंस को कैसे बेहतर बनाती है.
वेब पर एआई का अनुमान
हम सभी ने सुना है कि एआई हमारी दुनिया को बदल रहा है. वेब भी इससे अछूता नहीं है.
इस साल Chrome ने जनरेटिव एआई की सुविधाएं जोड़ी हैं. इनमें पसंद के मुताबिक थीम बनाना और टेक्स्ट का पहला ड्राफ़्ट लिखने में आपकी मदद करना शामिल है. एआई टेक्नोलॉजी से कहीं ज़्यादा ज़रूरी है; एआई, वेब ऐप्लिकेशन को बेहतर बना सकता है.
दृष्टि के लिए, वेब पेजों में स्मार्ट कॉम्पोनेंट जोड़े जा सकते हैं. जैसे, चेहरे की पहचान करना या जेस्चर की पहचान करना, ऑडियो की कैटगरी तय करने या भाषा की पहचान करने के लिए. पिछले साल, हमने जनरेटिव एआई की लोकप्रियता में सुधार देखा. इसमें वेब पर बड़े लैंग्वेज मॉडल के कुछ शानदार डेमो भी शामिल हैं. वेब डेवलपर के लिए, उपयोगकर्ता के डिवाइस पर मौजूद एआई (AI) की सुविधा को ज़रूर देखें.
फ़िलहाल, वेब पर एआई के अनुमान की सुविधा ज़्यादातर डिवाइसों के लिए उपलब्ध है. साथ ही, एआई प्रोसेसिंग को वेब पेज पर भी प्रोसेस किया जा सकता है. इसके लिए, उपयोगकर्ता के डिवाइस के हार्डवेयर का इस्तेमाल किया जाता है.
यह कई कारणों से शक्तिशाली है:
- लागत में कमी: ब्राउज़र क्लाइंट पर अनुमान लगाने से सर्वर की लागत काफ़ी कम हो जाती है. यह जेन एआई वाली क्वेरी के लिए खास तौर पर काम का हो सकता है. यह सामान्य क्वेरी से ज़्यादा महंगा हो सकता है.
- इंतज़ार: ऐसे ऐप्लिकेशन जो ऑडियो या वीडियो ऐप्लिकेशन जैसे इंतज़ार के समय को लेकर काफ़ी संवेदनशील होते हैं, उनके लिए डिवाइस पर पूरी प्रोसेस होने से इंतज़ार का समय कम हो जाता है.
- निजता: क्लाइंट-साइड पर काम करने से, ऐप्लिकेशन की ऐसी नई कैटगरी भी अनलॉक हो सकती है जिसके लिए ज़्यादा निजता की ज़रूरत होती है. ऐसे में, सर्वर पर डेटा नहीं भेजा जा सकता.
वेब पर एआई वर्कलोड कैसे काम करते हैं
फ़िलहाल, ऐप्लिकेशन डेवलपर और रिसर्चर, फ़्रेमवर्क का इस्तेमाल करके मॉडल बनाते हैं. साथ ही, वे मॉडल Tensorflow.js या ONNX रनटाइम वेब जैसे रनटाइम का इस्तेमाल करके, ब्राउज़र में एक्ज़ीक्यूट करते हैं. साथ ही, रनटाइम, एक्ज़ीक्यूशन के लिए वेब एपीआई का इस्तेमाल करते हैं.
वे सभी रनटाइम आखिर में JavaScript या WebAssembly के ज़रिए या WebGL या WebGPU के ज़रिए जीपीयू पर, सीपीयू पर चलने की वजह से खत्म हो जाते हैं.
मशीन लर्निंग पर होने वाले काम
मशीन लर्निंग (एमएल) वर्कलोड, कंप्यूटेशनल नोड के ग्राफ़ के ज़रिए टेन्सर को पुश करते हैं. टेन्सर इन नोड के इनपुट और आउटपुट होते हैं, जो डेटा का बहुत ज़्यादा हिसाब लगाते हैं.
ऐसा इसलिए ज़रूरी है, क्योंकि:
- टेन्सर बहुत बड़े डेटा स्ट्रक्चर होते हैं. ये ऐसे मॉडल पर कंप्यूटेशन करते हैं जिनमें अरबों वज़न हो सकते हैं
- स्केलिंग और अनुमान से डेटा समानता हो सकती है. इसका मतलब है कि टेंसर में सभी एलिमेंट पर एक जैसी कार्रवाइयां की जाती हैं.
- ML के लिए सटीक जानकारी की ज़रूरत नहीं होती. चांद पर उतरने के लिए आपको 64-बिट के फ़्लोटिंग पॉइंट नंबर की ज़रूरत पड़ सकती है. हालांकि, चेहरे की पहचान करने के लिए, आपको सिर्फ़ 8-बिट या उससे कम संख्याओं की ज़रूरत पड़ सकती है.
अच्छी बात यह है कि चिप डिज़ाइनर ने मॉडल को तेज़ी से काम करने, ज़्यादा समय तक चलाने, और यहां तक कि उन्हें पूरी तरह से चलाने के लिए भी सुविधाएं जोड़ी हैं.
इस बीच, WebAssembly और WebGPU टीमों में, हम इन नई क्षमताओं को वेब डेवलपर को उपलब्ध कराने के लिए काम कर रहे हैं. अगर आप वेब ऐप्लिकेशन डेवलपर हैं, तो हो सकता है कि आप कम लेवल वाले इन प्रिमिटिव का बार-बार इस्तेमाल न करें. हमें उम्मीद है कि इस्तेमाल किए जा रहे टूलचेन या फ़्रेमवर्क, नई सुविधाओं और एक्सटेंशन के साथ काम करेंगे. इसलिए, आपको अपने इन्फ़्रास्ट्रक्चर में कम से कम बदलाव करने पर फ़ायदा मिलेगा. हालांकि, अगर आपको ऐप्लिकेशन की परफ़ॉर्मेंस को मैन्युअल तरीके से ऑप्टिमाइज़ करना है, तो ये सुविधाएं आपके काम के हिसाब से काम की हैं.
WebAssembly
WebAssembly (Wasm) एक छोटा और बेहतर बाइट कोड फ़ॉर्मैट है. रनटाइम इस फ़ॉर्मैट को समझ सकते हैं और इसे चला सकते हैं. इसे डिवाइस में मौजूद हार्डवेयर की क्षमता का फ़ायदा लेने के लिए डिज़ाइन किया गया है, ताकि यह स्थानीय स्पीड पर काम कर सके. कोड की पुष्टि की जाती है और वह मेमोरी को सुरक्षित रखने वाले और सैंडबॉक्स किए गए एनवायरमेंट में काम करता है.
Wasm मॉड्यूल की जानकारी को बहुत ज़्यादा बाइनरी एन्कोडिंग की मदद से दिखाया जाता है. टेक्स्ट-आधारित फ़ॉर्मैट के मुकाबले, इसका मतलब है, तेज़ी से डिकोड करना, ज़्यादा तेज़ी से लोड होना, और कम मेमोरी का इस्तेमाल करना. इसे इस हिसाब से पोर्टेबल किया जा सकता है कि इसमें मौजूद आर्किटेक्चर का अनुमान नहीं लगाया जा सकता, क्योंकि आधुनिक आर्किटेक्चर में पहले से कोई आम बात नहीं है.
WebAssembly की जानकारी बार-बार इस्तेमाल की जाती है. साथ ही, इस पर एक खुले W3C कम्यूनिटी ग्रुप में काम किया जाता है.
बाइनरी फ़ॉर्मैट, होस्ट एनवायरमेंट के बारे में कोई अनुमान नहीं लगाता. इसलिए, इसे वेब एम्बेड करने के बजाय किसी अन्य जगह पर भी अच्छी तरह से काम करने के लिए डिज़ाइन किया गया है.
आपके ऐप्लिकेशन को सिर्फ़ एक बार कंपाइल किया जा सकता है और हर जगह चलाया जा सकता है: डेस्कटॉप, लैपटॉप, फ़ोन या ब्राउज़र वाला कोई भी अन्य डिवाइस. इस बारे में ज़्यादा जानने के लिए, एक बार लिखें, WebAssembly की मदद से किसी भी जगह चलाएं लेख पढ़ें.
वेब पर एआई अनुमान चलाने वाले ज़्यादातर प्रोडक्शन ऐप्लिकेशन, WebAssembly का इस्तेमाल करते हैं. ये ऐप्लिकेशन, सीपीयू कंप्यूटिंग और खास मकसद वाले कंप्यूट, दोनों के लिए काम करते हैं. नेटिव ऐप्लिकेशन पर, आपके पास सामान्य मकसद और खास मकसद वाले कंप्यूट, दोनों को ऐक्सेस करने का विकल्प होता है. ऐसा इसलिए, क्योंकि ऐप्लिकेशन के पास डिवाइस की क्षमताओं को ऐक्सेस करने का विकल्प होता है.
वेब पर, पोर्टेबिलिटी और सुरक्षा के लिए, हम सावधानी से इस बात का मूल्यांकन करते हैं कि कौनसे प्रिमिटिव का सेट सार्वजनिक किया गया है. इससे वेब की सुलभता सुविधाओं और हार्डवेयर से मिलने वाले बेहतरीन परफ़ॉर्मेंस में मदद मिलती है.
WebAssembly, सीपीयू का एक पोर्टेबल एब्स्ट्रैक्ट है. इसलिए, सभी Wasm अनुमान सीपीयू पर ही चलते हैं. हालांकि, यह बेहतर परफ़ॉर्म करने वाला विकल्प नहीं है, लेकिन ज़्यादातर डिवाइसों पर सीपीयू उपलब्ध हैं और ज़्यादातर वर्कलोड पर काम करते हैं.
टेक्स्ट या ऑडियो वर्कलोड जैसे छोटे वर्कलोड के लिए, जीपीयू महंगा होगा. हाल ही में ऐसे कई उदाहरण दिए गए हैं जिनमें Wasm का इस्तेमाल करना सही है:
- Adobe, वेब पर Photoshop को बेहतर बनाने के लिए Tensorflow.js का इस्तेमाल करता है.
- Google Meet ने बैकग्राउंड को धुंधला करने की सुविधा जोड़ी है. यह वेब पर Wasm का इस्तेमाल करने वाले पहले वीडियो इफ़ेक्ट में से एक है.
- YouTube में ऑगमेंटेड रिएलिटी (एआर) के कई इफ़ेक्ट मौजूद हैं.
- Google Photos, ऑनलाइन फ़ोटो में बदलाव करने की अनुमति देता है.
ओपन सोर्स डेमो में आपको और ज़्यादा जानकारी मिल सकती है. जैसे: whisper-tiny, llama.cpp, और ब्राउज़र में चल रहे Gemma2B.
अपने आवेदनों पर पूरी तरह से नज़र रखें
आपको किसी खास एमएल मॉडल, ऐप्लिकेशन इंफ़्रास्ट्रक्चर, और उपयोगकर्ताओं के लिए ऐप्लिकेशन के इस्तेमाल के अनुभव के हिसाब से प्रिमिटिव चुनना चाहिए
उदाहरण के लिए, MediaPipe के फ़ेस लैंडमार्क की पहचान करने में, सीपीयू के अनुमान और जीपीयू के अनुमान की तुलना की जा सकती है (Apple M1 डिवाइस पर चल रहा होता है), लेकिन कुछ ऐसे मॉडल हैं जिनमें फ़र्क़ काफ़ी ज़्यादा हो सकता है.
जब मशीन लर्निंग के वर्कलोड की बात आती है, तो हम सभी ऐप्लिकेशन व्यू को ध्यान में रखते हैं. साथ ही, फ़्रेमवर्क के लेखकों और ऐप्लिकेशन पार्टनर की ज़रूरतों को ध्यान में रखते हैं, ताकि सबसे ज़्यादा अनुरोध किए गए सुधारों को डेवलप और शिप किया जा सके. इन्हें आम तौर पर तीन कैटगरी में रखा जाता है:
- परफ़ॉर्मेंस के लिए ज़रूरी सीपीयू एक्सटेंशन का इस्तेमाल करें
- बड़े मॉडल चलाने की सुविधा चालू करें
- अन्य वेब एपीआई के साथ बिना किसी रुकावट के इंटरऑप चालू करें
ज़्यादा तेज़ कंप्यूटिंग
जैसा कि साफ़ तौर पर बताया गया है, WebAssembly की खास जानकारी में निर्देशों के सिर्फ़ कुछ ऐसे सेट शामिल हैं जिन्हें हम वेब पर दिखाते हैं. हालांकि, हार्डवेयर में नए निर्देश जोड़े जाते हैं. इससे नेटिव और WebAssembly की परफ़ॉर्मेंस के बीच का अंतर बढ़ता है.
याद रखें कि एमएल मॉडल के लिए, हमेशा ज़्यादा सटीक जानकारी की ज़रूरत नहीं होती. रिलैक्स्ड सिमडी एक ऐसा सुझाव है जो कुछ सख्त और तय न की जाने वाली शर्तों को कम कर देता है. इससे ऐसे वेक्टर कोड के लिए तेज़ी से कोड जनरेट करने में मदद मिलती है जो बेहतर परफ़ॉर्म करते हैं. इसके अलावा, आरामदेह सिमडी में नया डॉट प्रॉडक्ट और एफ़एमए के निर्देश जोड़े गए हैं. इनकी मदद से, मौजूदा वर्कलोड 1.5 से तीन गुना तक बढ़ जाते हैं. यह Chrome 114 में भेजा गया था.
हाफ़-प्रीसिज़न फ़्लोटिंग पॉइंट फ़ॉर्मैट, IEEE FP16 के लिए, 32-बिट के बजाय 16-बिट का इस्तेमाल करता है. ये एक सटीक वैल्यू के लिए इस्तेमाल होते हैं. किसी सिंगल प्रिसिज़न वैल्यू की तुलना में, आधी सटीक वैल्यू का इस्तेमाल करने, मेमोरी की ज़रूरत को कम करने के कई फ़ायदे हैं. इससे बड़े न्यूरल नेटवर्क की ट्रेनिंग और डिप्लॉयमेंट, और मेमोरी बैंडविड्थ को कम करने में मदद मिलती है. कम सटीक होने की वजह से, डेटा ट्रांसफ़र और गणित के कामों की रफ़्तार बढ़ जाती है.
बड़े मॉडल
Wasm लीनियर मेमोरी में मौजूद पॉइंटर, 32-बिट पूर्णांक के तौर पर दिखाए जाते हैं. इसके दो नतीजे होते हैं: हीप साइज़ 4 जीबी तक सीमित होता है (जब कंप्यूटर में उससे ज़्यादा रैम होती है) और Wasm को टारगेट करने वाला ऐप्लिकेशन कोड 32-बिट पॉइंटर साइज़ (जिसका) के साथ काम करता हो.
खास तौर पर, हमारे मौजूदा जैसे बड़े मॉडल की वजह से, इन मॉडल को WebAssembly में लोड करना प्रतिबंधित हो सकता है. Memory64 प्रस्ताव इन पाबंदियों को लीनियर मेमोरी से हटा देता है. इससे उनका साइज़ चार जीबी से ज़्यादा होने पर और नेटिव प्लैटफ़ॉर्म के अड्रेस स्पेस से मैच हो जाता है.
हमने Chrome पर पूरी तरह से काम कर दिया है. हमारा अनुमान है कि इसे इस साल के आखिर तक शिप कर दिया जाएगा. फ़िलहाल, आपके पास chrome://flags/#enable-experimental-webassembly-features फ़्लैग के साथ एक्सपेरिमेंट चलाने और हमें सुझाव/राय देने या शिकायत करने का विकल्प है.
बेहतर वेब इंटरऑप
वेब पर खास मकसद से कंप्यूट करने के लिए, WebAssembly एक एंट्री पॉइंट हो सकता है.
जीपीयू ऐप्लिकेशन को वेब पर लाने के लिए WebAssembly का इस्तेमाल किया जा सकता है. इसका मतलब है कि जिस C++ ऐप्लिकेशन को उपयोगकर्ता के डिवाइस पर चलाया जा सकता है वह छोटे बदलावों के साथ वेब पर भी चल सकता है.
Wasm कंपाइलर टूलचेन, Emscripten में पहले से ही WebGPU के लिए बाइंडिंग मौजूद हैं. वेब पर एआई के इस्तेमाल के बारे में अनुमान लगाने के लिए, यह बेहद ज़रूरी है. इसलिए, यह ज़रूरी है कि Wasm अन्य वेब प्लैटफ़ॉर्म के साथ आसानी से इंटिग्रेट कर सके. हम इस क्षेत्र में कुछ अलग-अलग प्रपोज़ल पर काम कर रहे हैं.
JavaScript प्रॉमिस इंटिग्रेशन (JSPI)
सामान्य C और C++ (साथ ही कई अन्य भाषाएं) के ऐप्लिकेशन आम तौर पर सिंक्रोनस एपीआई के लिए लिखे जाते हैं. इसका मतलब है कि कार्रवाई पूरी होने तक ऐप्लिकेशन का इस्तेमाल बंद हो जाएगा. आम तौर पर, इस तरह के ब्लॉक करने वाले ऐप्लिकेशन को एक साथ काम नहीं करने वाले ऐप्लिकेशन की तुलना में लिखना ज़्यादा आसान होता है.
जब महंगे ऑपरेशन मुख्य थ्रेड को ब्लॉक करते हैं, तो वे I/O को ब्लॉक कर सकते हैं. साथ ही, जैंक उपयोगकर्ताओं को दिखने लगता है. नेटिव ऐप्लिकेशन के सिंक्रोनस प्रोग्रामिंग मॉडल और वेब के एसिंक्रोनस मॉडल में अंतर है. इससे खास तौर पर, लेगसी ऐप्लिकेशन के लिए समस्या खड़ी हो जाती है. इसलिए, पोर्ट करने में काफ़ी खर्चा आता है. Amscripten की मदद से, Asyncify के साथ यह काम किया जा सकता है, लेकिन यह हमेशा सबसे अच्छा विकल्प नहीं होता - बड़ा कोड साइज़ और उतना असरदार नहीं.
नीचे दिया गया उदाहरण फ़ाइबोनाशी की गिनती करना है. इसके लिए, JavaScript प्रॉमिस का इस्तेमाल किया जाता है.
long promiseFib(long x) {
if (x == 0)
return 0;
if (x == 1)
return 1;
return promiseAdd(promiseFib(x - 1), promiseFib(x - 2));
}
// promise an addition
EM_ASYNC_JS(long, promiseAdd, (long x, long y), {
return Promise.resolve(x+y);
});
emcc -O3 fib.c -o b.html -s ASYNCIFY=2
इस उदाहरण में, इन बातों पर ध्यान दें:
EM_ASYNC_JSमैक्रो सभी ज़रूरी ग्लू कोड जनरेट करता है, ताकि हम प्रॉमिस के नतीजे को ऐक्सेस करने के लिए जेएसपीआई का इस्तेमाल कर सकें. यह ठीक वैसा ही है जैसा किसी सामान्य फ़ंक्शन के लिए किया जाता है.- खास कमांड लाइन विकल्प,
-s ASYNCIFY=2. इससे, उस कोड को जनरेट करने का विकल्प शुरू हो जाता है जो प्रॉमिस देने वाले JavaScript इंपोर्ट के साथ इंटरफ़ेस के लिए जेएसपीआई का इस्तेमाल करता है.
जेएसपीआई, इस्तेमाल करने के तरीके, और इसके फ़ायदों के बारे में ज़्यादा जानकारी के लिए, v8.dev पर WebAssembly JavaScript Promise Integration API पढ़ें. मौजूदा ऑरिजिन ट्रायल के बारे में जानें.
मेमोरी कंट्रोल
डेवलपर के पास Wasm मेमोरी का बहुत कम कंट्रोल होता है. मॉड्यूल की अपनी मेमोरी होती है. जिन एपीआई को इस मेमोरी को ऐक्सेस करने की ज़रूरत है उन्हें कॉपी इन या कॉपी आउट करना होगा. ऐसा करने से इसका इस्तेमाल बढ़ सकता है. उदाहरण के लिए, किसी ग्राफ़िक ऐप्लिकेशन को हर फ़्रेम के लिए कॉपी इन करके, उसे कॉपी करना पड़ सकता है.
मेमोरी कंट्रोल प्रस्ताव का मकसद, Wasm लीनियर मेमोरी पर बेहतर कंट्रोल देना है. साथ ही, ऐप्लिकेशन पाइपलाइन में कॉपी की संख्या कम करना है. यह प्रस्ताव पहले फ़ेज़ में है. हम Chrome के JavaScript इंजन, V8 में इसका प्रोटोटाइप बना रहे हैं, ताकि स्टैंडर्ड वर्शन में क्रम से आने वाले बदलावों की जानकारी दी जा सके.
तय करें कि कौनसा बैकएंड आपके लिए सही है
सीपीयू का इस्तेमाल हर जगह किया जाता है, लेकिन यह हमेशा सबसे अच्छा विकल्प नहीं होता. जीपीयू या एक्सीलेरेटर पर खास मकसद से बनाई गई कंप्यूट की सुविधा से, काफ़ी बेहतर परफ़ॉर्मेंस मिल सकती है. खास तौर पर, बड़े मॉडल और महंगे डिवाइसों पर. यह नेटिव ऐप्लिकेशन और वेब ऐप्लिकेशन, दोनों पर लागू होता है.
आपने कौनसा बैकएंड चुना है, यह ऐप्लिकेशन, फ़्रेमवर्क या टूलचेन पर निर्भर करता है. साथ ही, यह परफ़ॉर्मेंस पर असर डालने वाली अन्य चीज़ों पर भी निर्भर करता है. इसलिए, हम उन प्रस्तावों में निवेश करना जारी रख रहे हैं, जिनसे मुख्य Wasm वेब प्लैटफ़ॉर्म के साथ-साथ खास तौर पर WebGPU के साथ अच्छी तरह से काम कर पाए.