Google Lança LiteRT.js: Execute Modelos .tflite Diretamente no Navegador com WebGPU

O Google acaba de expandir os limites da inferência de IA no navegador. No dia 9 de julho de 2026, a empresa lançou o LiteRT.js, uma biblioteca JavaScript que permite executar modelos .tflite diretamente no navegador usando WebGPU — com ganhos de desempenho que chegam a 60× em relação à execução em CPU.

O que é o LiteRT.js?

O LiteRT.js não é um novo formato de modelo. É uma camada JavaScript sobre o LiteRT, a biblioteca de inferência on-device do Google (anteriormente conhecida como TensorFlow Lite). O runtime nativo foi compilado para WebAssembly e exposto ao JavaScript, permitindo que aplicações web aproveitem as mesmas otimizações que já existiam para Android, iOS e desktop.

A diferença em relação ao TensorFlow.js é significativa: enquanto o TF.js depende de kernels implementados em JavaScript, o LiteRT.js roda o runtime nativo com todas as suas otimizações — incluindo suporte a quantização e aceleração por hardware — sem intermediários.

Como a inferência acontece localmente no dispositivo do usuário, o Google destaca três benefícios imediatos: privacidade aprimorada (dados não saem do navegador), custo zero de servidor e latência ultrabaixa.

Três backends, uma única API

O runtime do LiteRT.js oferece três backends de execução:

• CPU (XNNPACK): biblioteca otimizada do Google com suporte a multi-threading e SIMD relaxado. É o backend com a maior cobertura de operadores.
• GPU (ML Drift sobre WebGPU): solução de GPU on-device do Google, funcionando através da API WebGPU do navegador.
• NPU (WebNN): atualmente experimental no Chrome e Edge, direciona a inferência para unidades de processamento neural quando disponíveis.

Uma regra importante: o LiteRT.js não suporta delegação parcial. Um modelo não pode ser dividido entre CPU e GPU. A delegação é tudo-ou-nada: se um modelo não puder ser totalmente delegado ao acelerador escolhido, o sistema cai automaticamente para execução em WebAssembly na CPU.

Números de desempenho

Os benchmarks do Google, executados em um MacBook Pro M4 (2024), revelam dois cenários distintos:

• Contra outros runtimes web: o LiteRT.js é até 3× mais rápido em tarefas de visão computacional e processamento de áudio, tanto em CPU quanto em GPU.
• GPU/NPU contra a própria CPU: para workloads pesados como rastreamento de objetos em tempo real e transcrição de áudio, a aceleração entrega ganhos de 5× a 60×. O Google não registrou o número “10×” que circulou junto com o lançamento.

Os resultados variam conforme GPU local, throttling térmico e otimização de drivers — o ambiente de teste controlado do Google representa condições favoráveis, não o pior caso.

Convertendo modelos PyTorch para .tflite

O LiteRT Torch converte modelos PyTorch para .tflite em uma única etapa. Mas os pré-requisitos são rigorosos:

• O modelo precisa ser exportável com torch.export.export (compatível com TorchDynamo).
• Não pode conter desvios condicionais que dependam de valores de tensor em runtime.
• Não pode ter dimensões de entrada ou saída dinâmicas — incluindo a dimensão do batch.

Para quantização, o AI Edge Quantizer configura esquemas de quantização por camada. Modelos .tflite pré-treinados estão disponíveis no Kaggle e na comunidade LiteRT do Hugging Face.

Pipeline mínimo: do carregamento à inferência

Uma vez convertido, o código de execução é compacto. Este é o caminho WebGPU (verificado contra @litertjs/core v2.5.2):

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

// Arquivos Wasm no node_modules ou CDN
await loadLiteRt('caminho/para/wasm/');

const model = await loadAndCompile('modelo.tflite', {
  accelerator: 'webgpu', // 'wasm' | 'webgpu' | 'webnn'
});

const input = new Tensor(
  new Float32Array(1 * 3 * 224 * 224),
  [1, 3, 224, 224]
);
const results = await model.run(input);

// Resultados da GPU ficam off-heap. Mova para CPU antes de acessar.
const cpuTensor = await results[0].moveTo('wasm');
const output = cpuTensor.toTypedArray();

// ATENÇÃO: LiteRT.js não faz garbage collection de tensores.
input.delete();
for (const t of results) t.delete();
cpuTensor.delete();

O último bloco merece destaque: o LiteRT.js não faz coleta de lixo em tensores. Todo Tensor precisa ser deletado explicitamente com .delete(), ou a aplicação vaza memória do dispositivo. O snippet do anúncio oficial do Google omite essa etapa — mas ela é obrigatória em produção.

Para WebNN, é necessário um parâmetro extra — o JSPI, que conecta agendamento síncrono de kernels com polling assíncrono do dispositivo:

await loadLiteRt('caminho/wasm/', {jspi: true});

const model = await loadAndCompile('modelo.tflite', {
  accelerator: 'webnn',
  webNNOptions: {devicePreference: 'npu'},
});

Antes de escrever pré-processamento, o Google recomenda testar com entradas aleatórias usando npx model-tester (pacote @litertjs/model-tester).

LiteRT.js vs TensorFlow.js

Os dois não são mutuamente exclusivos. O Google posiciona o LiteRT.js como substituto para os Graph Models do TF.js, não para a biblioteca inteira. O TensorFlow.js continua sendo a ferramenta recomendada para pré e pós-processamento.

O pacote @litertjs/tfjs-interop permite passar tensores entre os dois ambientes via runWithTfjsTensors. Evite tensor.dataSync no backend WebGPU — o custo é significativo.

Por que isso importa agora

O LiteRT.js representa um avanço concreto na direção de aplicações web com IA local. Para desenvolvedores brasileiros, três cenários se destacam:

• Aplicações que funcionam offline: classificação de imagens, detecção de objetos e transcrição de áudio rodando inteiramente no navegador do usuário, sem depender de APIs pagas.
• Privacidade como diferencial competitivo: setores regulados como saúde e finanças podem oferecer funcionalidades de IA sem que dados sensíveis saiam do dispositivo.
• Redução de custo de infraestrutura: startups que hoje dependem de GPUs em nuvem para inferência podem migrar workloads de classificação e processamento para o lado do cliente.

O WebGPU já está disponível no Chrome 113+, Edge 113+ e Opera 99+. O Firefox tem suporte experimental a partir da versão 130. O WebNN ainda é experimental, mas o caminho WebGPU está pronto para produção.