¡Hola Devs! El navegador ya es un runtime de IA de verdad
Durante años, correr modelos de machine learning del lado del cliente significaba una sola cosa: TensorFlow.js. Funcionaba, sí, pero estaba construido sobre kernels de JavaScript — y kernel JS es lento. Cada inferencia pagaba peaje en overhead del intérprete, presión de GC y acceso limitado al hardware.
Esa era acaba de terminar. Google liberó LiteRT.js, un binding de JavaScript del mismo runtime LiteRT que corre inferencia on-device en Android, iOS y desktop. Ejecuta modelos .tflite directo en el navegador vía WebAssembly, con aceleración de hardware por XNNPACK (CPU), ML Drift (GPU) y WebNN (NPU).
Por qué esto importa para tu stack:
- Cero costo de servidor — la inferencia se queda en el dispositivo
- Privacidad real — los datos del usuario nunca salen del browser
- Latencia sub-frame — clave para UX en tiempo real (tracking, transcripción, upscaling)
El anuncio técnico completo está en el release oficial de LiteRT.js.
Qué hace que LiteRT.js sea rápido de verdad
LiteRT.js no es una reimplementación en JS — es el mismo runtime C++ compilado a WebAssembly, compartiendo el stack cross-platform con mobile y desktop. O sea: cada optimización que Google lanza para Android o iOS llega a tu browser gratis.
El stack de aceleración
| Backend | Hardware | Mejor para |
|---|---|---|
| XNNPACK | CPU | Fallback, modelos chicos, compat amplia |
| ML Drift | GPU (WebGPU) | Modelos de visión, video en tiempo real |
| WebNN | NPU (CoreML, etc.) | GenAI, inferencia de bajo consumo |
Benchmarks que importan
Números del propio Google contra runtimes web existentes:
- Hasta 3x más rápido que TensorFlow.js en CPU y GPU
- Speedup de 5–60x al migrar de CPU a GPU/NPU en modelos pesados
- Demos reales: Depth Anything (estimación de profundidad → nube de puntos 3D), Real-ESRGAN (upscale 4x de patches 128×128 a 512×512)
Ejemplo mínimo que funciona
// Carga el runtime de LiteRT.js y las utilidades de Tensor
import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';
// Apunta a los archivos WASM que vienen en el paquete npm
await loadLiteRt('path/to/wasm/directory/');
// Compila tu modelo .tflite con aceleración de GPU
const model = await loadAndCompile('path/to/your/model.tflite', {
accelerator: 'webgpu' // o 'wasm' para fallback en CPU
});
// Arma el tensor de entrada — el shape debe coincidir con el del modelo
const inputTypedArray = new Float32Array(1 * 3 * 244 * 244);
const inputTensor = new Tensor(inputTypedArray, [1, 3, 244, 244]);
// Corre la inferencia — el resultado se queda en GPU por default
const results = await model.run(inputTensor);
// Mueve la salida de vuelta a CPU y conviértela a typed array
const resultArray = (await results[0].moveTo('wasm')).toTypedArray();
console.log(resultArray);
Esa es toda la superficie para una llamada de inferencia acelerada por GPU. Sin build step, sin bindings nativos, sin fork por plataforma.
Ruta de conversión de modelos
Si vienes de PyTorch, LiteRT Torch convierte modelos en un solo paso. Para cuantización, el AI Edge Quantizer te deja aplicar esquemas por capa — o sea, encoges el modelo sin destruir la precisión en las capas sensibles. Esa es la parte que la mayoría de los equipos se salta, y es justo donde vive la reducción de 2–3x en tamaño.
Dónde LiteRT.js NO es bala de plata
Antes de arrancar tu pipeline de inferencia del servidor, entiende las limitaciones:
1. WebNN todavía está llegando
La aceleración por NPU vía WebNN es upcoming, no universal. El soporte de Safari y Firefox para WebNN es irregular. Si tus usuarios están en browsers viejos, estás en XNNPACK CPU — rápido, pero sin milagros.
2. Tamaño del payload WASM
Entregar runtime + modelo al browser no es gratis. Un modelo de 100MB sigue siendo un download de 100MB. La cuantización ayuda, pero para LLMs grandes, streaming o carga en chunks se vuelve tu problema.
3. Latencia de cold start
La primera inferencia incluye compilación del modelo. Para predicciones puntuales (tipo una clasificación única al cargar la página), el costo de compilación puede superar el beneficio. Esto brilla en escenarios de inferencia repetida — streams de video, herramientas interactivas, sesiones continuas.
4. No es drop-in de TensorFlow.js
El formato es .tflite. Si tus modelos están en el formato propio de TF.js, vas a tener que reexportar. La migración es trabajo real, no find-and-replace.
5. El debug es más difícil
Cuando algo se rompe dentro de un runtime C++ compilado a WASM, tu stack trace de DevTools no es tu amigo. Planea más instrumentación de la que necesitarías con inferencia JS-nativa.
Cuándo usarlo
- Visión en tiempo real (detección de objetos, segmentación, profundidad)
- Procesamiento de audio (transcripción, denoising)
- Herramientas interactivas de imagen (upscaling, style transfer)
- Inferencia con datos sensibles que no pueden salir del dispositivo
Cuándo saltarlo
- Inferencia puntual al cargar la página
- Modelos gigantes sin presupuesto de cuantización
- Usuarios en browsers legacy que no controlas
El mensaje final
LiteRT.js no es una mejora marginal — es un cambio de categoría. Por primera vez, el browser corre el mismo runtime optimizado de tu app mobile, con la misma historia de aceleración de hardware. La distancia entre "demo web" y "app de IA en producción" acaba de encogerse.
Si estás construyendo cualquier cosa que toque visión, audio o GenAI on-device, este es el momento de prototipar. El paquete npm está vivo, las demos son open-source, y la ruta de export de Ultralytics YOLO significa que puedes ir de un script Python de entrenamiento a deploy en el browser en pocas líneas.
Próximos pasos recomendados
- Benchmarkea tu modelo — agarra el paquete npm de LiteRT.js y compara contra tu runtime actual en hardware real
- Cuantiza agresivo — usa el colab del AI Edge Quantizer; los esquemas por capa son donde se esconden las ganancias
- Planea para WebNN — arquitecta la selección de acelerador para que el soporte de NPU entre sin reescritura