Volver al blog
tech 2026-02-05

Ejecutando modelos de IA en el navegador con ONNX Runtime

Ejecutando modelos de IA en el navegador con ONNX Runtime

Durante años, "IA en el navegador" sonaba a demo de juguete: un clasificador diminuto sobre MNIST, quizá un style transfer que derretía tu portátil. Eso cambió cuando ONNX Runtime Web maduró y las rutas WebGPU/WebGL se volvieron lo suficientemente fiables para cargas reales de imagen. En Ai2Done usamos modelos basados en ONNX para impulsar funciones como mejora y segmentación en el dispositivo, porque enviar fotos de usuario a una GPU remota contradice todo lo que defendemos.

¿Por qué ONNX, en concreto?

El formato ONNX desacopla la autoría del modelo del despliegue. Los investigadores entrenan en PyTorch o donde sea, exportan a ONNX y nosotros consumimos un único artefacto que ONNX Runtime puede optimizar para distintos execution providers. En el navegador, eso significa que podemos apuntar a WebGPU cuando está disponible y degradarnos con elegancia cuando no.

Conceptualmente, el bucle de inferencia se ve así:

// Pseudocódigo: carga la sesión, alimenta tensores, lee tensores de salida
const session = await ort.InferenceSession.create("/models/segmentation.onnx");
const feeds = { input: inputTensor };
const results = await session.run(feeds);
const mask = results.output; // usado por el canvas / glue WASM

Las capas Go y WASM de nuestro stack se mantienen finas: mueven bytes, exponen el progreso y dejan las reglas de negocio en internal/apps/ai2done/tool — no dentro del propio runtime del modelo.

Memoria, tensores y honestidad

Las redes neuronales son hambrientas. Una suposición errónea — cargar un modelo "todo a resolución completa" en un portátil de hace cinco años — provoca cierres de pestaña y usuarios enfadados. Lo mitigamos con:

  • Cuantización del modelo donde la calidad lo permite
  • Carga progresiva para que la UI siga respondiendo
  • Techos claros sobre el tamaño de entrada, con mensajes visibles para el usuario

Es la misma filosofía que aplicamos al WASM de PDF y de vídeo: respetar los límites del navegador en vez de fingir que la web es un datacenter.

La privacidad como garantía técnica

Cuando la inferencia se ejecuta localmente, la historia de la privacidad se escribe sola. Tu imagen nunca toca nuestros discos para mejorarla — no porque lo prometamos suavemente en un banner, sino porque no existe una ruta de subida en la arquitectura para esa operación. Esa distinción importa en entornos regulados y para cualquiera que simplemente no quiera tener sus fotos de vacaciones en la GPU de un desconocido.

Dónde encaja Go

Seguimos amando Go para la orquestación, el serving estático y la incrustación de bundles WASM. El modelo mental es limpio: Go envía la aplicación, JS hace de puente a ONNX, WASM gestiona transformaciones deterministas donde compartir código con el servidor aporta valor. Los límites DDD mantienen a cada capa honesta — la lógica de dominio en tool/, los servicios coordinando peticiones, sin plantillas "inteligentes".

Depurando la deriva del mundo real

Los modelos se comportan de manera distinta entre dispositivos: los perfiles de color, la disponibilidad de WebGPU y las rarezas de coma flotante pueden desplazar salidas sutilmente. Invertimos en tests de golden-file sobre entradas representativas y en feedback de usuario sin telemetría (literalmente: "reportar incidencia" sin exfiltrar píxeles) para detectar casos límite.

Mirando hacia adelante

El ML en el dispositivo seguirá mejorando a medida que los navegadores expongan más rendimiento y los modelos se reduzcan. Ai2Done seguirá cabalgando esa ola sin convertir tus medios en los datos de entrenamiento de otra persona. Si eres ingeniero evaluando ONNX en el navegador, nuestro consejo es simple: trata la memoria y los fallbacks como requisitos de primera clase, y tus usuarios notarán la diferencia.