WebGPU vence a PyTorch en rendimiento 🚀

Una investigación liderada por A.B. Gunaydin en 2026 demostró que WebGPU corriendo en un navegador logra 159× más throughput que PyTorch usando dispatches por paso individual. Los benchmarks además muestran que WebGPU supera incluso a PyTorch MPS ejecutándose nativo en macOS, pese al overhead del navegador (48%). Los detalles están en gpubench.dev con simulations y evaluaciones paralelas que podés ejecutar en tiempo real.

Qué es WebGPU y por qué importa este resultado

WebGPU es una API estándar de bajo nivel que los navegadores exponen para acceso directo a GPU. A diferencia de WebGL (que es más antiguo y limitado), WebGPU te da control fino sobre compute shaders, pipelines y administración de memoria, más parecido a lo que tenés en Vulkan o Metal. Hasta hace poco, si querías hacer cálculo GPU serio, tenías que bajar a Python + PyTorch o CUDA. La idea de que un navegador pudiera competir era… ponele que optimista.

Pero lo que pasó acá es que alguien se tomó el trabajo de fusionar operaciones GPU. En vez de mandar cien pequeñas tareas a la GPU de una en una (lo que genera overhead), compilás todo en un único shader y lo mandás como una sola tarea. El resultado (spoiler: no es poco) es 159 veces más rápido.

Y hay un detalle que le cambia todo: el navegador es más lento que correr código nativo. Chrome tiene 48% de overhead comparado con Metal (la API de GPU de Apple). Pero ni con ese handicap, WebGPU logra superar a PyTorch MPS nativo. Eso sí que es un golazo.

Los benchmarks concretos: qué se midió exactamente

El sitio gpubench.dev tiene tres pruebas que vos mismo podés ejecutar en tiempo real desde tu navegador. La idea es que no tengas que confiar en capturas de pantalla o papers — corrés el benchmark en tu hardware y ves el resultado. Esto se conecta con lo que analizamos en plataformas IA populares.

Benchmark 1: Rastrigin (POP=4096, DIM=2000)

Evalúa una función matemática costosa (Rastrigin es una función de optimización) en 4096 individuos, cada uno con 2000 parámetros. Lo interesante acá es que es embarrassingly parallel: cada evaluación es independiente, lo que es perfecto para GPU. La versión PyTorch dispatch-por-paso es lenta porque manda 4096 tareas a la GPU secuencialmente. La versión WebGPU con kernel fusion manda todo junto.

Benchmark 2: Simulación financiera fused (POP=10000, 1000 timesteps)

Aquí es más interesante todavía. Corrés una simulación de 1000 pasos de tiempo sobre 10000 agentes (o portfolios, depende cómo lo veas). Eso es 10 millones de iteraciones. En PyTorch, si lo hacés step-by-step, cada paso es un dispatch nuevo. En WebGPU, fusionás todo en un shader que hace todos los 1000 timesteps dentro de un único compute invocation. Los 159× de speedup salen de acá.

Benchmark 3: Multiplicación de matrices paralela (16×16)

Benchmark clásico de throughput. Mide cuántas multiplicaciones 16×16 podés hacer por unidad de tiempo. Acá también ganás porque evitás el overhead de múltiples dispatches.

El paper: kernel fusion como la técnica clave

Gunaydin publicó en marzo de 2026 (bajo DOI 10.5281/zenodo.19331834) el paper técnico: “Single-Kernel Fusion for Sequential Fitness Evaluation via WebGPU Compute Shaders.” Lo que documenta es la diferencia brutal entre despachar operaciones de una en una versus compilarlas en un único kernel.

En PyTorch, si vos iterás un bucle en CPU y mandas cada iteración a GPU, pagás un costo de context-switch por cada mando. El shader se compila, se configura, corre 4 nanosegundos de lógica, se apaga, vuelve a compilarse, y así. En WebGPU con fusion, compilás la lógica de los 1000 pasos en un shader único, lo mandás una sola vez, y la GPU lo ejecuta todo en bloque. Sin overhead entre pasos. Más contexto en arquitectura de los modelos GPT.

Lo que no es sarcasmo: Chrome tiene 48% de overhead sobre Metal nativo. Eso significa que si corrés el mismo código JavaScript en Chrome versus compilado en Swift nativo en macOS, Chrome es 1.48× más lento. Dicho esto, (y esto es lo importante) WebGPU todavía supera a PyTorch MPS, que es lo “nativo” de GPU en macOS. Dibujate el triangulo mentalmente: Chrome is overhead pero WebGPU bate a la alternativa nativa en PyTorch.

Por qué esto cambia el juego

Hasta ahora, si querías algoritmos de optimización paralela (algoritmos genéticos, particle swarms, simulaciones de monte carlo) tenías que eligir entre: (a) correr lentamente en CPU, (b) bajar Python, instalar CUDA o Metal, debuggear dependencias, (c) usar un servicio en la nube y pagar por GPU-hours.

Con esto, escribís JavaScript, compilás el shader compute, y corrés 159× más rápido que la alternativa obvia (PyTorch per-step). El usuario no baja nada. No hay servidor. Es local, es reproducible, es transparent.

Para machine learning research, eso es importante. Para startups que armaban cobrar por “optimización en la nube”, menos. Para educación, es enorme — de repente podés enseñar algoritmos genéticos y particle swarms con visualización interactiva sin que el estudiante tenga que instalar toolchains de GPU.

Limitaciones y lo que falta

Esto no quiere decir que WebGPU sea listo para producción en todo. Algunas cosas que están confirmadas: Relacionado: modelos IA de Google.

Primero, es optimizaciones de núcleo muy específico. Los 159× son para problemas que son massively parallel y donde el overhead de dispatches es el cuello de botella. Si tu problema es “una red neuronal con dos layers”, no ves ese speedup porque el overhead de dispatches ya es minúsculo comparado con la lógica del shader.

Segundo, soporte de browser. WebGPU es estándar, pero adoption es lenta. Chrome lo soporta, Edge igual (porque es Chromium). Safari tiene soporte experimental. Firefox todavía está en desarrollo.

Tercero, la API es más baja que PyTorch. No hay autograd. Vos escribís shaders manualmente. Eso significa más código, más chance de bugs, y que no es plug-and-play para modelos pre-entrenados.

Errores comunes si probás esto

Error 1: Pensar que 159× speedup aplica a cualquier problema

No. Si tu shader es simple o el overhead de dispatches es chiquito, no ves ese número. Los 159× son específicos de este patrón: muchas evaluaciones independientes, poca lógica por evaluación. Benchmark cherry-picked, pero honesto.

Error 2: Ignorar el overhead del navegador

Chrome tiene 48% overhead versus Metal nativo. Eso no es nada, pero tampoco es cero. Si vos escribís un shader que rinde 100 TFLOPS en Metal, en Chrome va a rendir más o menos 67 TFLOPS. La gente se sorprende. Cubrimos ese tema en detalle en entrenar modelos de lenguaje grandes.

Error 3: Escribir shaders mal e intentar debuggearlos en producción

Shader compilation es un black box. El error message dice “compilation failed” y vos no sabés si es syntax, si es un typo en el type, o si es que la GPU no soporta esa operación. Debuggear en local, testa con datos chiquitos, y recién después deployá.

Preguntas Frecuentes

¿Puedo usar esto para entrenar redes neuronales?

Técnicamente sí, pero no es lo ideal. WebGPU no tiene autograd (diferenciación automática), así que tenías que implementar backprop manualmente o escribir los gradientes en shaders. PyTorch/JAX lo hacen de forma abstracta. Para inference de modelos pequeños está bien, para training desde cero es tedioso.

¿Necesito instalar algo para correr esto?

No. Entras a gpubench.dev en Chrome o Edge, clickeás “Run”, y listo. Corre en tu GPU local del navegador. Sin Python, sin CUDA, sin overhead de instalación. Eso es el punto.

¿Qué hardware necesito?

Una GPU relativamente reciente. Las benchmarks corren en RTX, RX, Apple Silicon, incluso iGPUs viejas. La prueba anónima que gpubench.dev hace es exactamente para ver qué GPUs hay en el salvaje y cómo rinden. No hay requisito mínimo duro, pero menos que 2 años atrás empieza a sufrir.

¿Esto significa que PyTorch está muerto?

No. PyTorch es un ecosistema. Tiene autograd, pretrained models, comunidad, papers. WebGPU es una técnica de optimización para un patrón específico. Son cosas diferentes. Dicho esto, si vos diseñás en JavaScript y tu problema es embarrassingly parallel, WebGPU te da un camino que antes no tenías.

¿Qué tan reproducible es? ¿Puedo confiar en los números?

El paper está publicado formalmente (DOI citado), los benchmarks son reproducibles en vivo (entras al sitio y corrés), y el código es abierto. Más reproducible que eso es difícil. Lo único que falta es que otros equipos lo repliquen en configuraciones distintas, pero los datos actuales son sólidos.

Conclusión

WebGPU con kernel fusion logró romper un techo que parecía imposible: un navegador ejecutando código GPU 159× más rápido que la alternativa obvia en CPU. El overhead del navegador existe (48%), pero incluso con ese handicap, supera a PyTorch MPS nativo. Es específico para problemas embarazingly parallel con muchas evaluaciones pequeñas independientes, no es solución universal. Pero para algoritmos genéticos, simulations de Monte Carlo, particle swarms, y problemas de optimización, esto abre una puerta que no existía antes: desarrollo en JavaScript, ejecución local en GPU, sin instalación de toolchains.

Lo que hace falta ahora es que browsers no-Chromium (Firefox, Safari en modo no-experimental) terminen de soportar WebGPU completamente. Y que alguien arme librerías de más alto nivel que abstracten los shaders. Una vez que tengas eso, la curva de adopción de WebGPU va a acelerar. Ponele que marzo 2026 es la fecha en que el paper se publica, pero el mundo todavía no se enteró. Fijate en gpubench.dev, corre un benchmark vos mismo, y sacá conclusiones.

Fuentes

• WebGPU Bench — How fast is your GPU in the browser? — Benchmarks en vivo de WebGPU vs PyTorch, con datos anónimos de hardware real
• Gunaydin, A.B. (2026) — Single-Kernel Fusion for Sequential Fitness Evaluation via WebGPU Compute Shaders — Paper técnico con metodología, resultados de 159× speedup y análisis de overhead de navegador