O navegador virou um runtime de IA de verdade
Olha só, dev. Durante anos, rodar modelo de machine learning no client-side significava uma coisa só: TensorFlow.js. Funcionava, mas era construído em cima de kernels JavaScript — e kernel JS é lento. Cada inferência pagava pedágio em overhead de interpretador, pressão de GC e acesso limitado ao hardware.
Essa era acabou. O Google liberou o LiteRT.js, um binding JavaScript do mesmo runtime LiteRT que roda inferência on-device no Android, iOS e desktop. Ele executa modelos .tflite direto no navegador via WebAssembly, com aceleração de hardware por XNNPACK (CPU), ML Drift (GPU) e WebNN (NPU).
Por que isso importa pro seu stack:
- Custo de servidor zerado — a inferência fica no dispositivo
- Privacidade real — dado do usuário nunca sai do browser
- Latência sub-frame — crítico pra UX em tempo real (tracking, transcrição, upscaling)
O anúncio técnico completo tá no release oficial do LiteRT.js.
O que faz o LiteRT.js ser rápido de verdade
O LiteRT.js não é uma reimplementação em JS — é o mesmo runtime C++ compilado pra WebAssembly, compartilhando o stack cross-platform com mobile e desktop. Ou seja: toda otimização que o Google lança pro Android ou iOS chega no seu browser de graça.
A stack de aceleração
| Backend | Hardware | Melhor pra |
|---|---|---|
| XNNPACK | CPU | Fallback, modelos pequenos, compat ampla |
| ML Drift | GPU (WebGPU) | Modelos de visão, vídeo em tempo real |
| WebNN | NPU (CoreML, etc.) | GenAI, inferência de baixo consumo |
Benchmarks que importam
Números do próprio Google contra runtimes web existentes:
- Até 3x mais rápido que TensorFlow.js em CPU e GPU
- Speedup de 5–60x ao migrar de CPU pra GPU/NPU em modelos pesados
- Demos reais: Depth Anything (estimativa de profundidade → nuvem de pontos 3D), Real-ESRGAN (upscale 4x de patches 128×128 pra 512×512)
Exemplo mínimo que funciona
// Carrega o runtime LiteRT.js e as utilidades de Tensor
import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';
// Aponta pros arquivos WASM que vêm no pacote npm
await loadLiteRt('path/to/wasm/directory/');
// Compila seu modelo .tflite com aceleração de GPU
const model = await loadAndCompile('path/to/your/model.tflite', {
accelerator: 'webgpu' // ou 'wasm' pra fallback em CPU
});
// Monta o tensor de entrada — o shape precisa bater com o do modelo
const inputTypedArray = new Float32Array(1 * 3 * 244 * 244);
const inputTensor = new Tensor(inputTypedArray, [1, 3, 244, 244]);
// Roda a inferência — o resultado fica na GPU por padrão
const results = await model.run(inputTensor);
// Move a saída de volta pra CPU e converte pra typed array
const resultArray = (await results[0].moveTo('wasm')).toTypedArray();
console.log(resultArray);
É essa a superfície inteira pra uma chamada de inferência acelerada por GPU. Sem build step, sem binding nativo, sem fork por plataforma.
Caminho de conversão de modelo
Se você vem do PyTorch, o LiteRT Torch converte modelos em um único passo. Pra quantização, o AI Edge Quantizer permite aplicar esquemas por camada — ou seja, você encolhe o modelo sem detonar a acurácia nas camadas sensíveis. Essa é a parte que a maioria dos times pula, e é exatamente onde mora a redução de 2–3x no tamanho.
Onde o LiteRT.js NÃO é bala de prata
Antes de arrancar seu pipeline de inferência no servidor, entende as limitações:
1. WebNN ainda tá chegando
Aceleração por NPU via WebNN é upcoming, não universal. Suporte de Safari e Firefox pro WebNN é irregular. Se seus usuários tão em browsers antigos, você tá no XNNPACK CPU — rápido, mas sem milagre.
2. Tamanho do payload WASM
Entregar runtime + modelo pro browser não é de graça. Um modelo de 100MB ainda é um download de 100MB. Quantização ajuda, mas pra LLMs grandes, streaming ou carregamento em chunks vira problema seu.
3. Latência de cold start
A primeira inferência inclui compilação do modelo. Pra predições pontuais (tipo uma classificação única no page load), o custo de compilação pode passar o benefício. Isso brilha em cenários de inferência repetida — streams de vídeo, ferramentas interativas, sessões contínuas.
4. Não é drop-in do TensorFlow.js
O formato é .tflite. Se seus modelos tão no formato próprio do TF.js, vai precisar reexportar. A migração é trabalho real, não find-and-replace.
5. Debug é mais difícil
Quando algo quebra dentro de um runtime C++ compilado pra WASM, seu stack trace do DevTools não é seu amigo. Planeja mais instrumentação do que você precisaria com inferência JS-nativa.
Quando usar
- Visão em tempo real (detecção de objeto, segmentação, profundidade)
- Processamento de áudio (transcrição, denoising)
- Ferramentas interativas de imagem (upscaling, style transfer)
- Inferência com dado sensível que não pode sair do dispositivo
Quando pular
- Inferência pontual no page load
- Modelos gigantes sem orçamento de quantização
- Usuários em browsers legados que você não controla
O recado final
O LiteRT.js não é melhoria marginal — é mudança de categoria. Pela primeira vez, o browser roda o mesmo runtime otimizado do seu app mobile, com a mesma história de aceleração de hardware. A distância entre "demo web" e "app de IA em produção" acabou de encolher.
Se você tá construindo qualquer coisa que toca visão, áudio ou GenAI on-device, esse é o momento de prototipar. O pacote npm tá no ar, as demos são open-source, e o caminho de export do Ultralytics YOLO significa que dá pra ir de um script Python de treino pra deploy no browser em poucas linhas.
Próximos passos recomendados
- Benchmarka seu modelo — pega o pacote npm do LiteRT.js e compara com o runtime atual em hardware real
- Quantiza agressivo — usa o colab do AI Edge Quantizer; esquemas por camada são onde os ganhos se escondem
- Planeja pro WebNN — arquiteta a seleção de acelerador pra suporte a NPU encaixar sem reescrita