WebAssembly और WebGPU की सुविधाओं को बेहतर बनाने से वेब के एआई को बेहतर बनाने में मदद मिलती है. दूसरा हिस्सा

इस दस्तावेज़ में, तेज़ वेब एआई के लिए WebAssembly और WebGPU के वर्शन को बेहतर बनाने से जुड़ी जानकारी का पहला हिस्सा शामिल है. हमारा सुझाव है कि आप यह पोस्ट पढ़ें या जारी रखने से पहले, IO 24 में हुई बातचीत देखें.

Austin Eng

Deepti Gandluri

François Beaufort

WebGPU

WebGPU, वेब ऐप्लिकेशन को क्लाइंट के जीपीयू हार्डवेयर का ऐक्सेस देता है, ताकि वे बेहतर और एक साथ काम करने वाली कंप्यूटेशन की सेवा इस्तेमाल कर सकें. Chrome में WebGPU को लॉन्च करने के बाद से, हमने वेब पर आर्टिफ़िशियल इंटेलिजेंस (एआई) और मशीन लर्निंग (एमएल) के बेहतरीन डेमो देखे हैं.

उदाहरण के लिए, वेब स्टेबल डिफ़्यूज़न ने दिखाया कि टेक्स्ट से इमेज जनरेट करने के लिए, सीधे ब्राउज़र में एआई का इस्तेमाल किया जा सकता है. इस साल की शुरुआत में, Google की मीडिया की टीम ने बड़े लैंग्वेज मॉडल के अनुमान के लिए, एक्सपेरिमेंट के तौर पर उपलब्ध सहायता पब्लिश की थी.

नीचे दिए गए ऐनिमेशन में, Gemma को दिखाया गया है. यह Google का ओपन सोर्स लार्ज लैंग्वेज मॉडल (एलएलएम) है. यह रीयल टाइम में, पूरी तरह से Chrome के उपयोगकर्ता के डिवाइस पर चल रहा है.

Meta के सेगमेंट एनीथिंग मॉडल के गलेगिंग फ़ेस का डेमो, पूरी तरह से क्लाइंट पर अच्छी क्वालिटी के ऑब्जेक्ट मास्क तैयार करता है.

ये कुछ शानदार प्रोजेक्ट हैं, जो AI और ML के WebGPU की अहमियत दिखाते हैं. WebGPU, इन मॉडल और अन्य मॉडल को सीपीयू के मुकाबले ज़्यादा तेज़ी से चलाने की अनुमति देता है.

हगिंग फ़ेस के टेक्स्ट एम्बेड करने के लिए WebGPU मानदंड से पता चलता है कि एक ही मॉडल के सीपीयू से लागू करने की तुलना में, कितनी स्पीडअप होती हैं. Apple M1 Max लैपटॉप पर, WebGPU की रफ़्तार 30 गुना से ज़्यादा थी. अन्य संगठनों ने बताया है कि WebGPU ने मानदंड को 120 गुना से ज़्यादा बढ़ाया है.

एआई और मशीन लर्निंग के लिए WebGPU की सुविधाओं को बेहतर बनाना

WebGPU, एआई और एमएल मॉडल के लिए एक बेहतरीन विकल्प है. इसमें करोड़ों पैरामीटर शामिल हो सकते हैं. ऐसा कंप्यूट शेडर के साथ काम करने की वजह से होता है. कंप्यूट शेडर, जीपीयू पर चलते हैं. साथ ही, ये ज़्यादा डेटा पर पैरलल अरे ऑपरेशन को चलाने में मदद करते हैं.

पिछले साल WebGPU में कई सुधार किए गए हैं. इसके अलावा, हमने वेब पर मशीन लर्निंग और एआई (AI) की परफ़ॉर्मेंस को बेहतर बनाने के लिए, ज़्यादा सुविधाएं जोड़ी हैं. हाल ही में, हमने दो नई सुविधाएं लॉन्च की हैं: 16-बिट फ़्लोटिंग पॉइंट और पैक किए गए पूर्णांक डॉट प्रॉडक्ट.

16-बिट फ़्लोटिंग पॉइंट

याद रखें, एमएल वर्कलोड के लिए, सटीक जानकारी की ज़रूरत नहीं होती. shader-f16 ऐसी सुविधा है जो WebGPU की शेडिंग लैंग्वेज में, f16 टाइप के इस्तेमाल की सुविधा देती है. इस फ़्लोटिंग पॉइंट टाइप में, सामान्य 32 बिट के बजाय, 16 बिट होते हैं. f16 की रेंज कम है और यह कम सटीक है. हालांकि, कई एमएल मॉडल के लिए यह काफ़ी है.

यह सुविधा कई तरीकों से क्षमता को बढ़ाती है:

• कम मेमोरी: f16 एलिमेंट वाले टेन्सर, आधे से ज़्यादा स्टोरेज इस्तेमाल करते हैं. इससे, मेमोरी का इस्तेमाल आधा हो जाता है. अक्सर, मेमोरी बैंडविड्थ पर जीपीयू कंप्यूटेशन (हिसाब लगाना) में दिक्कत होती है. इसलिए, अक्सर आधी मेमोरी का मतलब यह हो सकता है कि शेडर दोगुनी तेज़ी से चलते हैं. तकनीकी तौर पर, आपको मेमोरी बैंडविड्थ बचाने के लिए f16 की ज़रूरत नहीं है. डेटा को कम सटीक फ़ॉर्मैट में स्टोर किया जा सकता है. इसके बाद, कंप्यूटेशन के लिए शेडर में उसे फ़ुल f32 तक बढ़ाया जा सकता है. हालांकि, जीपीयू, डेटा को पैक करने और अनपैक करने के लिए ज़्यादा कंप्यूटिंग पावर खर्च करता है.

• कम डेटा कन्वर्ज़न: f16, डेटा कन्वर्ज़न को कम करके कम कंप्यूट का इस्तेमाल करता है. कम सटीक डेटा को सेव किया जा सकता है और फिर बिना कन्वर्ज़न के सीधे इस्तेमाल किया जा सकता है.

• बढ़ी हुई समानता: मॉडर्न जीपीयू, जीपीयू की एक्ज़ीक्यूशन यूनिट में एक साथ ज़्यादा वैल्यू फ़िट कर सकते हैं. इससे, यह पैरलल कंप्यूटेशन को बहुत ज़्यादा संख्या में कर सकता है. उदाहरण के लिए, हर सेकंड 5 ट्रिलियन f32 फ़्लोटिंग-पॉइंट ऑपरेशन को सपोर्ट करने वाले जीपीयू में, हर सेकंड में 10 ट्रिलियन f16 फ़्लोटिंग-पॉइंट ऑपरेशन को काम करने की सुविधा मिल सकती है.

WebLLM एक ऐसा प्रोजेक्ट है जो कई बड़े लैंग्वेज मॉडल चला सकता है. यह Apache TVM का इस्तेमाल करता है, जो एक ओपन सोर्स मशीन लर्निंग कंपाइलर फ़्रेमवर्क है.

मैंने WebLLM को पेरिस की यात्रा की योजना बनाने के लिए कहा. इसके लिए, मैंने लामा 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-बिट पूर्णांक बनाने के लिए, वे हर एक को 4 लगातार पैक किए गए 8-बिट वाले पूर्णांकों के रूप में समझते हैं और उनके कॉम्पोनेंट के बीच डॉट प्रॉडक्ट का हिसाब लगाते हैं.

यह खास तौर पर एआई (AI) और मशीन लर्निंग के लिए फ़ायदेमंद है, क्योंकि मैट्रिक्स मल्टीप्लिकेशन कर्नेल कई बिंदु वाले प्रॉडक्ट से मिलकर बने होते हैं.

उदाहरण के लिए, मान लीजिए कि 4 x 8 के मैट्रिक्स को 8 x 1 वेक्टर से गुणा करना है. इसकी गिनती करने के लिए, आउटपुट वेक्टर में हर वैल्यू को कैलकुलेट करने के लिए, चार बिंदु वाले प्रॉडक्ट इस्तेमाल किए जाते हैं; A, B, C, और D.

इनमें से हर आउटपुट को कैलकुलेट करने की प्रोसेस एक ही है; हम उनमें से एक की गणना करने के चरणों को देखेंगे. किसी भी गणना से पहले, हमें सबसे पहले 8-बिट पूर्णांक डेटा को ऐसे टाइप में बदलना होगा जिससे हम अंकगणित के नतीजे कर सकें, जैसे कि f16. इसके बाद, हम एलिमेंट के हिसाब से गुणा करते हैं और आखिर में सभी प्रॉडक्ट को एक साथ जोड़ देते हैं. कुल मिलाकर, पूरे मैट्रिक्स-वेक्टर गुणा के लिए, हम डेटा को अनपैक करने के लिए 40 पूर्णांक फ़्लोट कन्वर्ज़न, 32 फ़्लोट मल्टीप्लिकेशन, और 28 फ़्लोट एडिशन लागू करते हैं.

ज़्यादा संक्रियाओं वाले बड़े आव्यूहों के लिए, पूर्णांक बिंदु वाले प्रॉडक्ट को पैक करके देना, कम काम करने में मदद कर सकता है.

रिज़ल्ट वेक्टर में हर आउटपुट के लिए, हम पैक किए गए दो डॉट प्रॉडक्ट से जुड़ी कार्रवाइयां करते हैं. इसके लिए, हम WebGPU में पहले से मौजूद शेडिंग लैंग्वेज का इस्तेमाल करते हैं dot4U8Packed. इसके बाद, हम नतीजों को एक साथ जोड़ते हैं. कुल मिलाकर, पूरे मैट्रिक्स-वेक्टर गुणा के लिए, हम कोई डेटा कन्वर्ज़न नहीं करते हैं. हम आठ पैक किए गए डॉट प्रॉडक्ट और चार पूर्णांक जोड़ देते हैं.

हमने अलग-अलग तरह के उपभोक्ताओं के लिए बनाए गए जीपीयू पर, 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` वैरिएबल में इकट्ठा करता है. लूप के अंत में, `सम` किसी सदिश और इनपुट मैट्रिक्स की एक पंक्ति के बीच पूरे बिंदु वाला गुणनफल रखता है.

// 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);
  }
}

बाद में — पैक किए गए पूर्णांक डॉट प्रॉडक्ट का इस्तेमाल करने के लिए लिखा गया WebGPU शेडर. मुख्य अंतर यह है कि वेक्टर और मैट्रिक्स से 4 फ़्लोट वैल्यू लोड करने के बजाय, यह शेडर एक 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);
  }
}

Chrome में, 16-बिट फ़्लोटिंग पॉइंट और पैक किए गए इंटीजर डॉट प्रॉडक्ट, दोनों ही शिपिंग के लिए उपलब्ध सुविधाएं हैं. इन सुविधाओं से, एआई और मशीन लर्निंग को तेज़ी से इस्तेमाल किया जा सकता है. 16-बिट फ़्लोटिंग पॉइंट तब उपलब्ध होता है, जब हार्डवेयर इसके साथ काम करता है और Chrome सभी डिवाइसों पर पैक किए गए पूर्णांक डॉट प्रॉडक्ट लागू करता है.

बेहतर परफ़ॉर्मेंस पाने के लिए, आज ही Chrome Stable में इन सुविधाओं का इस्तेमाल किया जा सकता है.

प्रस्तावित सुविधाएं

आने वाले समय में, हम दो और सुविधाओं की जांच कर रहे हैं: सबग्रुप और को-ऑपरेटिव मैट्रिक्स गुणा.

सबग्रुप की सुविधा, एसआईडी-लेवल पर पैरललिज़म को लागू करने या गणित के सामूहिक कामकाज करने में मदद करती है. जैसे, 16 से ज़्यादा संख्याओं का योग. इसकी मदद से, बेहतर तरीके से क्रॉस-थ्रेड डेटा शेयर किया जा सकता है. सबग्रुप, आधुनिक जीपीयू एपीआई पर काम करते हैं. इनके नाम अलग-अलग होते हैं और ये थोड़े अलग होते हैं.

हमने इस सामान्य सेट को एक प्रस्ताव में बदल दिया है, जिसे हमने WebGPU स्टैंडर्डाइज़ेशन ग्रुप के सामने रखा है. साथ ही, हमने प्रयोग के तौर पर इस्तेमाल होने वाले फ़्लैग के पीछे Chrome में सबग्रुप के प्रोटोटाइप बनाए हैं. साथ ही, चर्चा में अपने शुरुआती नतीजों को शामिल किया है. मुख्य समस्या यह है कि पोर्टेबल व्यवहार को कैसे पक्का किया जाए.

को-ऑपरेटिव मैट्रिक्स गुणा हाल ही में जीपीयू में जोड़ा गया है. बड़े मैट्रिक्स गुणा को एक से ज़्यादा छोटे मैट्रिक्स गुणा में विभाजित किया जा सकता है. कोऑपरेटिव मैट्रिक्स गुणा एक ही तार्किक चरण में इन छोटे आकार के ब्लॉक पर गुणा करता है. उस चरण में, नतीजे का हिसाब लगाने के लिए थ्रेड का एक ग्रुप बेहतर तरीके से एक-दूसरे की मदद करता है.

हमने जीपीयू एपीआई में मौजूद सर्वे में हिस्सा लिया है. साथ ही, हम WebGPU के लिए स्टैंडर्ड तय करने वाले ग्रुप को एक प्रस्ताव पेश करने की योजना बना रहे हैं. हमें उम्मीद है कि सबग्रुप की तरह ही, इसमें लगने वाली बातचीत का मुख्य विषय पोर्टेबिलिटी होनी चाहिए.

सबग्रुप की कार्रवाइयों की परफ़ॉर्मेंस का सही तरीके से आकलन करने के लिए, हमने MediaPipe में सबग्रुप के लिए एक्सपेरिमेंटल सपोर्ट को इंटिग्रेट किया. साथ ही, सबग्रुप की कार्रवाइयों के लिए, इसे Chrome के प्रोटोटाइप के साथ टेस्ट किया.

हमने बड़े लैंग्वेज मॉडल के प्रीफ़िल फ़ेज़ के जीपीयू कर्नेल में सबग्रुप का इस्तेमाल किया है. इसलिए, मैं सिर्फ़ पहले से भरी हुई पूरी जानकारी वाले चरण के स्पीडअप की रिपोर्ट कर रहा हूं. Intel जीपीयू पर, हम देखते हैं कि सबग्रुप, बेसलाइन के मुकाबले ढाई गुना तेज़ परफ़ॉर्म करते हैं. हालांकि, ये सुधार अलग-अलग जीपीयू में एक जैसे नहीं होते.

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

जीपीयू ऑप्टिमाइज़ेशन मुश्किल है

जीपीयू को ऑप्टिमाइज़ करने का सबसे अच्छा तरीका, इस बात पर निर्भर करता है कि क्लाइंट किस तरह का जीपीयू ऑफ़र कर रहा है. जीपीयू की नई सुविधाओं का इस्तेमाल करने से हमेशा उम्मीद के मुताबिक नतीजे नहीं मिलते, क्योंकि इसमें कई जटिल कारक शामिल हो सकते हैं. एक जीपीयू पर सबसे अच्छी ऑप्टिमाइज़ेशन रणनीति, शायद दूसरे जीपीयू पर बेहतर न हो.

जीपीयू के कंप्यूटिंग थ्रेड का पूरी तरह से इस्तेमाल करते समय, मेमोरी बैंडविड्थ को कम करना हो.

मेमोरी के ऐक्सेस के पैटर्न भी बहुत ज़रूरी हो सकते हैं. जब कंप्यूट थ्रेड, हार्डवेयर के लिए सबसे सही पैटर्न में मेमोरी को ऐक्सेस करती हैं, तो जीपीयू बेहतर परफ़ॉर्म करते हैं. अहम जानकारी: अलग-अलग जीपीयू हार्डवेयर पर, परफ़ॉर्मेंस की अलग-अलग विशेषताएं होनी चाहिए. जीपीयू के हिसाब से, आपको अलग-अलग ऑप्टिमाइज़ेशन चलाने की ज़रूरत पड़ सकती है.

नीचे दिए गए चार्ट में, हमने उसी मैट्रिक्स गुणा वाले एल्गोरिदम की मदद ली है. हालांकि, हमने इसमें एक और डाइमेंशन जोड़ा है, ताकि यह दिखाया जा सके कि अलग-अलग तरह की ऑप्टिमाइज़ेशन रणनीतियों के असर के साथ-साथ, अलग-अलग जीपीयू में क्या जटिलता और क्या होता है. हमने यहां एक नई तकनीक पेश की है. इसे हम "स्विज़ल" कहेंगे. Swizzle के लिए, मेमोरी के ऐक्सेस पैटर्न को ऑप्टिमाइज़ किया जाता है, ताकि वह हार्डवेयर के लिए ज़्यादा बेहतर तरीके से काम कर सके.

आप देख सकते हैं कि मेमोरी स्विज़ल का गहरा असर पड़ता है; कभी-कभी ये सबग्रुप के मुकाबले ज़्यादा असरदार होते हैं. जीपीयू 6 पर, स्विज़ल 12 गुना स्पीडअप देता है, जबकि सबग्रुप में 13 गुना स्पीडअप मिलता है. दोनों को जोड़ने पर, उनमें 26 गुना तेज़ी से बढ़ोतरी होती है. अन्य जीपीयू के लिए, कभी-कभी स्विज़ल और सबग्रुप, दोनों में से किसी एक के मुकाबले बेहतर परफ़ॉर्म करते हैं. साथ ही, दूसरे जीपीयू पर, खास तौर पर स्विज़ल का इस्तेमाल करने से बेहतर नतीजे मिलते हैं.

जीपीयू एल्गोरिदम को ट्यून करने और ऑप्टिमाइज़ करने के लिए, काफ़ी विशेषज्ञता की ज़रूरत हो सकती है. हालांकि, अच्छी बात यह है कि MediaMedia, Transformers.js, Apache TVM, ONNX Runtime Web जैसे बड़े लेवल के लाइब्रेरी फ़्रेमवर्क पर काफ़ी काम किया जा रहा है.

लाइब्रेरी और फ़्रेमवर्क इस तरह तैयार होते हैं कि वे अलग-अलग जीपीयू आर्किटेक्चर को मैनेज करने में आने वाली मुश्किलों को मैनेज कर सकें. साथ ही, प्लैटफ़ॉर्म के लिए खास कोड जनरेट कर सकें, जो क्लाइंट पर अच्छे से चलेगा.

सीखने वाली अहम बातें

Chrome टीम, WebAssembly और WebGPU के मानकों को बेहतर बनाने में लगातार मदद कर रही है, ताकि मशीन लर्निंग के वर्कलोड के लिए वेब प्लैटफ़ॉर्म को बेहतर बनाया जा सके. हम तेज़ कंप्यूट प्रिमिटिव पर काम कर रहे हैं. साथ ही, हम वेब के स्टैंडर्ड को बेहतर तरीके से इंटरऑप भी कर रहे हैं. साथ ही, हम यह भी पक्का कर रहे हैं कि छोटे और बड़े, दोनों तरह के मॉडल सभी डिवाइसों पर बेहतर तरीके से काम कर सकें.

हमारा मकसद, वेब की सबसे अच्छी सुविधाओं को बनाए रखते हुए, इस प्लैटफ़ॉर्म की क्षमताओं को बढ़ाना है. जैसे, पहुंच, उपयोगिता, और पोर्टेबिलिटी. हम यह अकेले नहीं कर रहे हैं. हम W3C के अन्य ब्राउज़र वेंडर और कई डेवलपमेंट पार्टनर के साथ मिलकर काम कर रहे हैं.

WebAssembly और WebGPU के साथ काम करते समय, हमें उम्मीद है कि आपको ये बातें याद होंगी:

• एआई का अनुमान लगाने की सुविधा अब वेब पर, सभी डिवाइसों के लिए उपलब्ध है. इसका फ़ायदा यह है कि क्लाइंट के डिवाइसों पर आपके विज्ञापन चलाए जा सकते हैं. जैसे, सर्वर की कम कीमत, इंतज़ार का समय कम होना, और निजता बढ़ाने की सुविधा.
• हालांकि यहां चर्चा की गई कई सुविधाएं मुख्य रूप से फ़्रेमवर्क के लेखकों के लिए काम की हैं, लेकिन आपके ऐप्लिकेशन को ज़्यादा खर्च किए बिना फ़ायदा हो सकता है.
• वेब के स्टैंडर्ड लगातार बदलते रहते हैं. साथ ही, हमें सुझाव/शिकायत/राय का इंतज़ार होता है. WebAssembly और WebGPU के लिए अपने जवाब शेयर करें.

स्वीकार की गई

हम Intel वेब ग्राफ़िक्स टीम को धन्यवाद देना चाहते हैं. इसने WebGPU f16 और इंटेजर डॉट प्रॉडक्ट की सुविधाओं को बेहतर बनाने में अहम भूमिका निभाई. हम W3C के WebAssembly और WebGPU के अन्य सदस्यों को धन्यवाद देना चाहते हैं. साथ ही, हम ब्राउज़र के दूसरे वेंडर को भी धन्यवाद देना चाहते हैं.

बेहतरीन पार्टनर बनने के लिए, Google और ओपन सोर्स कम्यूनिटी, दोनों की एआई और एमएल टीमों को धन्यवाद. और हां, हमारी टीम के वे सभी साथी जो यह सब संभव बनाते हैं.