LiteRT.js: Google leva inferência de IA acelerada pra dentro do browser

O Google anunciou no seu blog de desenvolvedores o LiteRT.js, um binding JavaScript do LiteRT (o antigo TensorFlow Lite, runtime de inferência on-device que já roda em Android, iOS e desktop). A ideia central é simples e ambiciosa: rodar modelos .tflite inteiramente no browser, sem servidor de inferência no meio.

Pra quem constrói produto no Brasil, esse ponto importa mais do que parece. Inferência client-side significa zero custo de servidor de GPU, latência baixíssima (sem round-trip pra API) e dados que não saem do dispositivo do usuário. Em cenários com conexão instável ou orçamento apertado de infraestrutura, tirar o modelo do backend muda a conta.

O que muda em relação ao TensorFlow.js

O LiteRT.js é posicionado explicitamente como uma evolução do TensorFlow.js para executar modelos .tflite. A diferença técnica está no motor: enquanto o TF.js dependia de kernels escritos em JavaScript (mais lentos), o LiteRT.js expõe o runtime nativo e cross-platform do LiteRT via WebAssembly. Na prática, o mesmo stack otimizado que roda no Android chega ao navegador, com os backends de aceleração:

• CPU via XNNPACK, com suporte multi-thread e SIMD relaxado
• GPU via ML Drift, aproveitando WebGPU
• NPU via WebNN, ainda experimental no Chrome e no Edge

Esse compartilhamento de stack tem um efeito colateral bom: melhorias de quantização e otimização de hardware feitas para mobile chegam automaticamente à web.

Os números (e o asterisco)

O Google afirma que o LiteRT.js supera outros runtimes web em até 3x em inferência de CPU e GPU, em modelos clássicos de visão e áudio. Para aplicações em tempo real (rastreamento de objetos, transcrição de áudio, manipulação de imagem), rodar em GPU ou NPU renderia de 5x a 60x de ganho sobre a execução em CPU pura.

Vale o ceticismo de praxe: os benchmarks foram feitos num MacBook Pro com chip M4 (2024) em ambiente controlado. A própria nota do post admite que o desempenho real varia conforme a GPU local, throttling térmico e otimizações de driver do browser. Ou seja, 60x é o teto num hardware caro e recente, não a expectativa média num notebook corporativo ou celular intermediário, dispositivos bem mais comuns no público brasileiro. Antes de prometer tempo real pro cliente, meça no device-alvo real.

A cara do código

O fluxo básico é enxuto. O snippet da documentação carrega o runtime WASM, compila o modelo apontando o acelerador e roda o tensor de entrada:

import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';

await loadLiteRt('path/to/wasm/directory/');

const model = await loadAndCompile('path/to/your/model.tflite', { accelerator: webgpu });

const inputTypedArray = new Float32Array(1 * 3 * 244 * 244);
const inputTensor = new Tensor(inputTypedArray, [1, 3, 244, 244]);

const results = await model.run(inputTensor);

// resultado vive na GPU; move-se pra CPU e converte pra typedArray
const resultArray = (await results[0].moveTo('wasm')).toTypedArray();

Repare no detalhe do moveTo('wasm'): o tensor de saída fica na GPU e precisa ser movido explicitamente pra CPU. Esse tipo de transferência tem custo, e ignorá-lo em loops de tempo real é a receita clássica pra jogar fora o ganho de performance que a GPU trouxe.

Ecossistema e conversão

O release não vem sozinho. Modelos PyTorch podem ser convertidos em uma etapa com o LiteRT Torch, e o AI Edge Quantizer permite configurar esquemas de quantização por camada pra reduzir tamanho sem destruir a qualidade. Há também integração oficial de export com a Ultralytics, criadora do YOLO, para deploy de modelos de detecção de objetos.

Os demos mostram casos concretos: busca vetorial no browser com EmbeddingGemma, estimativa de profundidade monocular com Depth-Anything-V2 (webcam virando point cloud 3D), e upscaling de imagem 4x com Real-ESRGAN. Para LLMs, o Google aponta o LiteRT-LM.js, que adiciona suporte a modelos de linguagem via a mesma API JavaScript. Modelos prontos estão no Kaggle e no Hugging Face da comunidade LiteRT, e o pacote sai como @litertjs/core no npm.

Vale a pena olhar?

Se você já tem pipeline em TF.js ou modelos .tflite, o caminho de migração parece razoável e o ganho de performance é o argumento mais forte. O calcanhar de Aquiles é a fragmentação de suporte: WebGPU ainda amadurece entre navegadores e WebNN é experimental. Para produção ampla, o fallback pra CPU via XNNPACK segue sendo o piso confiável, e é nele, não no M4, que a maioria dos seus usuários vai rodar o modelo.

Fonte: Google Developers Blog