LiteRT.js, TensorFlow.js-നെ മറികടക്കുന്നു
WebGPU ഉപയോഗിക്കുന്ന LiteRT.js, ഒരു M2 Max ഡെസ്ക്ടോപ്പ് GPU-വിൽ 0.41 ms-ൽ MobileNetV2 ഇൻഫറൻസ് നടത്തുകയും 2,439 FPS വേഗത നൽകുകയും ചെയ്യുന്നു—ഇത് അതേ ഹാർഡ്വെയറിലുള്ള TensorFlow.js-നേക്കാൾ 25 മടിക്കും അധികം വേഗതയുള്ളതാണ്. വലിയ മോഡലുകളുടെ കാര്യത്തിൽ ഈ വ്യത്യാസം വർദ്ധിക്കുന്നു, ഇത് വെബ് അധിഷ്ഠിത മെഷീൻ ലേണിംഗിനെ (machine learning) മുമ്പ് നേറ്റീവ് ആപ്പുകൾക്ക് (native apps) മാത്രം ലഭ്യമായിരുന്ന ഒരു പെർഫോമൻസ് തലത്തിലേക്ക് എത്തിക്കുന്നു.
ഈ ബെഞ്ച്മാർക്ക് (benchmark) പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
ഡെവലപ്പർമാർ സാധാരണയായി WebGL ബാക്കെൻഡ് (backend) വഴി ഓൺ-ഡിവൈസ് ഇൻഫറൻസിനായി TensorFlow.js ഉപയോഗിക്കുന്നു. WebGL ടെൻസർ ഓപ്പറേഷനുകളെ (tensor ops) ബ്രൗസറിലെ 2-D ഗ്രാഫിക്സ് പൈപ്പ്ലൈനുമായി ബന്ധിപ്പിക്കുന്നു; ഇത് എല്ലായിടത്തും പ്രവർത്തിക്കുമെങ്കിലും ഡീപ്പ് ലേണിംഗ് മോഡലുകൾക്ക് ആവശ്യമായ വൻതോതിലുള്ള പാരലലിസത്തിന് (parallelism) വേണ്ടി നിർമ്മിച്ചതല്ല. അടുത്ത തലമുറ ഗ്രാഫിക്സ് API ആയ WebGPU, GPU കമ്പ്യൂട്ട് യൂണിറ്റുകളിലേക്ക് നേരിട്ടുള്ള പ്രവേശനം നൽകുന്നു. TensorFlow-Lite മോഡലുകൾക്കായി WebGPU അടിസ്ഥാനമാക്കിയുള്ള ഇൻഫറൻസ് എഞ്ചിൻ അവതരിപ്പിക്കുന്ന ആദ്യത്തെ ലൈബ്രറിയാണ് LiteRT.js, കൂടാതെ മൂന്നിരട്ടി വേഗത വർദ്ധനവ് ഉണ്ടായതായി ഗൂഗിൾ റിപ്പോർട്ട് ചെയ്യുന്നു. സ്വതന്ത്രമായ പരിശോധനകൾ ഇതിലും വലിയ നേട്ടം കാണിക്കുന്നുണ്ട്, ഇത് വെബ് ML-ന് WebGPU ആയിരിക്കുമോ ഡിഫോൾട്ട് പാത എന്ന ചോദ്യം ഉയർത്തുന്നു.
ടെസ്റ്റ് എങ്ങനെയാണ് നടത്തിയത്
ഞങ്ങൾ രണ്ട് ഇമേജ്-ക്ലാസിഫിക്കേഷൻ മോഡലുകൾ—MobileNetV2, EfficientNet-Lite4—ബെഞ്ച്മാർക്ക് ചെയ്തു, ഇവ രണ്ടും TensorFlow-Lite-ലേക്ക് മാറ്റിയവയായിരുന്നു. Apple-silicon M2 Max ചിപ്പിലാണ് ടെസ്റ്റുകൾ നടത്തിയത്. ഓരോ മോഡലിനും, നിരവധി ഇറ്ററേഷനുകളിലൂടെയുള്ള (iterations) ഒരു സിംഗിൾ ഫോർവേഡ് പാസിന്റെ ലേറ്റൻസി (latency) ഞങ്ങൾ അളക്കുകയും ഫ്രെയിംസ്-പെർ-സെക്കൻഡ് (FPS) റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്തു. ഇതേ മോഡലുകൾ തന്നെ WebGL ബാക്കെൻഡിൽ TensorFlow.js ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കുകയും ഓരോ ലൈബ്രറിയുടെയും കോൾഡ്-സ്റ്റാർട്ട് (cold-start) സമയം രേഖപ്പെടുത്തുകയും ചെയ്തു.
ഫലങ്ങൾ: വേഗതയും സ്റ്റാർട്ടപ്പും
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 മടിക്കും (>25×) അധികം മുൻതൂക്കം കാണിക്കുന്നു.
ആദ്യത്തെ ഇൻഫറൻസിനുമുമ്പ് അതിന്റെ WebGL ഷേഡറുകൾ (shaders) കംപൈൽ ചെയ്യാൻ TensorFlow.js ഏകദേശം 10 സെക്കൻഡ് (10,014 ms) എടുത്തു. എന്നാൽ LiteRT.js വെറും 4.3 ms-ൽ തയ്യാറായിരുന്നു, ഇത് ഇന്ററാക്ടീവ് ആപ്പുകൾക്കുള്ള കോൾഡ്-സ്റ്റാർട്ട് കാലതാമസം (cold-start penalty) അടിസ്ഥാനപരമായി ഇല്ലാതാക്കുന്നു.
മോഡലിന്റെ വലിപ്പം അഞ്ചിരട്ടിയാക്കിയപ്പോൾ, ലേറ്റൻസി വെറും 50% മാത്രമേ വർദ്ധിച്ചുള്ളൂ, ഇത് GPU-വിന്റെ പാരലലിസം അധിക ജോലി ഭൂരിഭാഗവും ഏറ്റെടുക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നു. ഇതിന്റെ ഫലമായി, സെർവർ സന്ദർശനങ്ങളില്ലാതെ (server round-trips) റിയൽ-ടൈം വീഡിയോ സ്ട്രീമുകൾ, AR ഓവർലേകൾ, അല്ലെങ്കിൽ വിഷൻ മോഡലുകളുടെ വേഗത്തിലുള്ള പ്രോട്ടോടൈപ്പിംഗ് എന്നിവ ബ്രൗസറിന് കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന ഒരു പെർഫോമൻസ് പരിധിയിലേക്ക് ഇത് മാറുന്നു.
ഈ കണക്കുകൾ മറച്ചുവെക്കുന്ന കാര്യങ്ങൾ
- Batching – മിക്ക TensorFlow-Lite മോഡലുകളും ബാച്ച് ഡൈമൻഷനെ (batch dimension) 1 ആയി പരിമിതപ്പെടുത്തുന്നു. ഒറ്റ കോൾ വഴി ഒന്നിലധികം ചിത്രങ്ങൾ നൽകുന്നത് നേരിട്ട് പിന്തുണയ്ക്കുന്നില്ല, അതിനാൽ ഡെവലപ്പർമാർക്ക് Web Workers ഉപയോഗിക്കുകയോ അല്ലെങ്കിൽ ഇൻപുട്ടുകൾ മാനുവലായി പൈപ്പ്ലൈൻ ചെയ്യുകയോ ചെയ്യേണ്ടി വരുന്നു.
- Memory management – LiteRT.js GPU ടെൻസറുകളെ (tensors) സ്വയമേവ ഗാർബേജ് കളക്ട് (garbage-collect) ചെയ്യുന്നില്ല. ഡെവലപ്പർമാർ തങ്ങൾ നിർമ്മിക്കുന്ന ഓരോ ടെൻസറിലും
.delete()വിളിക്കണം, അല്ലെങ്കിൽ ഏതാനും നൂറ് ഇൻഫറൻസുകൾക്ക് ശേഷം GPU മെമ്മറി തീർന്നുപോകാൻ സാധ്യതയുണ്ട്. - Hardware reach – ഡെസ്ക്ടോപ്പ് Chrome, Firefox എന്നിവയിൽ WebGPU സുസ്ഥിരമാണ്. ആൻഡ്രോയിഡിലെ Chrome, iOS-ലെ Safari ഉൾപ്പെടെയുള്ള മൊബൈൽ ബ്രൗസറുകളിൽ, പരീക്ഷണാത്മക ഫ്ലാഗുകൾക്ക് (experimental flags) പിന്നിൽ മാത്രമേ ഈ API ലഭ്യമാകൂ അല്ലെങ്കിൽ ഒട്ടും ലഭ്യമാകില്ല. ഈ പ്ലാറ്റ്ഫോമുകളിൽ WASM ബാക്കെൻഡ് മാത്രമാണ് സാർവത്രികമായി ലഭ്യമായ മാർഗ്ഗം, എന്നാൽ വലിയ മോഡലുകൾക്ക് ഇത് വളരെ സാവധാനത്തിലാണ് പ്രവർത്തിക്കുന്നത്.
ഈ നിയന്ത്രണങ്ങൾ സൂചിപ്പിക്കുന്നത്, വേഗത മികച്ചതാണെങ്കിലും അത് കൈവരിക്കാനുള്ള എഞ്ചിനീയറിംഗ് പരിശ്രമം അത്ര എളുപ്പമല്ല എന്നാണ്.
പരിമിതികളും വിട്ടുവീഴ്ചകളും (trade-offs)
TensorFlow.js-ന്റെ WebGL ബാക്കെൻഡ് ഇപ്പോഴും ഏതാണ്ട് സാർവത്രികമായ പൊരുത്തക്ഷമത (compatibility) വാഗ്ദാനം ചെയ്യുന്നു. ഡെസ്ക്ടോപ്പ്, ആൻഡ്രോയിഡ്, iOS എന്നിങ്ങനെ വിവിധ ഉപയോക്താക്കളെ ലക്ഷ്യമിടുന്ന ഒരു ഡെവലപ്പർക്ക്, കുറഞ്ഞ പ്രവർത്തനക്ഷമത (throughput) ആണെങ്കിലും എല്ലായിടത്തും പ്രവർത്തിക്കുന്ന ഒരൊറ്റ കോഡ് പാത്ത് ഉപയോഗിക്കാം. WASM ബാക്കെൻഡ് ഏതാണ്ട് എല്ലാ ഹാർഡ്വെയറിലും പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, ഇവിടെ അളന്ന വലിയ മോഡലുകളുടെ കാര്യത്തിൽ WebGPU-വിനെക്കാൾ പിന്നിലാണ്.
WebGPU ലഭ്യമായ ഒരു ഡെസ്ക്ടോപ്പ് എൻവയോൺമെന്റ് ആണ് ലക്ഷ്യമെങ്കിൽ LiteRT.js മികച്ചതാണ്. ഇത് .tflite മോഡലുകൾ നേരിട്ട് പ്രവർത്തിപ്പിക്കുന്നു, അതിനാൽ ഡെവലപ്പർമാർക്ക് മോഡലുകൾ കൺവേർഷൻ കൂടാതെ Hugging Face അല്ലെങ്കിൽ Kaggle എന്നിവയിൽ നിന്ന് നേരിട്ട് എടുക്കാം, ഇത് ഒറിജിനൽ ക്വാണ്ടൈസേഷനും (quantization) പെർഫോമൻസും നിലനിർത്തുന്നു. ഇതിന്റെ വിട്ടുവീഴ്ച, പരിമിതമായ ഉപയോഗസാധ്യതയും (deployment envelope) വിഭവങ്ങൾ (resources) ശ്രദ്ധാപൂർവ്വം കൈകാര്യം ചെയ്യേണ്ടി വരുന്നതും ആണ്.
ഡെവലപ്പർമാർ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- Target platform – വെബ് മാത്രമുള്ള ഒരു ഡെസ്ക്ടോപ്പ് ടൂളിന് (ഉദാഹരണത്തിന്, റിയൽ ടൈമിൽ സ്റ്റൈൽ ട്രാൻസ്ഫർ നടത്തുന്ന ഒരു ഡിസൈൻ ആപ്പ്), LiteRT.js ഉപയോഗിച്ചുള്ള WebGPU ആയിരിക്കാൻ സാധ്യതയുള്ള ഏറ്റവും മികച്ച തിരഞ്ഞെടുപ്പാണ്.
- Model size – വലിയതും കമ്പ്യൂട്ട് ഭാരമുള്ളതുമായ മോഡലുകൾക്ക് GPU പാരലലിസത്തിൽ നിന്ന് കൂടുതൽ പ്രയോജനം ലഭിക്കും; ചെറിയ മോഡലുകൾക്ക് ഇതിനായുള്ള അധിക എഞ്ചിനീയറിംഗ് പരിശ്രമം അർഹമായേക്കില്ല.
- Memory discipline – ടെൻസറുകൾ കൃത്യമായി ഡിലീറ്റ് ചെയ്യാനോ അല്ലെങ്കിൽ വിഭവങ്ങൾ സ്വയമേവ മോചിപ്പിക്കുന്ന രീതിയിലുള്ള ഒരു സ്കോപ്പിൽ (scope) ഇൻഫറൻസ് കോളുകൾ ഉൾപ്പെടുത്താനോ പ്ലാൻ ചെയ്യുക.
- Fallback strategy – WebGPU പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയാത്ത ബ്രൗസറുകൾക്കായി WASM അല്ലെങ്കിൽ WebGL ഫാള்பാക്ക് (fallback) നൽകുക, ഇത് കൂടുതൽ ഉപയോക്താക്കൾക്ക് ആപ്പ് ഉപയോഗിക്കാൻ സാധ്യമാക്കും.
ചുരുക്കം (Takeaway)
LiteRT.js തെളിയിക്കുന്നത് WebGPU-വിന് വെബ് അധിഷ്ഠിത ഇൻഫറൻസിനെ മില്ലിസെക്കൻഡിന് താഴെ എന്ന നിലവാരത്തിലേക്ക് എത്തിക്കാൻ കഴിയുമെന്നാണ്, ഇത് ഡെസ്ക്ടോപ്പ് GPU-കളിൽ TensorFlow.js-നേക്കാൾ 25 × കൂടുതൽ വേഗത നൽകുന്നു. ഈ സാങ്കേതികവിദ്യ ഇപ്പോഴും വളർന്നുകൊണ്ടിരിക്കുകയാണ്, അതിനാൽ ബാച്ചിംഗ് പരിധികൾ, മാനുവൽ മെമ്മറി ക്ലീനപ്പ്, പരിമിതമായ മൊബൈൽ സപ്പോർട്ട് എന്നിവ ഡെവലപ്പർമാർ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. റിയൽ-ടൈം പെർഫോമൻസ് ആവശ്യമായ ഡെസ്ക്ടോപ്പ് മുൻഗണനയുള്ള അനുഭവങ്ങൾക്ക് ഈ പുതിയ ലൈബ്രറി മികച്ചൊരു മുന്നേറ്റം വാഗ്ദാനം ചെയ്യുന്നു; എന്നാൽ ക്രോസ്-പ്ലാറ്റ്ഫോം ലഭ്യതയ്ക്കായി പഴയ WebGL, WASM ബാക്കെൻഡുകൾ ഇപ്പോഴും അത്യാവശ്യമാണ്.
