LiteRT.js: ejecutar IA local en el navegador con una alternativa clara

LiteRT.js es la interfaz de Google para ejecutar inferencia de inteligencia artificial (IA) en el navegador. Puede usar WebAssembly en la unidad central de procesamiento (CPU) y WebGPU cuando existe aceleración compatible. El diseño debe contemplar desde el inicio los dispositivos que no cubren la ruta preferida.

El caso práctico evaluará la calidad de una foto antes de subirla. El modelo local detectará desenfoque o exposición deficiente y mostrará una recomendación. Si el navegador no puede ejecutar el modelo, la aplicación explicará el límite y ofrecerá otra ruta.

LiteRT.js lleva el modelo al dispositivo

A fecha de 15 de julio de 2026, Google documentaba LiteRT.js como un entorno web para cargar y ejecutar modelos compatibles. La guía de inicio muestra una API de carga y compilación y una ruta acelerada con WebGPU. La compatibilidad real depende del navegador, el hardware y el modelo.

Ejecutar en el dispositivo puede reducir viajes de red durante la inferencia. También permite respuestas incluso cuando la conexión es inestable, siempre que la aplicación y el modelo ya estén disponibles. No elimina el coste de descarga, compilación y memoria.

Antes de elegirlo, define qué aporta al caso de fotografía. Una advertencia inmediata antes de subir puede ahorrar una carga inútil y mantener la imagen fuera del servidor. Esa ventaja solo existe si las demás partes de la página tampoco transmiten la foto.

La detección precede a la descarga

Comprueba las capacidades antes de descargar un modelo grande. Detecta las APIs necesarias, registra memoria disponible cuando sea posible y considera el tipo de dispositivo. La interfaz debe permanecer utilizable mientras se decide la ruta.

Para la foto, muestra primero el selector y una explicación breve. Si el navegador cumple las condiciones, inicia la carga del modelo con progreso visible. Si no, ofrece una evaluación remota opcional o permite continuar sin análisis.

No uses una detección basada solo en el nombre del navegador. Las versiones, controladores y políticas pueden variar dentro de la misma familia. Ejecuta una prueba de capacidad y captura el error de inicialización.

La carga necesita estados y límites claros

El modelo añade bytes, tiempo de arranque y memoria al recorrido. Informa que se prepara el análisis local y permite cancelar cuando la descarga tarde. Guarda en caché solo si la política del producto y el almacenamiento disponible lo permiten.

Una barra completa no demuestra que el modelo esté listo. Distingue descarga, compilación y primera inferencia. Para el caso práctico, habilita «Analizar foto» después de confirmar que la ruta local responde con una entrada de prueba.

Define un tiempo máximo y una recuperación. Si la compilación falla, libera recursos y activa la alternativa. Un bucle de reintentos silencioso consume batería y mantiene a la persona sin una decisión.

La calidad debe medirse con fotos representativas

Prepara imágenes de prueba con buena calidad, desenfoque, poca luz y tamaños distintos. Compara la salida del modelo con una clasificación revisada y registra errores relevantes. Una demostración con una sola foto no permite evaluar el comportamiento.

Mide también tiempo hasta el primer resultado, latencia posterior, memoria y temperatura percibida en sesiones largas. Incluye móviles de gama media, un equipo sin WebGPU y navegadores representativos. Los benchmarks del proveedor sirven como referencia, no como aceptación de tu producto.

Si el análisis determina que una foto está borrosa, explica la acción: estabilizar el dispositivo, mejorar la luz o repetir la toma. Una puntuación sin contexto no ayuda. La guía de prompts aplica el mismo principio de resultado verificable.

La privacidad depende de todo el recorrido

La inferencia local describe dónde se ejecuta el modelo, no todo lo que hace la aplicación. Analítica, registros de error, almacenamiento, miniaturas o servicios de copia pueden enviar datos. Documenta cada salida de red antes de afirmar que la imagen permanece en el dispositivo.

Inspecciona la red durante selección, análisis y descarte. Repite la prueba con la alternativa remota y muestra una solicitud de consentimiento antes de subir. El texto debe diferenciar con claridad ambas rutas.

Evita registrar la imagen, su contenido extraído o identificadores innecesarios. Si necesitas telemetría, mide tiempos y códigos de estado sin adjuntar datos personales. La persona debe poder continuar cuando rechaza la alternativa.

La alternativa forma parte del producto

Una ruta alternativa no es un error vergonzoso que deba ocultarse. Explica que el análisis local no está disponible en ese dispositivo y ofrece opciones concretas: continuar sin evaluación, usar un servidor con consentimiento o probar otra imagen. Conserva la función principal siempre que sea seguro.

La alternativa remota necesita sus propias reglas de retención, acceso y eliminación. No la actives en segundo plano. El enfoque responsable de vibe coding exige probar tanto el camino principal como el degradado.

Registra cuántas sesiones usan cada ruta y por qué falla la local. Esa evidencia permite decidir si conviene cambiar el modelo, reducir su tamaño o retirar una función. No conviertas el porcentaje en una promesa sin fecha y muestra representativa.

Los límites aparecen en descarga, memoria y compatibilidad

Un modelo puede ser demasiado grande para una conexión móvil o agotar memoria durante varias inferencias. WebGPU puede existir y aun así fallar al compilar una operación. Captura ambos casos y restablece la interfaz.

La calidad también puede variar entre grupos de imágenes que no estaban en la evaluación. Revisa iluminación, dispositivos y contextos diversos. Un resultado local incorrecto sigue siendo un resultado incorrecto.

Finalmente, el navegador comparte recursos con el resto de la página. Evita ejecutar varias inferencias simultáneas y libera tensores o sesiones que ya no uses. Una interfaz fluida importa tanto como la cifra aislada de inferencia.

Comprueba la experiencia antes de publicarla

Recorre estas casillas en varios dispositivos. Cada respuesta debe apoyarse en una medición, una inspección de red o un comportamiento visible.

• La aplicación detecta capacidades antes de descargar el modelo.
• Carga, compilación, ejecución y error tienen estados comprensibles.
• Las fotos de prueba cubren calidad, tamaños y dispositivos distintos.
• Todo el recorrido de datos, incluida la telemetría, está documentado.
• La alternativa remota requiere información y consentimiento explícitos.
• Un fallo libera recursos y permite continuar de forma segura.

LiteRT.js abre una ruta útil para IA local, pero la arquitectura fiable incluye también el dispositivo que no puede usarla. Detecta, carga, ejecuta, mide y activa una alternativa declarada. Esa secuencia convierte una demostración en una función mantenible.