Un modelo de 7 MB que corre en el navegador

Un modelo de embeddings de 7 MB que corre dentro del navegador suena casi a truco de demo. Pero cuando lo pruebas, el punto no es solo el tamaño. Lo interesante es que puedes generar embeddings sin mandar texto a un servidor, sin depender de una GPU remota y sin abrir la puerta a una latencia que te arruina la experiencia.

Eso cambia bastante la conversación sobre IA local ligera. Si el modelo cabe en 7 MB y se ejecuta con WASM, ya no estás hablando de una app de laboratorio. Estás hablando de una pieza que puede vivir en una web pública, en un panel interno, en una herramienta offline o en un flujo donde la privacidad importa de verdad. La demo de Ternlight, disponible en https://ternlight-demo.vercel.app/, apunta justo a ese escenario.

Qué demuestra Ternlight y por qué importa

Ternlight es un modelo de embeddings pequeño, de 7 MB, diseñado para correr en el navegador con WebAssembly. La idea no es competir con modelos grandes en calidad absoluta, sino mostrar que puedes resolver tareas útiles de representación semántica directamente en el cliente. Eso incluye búsqueda semántica, clasificación ligera, deduplicación de texto y recuperación de contexto local.

La diferencia frente a una API tradicional es clara: el texto no sale del dispositivo para convertirse en embeddings. En un flujo clásico, tú envías el contenido a un backend o a un proveedor externo, esperas respuesta y luego trabajas con esos vectores. Aquí el cálculo ocurre en el navegador, así que el tiempo de ida y vuelta con el servidor desaparece de la ecuación.

En la práctica, eso importa por tres razones concretas:

1. Menos exposición de datos sensibles. Si el texto nunca sale del navegador, reduces el número de puntos donde puede quedar registrado.
2. Menor latencia percibida. No dependes de red móvil, VPN, proxies o saturación del backend.
3. Mejor tolerancia al modo offline. Si la app ya descargó el modelo, puede seguir funcionando sin conexión.

Para equipos en LatAm, esto no es un detalle menor. En muchos contextos, la conectividad todavía es variable, los costos de datos pesan y las políticas de privacidad se vuelven más exigentes cuando trabajas con información de clientes, salud, legal o finanzas.

Embeddings, en términos prácticos

Un embedding es una representación numérica de texto que captura similitud semántica. No necesitas pensar en cada número del vector; te basta con saber que dos frases parecidas suelen quedar cerca en ese espacio. Por ejemplo, “cancelar mi suscripción” y “quiero dar de baja mi plan” deberían terminar más cerca entre sí que respecto a “cómo cambio mi contraseña”.

Eso sirve para varias tareas reales:

• búsqueda semántica en documentación interna
• recomendación de contenido
• agrupación de tickets de soporte
• detección de duplicados
• clasificación de intención en formularios

Lo útil de Ternlight no es inventar una categoría nueva, sino llevar esas tareas a un entorno donde el navegador hace el trabajo localmente.

Qué significa 7 MB en la práctica

Siete megabytes no son nada si los comparas con modelos grandes, pero sí son una cifra muy relevante para web. Un archivo de ese tamaño puede descargarse rápido en una conexión decente y no castiga tanto el almacenamiento del dispositivo. También es más razonable para una app que quiere cargar sin hacer esperar al usuario varios segundos antes de mostrar algo útil.

No significa que el costo sea cero. Un modelo pequeño sigue consumiendo CPU, memoria y tiempo de inicialización. Pero el punto es que el umbral de entrada baja lo suficiente como para pensar en IA local ligera como una opción real, no como una curiosidad técnica.

Cómo corre en el navegador con WASM

WebAssembly, o WASM, permite ejecutar código compilado en el navegador con buen rendimiento. No es magia, pero sí una forma bastante práctica de acercarte al rendimiento nativo sin abandonar el entorno web. En este caso, el modelo se apoya en ese entorno para hacer inferencia local en el cliente.

Si vienes del mundo web, la idea es simple: en vez de llamar a un endpoint remoto, tu app descarga el modelo y lo ejecuta ahí mismo. Si ya trabajas con machine learning, piensa en un runtime compacto que vive al lado de tu interfaz. La ventaja es que puedes distribuir una experiencia de IA dentro de una página normal, sin instalar una app pesada.

La documentación oficial de WebAssembly explica el objetivo del estándar y su foco en rendimiento y portabilidad: https://webassembly.org/. Si quieres entender mejor el soporte de APIs y el modelo de ejecución en el navegador, también vale la pena revisar la guía de MDN: https://developer.mozilla.org/en-US/docs/WebAssembly.

Flujo típico de ejecución

En una implementación de este tipo, el flujo suele verse así:

1. El usuario abre la página.
2. El navegador descarga el bundle web y el archivo del modelo.
3. El runtime WASM inicializa el motor de inferencia.
4. La app tokeniza o prepara el texto de entrada.
5. El modelo produce el embedding.
6. La interfaz usa ese vector para búsqueda, ranking o clasificación.

La parte importante es que el paso 5 ocurre localmente. Eso cambia la arquitectura completa, porque ya no dependes de un servicio dedicado solo para embeddings.

Qué gana y qué pierde frente a una API remota

Aquí conviene ser concreto. Una API remota puede ofrecer modelos más grandes, actualizaciones centralizadas y, en muchos casos, mejor calidad. Pero también introduce latencia de red, costo por uso y un nuevo punto de riesgo para datos sensibles.

Ternlight apunta al otro extremo: menos peso, menos dependencia externa y una experiencia más privada. A cambio, aceptas límites en capacidad y precisión. No es una sustitución universal; es una herramienta para casos donde la eficiencia y la autonomía pesan más que la máxima calidad posible.

Privacidad, latencia y apps offline

La parte más interesante de una IA local ligera no es solo técnica. Es de producto. Cuando procesas embeddings en el navegador, cambias la relación entre tu app y los datos del usuario. Ya no necesitas mandar cada consulta a un servidor para entender su intención o ubicarla en un espacio semántico.

Eso tiene valor en escenarios donde el texto es sensible. Piensa en notas médicas, borradores legales, tickets internos, documentos de soporte o mensajes privados. Si tu app puede generar embeddings sin salir del dispositivo, reduces superficie de exposición. No eliminas todos los riesgos, porque el navegador sigue siendo un entorno compartido, pero sí recortas una parte importante del problema.

La latencia también se siente distinto. En una red móvil inestable, esperar una llamada a servidor puede sumar cientos de milisegundos o varios segundos. Con un modelo local, el tiempo depende más del hardware del dispositivo y de cuánto tarda en cargar el modelo. Si el usuario ya tiene la página abierta, la sensación suele ser más fluida.

Privacidad: qué mejora y qué no

Lo que mejora es bastante claro:

• el texto no tiene que viajar a un backend para ser vectorizado
• reduces logging involuntario en servicios intermedios
• puedes diseñar flujos donde el contenido sensible nunca salga del dispositivo

Lo que no desaparece:

• el navegador sigue teniendo acceso al contenido mientras la app está abierta
• si guardas embeddings o texto en almacenamiento local, también debes protegerlos
• si tu app usa analítica, debes revisar qué datos recolecta

En otras palabras, correr el modelo en el navegador no te vuelve automáticamente seguro. Pero sí te da una base mucho mejor para construir experiencias privadas por diseño.

Latencia: por qué el tamaño sí importa

El tamaño del modelo afecta el tiempo de descarga y, en muchos casos, el tiempo de carga inicial. Un archivo de 7 MB es mucho más razonable que un paquete de cientos de megabytes. Para una app web, eso significa menos fricción al primer acceso y menos castigo en planes de datos limitados.

Además, una vez cargado, el costo de una inferencia local suele ser predecible. No tienes el vaivén de un servidor compartido ni el ruido de una red congestionada. Eso ayuda a construir interfaces más consistentes, sobre todo si vas a disparar embeddings en tiempo real mientras el usuario escribe.

Apps offline: casos donde sí encaja

No todo producto necesita IA offline, pero hay varios casos donde sí tiene sentido:

• un buscador de documentación que debe funcionar en campo
• una app de soporte para técnicos con conectividad intermitente
• una herramienta para periodistas o investigadores que trabajan con archivos locales
• un portal interno que debe seguir respondiendo aunque el enlace a internet se caiga

En esos escenarios, un modelo de embeddings pequeño puede ser suficiente para recuperar documentos relacionados, priorizar resultados o clasificar entradas sin llamar a una API externa.

Casos de uso reales para equipos en LatAm

Si trabajas en producto o desarrollo en Latinoamérica, probablemente ya viste que la infraestructura ideal no siempre coincide con la realidad del usuario final. Hay oficinas con buena conectividad, sí, pero también hay vendedores de campo, equipos distribuidos, zonas con cobertura irregular y usuarios que navegan desde celulares de gama media.

Ahí una solución como Ternlight encaja mejor de lo que parece. No porque resuelva todo, sino porque reduce dependencias. Si tu caso de uso se basa en texto corto y tareas de similitud, un modelo ligero en navegador puede ser suficiente para una primera versión útil.

Ejemplos concretos

• Centro de ayuda interno: el agente escribe una consulta y el sistema sugiere artículos parecidos sin enviar el texto a un servicio externo.
• Formulario de soporte: la app detecta intención y agrupa tickets similares antes de subirlos al backend.
• Catálogo offline: un vendedor busca productos por descripción aunque esté sin señal.
• Notas de campo: un equipo técnico clasifica observaciones por tema sin depender de conectividad.

Estos casos no requieren necesariamente un modelo enorme. Requieren consistencia, rapidez y una barrera baja para empezar a usar la función.

Cuándo no usarlo

También conviene decirlo con claridad: no siempre conviene meter embeddings en el navegador. Si tu aplicación necesita calidad alta en varios idiomas, razonamiento complejo o un corpus enorme con re-ranking avanzado, probablemente necesites una arquitectura más robusta.

Tampoco es la mejor opción si tu prioridad es centralizar todo para auditar, versionar y controlar el comportamiento desde backend. En algunos equipos, una API remota sigue siendo más fácil de operar y de gobernar.

Limitaciones que debes mirar antes de adoptarlo

La tentación con cualquier demo ligera es pensar que ya encontraste la pieza que faltaba. Pero hay varios límites reales que conviene revisar antes de llevar algo así a producción.

Primero, la calidad del embedding. Un modelo pequeño puede funcionar bien para tareas acotadas, pero no necesariamente compite con modelos más grandes en cobertura semántica o robustez multilingüe. Si tu producto atiende español, portugués e inglés al mismo tiempo, necesitas probar con datos reales, no con frases de ejemplo.

Segundo, el costo en dispositivos modestos. Que algo corra en el navegador no significa que corra bien en cualquier equipo. Un teléfono de gama baja, una laptop vieja o un navegador con poca memoria pueden sufrir si además de la app tienes otras pestañas abiertas.

Tercero, el ciclo de actualización. Si el modelo vive en el cliente, debes pensar cómo distribuir nuevas versiones, cómo invalidar caché y cómo medir si la actualización realmente mejora el producto. El hecho de que sea pequeño ayuda, pero no elimina la operación.

Checklist antes de moverlo a producción

1. Prueba el modelo con texto real de tus usuarios, no solo con ejemplos sintéticos.
2. Mide tiempo de carga inicial en redes lentas y en dispositivos de gama media.
3. Define qué datos se guardan localmente y por cuánto tiempo.
4. Revisa si necesitas soporte multilingüe o solo español.
5. Decide si la app debe seguir útil sin conexión y qué parte del flujo debe funcionar offline.

Si quieres comparar el enfoque con otros runtimes web o con la documentación de ejecución local en navegador, también puedes revisar los recursos oficiales de MDN sobre WebAssembly y el estándar en https://webassembly.org/.

Qué nos dice esta demo sobre el futuro cercano

La lección más útil de Ternlight no es que todo modelo tenga que vivir en el navegador. La lección es que ya puedes mover ciertas tareas de IA a la capa más cercana al usuario sin que el costo técnico sea absurdo. Hace unos años, eso sonaba más experimental. Hoy ya cabe en una discusión de producto.

Para nosotros, el punto de inflexión está en el equilibrio. Si un modelo de 7 MB permite resolver una necesidad concreta con menos latencia, mejor privacidad y soporte offline, entonces vale la pena considerarlo. No como reemplazo de todo lo demás, sino como una opción más en tu arquitectura.

También obliga a pensar mejor el diseño. Cuando la IA deja de ser un servicio remoto y pasa a ser una pieza local, la interfaz, el almacenamiento y el flujo de actualización importan más. Ya no puedes esconderte detrás de “el backend lo resuelve”. Tienes que decidir qué hace el cliente, qué hace el servidor y qué datos merece la pena mover.

En mercados como los de LatAm, donde el ancho de banda, el precio del plan de datos y la privacidad no son temas abstractos, este tipo de enfoque tiene bastante sentido. No para todo, no para cualquier caso, pero sí para muchas herramientas útiles que hoy siguen dependiendo de una API por costumbre.

Tabla resumen