Marktechpost skriver, at Google har udgivet LiteRT.js, en JavaScript-binding af LiteRT, som gør det muligt at køre .tflite-modeller direkte i browseren. Ifølge artiklen peger Google på, at lokal inference kan give forbedret privatliv, ingen serveromkostninger pr. inference og lav latenstid, fordi data og beregninger bliver på klienten. Marktechpost tilføjer, at de tal for ydeevne, som nævnes, er leverandør-rapporterede, og at en udbredt “10×”-figur ikke fremgår af det materiale, der refereres.
Ifølge Marktechpost er LiteRT.js ikke et nyt modelformat. Den eksisterende native LiteRT-runtime er kompileret til WebAssembly og udstillet til JavaScript, så modellerne fortsat er .tflite. Pointen er, at webapps dermed kan drage nytte af optimeringer, der allerede findes i LiteRT på andre platforme.
Hvad LiteRT og LiteRT.js indebærer
Marktechpost beskriver LiteRT som Googles on-device inference-bibliotek, tidligere kaldt TensorFlow Lite. LiteRT.js er en JavaScript-binding til den samme runtime. Modellerne forbliver .tflite, og ifølge artiklen er fokus at bringe den krydsplatforms-runtime ind i browseren i stedet for at introducere et nyt format.
Artiklen fremhæver også, at tidligere web-ML-løsninger som TensorFlow.js byggede på JavaScript-baserede kerner, som Google ifølge Marktechpost betegner som mindre performante. Med LiteRT.js følger den native runtime med over i webben, hvilket ifølge artiklen betyder, at forudgående arbejde med performanceforbedringer og kvantisering kan komme browsermiljøet til gode.
Backends og delegation
Under motorhjelmen gennemgår Marktechpost tre backends: CPU via XNNPACK, GPU via ML Drift gennem WebGPU og NPU via WebNN-API’et, som fortsat er eksperimentelt i Chrome og Edge. Ifølge artiklen har CPU-stien den bredeste operator-dækning.
Marktechpost beskriver to regler for dispatch. For det første understøttes ikke delvis delegation, så en modelgraf kan ikke deles mellem for eksempel CPU og GPU. For det andet er delegation alt-eller-intet pr. model. Kan en model ikke fuldt ud delegeres til den valgte accelerator, falder kørsel tilbage til wasm på CPU.
Konsekvenser for kompatibilitet
Ifølge Marktechpost betyder alt-eller-intet-delegation, at et enkelt ikke-understøttet operator på en accelerator kan udløse et komplet fallback til CPU. Artiklen peger derfor på operator-dækning som afgørende for, om en model i praksis kan køre på GPU eller NPU i browseren.
CPU-stien sikrer bred kompatibilitet, men Marktechpost gør opmærksom på, at fravær af fuld operator-understøttelse på en accelerator mindsker muligheden for at udnytte den pågældende hardware. Det kan have betydning for den latenstid, som opleves ved kørsel i browseren.
Genbrug af eksisterende optimeringer
Marktechpost skriver, at fordi LiteRT.js bringer den eksisterende runtime til web, kan forbedringer fra andre platforme i udgangspunktet genbruges. Artiklen nævner, at dette omfatter generelle performanceforbedringer, kvantisering og hardwareoptimeringer, der allerede er udviklet til LiteRT uden for browseren.
Ifølge artiklen er det en væsentlig forskel i forhold til tidligere web-ML-tilgange, fordi webapps nu kan arve optimeringer direkte fra den native runtime. Marktechpost præsenterer det som en teknisk tilgang, der reducerer kløften mellem web og mobile/desktop-miljøer.
Hvad Google rapporterer om performance
Marktechpost refererer, at Google rapporterer to overordnede resultater. For det første op til 3× hurtigere end andre web-runtimes på tværs af CPU og GPU for klassiske computer vision- og lydmodeller. For det andet 5–60× speedup i forhold til egen CPU-kørsel, når GPU eller NPU anvendes til krævende realtidsopgaver som objektsporing og lydtranskription.
Begge benchmarks er ifølge Marktechpost kørt i et kontrolleret browsermiljø på en 2024 MacBook Pro med M4 Apple Silicon. Artiklen noterer, at Google gør opmærksom på, at faktiske resultater varierer efter lokal GPU, termisk throttling og driveroptimering. Samtidig nævner Marktechpost, at en “10×”-figur, som har cirkuleret i forbindelse med lanceringen, ikke fremgår af det materiale, der refereres.
WebGPU, WebNN og praktisk support
Marktechpost beskriver, at GPU-udførelse går via WebGPU, mens NPU-udførelse går gennem WebNN-API’et. Ifølge artiklen er WebNN fortsat eksperimentel i Chrome og Edge, hvilket kan give variation i support og adfærd på tværs af enheder og versioner. Det præsenteres som et spørgsmål om browsersupportens modenhed, ikke som en begrænsning unik for LiteRT.js.
Artiklen fastholder samtidig, at fallback-mekanismen til CPU via wasm hænger tæt sammen med de nævnte regler for delegation. I praksis betyder det, at operator-kompatibilitet på acceleratorer er en væsentlig faktor, når formålet er at udnytte GPU eller NPU i browseren.
Privatliv og omkostninger ved lokal kørsel
Ifølge Marktechpost fremhæver Google forbedret privatliv som en central fordel, fordi data behandles lokalt i browseren. Artiklen refererer også, at Google peger på ingen serveromkostninger pr. inference som en gevinst, fordi beregningen ikke kalder en server-side model under kørsel.
Marktechpost præsenterer disse fordele i forlængelse af den lokale eksekveringsmodel, hvor både data og beregninger bliver på klienten. Artiklen kobler samme model til den rapporterede lave latenstid, under forbehold for de nævnte forskelle i hardware og drivere.
Opsummering af det tekniske billede
Samlet set beskriver Marktechpost, at LiteRT.js bringer LiteRT’s runtime ind i browseren via WebAssembly og giver .tflite-modeller adgang til CPU, GPU og potentielt NPU. Ifølge artiklen udstikker Google klare regler for delegation, hvor fuld operator-understøttelse er en forudsætning for at udnytte acceleratorer. CPU-stien har bredest dækning og fungerer som fallback.
Marktechpost konkluderer, at de rapporterede hastighedsgevinster er leverandør-rapporterede og må ses i lyset af testopsætningen på en 2024 MacBook Pro med M4. Artiklen fremhæver samtidig, at resultater vil variere med hardware, termiske forhold og driveroptimering, og noterer at en “10×”-figur ikke indgår i materialet.
