LiteRT.js, TensorFlow.js ને પાછળ છોડી રહ્યું છે

WebGPU સાથેનું LiteRT.js MobileNetV2 ઇન્ફરન્સ (inference) 0.41 ms માં ચલાવે છે, જે M2 Max ડેસ્કટોપ GPU પર 2,439 FPS આપે છે—જે સમાન હાર્ડવેર પર TensorFlow.js કરતા 25 × થી વધુ ઝડપી છે. મોટા મોડલ્સ માટે આ તફાવત વધુ વધે છે, જે વેબ-આધારિત મશીન લર્નિંગને એવા પર્ફોર્મન્સ સ્તર પર લઈ જાય છે જે પહેલા માત્ર નેટિવ એપ્સ માટે જ અનામત હતું.

આ બેન્ચમાર્ક શા માટે મહત્વનો છે

ડેવલપર્સ ઓન-ડિવાઇસ ઇન્ફરન્સ માટે TensorFlow.js નો ઉપયોગ કરતા આવ્યા છે, જે સામાન્ય રીતે WebGL બેકએન્ડ દ્વારા કરવામાં આવે છે. WebGL ટેન્સર ઓપરેશન્સને બ્રાઉઝરના 2-D ગ્રાફિક્સ પાઇપલાઇન પર મેપ કરે છે; તે દરેક જગ્યાએ કામ કરે છે પરંતુ ડીપ-લર્નિંગ મોડલ્સને જરૂરી વિશાળ પેરેલલિઝમ (parallelism) માટે બનાવવામાં આવ્યું નથી. WebGPU, જે આગામી પેઢીનું ગ્રાફિક્સ API છે, તે GPU કમ્પ્યુટ યુનિટ્સનો સીધો એક્સેસ આપે છે. LiteRT.js એ TensorFlow-Lite મોડલ્સ માટે WebGPU-બેક્ડ ઇન્ફરન્સ એન્જિન પ્રદાન કરનાર પ્રથમ લાઇબ્રેરી છે, અને Google ત્રણ ગણા સ્પીડઅપ (speedup) નો અહેવાલ આપે છે. સ્વતંત્ર પરીક્ષણો વધુ મોટો ફાયદો દર્શાવે છે, જે એ પ્રશ્ન ઉભો કરે છે કે શું WebGPU વેબ ML માટે ડિફોલ્ટ માર્ગ બનશે.

ટેસ્ટ કેવી રીતે કરવામાં આવ્યો હતો

અમે બે ઇમેજ-ક્લાસિફિકેશન મોડલ્સ—MobileNetV2 અને EfficientNet-Lite4—નું બેન્ચમાર્ક કર્યું, જે બંનેને TensorFlow-Lite માં રૂપાંતરિત કરવામાં આવ્યા હતા. ટેસ્ટ Apple-silicon M2 Max ચિપ પર ચલાવવામાં આવ્યા હતા. દરેક મોડલ માટે અમે ઘણા ઇટરેશન્સ (iterations) પર સિંગલ ફોરવર્ડ પાસની લેટન્સી (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× ફાયદો બતાવે છે.

પ્રથમ ઇન્ફરન્સ પહેલા તેના WebGL શેડર્સ (shaders) કમ્પાઇલ કરવા માટે TensorFlow.js ને લગભગ 10 સેકન્ડ (10,014 ms) ની જરૂર પડી હતી. LiteRT.js માત્ર 4.3 ms માં તૈયાર હતું, જે ઇન્ટરેક્ટિવ એપ્સ માટે કોલ્ડ-સ્ટાર્ટ પેનલ્ટીને (cold-start penalty) લગભગ નાબૂદ કરે છે.

જ્યારે અમે મોડલનું કદ પાંચ ગણું વધાર્યું, ત્યારે લેટન્સી માત્ર 50% વધી, જે પુષ્ટિ કરે છે કે GPU નું પેરેલલિઝમ વધારાના મોટાભાગના કામને શોષી લે છે. તેનું પરિણામ એવું પર્ફોર્મન્સ છે જે બ્રાઉઝરને સર્વર રાઉન્ડ-ટ્રિપ્સ વગર રીઅલ-ટાઇમ વિડિયો સ્ટ્રીમ્સ, AR ઓવરલે અથવા વિઝન મોડલ્સના ઝડપી પ્રોટોટાઇપિંગને હેન્ડલ કરવા દે છે.

આ આંકડા શું છુપાવે છે

  • Batching – મોટાભાગના TensorFlow-Lite મોડલ્સ બેચ ડાયમેન્શનને (batch dimension) 1 પર લોક કરે છે. સિંગલ કોલમાં એકસાથે અનેક ઇમેજ આપવાનું સીધું સપોર્ટ નથી મળતું, જેના કારણે ડેવલપર્સને Web Workers બનાવવા પડે છે અથવા મેન્યુઅલી ઇનપુટ્સ પાઇપલાઇન કરવા પડે છે.
  • Memory management – LiteRT.js આપમેળે GPU ટેન્સરનું ગાર્બેજ-કલેક્શન (garbage-collect) કરતું નથી. ડેવલપર્સે બનાવેલા દરેક ટેન્સર પર .delete() કોલ કરવું આવશ્યક છે, અન્યથા થોડાક સો ઇન્ફરન્સ પછી GPU મેમરી ખતમ થવાનું જોખમ રહે છે.
  • Hardware reach – WebGPU ડેસ્કટોપ Chrome અને Firefox પર સ્થિર છે. મોબાઈલ બ્રાઉઝર્સ—જેમાં Android પર Chrome અને iOS પર Safari શામેલ છે—API ને માત્ર પ્રાયોગિક ફ્લેગ્સ (experimental flags) દ્વારા જ અથવા બિલકુલ આપતા નથી. તે પ્લેટફોર્મ્સ પર WASM બેકએન્ડ એ એકમાત્ર યુનિવર્સલ રીતે ઉપલબ્ધ માર્ગ છે, પરંતુ તે મોટા મોડલ્સ માટે નોંધપાત્ર રીતે ધીમું છે.

આ મર્યાદાઓનો અર્થ એ છે કે ભલે કાચી ઝડપ (raw speed) પ્રભાવિત કરે છે, પરંતુ તેને પ્રાપ્ત કરવા માટેનો એન્જિનિયરિંગ પ્રયાસ સરળ નથી.

મર્યાદાઓ અને સમજૂતીઓ (trade-offs)

TensorFlow.js નું WebGL બેકએન્ડ હજુ પણ લગભગ યુનિવર્સલ સુસંગતતા (compatibility) આપે છે. ડેસ્કટોપ, Android, iOS જેવા મિશ્ર પ્રેક્ષકોને લક્ષ્ય બનાવતા ડેવલપર એક જ કોડ પાથ પર ભરોસો રાખી શકે છે જે દરેક જગ્યાએ ચાલે છે, ભલે તે ઓછી થ્રુપુટ (throughput) પર હોય. WASM બેકએન્ડ લગભગ કોઈપણ હાર્ડવેર પર ચાલે છે પરંતુ અહીં માપવામાં આવેલા મોટા મોડલ્સ માટે WebGPU કરતા પાછળ રહી જાય છે.

જ્યારે લક્ષ્ય WebGPU સક્ષમ ડેસ્કટોપ એન્વાયરમેન્ટ હોય ત્યારે LiteRT.js શ્રેષ્ઠ કામ કરે છે. તે .tflite મોડલ્સ સીધા ચલાવે છે, જેનાથી ડેવલપર્સ કોઈપણ રૂપાંતર વગર Hugging Face અથવા Kaggle માંથી મોડલ્સ મેળવી શકે છે, અને મૂળ ક્વોન્ટાઇઝેશન (quantization) અને પર્ફોર્મન્સ જાળવી શકે છે. તેની સામેનો નુકસાન (trade-off) એ ઓછું ડિપ્લોયમેન્ટ સ્તર અને સંસાધનોના (resources) કાળજીપૂર્વક સંચાલનની જરૂરિયાત છે.

ડેવલપર્સે શું ધ્યાનમાં લેવું જોઈએ

  • Target platform – વેબ-ઓન્લી ડેસ્કટોપ ટૂલ માટે (દા.ત., રીઅલ-ટાઇમમાં સ્ટાઇલ ટ્રાન્સફર લાગુ કરતી ડિઝાઇન એપ), LiteRT.js સાથે WebGPU સંભવિત શ્રેષ્ઠ પસંદગી છે.
  • Model size – મોટા, કમ્પ્યુટ-હેવી મોડલ્સને GPU પેરેલલિઝમથી સૌથી વધુ ફાયદો થાય છે; નાના મોડલ્સ વધારાના એન્જિનિયરિંગને યોગ્ય ઠેરવી શકતા નથી.
  • Memory discipline – સ્પષ્ટ ટેન્સર ડિલીશનનું આયોજન કરો અથવા ઇન્ફરન્સ કો

LiteRT.js સાબિત કરે છે કે WebGPU વેબ-આધારિત ઇન્ફરન્સને સબ-મિલિસેકન્ડ સ્તર સુધી લઈ જઈ શકે છે, જે ડેસ્કટોપ GPUs પર TensorFlow.js કરતા 25 × થી વધુ ઝડપ પૂરી પાડે છે. આ ટેકનોલોજી હજુ પણ પરિપક્વ થઈ રહી છે, અને ડેવલપર્સે બેચિંગ મર્યાદાઓ, મેન્યુઅલ મેમરી ક્લીનઅપ અને મર્યાદિત મોબાઈલ સપોર્ટ જેવી બાબતોને સંભાળવી પડશે. રિયલ-ટાઇમ પર્ફોર્મન્સની માંગ કરતા ડેસ્કટોપ-ફર્સ્ટ અનુભવો માટે, આ નવી લાઇબ્રેરી એક આકર્ષક માર્ગ પ્રદાન કરે છે; જ્યારે ક્રોસ-પ્લેટફોર્મ પહોંચ માટે, જૂના WebGL અને WASM બેકએન્ડ્સ અનિવાર્ય રહે છે.