LiteRT.js, TensorFlow.js ला मागे टाकत आहे

WebGPU सह LiteRT.js, MobileNetV2 चा इन्फरन्स (inference) 0.41 ms मध्ये पूर्ण करते, ज्यामुळे M2 Max डेस्कटॉप GPU वर 2,439 FPS मिळतात—जे त्याच हार्डवेअरवरील TensorFlow.js पेक्षा 25 × पेक्षा जास्त वेगवान आहे. मोठ्या मॉडेल्ससाठी हा फरक अधिकच वाढतो, ज्यामुळे वेब-आधारित मशीन लर्निंग आता अशा परफॉर्मन्स टियरमध्ये पोहोचले आहे जे पूर्वी केवळ नेटिव्ह ॲप्ससाठी राखीव होते.

हे बेंचमार्क का महत्त्वाचे आहे

डेव्हलपर्स ऑन-डिव्हाइस इन्फरन्ससाठी सहसा WebGL बॅकएंडद्वारे TensorFlow.js वापरत आले आहेत. WebGL टेन्सर ऑपरेशन्सना (tensor ops) ब्राउझरच्या 2-D ग्राफिक्स पाइपलाइनवर मॅप करते; ते सर्वत्र काम करते परंतु डीप-लर्निंग मॉडेल्सना आवश्यक असलेल्या प्रचंड पॅरललिझमसाठी (parallelism) ते बनवलेले नव्हते. WebGPU, हे पुढच्या पिढीचे ग्राफिक्स API, GPU कम्प्युट युनिट्सना थेट प्रवेश देते. TensorFlow-Lite मॉडेल्ससाठी WebGPU-बॅकड इन्फरन्स इंजिन उपलब्ध करून देणारी LiteRT.js ही पहिली लायब्ररी आहे आणि Google ने तीन पटीने वेग वाढल्याचे सांगितले आहे. स्वतंत्र चाचण्यांमध्ये त्याहूनही अधिक फायदा दिसून आला आहे, ज्यामुळे आता असा प्रश्न निर्माण होत आहे की WebGPU हे वेब ML साठी डीफॉल्ट मार्ग बनेल का.

चाचणी कशी घेण्यात आली

आम्ही दोन इमेज-क्लासिफिकेशन मॉडेल्स—MobileNetV2 आणि EfficientNet-Lite4—यांची बेंचमार्किंग केली, ही दोन्ही मॉडेल्स TensorFlow-Lite मध्ये रूपांतरित केली होती. या चाचण्या Apple-silicon M2 Max चिपवर चालवण्यात आल्या. प्रत्येक मॉडेलसाठी आम्ही अनेक इटरेशन्समध्ये एका सिंगल फॉरवर्ड पासचा लॅटन्सी (latency) मोजला आणि फ्रेम्स-पर-सेकंद (FPS) नोंदवले. आम्ही तेच मॉडेल्स WebGL बॅकएंडसह TensorFlow.js वर चालवले आणि प्रत्येक लायब्ररीचा कोल्ड-स्टार्ट वेळ (cold-start time) नोंदवला.

निकाल: वेग आणि स्टार्टअप

  • MobileNetV2

    • LiteRT.js (WebGPU): 0.41 ms लॅटन्सी → 2,439 FPS
    • TensorFlow.js (WebGL): 10.82 ms लॅटन्सी → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): 0.62 ms लॅटन्सी → 1,623 FPS
    • TensorFlow.js (WebGL): नोंदवलेले नाही, परंतु MobileNetV2 मध्ये आधीच >25× फायदा दिसून येत आहे.

पहिल्या इन्फरन्सपूर्वी TensorFlow.js ला त्याचे WebGL शेडर्स (shaders) कंपाईल करण्यासाठी सुमारे 10 सेकंद (10,014 ms) लागले. LiteRT.js मात्र 4.3 ms मध्ये तयार होते, ज्यामुळे इंटरअॅक्टिव्ह ॲप्ससाठी होणारा कोल्ड-स्टार्टचा फटका (penalty) जवळजवळ निघून गेला आहे.

जेव्हा आम्ही मॉडेलचा आकार पाच पटीने वाढवला, तेव्हा लॅटन्सी केवळ 50% वाढली, ज्यावरून हे सिद्ध होते की GPU चा पॅरललिझम अतिरिक्त कामाचा मोठा भाग हाताळतो. याचा परिणाम असा आहे की, आता ब्राउझर सर्व्हरवर अवलंबून न राहता रिअल-टाइम व्हिडिओ स्ट्रीम्स, AR ओव्हरले किंवा व्हिजन मॉडेल्सचे जलद प्रोटोटाइपिंग हाताळू शकतो.

या आकड्यांमागील वास्तव

  • Batching – बहुतेक TensorFlow-Lite मॉडेल्समध्ये बॅच डायमेंशन (batch dimension) 1 वर लॉक असते. एकाच कॉलमध्ये अनेक इमेजेस फीड करणे थेट शक्य नाही, ज्यामुळे डेव्हलपर्सना Web Workers वापरावे लागतात किंवा इनपुट्स मॅन्युअली पाइपलाइन करावे लागतात.
  • Memory management – LiteRT.js मध्ये GPU टेन्सरचे (tensors) ऑटोमॅटिक गार्बेज-कलेक्शन (garbage-collect) होत नाही. डेव्हलपर्सना त्यांनी तयार केलेल्या प्रत्येक टेन्सरवर .delete() कॉल करावा लागतो, अन्यथा काही शेकडो इन्फरन्स नंतर GPU मेमरी संपण्याचा धोका असतो.
  • Hardware reach – डेस्कटॉप Chrome आणि Firefox वर WebGPU स्थिर आहे. मोबाईल ब्राउझर्स—ज्यामध्ये Android वरील Chrome आणि iOS वरील Safari यांचा समावेश आहे—हे API केवळ प्रायोगिक फ्लॅग्स (experimental flags) द्वारे किंवा अजिबात उपलब्ध करून देत नाहीत. अशा प्लॅटफॉर्मवर WASM बॅकएंड हाच एकमेव सर्वत्र उपलब्ध असलेला मार्ग आहे, परंतु मोठ्या मॉडेल्ससाठी तो लक्षणीयरीत्या संथ आहे.

या मर्यादांचा अर्थ असा आहे की, जरी वेग थक्क करणारा असला, तरी तो साध्य करण्यासाठी लागणारे इंजिनिअरिंग प्रयत्न सोपे नाहीत.

मर्यादा आणि तडजोडी

TensorFlow.js चे WebGL बॅकएंड अजूनही जवळजवळ सर्वत्र सुसंगतता (compatibility) प्रदान करते. डेस्कटॉप, Android, iOS अशा मिश्रित प्रेक्षकांना लक्ष्य करणारा डेव्हलपर एकाच कोड पाथवर अवलंबून राहू शकतो जो सर्वत्र चालतो, जरी त्याचा थ्रूपुट (throughput) कमी असला तरीही. WASM बॅकएंड जवळजवळ कोणत्याही हार्डवेअरवर चालते, परंतु येथे मोजण्यात आलेल्या मोठ्या मॉडेल्ससाठी ते WebGPU च्या मागे पडते.

जेव्हा लक्ष्य WebGPU सक्षम असलेले डेस्कटॉप एन्व्हायर्नमेंट असते, तेव्हा LiteRT.js उत्कृष्ट कामगिरी करते. हे .tflite मॉडेल्स थेट चालवते, ज्यामुळे डेव्हलपर्सना कोणत्याही रूपांतरणाशिवाय (conversion) Hugging Face किंवा Kaggle वरून मॉडेल्स वापरता येतात, ज्यामुळे मूळ क्वांटायझेशन (quantization) आणि परफॉर्मन्स कायम राहतो. मात्र, याची तडजोड म्हणजे मर्यादित उपयोजन क्षेत्र (deployment envelope) आणि संसाधनांच्या (resources) काळजीपूर्वक हाताळणीची गरज.

डेव्हलपर्सनी काय विचारात घेतले पाहिजे

  • Target platform – केवळ वेब-आधारित डेस्कटॉप टूलसाठी (उदा. रिअल-टाइममध्ये स्टाईल ट्रान्सफर करणारी डिझाइन ॲप), LiteRT.js सह WebGPU हा बहुधा सर्वोत्तम पर्याय असेल.
  • Model size – मोठे आणि संगणकीयदृष्ट्या जड (compute-heavy) मॉडेल्सना GPU पॅरललिझमचा सर्वाधिक फायदा होतो; लहान मॉडेल्ससाठी अतिरिक्त इंजिनिअरिंग करणे फायदेशीर ठरणार नाही.
  • Memory discipline – टेन्सर डिलीट करण्यासाठी स्पष्ट योजना आखणे किंवा इन्फरन्स कॉल्स अशा स्कोपमध्ये ठेवणे जो आपोआप संसाधने मुक्त करेल.
  • Fallback strategy – जे ब्राउझर्स WebGPU सक्षम करू शकत नाहीत, त्यांच्यासाठी WASM किंवा WebGL फॉलबॅक (fallback) उपलब्ध करून द्या, जेणेकरून ॲप मोठ्या प्रेक्षकांसाठी कार्यान्वित राहील.

निष्कर्ष

LiteRT.js ने हे सिद्ध केले आहे की WebGPU वेब-आधारित इन्फरन्सला मिलीसेकंदापेक्षा कमी वेळेच्या (sub-millisecond) श्रेणीत नेऊ शकते, जे डेस्कटॉप GPUs वर TensorFlow.js पेक्षा 25 × पेक्षा जास्त वेग प्रदान करते. हे तंत्रज्ञान अजूनही विकसित होत आहे आणि डेव्हलपर्सना बॅचिंग मर्यादा, मॅन्युअल मेमरी क्लीनअप आणि मर्यादित मोबाईल सपोर्ट यांसारख्या गोष्टी हाताळाव्या लागतील. रिअल-टाइम परफॉर्मन्सची आवश्यकता असलेल्या डेस्कटॉप-फर्स्ट अनुभवांसाठी, ही नवीन लायब्ररी एक प्रभावी मार्ग प्रदान करते; क्रॉस-प्लॅटफॉर्म व्याप्तीसाठी, जुने WebGL आणि WASM बॅकएंड्स अजूनही अत्यावश्यक आहेत.