जानें कि WebAssembly और WebGPU के ज़रिए, बेहतर तरीके से मशीन लर्निंग का इस्तेमाल करके, वेब पर मशीन लर्निंग की परफ़ॉर्मेंस को कैसे बेहतर बनाया जाता है.
वेब पर एआई का अनुमान
हम सभी ने इस बात के बारे में सुना है: एआई (AI) हमारी दुनिया बदल रहा है. वेब भी इससे अछूता नहीं है.
इस साल Chrome में जनरेटिव एआई की सुविधाएं जोड़ी गई हैं. इनमें पसंद के मुताबिक थीम बनाना और टेक्स्ट का पहला ड्राफ़्ट लिखने में आपकी मदद करना शामिल है. हालांकि, एआई हमारे लिए बहुत काम का है; एआई, वेब ऐप्लिकेशन को खुद ही बेहतर बना सकता है.
वेब पेज देखने के लिए, इंटेलिजेंट कॉम्पोनेंट एम्बेड कर सकते हैं. जैसे, चेहरे चुनना या जेस्चर की पहचान करना, ऑडियो की कैटगरी तय करने या भाषा की पहचान करने के लिए. पिछले साल, हमने जनरेटिव एआई की तकनीक लॉन्च की. इसमें वेब पर लार्ज लैंग्वेज मॉडल के कुछ बेहतरीन डेमो भी शामिल हैं. वेब डेवलपर के लिए, डिवाइस में मौजूद एआई के इस्तेमाल की सुविधा ज़रूर देखें.
आज-कल, वेब पर एआई का अनुमान लगाने की सुविधा कई डिवाइसों के लिए उपलब्ध है. साथ ही, उपयोगकर्ता के डिवाइस के हार्डवेयर का फ़ायदा लेते हुए, वेब पेज पर भी एआई की प्रोसेसिंग की जा सकती है.
इसकी कई वजहें हैं:
- खर्च में कमी: ब्राउज़र क्लाइंट पर कोई अनुमान चलाने पर सर्वर की लागत काफ़ी कम हो जाती है. यह खास तौर पर जनरेटिव एआई की क्वेरी के लिए काम का हो सकता है. आम तौर पर की जाने वाली क्वेरी के मुकाबले, यह क्वेरी बहुत ज़्यादा महंगा हो सकती है.
- इंतज़ार का समय: वे ऐप्लिकेशन जो खास तौर पर, इंतज़ार के समय को लेकर संवेदनशील होते हैं, जैसे कि ऑडियो या वीडियो ऐप्लिकेशन - उनके लिए डिवाइस पर प्रोसेसिंग पूरी होने के बाद इंतज़ार का समय कम हो जाता है.
- निजता: क्लाइंट साइड पर चलने वाले ऐप्लिकेशन, नए तरह के ऐप्लिकेशन अनलॉक कर सकते हैं. इसके लिए, ज़्यादा निजता की ज़रूरत होती है, जहां डेटा को सर्वर पर नहीं भेजा जा सकता.
आज के समय में वेब पर एआई के वर्कलोड किस तरह काम करते हैं
फ़िलहाल, ऐप्लिकेशन डेवलपर और रिसर्च करने वाले लोग फ़्रेमवर्क का इस्तेमाल करके मॉडल बनाते हैं और मॉडल, ब्राउज़र में Tensorflow.js या ONNX रनटाइम वेब जैसे रनटाइम का इस्तेमाल करके एक्ज़ीक्यूट करते हैं. साथ ही, रनटाइम, एक्ज़ीक्यूशन के लिए Web API का इस्तेमाल करते हैं.
ये सभी रनटाइम, 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 की परफ़ॉर्मेंस के बीच का अंतर बढ़ जाता है.
याद रखें, एमएल मॉडल में हमेशा ज़्यादा सटीक जानकारी की ज़रूरत नहीं होती. रिलैक्स्ड एसआईएम एक ऐसा प्रस्ताव है जो कुछ सख्त, गैर-तय करने से जुड़ी शर्तों को कम कर देता है. इस वजह से, वेक्टर से जुड़ी कार्रवाइयां तेज़ हो जाती हैं, जो परफ़ॉर्मेंस के लिहाज़ से सबसे ज़रूरी होती हैं. इसके अलावा, आरामदेह SIMD में नए डॉट प्रॉडक्ट और FMA के निर्देश दिए गए हैं. इनकी मदद से, मौजूदा वर्कलोड को 1.5 से 3 गुना के बीच तेज़ी से किया जा सकता है. इसे Chrome के वर्शन 114 में शिप किया गया था.
हाफ़-प्रीसिज़न फ़्लोटिंग पॉइंट फ़ॉर्मैट में, सटीक वैल्यू के लिए इस्तेमाल होने वाले 32-बिट के बजाय, IEEE FP16 के लिए, 16-बिट का इस्तेमाल किया जाता है. एकल सटीक मानों की तुलना में, अर्ध-सटीक मानों और कम मेमोरी की शर्तों का उपयोग करने के कई लाभ हैं, जो बड़े न्यूरल नेटवर्क के प्रशिक्षण और परिनियोजन को सक्षम बनाते हैं, और कम मेमोरी बैंडविड्थ को सक्षम बनाते हैं. इसको इस्तेमाल करने से, डेटा को ट्रांसफ़र करने और गणित से जुड़े काम तेज़ी से करने में मदद मिलती है.
बड़े मॉडल
Wasm लीनियर मेमोरी के पॉइंटर, 32-बिट पूर्णांक के तौर पर दिखाए जाते हैं. इसके दो नतीजे होते हैं: हीप का साइज़ 4 जीबी तक सीमित होता है (जब कंप्यूटर में फ़िज़िकल रैम उससे ज़्यादा होती है). साथ ही, Wasm को टारगेट करने वाला ऐप्लिकेशन कोड, 32-बिट पॉइंटर साइज़ (जो कि) के साथ काम करता हो.
खास तौर पर, हमारे पास आज के बड़े मॉडल हैं. इसलिए, इन मॉडल को WebAssembly में लोड करना मुश्किल हो सकता है. Memory64 प्रस्ताव, लीनियर मेमोरी के हिसाब से इन पाबंदियों को हटाता है. इसका साइज़ 4 जीबी से ज़्यादा होना चाहिए और यह नेटिव प्लैटफ़ॉर्म के अड्रेस स्पेस के बराबर होना चाहिए.
हम Chrome पर सभी सुविधाएं लागू कर रहे हैं. इसके लिए, इस साल के आखिर तक लॉन्च होने का अनुमान है. फ़िलहाल, फ़्लैग फ़्लैग के साथ एक्सपेरिमेंट किया जा सकता है chrome://flags/#enable-experimental-webassembly-features. साथ ही, हमें सुझाव/राय दें या शिकायत करें.
बेहतर वेब इंटरऑप
वेब पर खास मकसद की गणना करने के लिए, WebAssembly एक एंट्री पॉइंट हो सकता है.
जीपीयू ऐप्लिकेशन को वेब पर लाने के लिए, WebAssembly का इस्तेमाल किया जा सकता है. इसका मतलब है कि जो C++ ऐप्लिकेशन किसी डिवाइस पर चल सकता है वह वेब पर भी काम कर सकता है. हालांकि, उसमें छोटे-मोटे बदलाव करने होंगे.
Emscripten, Wasm कंपाइलर टूलचेन में, पहले से ही WebGPU के लिए बाइंडिंग होती हैं. यह वेब पर एआई के अनुमान लगाने का एंट्री पॉइंट है. इसलिए, यह ज़रूरी है कि Wasm वेब प्लैटफ़ॉर्म के साथ आसानी से काम कर सके. हम इस क्षेत्र में कुछ अलग-अलग प्रस्तावों पर काम कर रहे हैं.
JavaScript प्रॉमिस इंटिग्रेशन (जेएसपीआई)
सामान्य C और C++ (साथ ही कई अन्य भाषाएं) ऐप्लिकेशन आम तौर पर सिंक्रोनस एपीआई के साथ लिखे जाते हैं. इसका मतलब है कि जब तक कार्रवाई पूरी नहीं होती, तब तक ऐप्लिकेशन एक्ज़ीक्यूट नहीं होगा. आम तौर पर, सिंक न करने वाले ऐप्लिकेशन के मुकाबले, ब्लॉक करने वाले ऐसे ऐप्लिकेशन में लिखना ज़्यादा आसान होता है.
जब महंगी कार्रवाइयां मुख्य थ्रेड को ब्लॉक करती हैं, तब वे I/O को ब्लॉक कर सकती हैं और जैंक उपयोगकर्ताओं को दिखता है. नेटिव ऐप्लिकेशन के सिंक्रोनस प्रोग्रामिंग मॉडल और वेब के एसिंक्रोनस मॉडल के बीच मैच नहीं है. इससे लेगसी ऐप्लिकेशन के लिए खास तौर पर समस्या होती है, जिसे पोर्ट करना महंगा पड़ सकता है. Emscripten ऐसा करने के लिए एसिंक्रोनसी का इस्तेमाल करता है, लेकिन यह हमेशा सबसे अच्छा विकल्प नहीं होता. यानी कोड का साइज़ बड़ा होना और यह उतना कारगर नहीं है.
नीचे दिए गए उदाहरण में फ़ाइबोनाशी की गणना की जा रही है, जिसमें जोड़ने के लिए 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 लीनियर मेमोरी को बेहतर तरीके से कंट्रोल करना और ऐप्लिकेशन पाइपलाइन में मौजूद कॉपी की संख्या को कम करना है. यह प्रस्ताव चरण 1 में है, हम मानक के विकास की सूचना देने के लिए Chrome के JavaScript इंजन, V8 में इसका प्रोटोटाइप बना रहे हैं.
तय करें कि आपके लिए कौनसा बैकएंड सही है
वैसे तो सीपीयू हर जगह मौजूद होता है, लेकिन यह हमेशा सबसे अच्छा विकल्प नहीं होता. जीपीयू या ऐक्सेलरेटर के खास मकसद वाले कंप्यूट की मदद से, खास तौर पर बड़े मॉडल और महंगे डिवाइसों की परफ़ॉर्मेंस बेहतर हो सकती है. यह मूल ऐप्लिकेशन और वेब ऐप्लिकेशन दोनों के लिए सही है.
आप कौनसा बैकएंड चुन सकते हैं, यह ऐप्लिकेशन, फ़्रेमवर्क या टूलचेन के साथ-साथ परफ़ॉर्मेंस पर असर डालने वाले दूसरे फ़ैक्टर पर निर्भर करता है. हालांकि, हम ऐसे प्रस्तावों पर लगातार काम कर रहे हैं जिनकी मदद से Wasm को अन्य वेब प्लैटफ़ॉर्म और खास तौर पर WebGPU के साथ बेहतर तरीके से काम करने में मदद मिल सके.