spinny:~/writing $ vim webgpu-on-device-ai-browser.md
1~2Durante 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.3~4Este 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.5~6Es 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.7~8## No todo tiene que volverse local9~10La versión infantil del argumento es: "nube versus dispositivo". La versión útil es híbrida.11~12Algunas 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.13~14Otras 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.15~16La arquitectura sana decide en tiempo de ejecución:17~18```mermaid19flowchart TD20 User[Usuario] --> Browser[Navegadores]21 Browser --> Detect[Detección de características]22 Detect -->|Apoyado| Local[inferencia local]23 Detect -->|No compatible| Cloud[Repliegue de la nube]24 Local --> UX[Respuesta rápida]25 Cloud --> UX26 UX --> Metrics[Métricas y calidad]27```28~29El navegador no tiene por qué ganarle a la nube. Debe evitar que la nube realice trabajos que no es necesario realizar allí.30~31## Por qué es importante WebGPU32~33WebGPU 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.34~35En 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.36~37Sin embargo, lo primero que hay que escribir no es un sombreador. Es una detección de características sobria:38~39```typescript40export async function requestWebGpuDevice() {41 if (!('gpu' in navigator)) {42 return null;43 }44~45 const adapter = await navigator.gpu.requestAdapter({46 powerPreference: 'high-performance',47 });48~49 if (!adapter) {50 return null;51 }52~53 return adapter.requestDevice();54}55```56~57Esta 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.58~59## IA incorporada: cuando el navegador trae el modelo60~61Chrome 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.62~63Si funciona bien cambia mucho:64~65- menos llamadas al servidor para tareas simples;66- datos que puedan quedar en el dispositivo;67- menor latencia;68- experiencias fuera de línea o semi-fuera de línea;69- UX más natural para escritura y traducción.70~71Pero 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.72~73```typescript74type LocalCapability = 'available' | 'downloadable' | 'unsupported';75~76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {77 const SummarizerApi = (globalThis as any).Summarizer;78~79 if (!SummarizerApi?.availability) {80 return 'unsupported';81 }82~83 const availability = await SummarizerApi.availability();84~85 if (availability === 'available') return 'available';86 if (availability === 'downloadable') return 'downloadable';87~88 return 'unsupported';89}90```91~92El código específico cambiará, pero el patrón permanece: usted verifica la disponibilidad, explica las descargas, ofrece alternativas y mide la calidad.93~94## El retroceso no es un triste plan B95~96El retroceso de la nube no es una derrota. Es parte del producto.97~98```typescript99interface AiRequest {100 task: 'summarize' | 'rewrite' | 'classify';101 input: string;102}103~104interface AiResult {105 output: string;106 runtime: 'local' | 'cloud';107}108~109export async function runAiTask(request: AiRequest): Promise<AiResult> {110 const local = await tryLocalAi(request);111~112 if (local) {113 return { output: local, runtime: 'local' };114 }115~116 const cloud = await fetch('/api/ai', {117 method: 'POST',118 headers: { 'Content-Type': 'application/json' },119 body: JSON.stringify(request),120 }).then((res) => res.json());121~122 return { output: cloud.output, runtime: 'cloud' };123}124```125~126Esta 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.127~128Sin 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.129~130## La UX del modelo importa131~132Si 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".133~134Una buena experiencia:135~136- muestra el estado de preparación;137- no bloquea toda la página;138- le permite continuar con el respaldo de la nube;139- evitar sorpresas con la batería y la memoria;140- recuerde el modelo siempre que sea posible;141- Explique el beneficio en una oración concreta.142~143Lo peor es una función "inteligente" que parece no funcionar porque está descargando algo silenciosamente.144~145## Privacidad: mejor, no automáticamente segura146~147Procesar 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.148~149Sin embargo, local no significa automáticamente seguro. Sin embargo, es necesario pensar en:150~151- XSS;152- registros accidentales;153- datos guardados en el almacenamiento;154- inyección rápida de contenido que no es de confianza;155- permisos otorgados al modelo;156- salidas utilizadas en acciones automáticas.157~158Si 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.159~160## Donde se pone realmente interesante161~162El texto es sólo el comienzo. WebGPU hace creíbles las experiencias web que hasta hace poco parecían una aplicación nativa:163~164- editores 3D complejos;165- Salpicaduras gaussianas en el navegador;166- filtros de vídeo en tiempo real;167- CAD ligero;168- visualizaciones científicas;169- herramientas creativas con vista previa instantánea;170- inferencia de visión cerca de la interfaz de usuario;171- juegos de navegador más ambiciosos.172~173Aquí 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.174~175## Lista de verificación antes de la producción.176~177Antes de mostrar una función del dispositivo a los usuarios, comprobaría:178~1791. Apunte a navegadores y dispositivos.1802. Repliegue de la nube o degradación elegante.1813. Tiempo de descarga y caché del modelo.1824. Memoria y batería en hardware medio.1835. Calidad en comparación con la versión en la nube.1846. Política de privacidad y mensajes de usuario.1857. Pruebas con entradas hostiles.1868. Métricas separadas para el tiempo de ejecución local y en la nube.1879. Planee actualizar o deshabilitar la plantilla.188~189Es 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.190~191## El compromiso correcto192~193No 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.194~195WebGPU, 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.196~197## Fuentes útiles198~199- [API WebGPU-MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)200- [Especificación WebGPU - W3C](https://www.w3.org/TR/webgpu/)201- [IA integrada: Chrome para desarrolladores](https://developer.chrome.com/docs/ai/built-in)202- [API de IA integradas: Chrome para desarrolladores](https://developer.chrome.com/docs/ai/built-in-apis)203- [API WebNN](https://webnn.io/)204~
NORMAL · webgpu-on-device-ai-browser.md [readonly]204 lines · :q to close