यह दस्तावेज़, वेब पर एआई की सुविधाओं को तेज़ करने के लिए, WebAssembly और WebGPU में किए गए सुधारों का पहला हिस्सा है. हमारा सुझाव है कि आगे बढ़ने से पहले, यह पोस्ट पढ़ें या IO 24 में हुई बातचीत देखें.
WebGPU
WebGPU, वेब ऐप्लिकेशन को क्लाइंट के GPU हार्डवेयर का ऐक्सेस देता है, ताकि वे बेहतर और तेज़ी से कई काम एक साथ कर सकें. Chrome में WebGPU लॉन्च करने के बाद, हमें वेब पर आर्टिफ़िशियल इंटेलिजेंस (एआई) और मशीन लर्निंग (एमएल) के बेहतरीन डेमो देखने को मिले हैं.
उदाहरण के लिए, वेब स्टेबल डिफ़्यूज़न से पता चला है कि एआई का इस्तेमाल करके, टेक्स्ट से सीधे ब्राउज़र में इमेज जनरेट की जा सकती हैं. इस साल की शुरुआत में, Google की Mediapipe टीम ने बड़े लैंग्वेज मॉडल के अनुमान के लिए, प्रयोग के तौर पर सहायता पब्लिश की थी.
इस ऐनिमेशन में, Google का ओपन सोर्स लार्ज लैंग्वेज मॉडल (एलएलएम) Gemma दिखाया गया है. यह मॉडल, Chrome में डिवाइस पर पूरी तरह से रीयल टाइम में काम करता है.
Meta के Segment Anything मॉडल का यह Hugging Face का डेमो, क्लाइंट पर पूरी तरह से अच्छी क्वालिटी के ऑब्जेक्ट मास्क बनाता है.
ये सिर्फ़ कुछ ऐसे बेहतरीन प्रोजेक्ट हैं जिनसे एआई और एमएल के लिए, WebGPU की क्षमता का पता चलता है. WebGPU की मदद से, इन मॉडल और अन्य मॉडल, सीपीयू की तुलना में ज़्यादा तेज़ी से काम करते हैं.
Hugging Face के टेक्स्ट एम्बेडिंग के लिए WebGPU मानदंड, उसी मॉडल के सीपीयू लागू करने की तुलना में काफ़ी तेज़ी दिखाता है. Apple M1 Max लैपटॉप पर, WebGPU 30 गुना ज़्यादा तेज़ था. कुछ लोगों ने बताया है कि WebGPU, बेंचमार्क को 120 गुना से ज़्यादा तक तेज़ करता है.
एआई और मशीन लर्निंग के लिए, WebGPU की सुविधाओं को बेहतर बनाना
WebGPU, एआई और एमएल मॉडल के लिए बेहतरीन है. इन मॉडल में अरबों पैरामीटर हो सकते हैं. ऐसा कंप्यूट शेडर की सुविधा की वजह से होता है. कंप्यूट शेडर, जीपीयू पर चलते हैं. साथ ही, बड़े डेटा पर एक साथ कई ऐरे ऑपरेशन चलाने में मदद करते हैं.
पिछले साल, WebGPU में कई सुधार किए गए हैं. साथ ही, हमने वेब पर एमएल और एआई की परफ़ॉर्मेंस को बेहतर बनाने के लिए, इसमें और भी सुविधाएं जोड़ी हैं. हाल ही में, हमने दो नई सुविधाएं लॉन्च की हैं: 16-बिट फ़्लोटिंग पॉइंट और पैक किए गए पूर्णांक बिंदु प्रॉडक्ट.
16-बिट फ़्लोटिंग पॉइंट
याद रखें कि एमएल वर्कलोड के लिए सटीक जानकारी की ज़रूरत नहीं होती. shader-f16 एक ऐसी सुविधा है जो WebGPU शेडिंग लैंग्वेज में f16 टाइप का इस्तेमाल करने की सुविधा देती है. यह फ़्लोटिंग पॉइंट टाइप, सामान्य 32 बिट के बजाय 16 बिट का इस्तेमाल करता है. f16 की रेंज छोटी होती है और यह कम सटीक होता है. हालांकि, कई एमएल मॉडल के लिए यह काफ़ी है.
इस सुविधा से, कई तरीकों से बेहतर तरीके से काम किया जा सकता है:
कम मेमोरी: f16 एलिमेंट वाले टेंसर, आधे स्टोरेज में सेव होते हैं. इससे मेमोरी के इस्तेमाल में भी आधा कटौती होती है. GPU के हिसाब लगाने की प्रोसेस में, मेमोरी बैंडविड्थ की कमी अक्सर रुकावट बनती है. इसलिए, आधी मेमोरी का मतलब अक्सर यह हो सकता है कि शेडर दोगुनी तेज़ी से चलें. तकनीकी तौर पर, मेमोरी बैंडविड्थ बचाने के लिए, आपको f16 की ज़रूरत नहीं है. डेटा को कम सटीक फ़ॉर्मैट में स्टोर किया जा सकता है. इसके बाद, कैलकुलेशन के लिए शेडर में इसे फ़ुल f32 तक बढ़ाया जा सकता है. हालांकि, डेटा को पैक और अनपैक करने के लिए, जीपीयू को ज़्यादा कंप्यूटिंग पावर खर्च करनी पड़ती है.
कम डेटा कन्वर्ज़न: f16, डेटा कन्वर्ज़न को कम करके कम कंप्यूट का इस्तेमाल करता है. कम सटीक डेटा को सेव किया जा सकता है और फिर कन्वर्ज़न के बिना सीधे तौर पर इस्तेमाल किया जा सकता है.
ज़्यादा पैरलल प्रोसेसिंग: आधुनिक जीपीयू, जीपीयू की एक्ज़ीक्यूशन यूनिट में एक साथ ज़्यादा वैल्यू फ़िट कर सकते हैं. इससे, ज़्यादा संख्या में पैरलल कैलकुलेशन की जा सकती हैं. उदाहरण के लिए, ऐसा हो सकता है कि कोई ऐसा जीपीयू जो हर सेकंड में 5 ट्रिलियन f32 फ़्लोटिंग-पॉइंट ऑपरेशन कर सकता है, वह हर सेकंड में 10 ट्रिलियन f16 फ़्लोटिंग-पॉइंट ऑपरेशन कर सकता है.
shader-f16 की मदद से, Hugging Face का टेक्स्ट एम्बेड करने के लिए WebGPU बेंचमार्क, Apple M1 Max लैपटॉप पर f32 की तुलना में तीन गुना तेज़ी से बेंचमार्क करता है.
WebLLM एक ऐसा प्रोजेक्ट है जिसमें कई लार्ज लैंग्वेज मॉडल चलाए जा सकते हैं. यह Apache TVM का इस्तेमाल करता है, जो मशीन लर्निंग के लिए ओपन सोर्स कंपाइलर फ़्रेमवर्क है.
मैंने WebLLM से, आठ अरब पैरामीटर वाले Llama 3 मॉडल का इस्तेमाल करके, पेरिस की यात्रा की योजना बनाने के लिए कहा. नतीजों से पता चलता है कि मॉडल के प्रीफ़िल फ़ेज़ के दौरान, f16, f32 से 2.1 गुना तेज़ है. डीकोड करने के दौरान, यह 1.3 गुना ज़्यादा तेज़ है.
ऐप्लिकेशन को पहले यह पुष्टि करनी होगी कि जीपीयू अडैप्टर, f16 के साथ काम करता है या नहीं. अगर यह उपलब्ध है, तो जीपीयू डिवाइस का अनुरोध करते समय, इसे साफ़ तौर पर चालू करें. अगर f16 का इस्तेमाल नहीं किया जा सकता, तो requiredFeatures कलेक्शन में इसका अनुरोध नहीं किया जा सकता.
// main.js
const adapter = await navigator.gpu.requestAdapter();
const supportsF16 = adapter.features.has('shader-f16');
if (supportsF16) {
// Use f16.
const device = await adapter.requestDevice({
requiredFeatures: ['shader-f16'],
});
initApp(device);
}
इसके बाद, अपने WebGPU शेडर में सबसे ऊपर, f16 को साफ़ तौर पर चालू करना होगा. इसके बाद, किसी भी फ़्लोट डेटा टाइप की तरह ही, शेडर में इसका इस्तेमाल किया जा सकता है.
// my-shader.wgsl
enable f16;
struct Data {
values : array<vec4<f16>>
}
@group(0) @binding(0) var<storage, read> data : Data;
@compute @workgroup_size(64) fn main(@builtin(global_invocation_id) gid : vec3u) {
let value : vec4<f16> = data.values[gid.x];
...
}
पैक किए गए पूर्णांक डॉट प्रॉडक्ट
कई मॉडल अब भी सिर्फ़ 8 बिट की सटीक जानकारी (f16 का आधा) के साथ अच्छी तरह से काम करते हैं. यह सेगमेंटेशन और ऑब्जेक्ट की पहचान करने के लिए, एलएलएम और इमेज मॉडल के बीच लोकप्रिय है. हालांकि, सटीक जानकारी कम होने पर मॉडल के आउटपुट की क्वालिटी खराब हो जाती है. इसलिए, 8-बिट क्वांटिज़ेशन हर ऐप्लिकेशन के लिए सही नहीं है.
कुछ ही जीपीयू में, 8-बिट वैल्यू का इस्तेमाल करने की सुविधा पहले से मौजूद होती है. ऐसे में, पैक किए गए पूर्णांक बिंदु वाले प्रॉडक्ट काम आते हैं. हमने Chrome 123 में DP4a को शिप किया है.
आधुनिक जीपीयू में, दो 32-बिट इंटिजर लेने, उन्हें चार लगातार पैक किए गए 8-बिट इंटिजर के तौर पर समझने, और उनके कॉम्पोनेंट के बीच डॉट प्रॉडक्ट का हिसाब लगाने के लिए खास निर्देश होते हैं.
यह एआई और मशीन लर्निंग के लिए खास तौर पर फ़ायदेमंद है, क्योंकि मैट्रिक्स गुणा करने वाले कर्नेल में बहुत सारे डॉट प्रॉडक्ट होते हैं.
उदाहरण के लिए, आइए 4 x 8 मैट्रिक्स को 8 x 1 वेक्टर से गुणा करें. इसका हिसाब लगाने के लिए, आउटपुट वेक्टर में मौजूद हर वैल्यू का हिसाब लगाने के लिए चार डॉट प्रॉडक्ट लेना ज़रूरी है: A, B, C, और D.
इनमें से हर आउटपुट का हिसाब लगाने की प्रोसेस एक जैसी होती है. हम इनमें से किसी एक का हिसाब लगाने के तरीके के बारे में जानेंगे. किसी भी हिसाब लगाने से पहले, हमें 8-बिट के पूर्णांक डेटा को ऐसे टाइप में बदलना होगा जिससे हम अंकगणित की कार्रवाई कर सकें. जैसे, f16. इसके बाद, हम एलिमेंट के हिसाब से गुणा करते हैं और आखिर में, सभी प्रॉडक्ट को जोड़ देते हैं. कुल मिलाकर, मैट्रिक्स-वेक्टर के गुणन के लिए, हम डेटा को अनपैक करने के लिए 40 इंटिजर से फ़्लोट में बदलाव करते हैं. साथ ही, 32 फ़्लोट के गुणन और 28 फ़्लोट के जोड़ का इस्तेमाल करते हैं.
ज़्यादा ऑपरेशन वाले बड़े मैट्रिक्स के लिए, पैक किए गए इंटिजर डॉट प्रॉडक्ट से काम की संख्या कम करने में मदद मिल सकती है.
नतीजे के वेक्टर में मौजूद हर आउटपुट के लिए, हम dot4U8Packed में पहले से मौजूद WebGPU Shading Language का इस्तेमाल करके, दो पैक किए गए डॉट प्रॉडक्ट ऑपरेशन करते हैं. इसके बाद, नतीजों को आपस में जोड़ देते हैं. कुल मिलाकर, मैट्रिक्स-वेक्टर के गुणा करने के लिए, हम कोई डेटा कन्वर्ज़न नहीं करते. हम आठ पैक किए गए डॉट प्रॉडक्ट और चार इंटिजर जोड़ते हैं.
हमने अलग-अलग तरह के कंज्यूमर जीपीयू पर, 8-बिट डेटा वाले पैक किए गए इंटिजर डॉट प्रॉडक्ट की जांच की. 16-बिट फ़्लोटिंग पॉइंट की तुलना में, हम देख सकते हैं कि 8-बिट 1.6 से 2.8 गुना तेज़ है. पैक किए गए पूर्णांक बिंदु प्रॉडक्ट का इस्तेमाल करने पर, परफ़ॉर्मेंस और भी बेहतर होती है. यह 1.7 से 2.9 गुना तेज़ है.
wgslLanguageFeatures प्रॉपर्टी की मदद से, ब्राउज़र के साथ काम करने की सुविधा देखें. अगर जीपीयू में पैक किए गए बिंदु वाले प्रॉडक्ट नेटिव तौर पर काम नहीं करते, तो ब्राउज़र अपने-आप पॉलीफ़िल लागू करता है.
// main.js
if (navigator.gpu.wgslLanguageFeatures.has('packed_4x8_integer_dot_product')) {
// Use dot4U8Packed, dot4I8Packed builtin
// functions in the shaders.
}
यहां दिए गए कोड स्निपेट में, WebGPU शेडर में पैक किए गए इंटिजर प्रॉडक्ट का इस्तेमाल करने के लिए ज़रूरी बदलावों को हाइलाइट किया गया है.
पहले — यह एक WebGPU शेडर है, जो वैरिएबल `sum` में कुछ डॉट प्रॉडक्ट इकट्ठा करता है. लूप के आखिर में, `sum` में इनपुट मैट्रिक्स के वेक्टर और एक पंक्ति के बीच का पूरा डॉट प्रॉडक्ट होता है.
// my-dot-product.wgsl @compute @workgroup_size(64) fn main(@builtin(global_invocation_id) gid : vec3u) { var sum : f16; let start = gid.x * uniforms.dim; for (var i = 0u; i < uniforms.dim; i++) { let v1 : vec4<f16> = vector.values[i]; let v2 : vec4<f16> = matrix.values[start + i]; sum += dot(v1, v2); } }
After — पैक किए गए इंटिजर डॉट प्रॉडक्ट का इस्तेमाल करने के लिए लिखा गया WebGPU शेडर. मुख्य अंतर यह है कि वेक्टर और मैट्रिक से चार फ़्लोट वैल्यू लोड करने के बजाय, यह शेडर एक 32-बिट इंटिजर लोड करता है. यह 32-बिट का पूर्णांक, चार 8-बिट के पूर्णांक की वैल्यू का डेटा रखता है. इसके बाद, हम दो वैल्यू के डॉट प्रॉडक्ट का हिसाब लगाने के लिए, dot4U8Packed को कॉल करते हैं.
// my-dot-product.wgsl
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) gid : vec3u) {
var sum : f32;
let start = gid.x * uniforms.dim;
for (var i = 0u; i < uniforms.dim; i++) {
let v1 : u32 = vector.values[i];
let v2 : u32 = matrix.values[start + i];
sum += dot4U8Packed(v1, v2);
}
}
16-बिट फ़्लोटिंग पॉइंट और पैक किए गए इंटिजर डॉट प्रॉडक्ट, Chrome में पहले से मौजूद सुविधाएं हैं. इनसे एआई और एमएल की प्रोसेस तेज़ होती है. 16-बिट फ़्लोटिंग पॉइंट तब उपलब्ध होता है, जब हार्डवेयर उस पर काम करता हो. साथ ही, Chrome सभी डिवाइसों पर पैक किए गए इंटिजर डॉट प्रॉडक्ट लागू करता है.
बेहतर परफ़ॉर्मेंस पाने के लिए, आज ही Chrome के स्टैबल वर्शन में इन सुविधाओं का इस्तेमाल किया जा सकता है.
सुझाई गई सुविधाएं
आने वाले समय में, हम दो और सुविधाओं पर काम कर रहे हैं: सबग्रुप और साथ मिलकर मैट्रिक्स का गुणा करने की सुविधा.
सबग्रुप की सुविधा, SIMD-लेवल के पैरलल प्रोसेसिंग को चालू करती है, ताकि एक साथ कई गणितीय ऑपरेशन किए जा सकें या एक-दूसरे से संपर्क किया जा सके. जैसे, 16 से ज़्यादा संख्याओं का जोड़. इससे, अलग-अलग थ्रेड के बीच डेटा को आसानी से शेयर किया जा सकता है. सबग्रुप, नए जीपीयू एपीआई पर काम करते हैं. हालांकि, इनका नाम और फ़ॉर्मैट अलग-अलग हो सकता है.
हमने सामान्य सेट को एक प्रस्ताव में बदल दिया है. हमने इसे WebGPU स्टैंडर्डाइज़ेशन ग्रुप के पास भेज दिया है. साथ ही, हमने एक्सपेरिमेंट के तौर पर उपलब्ध फ़्लैग की मदद से, Chrome में सबग्रुप का प्रोटोटाइप बनाया है. साथ ही, हमने शुरुआती नतीजों को चर्चा में शामिल किया है. मुख्य समस्या यह है कि यह कैसे पक्का किया जाए कि ऐप्लिकेशन को एक डिवाइस से दूसरे डिवाइस पर ले जाया जा सकता है.
जीपीयू में, हाल ही में कोऑपरेटिव मैट्रिक्स मल्टीप्लाई को जोड़ा गया है. बड़े मैट्रिक्स के गुणा को कई छोटे मैट्रिक्स के गुणा में बांटा जा सकता है. साथ मिलकर मैट्रिक्स का गुणा करने की सुविधा, एक ही लॉजिकल चरण में इन छोटे और तय साइज़ वाले ब्लॉक पर गुणा करती है. इस चरण में, नतीजे का हिसाब लगाने के लिए थ्रेड का एक ग्रुप मिलकर काम करता है.
हमने मौजूदा जीपीयू एपीआई में सहायता के बारे में सर्वे किया. साथ ही, WebGPU स्टैंडर्डाइज़ेशन ग्रुप को एक प्रस्ताव पेश करने का प्लान बनाया है. सबग्रुप की तरह ही, हमें उम्मीद है कि ज़्यादातर चर्चा, डेटा को एक से दूसरी जगह ले जाने की सुविधा के बारे में होगी.
किसी असल ऐप्लिकेशन में, सबग्रुप ऑपरेशन की परफ़ॉर्मेंस का आकलन करने के लिए, हमने MediaPipe में सबग्रुप के लिए एक्सपेरिमेंटल सपोर्ट इंटिग्रेट किया. साथ ही, सबग्रुप ऑपरेशन के लिए Chrome के प्रोटोटाइप के साथ इसका टेस्ट किया.
हमने बड़े लैंग्वेज मॉडल के प्रीफ़िल फ़ेज़ के GPU कर्नेल में सबग्रुप का इस्तेमाल किया है. इसलिए, हम सिर्फ़ प्रीफ़िल फ़ेज़ के लिए स्पीडअप की रिपोर्ट कर रहे हैं. Intel जीपीयू पर, हमें पता चला है कि सबग्रुप, बेसलाइन की तुलना में दो-और-आधे गुना तेज़ी से काम करते हैं. हालांकि, ये सुधार अलग-अलग जीपीयू के लिए एक जैसे नहीं होते.
अगला चार्ट, कई कंज्यूमर जीपीयू पर मैट्रिक्स मल्टीप्लाई माइक्रोबेंचमार्क को ऑप्टिमाइज़ करने के लिए, सबग्रुप लागू करने के नतीजे दिखाता है. मैट्रिक्स का गुणा करना, लार्ज लैंग्वेज मॉडल में सबसे ज़्यादा समय लेने वाली प्रोसेस है. डेटा से पता चलता है कि कई जीपीयू पर, सबग्रुप की मदद से, बेसलाइन की तुलना में दो, पांच, और यहां तक कि तेरह गुना तक तेज़ी से काम किया जा सकता है. हालांकि, ध्यान दें कि पहले जीपीयू पर, सबग्रुप काफ़ी बेहतर नहीं हैं.
जीपीयू को ऑप्टिमाइज़ करना मुश्किल है
आखिर में, आपके जीपीयू को ऑप्टिमाइज़ करने का सबसे अच्छा तरीका, इस बात पर निर्भर करता है कि क्लाइंट कौनसा जीपीयू ऑफ़र करता है. जीपीयू की नई सुविधाओं का इस्तेमाल करने से, हमेशा आपको उम्मीद के मुताबिक नतीजे नहीं मिलते. इसकी कई वजहें हो सकती हैं. ऐसा हो सकता है कि एक जीपीयू के लिए ऑप्टिमाइज़ेशन की सबसे अच्छी रणनीति, दूसरे जीपीयू के लिए सबसे अच्छी न हो.
आपको जीपीयू की कंप्यूटिंग थ्रेड का पूरा इस्तेमाल करते हुए, मेमोरी बैंडविड्थ को कम करना है.
मेमोरी ऐक्सेस करने के पैटर्न भी बहुत ज़रूरी हो सकते हैं. जब कंप्यूट थ्रेड, हार्डवेयर के लिए सबसे सही पैटर्न में मेमोरी ऐक्सेस करते हैं, तो जीपीयू बेहतर परफ़ॉर्म करते हैं. अहम जानकारी: आपको अलग-अलग जीपीयू हार्डवेयर पर, परफ़ॉर्मेंस की अलग-अलग विशेषताओं की उम्मीद करनी चाहिए. जीपीयू के हिसाब से, आपको अलग-अलग ऑप्टिमाइज़ेशन चलाने पड़ सकते हैं.
नीचे दिए गए चार्ट में, हमने मैट्रिक्स का गुणा करने वाला वही एल्गोरिदम लिया है. हालांकि, हमने अलग-अलग ऑप्टिमाइज़ेशन की रणनीतियों के असर और अलग-अलग जीपीयू के बीच की जटिलता और अंतर को दिखाने के लिए, एक और डाइमेंशन जोड़ा है. हमने यहां एक नई तकनीक शुरू की है, जिसे हम "Swizzle" कहेंगे. Swizzle, मेमोरी ऐक्सेस पैटर्न को ऑप्टिमाइज़ करता है, ताकि हार्डवेयर के लिए यह ज़्यादा बेहतर हो सके.
इससे पता चलता है कि मेमोरी स्विज़ल का काफ़ी असर पड़ता है. कभी-कभी, इसका असर सबग्रुप से भी ज़्यादा होता है. GPU 6 पर, स्विज़ल की मदद से 12 गुना तेज़ी से काम किया जा सकता है. वहीं, सबग्रुप की मदद से 13 गुना तेज़ी से काम किया जा सकता है. इन दोनों के साथ, 26 गुना ज़्यादा तेज़ी से काम किया जा सकता है. अन्य जीपीयू के लिए, कभी-कभी स्विज़ल और सबग्रुप, दोनों की परफ़ॉर्मेंस अलग-अलग इस्तेमाल करने की तुलना में बेहतर होती है. वहीं, अन्य जीपीयू पर, सिर्फ़ स्वाइज़ल का इस्तेमाल करने से सबसे बेहतर परफ़ॉर्मेंस मिलती है.
हर हार्डवेयर पर बेहतर तरीके से काम करने के लिए, जीपीयू के एल्गोरिद्म को ट्यून और ऑप्टिमाइज़ करने के लिए काफ़ी विशेषज्ञता की ज़रूरत होती है. हालांकि, ज़्यादा बेहतर लाइब्रेरी फ़्रेमवर्क के लिए, बहुत सारे लोग काम कर रहे हैं. जैसे, Mediapipe, Transformers.js, Apache TVM, ONNX Runtime Web वगैरह.
लाइब्रेरी और फ़्रेमवर्क, अलग-अलग जीपीयू आर्किटेक्चर को मैनेज करने की जटिलता को हैंडल करने और प्लैटफ़ॉर्म के हिसाब से कोड जनरेट करने के लिए बेहतर हैं. यह कोड, क्लाइंट पर अच्छी तरह से चलेगा.
सीखने वाली अहम बातें
Chrome की टीम, मशीन लर्निंग के वर्कलोड के लिए वेब प्लैटफ़ॉर्म को बेहतर बनाने के मकसद से, WebAssembly और WebGPU स्टैंडर्ड को बेहतर बनाने में लगातार मदद कर रही है. हम तेज़ कंप्यूट प्राइमिटिव और वेब स्टैंडर्ड के बीच बेहतर इंटरऑपरेबिलिटी पर काम कर रहे हैं. साथ ही, यह पक्का कर रहे हैं कि बड़े और छोटे, दोनों तरह के मॉडल सभी डिवाइसों पर बेहतर तरीके से काम कर पाएं.
हमारा लक्ष्य, वेब की बेहतरीन सुविधाओं को बनाए रखते हुए, प्लैटफ़ॉर्म की क्षमताओं को बढ़ाना है. इन सुविधाओं में, वेब की पहुंच, इस्तेमाल करने का तरीका, और उसे एक से दूसरी जगह ले जाने की सुविधा शामिल है. हम यह काम अकेले नहीं कर रहे हैं. हम W3C के अन्य ब्राउज़र वेंडर और कई डेवलपमेंट पार्टनर के साथ मिलकर काम कर रहे हैं.
हमें उम्मीद है कि WebAssembly और WebGPU का इस्तेमाल करते समय, आप इन बातों का ध्यान रखेंगे:
- एआई का अनुमान लगाने की सुविधा, अब वेब पर सभी डिवाइसों के लिए उपलब्ध है. इससे क्लाइंट डिवाइसों पर काम करने का फ़ायदा मिलता है. जैसे, सर्वर की लागत कम होना, इंतज़ार का समय कम होना, और निजता को बेहतर बनाना.
- इस लेख में बताई गई कई सुविधाएं, मुख्य रूप से फ़्रेमवर्क के लेखकों के लिए काम की हैं. हालांकि, इनसे आपके ऐप्लिकेशन को भी फ़ायदा मिल सकता है.
- वेब स्टैंडर्ड लगातार बदलते रहते हैं और बेहतर होते रहते हैं. इसलिए, हमें आपके सुझाव, शिकायत या राय का इंतज़ार रहता है. WebAssembly और WebGPU के लिए, अपने एक्सटेंशन शेयर करें.
आभार
हम Intel की वेब ग्राफ़िक्स टीम का धन्यवाद करना चाहते हैं. इस टीम की मदद से, WebGPU f16 और पैक किए गए इंटिजर डॉट प्रॉडक्ट की सुविधाओं को लॉन्च किया गया. हम W3C के WebAssembly और WebGPU वर्किंग ग्रुप के अन्य सदस्यों का धन्यवाद करना चाहते हैं. इनमें ब्राउज़र के अन्य वेंडर भी शामिल हैं.
Google और ओपन सोर्स कम्यूनिटी, दोनों में एआई और एमएल की टीमों को बेहतरीन पार्टनर बनने के लिए धन्यवाद. साथ ही, हमारी टीम के उन सभी सदस्यों को भी धन्यवाद जिन्होंने इस उपलब्धि को हासिल करने में हमारी मदद की.