क्लाइंट-साइड एआई के लिए, परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को बेहतर बनाएं

Maud Nalpas
Maud Nalpas

वेब पर एआई की ज़्यादातर सुविधाएं, सर्वर पर काम करती हैं. हालांकि, क्लाइंट-साइड एआई सीधे तौर पर उपयोगकर्ता के ब्राउज़र में काम करता है. इससे कई फ़ायदे मिलते हैं. जैसे, कम इंतज़ार का समय, सर्वर साइड की लागत में कमी, एपीआई पासकोड की ज़रूरत नहीं पड़ना, उपयोगकर्ता की निजता को बेहतर बनाना, और ऑफ़लाइन ऐक्सेस. क्लाइंट-साइड एआई लागू किया जा सकता है, जो TensorFlow.js, Transformers.js, और MediaPipe GenAI जैसी JavaScript लाइब्रेरी के साथ सभी ब्राउज़र पर काम करता है.

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

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

मॉडल डाउनलोड करने से पहले

माइंड लाइब्रेरी और मॉडल का साइज़

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

मॉडल का साइज़ भी मायने रखता है. किसी एआई मॉडल के लिए, बड़े साइज़ का मतलब क्या है, यह कई बातों पर निर्भर करता है. 5 एमबी एक अच्छा नियम हो सकता है: यह वेब पेज के औसत साइज़ का 75वां प्रतिशत भी है. कम से कम 10 एमबी का होना चाहिए.

मॉडल के साइज़ के बारे में कुछ ज़रूरी बातें यहां दी गई हैं:

  • टास्क के हिसाब से बनाए गए कई एआई मॉडल बहुत छोटे हो सकते हैं. BudouX जैसे मॉडल का साइज़, जीज़िप करने पर सिर्फ़ 9.4 केबी होता है. यह मॉडल, एशियाई भाषाओं में वर्णों को सही तरीके से बांटने के लिए इस्तेमाल किया जाता है. MediaPipe का भाषा पहचानने वाला मॉडल 315 केबी का है.
  • विज़न मॉडल का साइज़ भी सही हो सकता है. Handpose मॉडल और उससे जुड़े सभी संसाधनों का कुल साइज़ 13.4 एमबी है. यह साइज़, ज़्यादातर छोटे किए गए फ़्रंटएंड पैकेज से काफ़ी ज़्यादा है. हालांकि, यह औसत वेब पेज के साइज़ के बराबर है. औसत वेब पेज का साइज़ 2.2 एमबी (डेस्कटॉप पर 2.6 एमबी) होता है.
  • जेन एआई मॉडल, वेब रिसॉर्स के लिए सुझाए गए साइज़ से ज़्यादा हो सकते हैं. DistilBERT का साइज़ 67 एमबी है. इसे बहुत छोटा एलएलएम या आसान एनएलपी मॉडल माना जाता है. हालांकि, इस बारे में अलग-अलग लोगों की अलग-अलग राय है. Gemma 2B जैसे छोटे एलएलएम का साइज़ भी 1.3 जीबी तक हो सकता है. यह साइज़, मीडियन वेब पेज के साइज़ से 100 गुना ज़्यादा है.

अपने ब्राउज़र के डेवलपर टूल का इस्तेमाल करके, उन मॉडल के डाउनलोड साइज़ का सटीक आकलन किया जा सकता है जिनका इस्तेमाल करना है.

Chrome DevTools के नेटवर्क पैनल में, MediaPipe के भाषा पहचानने वाले मॉडल का डाउनलोड साइज़. डेमो.
Chrome DevTools के नेटवर्क पैनल में, जनरल एआई के मॉडल के लिए डाउनलोड साइज़: Gemma 2B (छोटा एलएलएम), DistilBERT (छोटा एनएलपी / बहुत छोटा एलएलएम).

मॉडल का साइज़ ऑप्टिमाइज़ करना

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

ये सभी मॉडल एक ही काम करते हैं, लेकिन अलग-अलग सटीक तरीके से. साथ ही, इनका साइज़ भी अलग-अलग होता है: 3 एमबी से 1.5 जीबी तक.

देखें कि मॉडल चल सकता है या नहीं

सभी डिवाइसों पर एआई मॉडल नहीं चल सकते. मॉडल के इस्तेमाल के दौरान, अगर कोई दूसरी महंगी प्रोसेस चल रही है या शुरू की गई है, तो हो सकता है कि जिन डिवाइसों में ज़रूरी हार्डवेयर स्पेसिफ़िकेशन हैं वे भी काम न कर पाएं.

जब तक कोई समाधान उपलब्ध नहीं होता, तब तक ये काम किए जा सकते हैं:

  • देखें कि WebGPU काम करता है या नहीं. कई क्लाइंट-साइड एआई लाइब्रेरी, WebGPU का इस्तेमाल करती हैं. इनमें Transformers.js का वर्शन 3 और MediaPipe शामिल हैं. फ़िलहाल, अगर WebGPU काम नहीं करता है, तो इनमें से कुछ लाइब्रेरी अपने-आप Wasm पर स्विच नहीं होतीं. अगर आपको पता है कि आपकी क्लाइंट-साइड एआई लाइब्रेरी को WebGPU की ज़रूरत है, तो एआई से जुड़े कोड को WebGPU सुविधा की पहचान करने की जांच में शामिल करके, इस समस्या को कम किया जा सकता है.
  • कम क्षमता वाले डिवाइसों को हटा दें. डिवाइस की क्षमताओं और दबाव का अनुमान लगाने के लिए, Navigator.hardwareConcurrency, Navigator.deviceMemory और Compute Pressure API का इस्तेमाल करें. ये एपीआई सभी ब्राउज़र पर काम नहीं करते. साथ ही, फ़िंगरप्रिंटिंग को रोकने के लिए, इन्हें जान-बूझकर असटीक बनाया गया है. हालांकि, इनसे ऐसे डिवाइसों को बाहर रखा जा सकता है जो बहुत कम क्षमता वाले लगते हैं.

बड़ी फ़ाइलों के डाउनलोड के सिग्नल

बड़े मॉडल के लिए, डाउनलोड करने से पहले उपयोगकर्ताओं को चेतावनी दें. मोबाइल उपयोगकर्ताओं की तुलना में, डेस्कटॉप उपयोगकर्ताओं के बड़े डाउनलोड करने की संभावना ज़्यादा होती है. मोबाइल डिवाइसों का पता लगाने के लिए, User-Agent Client Hints API से mobile का इस्तेमाल करें. अगर UA-CH काम नहीं करता है, तो User-Agent स्ट्रिंग का इस्तेमाल करें.

बड़ी फ़ाइलों के डाउनलोड को सीमित करना

  • सिर्फ़ ज़रूरी फ़ाइलें डाउनलोड करें. अगर मॉडल का साइज़ बड़ा है, तो उसे सिर्फ़ तब डाउनलोड करें, जब आपको यह पक्का हो कि एआई की सुविधाओं का इस्तेमाल किया जाएगा. उदाहरण के लिए, अगर आपके ऐप्लिकेशन में टाइप करने से पहले सुझाव देने वाली एआई सुविधा है, तो उसे सिर्फ़ तब डाउनलोड करें, जब उपयोगकर्ता टाइप करने की सुविधाओं का इस्तेमाल करना शुरू करे.
  • Cache API का इस्तेमाल करके, डिवाइस पर मॉडल को साफ़ तौर पर कैश मेमोरी में सेव करें, ताकि हर बार उसे डाउनलोड करने से बचा जा सके. सिर्फ़ एचटीटीपी ब्राउज़र कैश मेमोरी पर भरोसा न करें.
  • मॉडल को डाउनलोड करने के लिए, उसे कई हिस्सों में बांटना. fetch-in-chunks, बड़े डाउनलोड को छोटे हिस्सों में बांटता है.

मॉडल डाउनलोड करना और उसे तैयार करना

उपयोगकर्ता को ब्लॉक न करें

उपयोगकर्ता अनुभव को बेहतर बनाने पर ध्यान दें: एआई मॉडल के पूरी तरह से लोड न होने पर भी, मुख्य सुविधाओं को काम करने दें.

पक्का करें कि उपयोगकर्ता अब भी पोस्ट कर सकें.
क्लाइंट-साइड एआई की सुविधा अभी तैयार न होने पर भी, उपयोगकर्ता अब भी अपनी समीक्षा पोस्ट कर सकते हैं. @maudnals का डेमो.

प्रोग्रेस दिखाना

मॉडल डाउनलोड करते समय, डाउनलोड की प्रोग्रेस और बचे हुए समय की जानकारी दें.

  • अगर मॉडल डाउनलोड करने की प्रोसेस को आपकी क्लाइंट-साइड एआई लाइब्रेरी मैनेज करती है, तो उपयोगकर्ता को डाउनलोड की प्रोग्रेस की स्थिति दिखाने के लिए, डाउनलोड की प्रोग्रेस की स्थिति का इस्तेमाल करें. अगर यह सुविधा उपलब्ध नहीं है, तो इसका अनुरोध करने के लिए कोई समस्या खोलें या इस सुविधा को उपलब्ध कराने में योगदान दें!
  • अगर मॉडल डाउनलोड करने की प्रोसेस को अपने कोड में मैनेज किया जाता है, तो fetch-in-chunks जैसी लाइब्रेरी का इस्तेमाल करके, मॉडल को कई हिस्सों में फ़ेच किया जा सकता है. साथ ही, उपयोगकर्ता को डाउनलोड की प्रोग्रेस दिखाई जा सकती है.
मॉडल डाउनलोड करने की प्रोग्रेस दिखाने वाला डिसप्ले. चंक में फ़ेच करें के साथ कस्टम तरीके से लागू करना. @tomayac का डेमो.

नेटवर्क से जुड़ी रुकावटों को आसानी से मैनेज करना

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

खराब इंटरनेट कनेक्शन की वजह से भी, वीडियो को अलग-अलग हिस्सों में डाउनलोड किया जा सकता है.

वेब वर्कर पर ज़्यादा समय लेने वाले टास्क भेजना

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

वेब वर्कर्स के आधार पर, डेमो और पूरी तरह से लागू किए गए वर्शन के बारे में जानें:

Chrome DevTools में परफ़ॉर्मेंस ट्रेस.
सबसे ऊपर: वेब वर्कर्स के साथ. सबसे नीचे: कोई वेब वर्कर नहीं है.

अनुमान लगाने के दौरान

मॉडल डाउनलोड हो जाने और तैयार होने के बाद, अनुमान लगाने की प्रोसेस शुरू की जा सकती है. अनुमान लगाने के लिए, कंप्यूटर पर काफ़ी काम करना पड़ सकता है.

अनुमान लगाने की प्रोसेस को वेब वर्कर्स पर ले जाना

अगर अनुमान WebGL, WebGPU या WebNN की मदद से लगाया जाता है, तो यह जीपीयू पर निर्भर करता है. इसका मतलब है कि यह एक अलग प्रोसेस में होता है, जो यूज़र इंटरफ़ेस (यूआई) को ब्लॉक नहीं करता.

हालांकि, सीपीयू पर काम करने वाले इंप्लीमेंटेशन (जैसे, Wasm, जो WebGPU के काम न करने पर उसका फ़ॉलबैक हो सकता है) के लिए, वेब वर्कर पर अनुमान लगाने की सुविधा को ले जाने से आपका पेज, मॉडल तैयार करने के दौरान की तरह ही रिस्पॉन्सिव बना रहता है.

एआई से जुड़ा सारा कोड (मॉडल फ़ेच करना, मॉडल तैयार करना, अनुमान लगाना) एक ही जगह पर होने पर, एआई को लागू करना आसान हो सकता है. इसलिए, जीपीयू का इस्तेमाल हो रहा है या नहीं, इस बात से कोई फ़र्क़ नहीं पड़ता कि आपने वेब वर्कर्स का इस्तेमाल किया है या नहीं.

गड़बड़ियां ठीक करना

भले ही, आपने यह जांच कर ली हो कि मॉडल डिवाइस पर चलेगा, लेकिन उपयोगकर्ता कोई ऐसी प्रोसेस शुरू कर सकता है जो बाद में ज़्यादा संसाधनों का इस्तेमाल करती है. इसे कम करने के लिए:

  • अनुमान से जुड़ी गड़बड़ियां मैनेज करना. अनुमान लगाने की प्रोसेस को try/catch ब्लॉक में शामिल करें और उससे जुड़ी रनटाइम गड़बड़ियों को मैनेज करें.
  • WebGPU से जुड़ी गड़बड़ियों को मैनेज करें. इनमें अनचाही और GPUDevice.lost, दोनों तरह की गड़बड़ियां शामिल हैं. ये गड़बड़ियां तब होती हैं, जब डिवाइस में समस्या होने की वजह से GPU रीसेट हो जाता है.

अनुमान की स्थिति दिखाना

अगर अनुमान लगाने में ज़्यादा समय लगता है, तो उपयोगकर्ता को बताएं कि मॉडल सोच रहा है. इंतज़ार के दौरान उपयोगकर्ताओं को ऐनिमेशन दिखाएं, ताकि वे यह महसूस कर सकें कि ऐप्लिकेशन सही तरीके से काम कर रहा है.

अनुमान लगाने के दौरान ऐनिमेशन का उदाहरण.
@maudnals और @argyleink
के बनाए गए डेमो

अनुमान को रद्द करने की सुविधा जोड़ना

उपयोगकर्ता को अपनी क्वेरी को तुरंत बेहतर बनाने की अनुमति दें. इससे सिस्टम को ऐसे जवाब जनरेट करने के लिए संसाधनों को बर्बाद नहीं करना पड़ता जो उपयोगकर्ता को कभी नहीं दिखेगा.