WebGPU e IA en el dispositivo: el navegador se está convirtiendo en un tiempo de ejecución importante

Durante años, el navegador fue la cara bonita de la aplicación y la nube fue el lugar donde sucedieron las cosas difíciles. El usuario escribe, hace clic, sube un archivo; la interfaz envía todo al servidor; el servidor llama a un modelo; la respuesta vuelve.

Este esquema sigue siendo muy útil, pero no es gratuito. Cada llamada trae consigo preguntas sobre latencia, costo, dependencia de la red y privacidad. Si el usuario está escribiendo una frase y quiere una sugerencia, medio segundo pesa. Si clasificas miles de pequeños insumos, los centavos se convierten en dinero real. Si el texto es confidencial, enviarlo desde el dispositivo no es una opción neutral.

Es por eso que WebGPU y la IA en el dispositivo están de moda. No porque mañana ejecutaremos todos los modelos en el navegador. Porque algunas de las funciones inteligentes pueden acercarse al usuario.

No todo tiene que volverse local

La versión infantil del argumento es: "nube versus dispositivo". La versión útil es híbrida.

Algunas tareas se ven muy bien en el dispositivo: resúmenes breves, detección de idioma, reescrituras ligeras, clasificaciones simples, filtros de imágenes, modelos de visión pequeños, experiencias creativas con retroalimentación inmediata.

Otras tareas siguen siendo mejores en la nube: razonamiento complejo, modelos de frontera, datos del lado del servidor, auditoría centralizada, calidad uniforme, flujo de trabajo en el que hay que controlar cuidadosamente cada paso.

La arquitectura sana decide en tiempo de ejecución:

El navegador no tiene por qué ganarle a la nube. Debe evitar que la nube realice trabajos que no es necesario realizar allí.

Por qué es importante WebGPU

WebGPU es una API moderna para utilizar la GPU desde el navegador. No es sólo para obtener mejores gráficos en 3D. También es importante porque expone primitivas adecuadas para la informática: cargas de trabajo paralelas, sombreadores, canalizaciones más cercanas a lo que hacen bien las GPU.

En el caso de la IA, la visualización científica, los editores 3D, los filtros de vídeo y las herramientas creativas, esta diferencia se siente. WebGL ha hecho mucho por la web, pero WebGPU nació con un modelo más adaptado al presente.

Sin embargo, lo primero que hay que escribir no es un sombreador. Es una detección de características sobria:

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

Esta característica dice una cosa importante: WebGPU no es un derecho otorgado en todos los dispositivos. Es una capacidad que debe ser verificada. Algunos navegadores no lo admiten completamente, algunas GPU tienen limitaciones, algunos entornos empresariales desactivan funciones y algunos usuarios utilizan hardware modesto.

IA incorporada: cuando el navegador trae el modelo

Chrome está impulsando API integradas para tareas como indicaciones locales, resúmenes, escritura, reescritura, traducción, detección de idioma y revisión. La idea es muy interesante: el navegador gestiona el modelo, la disponibilidad y las actualizaciones; la aplicación utiliza una API más cercana a la plataforma.

Si funciona bien cambia mucho:

• menos llamadas al servidor para tareas simples;
• datos que puedan quedar en el dispositivo;
• menor latencia;
• experiencias fuera de línea o semi-fuera de línea;
• UX más natural para escritura y traducción.

Pero debería tratarse como una mejora progresiva. Algunas API son estables, otras se encuentran en versión de prueba o vista previa, y otras aún dependen de la versión, el idioma y el dispositivo.

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

El código específico cambiará, pero el patrón permanece: usted verifica la disponibilidad, explica las descargas, ofrece alternativas y mide la calidad.

El retroceso no es un triste plan B

El retroceso de la nube no es una derrota. Es parte del producto.

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

Esta arquitectura le permite mejorar progresivamente. Aquellos con soporte local obtienen mejor latencia y privacidad. Aquellos que no lo tienen todavía usan la función. Puede medir el porcentaje de solicitudes locales, tiempos, errores, memoria, calidad percibida y costo.

Sin métricas, la IA en el dispositivo se convierte en una opción estética. Con las métricas, se convierte en una palanca de producto.

La UX del modelo importa

Si el navegador necesita descargar un modelo, el usuario lo percibe. No lo escondas detrás de una vaga ruleta. Es mejor ser claro: "Preparamos el modelo para utilizar esta función más rápido e incluso sin conexión".

Una buena experiencia:

• muestra el estado de preparación;
• no bloquea toda la página;
• le permite continuar con el respaldo de la nube;
• evitar sorpresas con la batería y la memoria;
• recuerde el modelo siempre que sea posible;
• Explique el beneficio en una oración concreta.

Lo peor es una función "inteligente" que parece no funcionar porque está descargando algo silenciosamente.

Privacidad: mejor, no automáticamente segura

Procesar datos en el dispositivo puede ser una gran ventaja. No es necesario que un borrador de correo electrónico, un documento interno o una nota personal abandonen su navegador para recibir una sugerencia.

Sin embargo, local no significa automáticamente seguro. Sin embargo, es necesario pensar en:

• XSS;
• registros accidentales;
• datos guardados en el almacenamiento;
• inyección rápida de contenido que no es de confianza;
• permisos otorgados al modelo;
• salidas utilizadas en acciones automáticas.

Si un modelo local puede leer una página web y luego completar un formulario, esa página puede intentar manipularla. Si puede llamar a la herramienta, se necesita confirmación. Si produce resultados estructurados, debe validarse. El hecho de que se ejecute en el dispositivo reduce algunos riesgos de privacidad, pero no elimina el modelo de seguridad.

Donde se pone realmente interesante

El texto es sólo el comienzo. WebGPU hace creíbles las experiencias web que hasta hace poco parecían una aplicación nativa:

• editores 3D complejos;
• Salpicaduras gaussianas en el navegador;
• filtros de vídeo en tiempo real;
• CAD ligero;
• visualizaciones científicas;
• herramientas creativas con vista previa instantánea;
• inferencia de visión cerca de la interfaz de usuario;
• juegos de navegador más ambiciosos.

Aquí el frontend, los gráficos y el aprendizaje automático comienzan a mezclarse. Es un área algo incómoda, pero también fértil: el navegador vuelve a ser una plataforma de aplicaciones seria, no sólo el lugar donde colocamos formularios y paneles.

Lista de verificación antes de la producción.

Antes de mostrar una función del dispositivo a los usuarios, comprobaría:

1. Apunte a navegadores y dispositivos.
2. Repliegue de la nube o degradación elegante.
3. Tiempo de descarga y caché del modelo.
4. Memoria y batería en hardware medio.
5. Calidad en comparación con la versión en la nube.
6. Política de privacidad y mensajes de usuario.
7. Pruebas con entradas hostiles.
8. Métricas separadas para el tiempo de ejecución local y en la nube.
9. Planee actualizar o deshabilitar la plantilla.

Es una lista concreta porque el problema es concreto. Una función de IA lenta, frágil u opaca no mejora solo porque se ejecuta en el navegador.

El compromiso correcto

No creo que el futuro esté "todo en el dispositivo". Y tampoco creo que la nube siga siendo el único lugar razonable para realizar inferencias. El futuro más probable es una combinación: local cuando mejore la latencia, la privacidad o el costo; nube cuando se necesita calidad, datos actualizados y control centralizado.

WebGPU, WebNN y las API de IA integradas no hacen que el navegador sea omnipotente. Lo hacen más adulto. Y para quienes crean productos web, esta es una gran noticia.

Fuentes útiles

• API WebGPU-MDN
• Especificación WebGPU - W3C
• IA integrada: Chrome para desarrolladores
• API de IA integradas: Chrome para desarrolladores
• API WebNN