En 2018 escribí mi primer post sobre TensorFlow.js. Estaba ejecutando PoseNet en una pestaña del navegador; estimación de poses humanas en tiempo real sin infraestructura de servidor. La idea parecía radical en aquel momento. La gente preguntaba por qué no usaba un servidor GPU dedicado. Mi respuesta fue la misma entonces que ahora: porque el navegador es suficiente, y no cuesta nada.
Ocho años después, el mismo principio aplica a la detección de objetos. Nunca he ejecutado YOLO desde un servidor. Ni una vez. La premisa de enviar imágenes de usuarios a la GPU de otra persona nunca me tuvo sentido cuando WebGL estaba ahí, ya dentro de cada portátil.
El argumento que llevo haciendo desde 2018
En aquel post de TensorFlow.js, escribí algo que sigue vigente:
Antes de TensorFlow.js, era imposible usar modelos de machine learning directamente en el navegador sin interacción con una API. Ahora podemos entrenar y usar modelos offline. Las predicciones son mucho más rápidas porque no requieren la petición al servidor. Otro beneficio es el bajo coste en servidor porque ahora todos estos cálculos están en el lado del cliente.
Tres beneficios. No han cambiado:
1. Cero coste de servidor. Cada inferencia que se ejecuta en el dispositivo del usuario es una que no pagas. Construí un clasificador de imágenes gato/perro, un detector de toxicidad de texto, demos de PoseNet; todo ejecutándose completamente en el navegador. Mi factura de AWS para inferencia ML ha sido cero durante ocho años porque nunca empecé una.
2. Predicciones offline. El modelo se descarga una vez, se cachea en el navegador y funciona para siempre sin conexión a internet. Intenta eso con una API cloud.
3. Privacidad por arquitectura. Cuando no hay servidor, no hay nada de lo que fiarte. Los datos del usuario se quedan en su dispositivo porque físicamente no tienen otro sitio al que ir. Esto no es una decisión de política; es una garantía estructural.
Por qué la industria fue por otro camino
La mayoría de empresas eligieron el camino del servidor igualmente. Las razones eran prácticas en aquel momento: WebGL era inmaduro, Wasm no existía aún, los modelos eran demasiado grandes para servir desde el navegador. La industria convergió en un patrón; subir imagen, ejecutar inferencia en GPU, devolver JSON.
Ese patrón creó problemas con los que la gente sigue lidiando hoy:
La privacidad es un pasivo legal. Tu imagen llega a un servidor, se loguea, quizás se almacena para "mejorar el modelo." El RGPD y la CCPA existen precisamente porque esta arquitectura filtra datos de usuario por defecto. Cada imagen enviada a una API de detección es un pasivo bajo el Artículo 9 del RGPD.
La latencia suma. Subir 2MB, esperar inferencia, descargar resultados. Con buena conexión: 800ms-2s. En móvil: timeout. La investigación de Google Web Vitals muestra que los usuarios abandonan tareas después de 3 segundos. La detección con ida y vuelta al servidor apenas cabe.
El coste escala linealmente. Mil detecciones por una API cloud significa una factura. Esto encarece el prototipado y mata la experimentación; justo lo opuesto a lo que yo quería en 2018 cuando simplemente intentaba hacer funcionar PoseNet con una webcam.
Qué maduró: WebAssembly alcanzó a WebGL
En 2018, el ML en navegador era limitado. TensorFlow.js usaba WebGL para acceder a la GPU, pero el ecosistema era pequeño y los modelos básicos. Desde entonces:
WebAssembly alcanzó velocidad de ejecución casi nativa. El equipo de ONNX Runtime publicó un backend Wasm que ejecuta grafos completos de redes neuronales en el navegador. Esto significa que modelos que no necesitan GPU (o que se ejecutan en dispositivos con GPUs débiles) pueden funcionar a velocidades aceptables.
WebGL maduró significativamente, y WebGPU está aterrizando en navegadores con soporte apropiado de compute shaders. Multiplicaciones de matrices que tardaban segundos en CPU en 2018 ahora terminan en milisegundos en GPUs integradas.
El ecosistema de modelos explotó. En 2018 tenía PoseNet y MobileNet. Hoy puedes ejecutar YOLO, Whisper, Stable Diffusion, LLMs; todo client-side. El zoo de modelos ONNX tiene cientos de modelos listos para producción optimizados para inferencia en navegador.
La tesis de 2018 era correcta. Solo necesitaba que las herramientas se pusieran a la altura.
Cómo funciona YOLO (y por qué es ideal para inferencia en navegador)
YOLO ("You Only Look Once") es arquitectónicamente perfecto para uso client-side porque procesa la imagen entera en un solo forward pass. Detectores tradicionales como R-CNN ejecutaban dos fases; proponer regiones, luego clasificar cada una. Lento y secuencial. YOLO hace todo a la vez:
- Dividir la imagen en una cuadrícula S x S
- Cada celda predice bounding boxes + confianza + probabilidades de clase simultáneamente
- Non-maximum suppression elimina duplicados
- Salida: objetos con coordenadas, etiquetas y scores de confianza
El paper original de 2016 de Redmon et al. logró 45 FPS. La arquitectura ha evolucionado a través de YOLOv5, YOLOv8 y más allá. El modelo detecta 80 categorías de objetos del dataset COCO: personas, vehículos, animales, muebles, electrónica, comida.
Inferencia de un solo pase significa latencia predecible. Sin propuestas de regiones iterativas, sin cómputo variable. Una imagen entra, un set de detecciones sale. Esa predecibilidad es lo que lo hace viable en un navegador donde no puedes asumir que una 3090 está esperando.
La privacidad no es una feature; es la ausencia de un servidor
Vuelvo a esto constantemente porque es el núcleo de por qué construyo las cosas así. Cuando digo "se ejecuta en tu navegador," quiero decir: abre DevTools, ve a la pestaña Network, ejecuta una detección. Cero peticiones salientes después de la descarga inicial del modelo. Tu imagen se queda en la memoria del navegador, la procesa la GPU, y los resultados se renderizan en un elemento canvas.
Esto importa en casos donde el procesamiento en servidor es ilegal o absurdo:
- Imagen médica. Los hospitales no pueden enviar escáneres de pacientes a APIs aleatorias. Las violaciones de HIPAA empiezan en $100 por registro.
- Grabaciones de vigilancia. Enviar feeds de cámaras a servicios cloud es un campo minado legal en la mayoría de jurisdicciones de la UE.
- Fotos personales. La gente no quiere sus fotos familiares en el ordenador de otro. El hecho de que esto necesite decirse es el problema.
Con detección en navegador, la cuestión de confianza es irrelevante. No hay servidor del que fiarse.
Qué puedes hacer con esto
Contar objetos. Sube una foto de un parking y obtén un conteo de vehículos. Estantería de almacén; cuenta cajas. Foto de evento; cuenta personas. Sin código, sin configuración.
Prototipar pipelines de visión por computador. Antes de escribir Python, prueba cómo funciona YOLO con tus imágenes específicas. Exporta las detecciones en JSON y aliméntalas a tu pipeline. El Detector de Objetos te permite ajustar umbrales de confianza y exportar tanto PNGs anotados como JSON estructurado.
Generar metadatos de accesibilidad. Ejecuta detección en imágenes de productos para producir texto alt descriptivo. "La imagen contiene: 2 personas, 1 portátil, 1 taza de café" supera un atributo alt vacío. La Iniciativa de Accesibilidad Web del W3C lo recomienda para todas las imágenes informativas.
Control de calidad desde una tablet. Equipos de fabricación pueden ejecutar detección de defectos en fotos de productos desde un navegador. Sin hardware dedicado. Sin dependencia cloud.
El umbral de confianza
Cada detección tiene un score entre 0 y 1. El umbral controla lo que ves:
- 0.3: Más detecciones, más ruido. Bueno para explorar qué encuentra el modelo.
- 0.7: Menos detecciones, alta precisión. Bueno para producción.
- 0.5: Balance razonable para la mayoría de casos.
Este es el trade-off precisión-vs-recall. CS231n de Stanford explica el framework mAP para evaluar detectores en detalle.
Limitaciones honestas
La inferencia en navegador no reemplaza todo. Las restricciones:
Velocidad. Una GPU dedicada ejecuta YOLOv8 en 5-10ms. Un navegador tarda 100-500ms por imagen. Bien para imágenes individuales; demasiado lento para vídeo en tiempo real a 30 FPS.
Tamaño del modelo. Los pesos de YOLO son 20-50MB. La primera carga requiere descargarlos. Después, la caché del navegador se encarga.
Categorías fijas. El modelo COCO conoce 80 clases. Objetos personalizados (piezas de maquinaria específicas, especies raras) necesitan modelos fine-tuned. Puedes traer tu propio modelo ONNX, pero el entrenamiento sigue requiriendo una GPU en otro lugar.
Móvil. Los teléfonos tienen GPUs más débiles. Espera 2-3 segundos por detección en hardware de gama media.
Nada de esto es un dealbreaker para el caso de uso principal: detección de objetos rápida, privada y de coste cero.
Círculo completo
En 2018 escribí "el bajo coste en servidor porque ahora todos estos cálculos están en el lado del cliente." Esa frase describe exactamente lo que hace el Detector de Objetos. Carga un modelo YOLO en el navegador, sube una imagen, obtén detecciones. Sin registro, sin API key, sin subir nada al servidor de nadie.
La tecnología maduró. El principio nunca cambió.
Se ejecuta sobre ONNX Runtime Web, entrenado en COCO (80 categorías). Arquitectura: YOLO de Ultralytics. Si quieres entender los fundamentos, empieza por mi post de TensorFlow.js de 2018.