Planteamiento y alcance
Una aplicación web desea ejecutar un modelo de clasificación de imágenes localmente en el navegador para reducir el riesgo de privacidad al subir imágenes y la latencia de red. El equipo está considerando el borrador de recomendación candidata (Candidate Recommendation Draft) de mayo de 2026 de la API W3C Web Neural Network. WebNN es una API de grafos computacionales que puede dirigirse a la ejecución en CPU, GPU y NPU; la especificación sigue evolucionando, por lo que un Candidate Recommendation Draft no es una promesa de soporte estable en todos los navegadores.
Proporciona una respuesta completa que cubra la conversión del modelo, la construcción y compilación del grafo, el despacho de inferencia, la elección del dispositivo, el fallback y la validación de la versión.
Qué evalúa el entrevistador
El entrevistador busca un ciclo de vida claro de "construir una vez, ejecutar muchas veces" y una distinción entre la compilación asíncrona de MLGraphBuilder.build() y la ejecución asíncrona de MLContext.dispatch(). WebNN debe describirse como una abstracción independiente del hardware, no como una garantía de que cada operador rinda igual en cada dispositivo.
Las respuestas sólidas abordan la cobertura de operadores, la vinculación de tensores (tensor binding), el bloqueo del hilo principal, la detección de capacidades, la privacidad y el fingerprinting, la compatibilidad de navegadores y un plan canary reversible.
Preguntas aclaratorias antes de responder
- ¿El modelo utiliza dimensiones fijas o debe admitir dimensiones dinámicas y múltiples precisiones?
- ¿Los navegadores y sistemas operativos objetivo exponen los mismos operadores y backends?
- ¿La inferencia debe permanecer fuera de línea o es aceptable un fallback seguro en el servidor?
- ¿El objetivo es la velocidad del primer pintado (first-paint), la latencia por fotograma, el rendimiento (throughput), la energía o la privacidad?
- ¿El modelo procesa imágenes sensibles y la capacidad del hardware podría convertirse en una señal de fingerprinting?
Un marco de respuesta de 30 segundos
"Trataría a WebNN como un backend de ejecución candidato. Primero validaría los operadores del modelo y las disposiciones de los tensores, y luego sacaría la construcción y compilación del grafo de la ruta crítica de inferencia. La compilación y el despacho son asíncronos, con tensores nombrados que vinculan entradas y salidas. Antes del lanzamiento construiría una matriz de navegadores, dispositivos y versiones del modelo; las capacidades no soportadas o los fallos de compilación recurrirían a WebAssembly o al servidor con un límite de datos claro. Mediría la primera compilación, la inferencia en estado estable, la memoria, la energía y la capacidad de respuesta del hilo principal, desplegaría gradualmente mediante canary y mantendría un kill switch."
Respuesta detallada paso a paso
Congelar el contrato del modelo
Fija la forma de entrada, el tipo de datos, la disposición, la normalización, las etiquetas de salida y una tolerancia de error. Convierte el modelo en un subgrafo de operadores compatibles, detectando operadores no admitidos durante la construcción del grafo en lugar de hacerlo tras una ejecución parcial en el dispositivo del usuario. Mantén una implementación de referencia en WebAssembly o en el servidor para comparaciones capa por capa.
Construir y compilar el grafo
Crea un contexto y MLGraphBuilder a través de navigator.ml, luego compone entradas, constantes y operadores. build() compila el grafo y devuelve una Promise; cada constructor debe poseer un grafo. Precalienta (warm) el grafo con anticipación o en un Worker para que la primera compilación no se traduzca en latencia al hacer clic.
const context = await navigator.ml.createContext({ deviceType: 'gpu' });
const builder = new MLGraphBuilder(context);
const input = builder.input('image', {
dataType: 'float32',
dimensions: [1, 224, 224, 3],
});
const weights = builder.constant(weightDescriptor, weightBuffer);
const logits = builder.conv2d(input, weights, convOptions);
const graph = await builder.build({ logits });La opción de dispositivo es solo una política candidata; una implementación debe validarse frente al navegador de destino y la versión de la especificación en lugar de asumir que aceptará cualquier valor.
Diseñar la ejecución asíncrona y el flujo de memoria
dispatch() envía la ejecución del grafo a una línea de tiempo de ejecución y retorna de inmediato. Vincula los tensores de entrada y salida nombrados, luego lee los resultados una vez completada la ejecución. Reutiliza el grafo compilado, el contexto y los búferes para inferencias repetidas en lugar de asignar por cada fotograma. Un flujo de cámara necesita contrapresión (backpressure): descarta o fusiona un fotograma nuevo mientras el anterior aún se está ejecutando en lugar de acumular una cola ilimitada.
Elegir dispositivos y fallbacks
Detecta la compatibilidad con la API, los operadores y el modelo antes de elegir CPU, GPU o NPU. La disponibilidad del dispositivo no demuestra que los operadores de destino sean eficientes; elige a partir de mediciones de extremo a extremo. Una cadena de fallback puede ser WebNN → WebAssembly → servidor, pero cada nivel debe compartir el preprocesamiento y las comprobaciones de resultados. Un fallback en el servidor sube imágenes, por lo que la interfaz de usuario y la capa de red deben establecer los límites de consentimiento y retención.
Proteger el hilo principal y la interacción
La construcción del grafo, la compilación, el preprocesamiento y el posprocesamiento pueden afectar la interacción. Traslada el trabajo pesado a un Dedicated Worker y mantén el hilo principal en la captura de entradas y el estado de la UI. Usa cancelaciones o números de secuencia para descartar resultados obsoletos. Mide las tareas largas (long tasks), las ráfagas de entrada y la recuperación de pestañas en segundo plano, no solo el tiempo promedio de inferencia.
Construir matrices de corrección y compatibilidad
Crea una matriz con la versión del navegador, el sistema operativo, el tipo de dispositivo, la precisión del modelo y el conjunto de operadores. Compara las salidas, la precisión y las entradas de límite con el backend de referencia. Registra fallos de compilación, operadores no admitidos, pérdida de dispositivo y destrucción de contexto. Debido a que el documento del W3C sigue siendo un Candidate Recommendation Draft, el plan de lanzamiento debe contemplar cambios en la especificación y diferencias de implementación.
Gestionar privacidad, permisos y fingerprinting
La ejecución local reduce la subida de imágenes, pero los archivos del modelo, las cachés y la telemetría aún pueden filtrar información. Almacena en caché solo los pesos necesarios, evita registrar características de entrada y no conviertas el tipo de dispositivo en un identificador de usuario. La especificación advierte que la programación de tareas en el dispositivo puede generar señales de fingerprinting; por lo tanto, los resultados de capacidad deben minimizarse y ser efímeros, contando con una alternativa por software o en servidor.
Canary, observación y reversión (rollback)
Comienza con un modelo no sensible y un conjunto reducido de navegadores. Compara la primera compilación, el P50/P95 en estado estable, las tareas largas del hilo principal, la memoria, la energía, la tasa de fallos y la tasa de fallback. Vuelve a ejecutar la matriz ante actualizaciones del modelo o del navegador. Si los dispositivos fallan, la precisión se desvía, el consumo energético es excesivo o se incumplen los requisitos de privacidad, deshabilita WebNN y utiliza el backend de referencia; conserva los hashes de versión, dispositivo y modelo para el análisis.
Respuesta modelo de alta calidad
"Congelaría el contrato de entrada, salida y error del modelo, y luego verificaría el mapeo de operadores a WebNN. El grafo se construye y compila una vez; build() y dispatch() siguen flujos asíncronos, y el bucle de inferencia reutiliza su contexto y búferes. La matriz de lanzamiento cubre versiones de navegador, dispositivo y modelo, con Workers gestionando la compilación y el preprocesamiento. WebNN, WebAssembly y el servidor forman una cadena de fallback observable, y el fallback en servidor define el límite de subida. Las métricas de canary incluyen la latencia inicial y en estado estable, tareas largas, memoria, energía, precisión y tasa de fallos; un kill switch restaura de inmediato el backend de referencia."
Errores comunes
- Tratar una Recomendación Candidata como soporte universal → las discrepancias de navegadores u operadores perjudican a los usuarios → construye una matriz de versiones y capacidades.
- Compilar el grafo en cada solicitud → el costo de la primera ejecución se repite → precalienta y reutiliza el grafo compilado.
- Evaluar solo en una GPU ideal → las rutas de CPU o NPU fallan → mide de extremo a extremo en cada backend.
- Tratar el despacho como sincrónico → tirones (jank) o resultados desordenados → utiliza estado asíncrono y números de secuencia.
- Encolar cada fotograma de la cámara → la latencia crece indefinidamente → aplica contrapresión y descarta fotogramas obsoletos.
- Reportar la capacidad del dispositivo como identidad → aumenta el riesgo de fingerprinting → minimiza la detección y mantén un fallback por software.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no usar WebGPU directamente?
WebGPU expone recursos de menor nivel y control sobre shaders, lo cual es adecuado para operadores personalizados y una programación fina. WebNN proporciona una abstracción de grafos de redes neuronales de mayor nivel que se asigna de manera más directa a frameworks y backends de hardware. La elección depende de la cobertura de operadores, la capacidad de mantenimiento, los objetivos de rendimiento y los límites de privacidad.
Pregunta de seguimiento 2: La compilación tarda diez segundos. ¿Cómo evitas que el usuario perciba la espera?
Mueve la carga y compilación del modelo a un Worker, precalienta durante el tiempo de inactividad y almacena en caché pesos con verificación de integridad. Si la primera solicitud aún no está disponible, muestra un estado transparente y usa WebAssembly o fallback en el servidor; nunca ocultes un fallo de compilación tras una salida falsa.
Pregunta de seguimiento 3: La salida de la GPU a veces difiere de la de referencia. ¿Qué haces?
Separa el redondeo de punto flotante, la conversión de precisión, las diferencias de implementación de operadores y un defecto real del modelo. Reproduce con entradas fijas, tensores intermedios y umbrales de tolerancia; si se excede la tolerancia del producto, usa otro backend y registra las versiones del navegador, controlador y modelo.
Pregunta de seguimiento 4: El usuario rechaza la subida de imágenes y WebNN no está disponible. ¿Qué procede?
Ofrece WebAssembly local o un estado claro de no disponibilidad; no eludas la elección del usuario. El producto puede reducir la complejidad del modelo u ofrecer un flujo manual, pero debe mantener transparente el límite de datos.