LiteRT.js Inashinda TensorFlow.js

LiteRT.js ikiwa na WebGPU inafanya utambuzi (inference) wa MobileNetV2 ndani ya 0.41 ms, ikitoa 2,439 FPS kwenye GPU ya desktop ya M2 Max—kwa zaidi ya mara 25 ya kasi ya TensorFlow.js kwenye kifaa kilekile. Pengo hili linazidi kuwa kubwa kwa mifano mikubwa zaidi, likiingiza mashine ya kujifunza (machine learning) inayotegemea wavuti katika kiwango cha utendaji ambacho hapo awali kilikuwa kimehifadhiwa kwa programu za asili (native apps).

Kwa nini kipimo hiki (benchmark) ni muhimu

Watengenezaji wamekuwa wakitumia TensorFlow.js kwa utambuzi wa ndani ya kifaa (on-device inference), kwa kawaida kupitia WebGL backend. WebGL huunganisha operesheni za tensor kwenye mfumo wa picha wa 2-D wa kivinjari; inafanya kazi kila mahali lakini haikuundwa kwa ajili ya uwezo mkubwa wa uendeshaji sambamba (parallelism) unaohitajika na mifano ya deep-learning. WebGPU, API ya picha ya kizazi kijacho, inatoa ufikiaji wa moja kwa moja kwa vitengo vya hesabu vya GPU. LiteRT.js ndiyo maktaba ya kwanza kutoa injini ya utambuzi inayotumia WebGPU kwa mifano ya TensorFlow-Lite, na Google imeripoti ongezeko la kasi mara tatu. Majaribio huru yanaonyesha faida kubwa zaidi, yakichochea swali la ikiwa WebGPU itakuwa njia ya kawaida kwa web ML.

Jinsi jaribio lilivyofanyika

Tulifanya kipimo kwa mifano miwili ya uainishaji wa picha—MobileNetV2 na EfficientNet-Lite4—yote mawili yakiwa yamebadilishwa kwenda TensorFlow-Lite. Majaribio yalifanyika kwenye chip ya Apple-silicon M2 Max. Kwa kila mfano, tulipima ucheleweshaji (latency) wa hatua moja ya mbele (forward pass) kupitia mzunguko mwingi na kuripoti picha kwa sekunde (FPS). Tulitumia mifano ile ile kwa TensorFlow.js kupitia WebGL backend na kurekodi muda wa kuanza (cold-start time) wa kila maktaba.

Matokeo: kasi na uanzishaji

  • MobileNetV2

    • LiteRT.js (WebGPU): ucheleweshaji wa 0.41 ms → 2,439 FPS
    • TensorFlow.js (WebGL): ucheleweshaji wa 10.82 ms → 92 FPS
  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): ucheleweshaji wa 0.62 ms → 1,623 FPS
    • TensorFlow.js (WebGL): haijaripotiwa, lakini MobileNetV2 tayari inaonyesha faida ya zaidi ya mara 25.

TensorFlow.js ilihitaji takriban sekunde 10 (10,014 ms) kukamilisha WebGL shaders zake kabla ya utambuzi wa kwanza. LiteRT.js ilikuwa tayari ndani ya 4.3 ms, jambo ambalo kwa kiasi kikubwa linaondoa changamoto ya muda wa kuanza (cold-start penalty) kwa programu zinazoingiliana (interactive apps).

Tulipoongeza ukubwa wa mfano mara tano, ucheleweshaji uliongezeka kwa 50% tu, ikithibitisha kuwa uwezo wa uendeshaji sambamba wa GPU unachukua sehemu kubwa ya kazi ya ziada. Matokeo yake ni kiwango kipya cha utendaji kinachoruhusu kivinjari kushughulikia mtiririko wa video wa wakati halisi (real-time video streams), AR overlays, au utengenezaji wa haraka wa mifano ya uoni (vision models) bila kuhitaji mawasiliano na seva.

Yale ambayo namba hazionyeshi

  • Batching – Mifano mingi ya TensorFlow-Lite inafunga kipimo cha batch (batch dimension) kwenye 1. Kuingiza picha nyingi kwa mwito mmoja haikubaliki moja kwa moja, jambo linalowasilisha watengenezaji kulazimika kutumia Web Workers au kupanga kwa mkono (manually pipeline) ingizo.
  • Memory management – LiteRT.js haifanyi usafishaji wa kumbukumbu (garbage-collect) wa GPU tensors kiotomatiki. Watengenezaji lazima watumie .delete() kwenye kila tensor wanayotengeneza, vinginevyo watahatarisha kuishiwa kwa kumbukumbu ya GPU baada ya utambuzi mamia machache.
  • Hardware reach – WebGPU imara kwenye Chrome na Firefox za desktop. Kivinjari vya simu—ikiwemo Chrome kwenye Android na Safari kwenye iOS—zinaonyesha API hii kupitia bendera za majaribio (experimental flags) pekee au haziionyeshi kabisa. Kwenye majukwaa hayo, WASM backend inabaki kuwa njia pekee inayopatikana kwa ulimwengu wote, lakini ni polepole zaidi kwa mifano mikubwa.

Vikwazo hivi vinamaanisha kuwa ingawa kasi ya ghafla inavutia, juhudi za kihandisi za kuifikia zinaweza kuwa ngumu.

Vikwazo na mabadiliko ya kulinganisha (trade-offs)

WebGL backend ya TensorFlow.js bado inatoa uoanishaji (compatibility) unaokaribia kuwa wa ulimwengu wote. Mtengenezaji anayelenga hadhira mchanganyiko—desktop, Android, iOS—anaweza kutegemea njia moja ya kodi inayofanya kazi kila mahali, ingawa kwa kasi ndogo zaidi. WASM backend inafanya kazi kwenye karibu kifaa chochote lakini inashindwa WebGPU kwa mifano mikubwa iliyopimwa hapa.

LiteRT.js inang'ara wakati lengo ni mazingira ya desktop yenye WebGPU ikiwa imewashwa. Inafanya kazi ya mifano ya .tflite moja kwa moja, ikiruhusu watengenezaji kuchukua mifano kutoka Hugging Face au Kaggle bila kubadilisha, ikihifadhi quantization na utendaji wa asili. Mabadiliko ya kulinganisha (trade-off) ni uwezo mdogo wa kueneza (deployment envelope) na hitaji la usimamizi makini wa rasilimali.

Yale ambayo watengenezaji wanapaswa kuzingatia

  • Jukwaa lengwa – Kwa zana ya desktop inayotegemea wavuti pekee (kwa mfano, programu ya usanifu inayotumia style transfer kwa wakati halisi), WebGPU ikiwa na LiteRT.js huenda ikawa chaguo bora zaidi.
  • Ukubwa wa mfano – Mifano mikubwa na inayohitaji hesabu nyingi inafaidika zaidi na uendeshaji sambamba wa GPU; mifano midogo inaweza isihitaji juhudi za ziada za kihandisi.
  • Nidhamu ya kumbukumbu – Panga kufuta tensor kwa wazi au funga wito wa utambuzi (inference calls) katika upeo (scope) unaofuta rasilimali kiotomatiki.
  • Mkakati wa mbadala (Fallback strategy) – Toa mbadala wa WASM au WebGL kwa vivinjari ambavyo haviwezi kuwasha WebGPU, ili kuifanya programu ifanye kazi kwa hadhira pana zaidi.

Hitimisho

LiteRT.js inathibitisha kuwa WebGPU inaweza kupeleka utambuzi (inference) unaotegemea wavuti katika kiwango cha chini ya milisekunde moja, ikitoa kasi zaidi ya 25 × ya TensorFlow.js kwenye GPU za kompyuta za mezani. Teknolojia hii bado inakua, na watengenezaji lazima washughulikie mipaka ya batching, usafishaji wa kumbukumbu wa kumanual, na msaada mdogo wa vifaa vya mkononi. Kwa uzoefu unaolenga zaidi kompyuta za mezani unaohitaji utendaji wa wakati halisi, maktaba hii mpya inatoa njia bora ya kusonga mbele; kwa ajili ya ufikiaji wa majukwaa mbalimbali, mifumo ya nyuma ya WebGL na WASM bado ni muhimu.