WebGPU: la IA en el navegador, en vuestra GPU
Cómo un sitio web puede ejecutar un modelo de lenguaje en el dispositivo de quien lo visita, sin instalaciones y sin una llamada a la nube por cada palabra generada. Abrís una página, aparece una barra de progreso que tarda unos minutos en completarse y, a continuación, un cuadro de texto. Escribís y el modelo responde. Sin programas que instalar, sin claves que pegar, sin servidores remotos generando palabras: el trabajo lo realiza la tarjeta gráfica del ordenador que tenéis delante, dirigida por una página web. En la siguiente visita, la barra apenas se ve, porque los pesos del modelo se han guardado en el disco, en un espacio que el navegador reserva para ese sitio.
El protagonista de esta escena se llama WebGPU, y conviene aclarar de inmediato qué no es. No es un modelo, no es un formato de archivo, no es un programa que instalar. Es una interfaz que el navegador ofrece a las páginas web para comunicarse con la tarjeta gráfica, tanto para renderizar gráficos como para realizar cálculo paralelo de propósito general, definida por la especificación del W3C. Descargar los pesos, conservarlos, traducir el texto a números y viceversa corresponde a otras piezas de la cadena. Este artículo las analiza todas en orden, con las cifras disponibles hoy y una mirada honesta a sus límites.
La GPU entra en el navegador
Para entender por qué la tarjeta gráfica es fundamental para la inteligencia artificial, ayuda la imagen de una cocina. El procesador es un chef experimentado que prepara un plato cada vez con gestos perfectos. La GPU es una cocina con miles de ayudantes, cada uno capaz de una sola operación sencilla, pero todos trabajando exactamente al mismo tiempo. Un modelo de lenguaje dedica su tiempo a multiplicar tablas de números, una tarea que se divide en millones de cálculos independientes: es la jornada ideal para la brigada de cocina, no para el chef.
Sin embargo, durante años los navegadores solo sabían comunicarse con la GPU principalmente para dibujar gráficos. Con WebGL, quien quería usarla para otros cálculos debía disfrazar los números de píxeles y las operaciones de efectos gráficos. WebGPU cambia este enfoque, ya que añade a los gráficos los compute shaders: pequeños programas escritos en un lenguaje llamado WGSL que la GPU ejecuta para cualquier cálculo, no solo para colorear triángulos.
Entre la página web y el silicio discurre una red de conductos no muy distinta de la de Brazil, la película de Terry Gilliam en la que cada solicitud atraviesa oficinas y tuberías antes de surtir efecto. El sitio habla WebGPU y el navegador lo traduce a Metal en Apple, Vulkan en Linux y Android, o DirectX en Windows; de ello se encargan distintos motores: Dawn en los navegadores basados en Chromium, wgpu en Firefox, y una implementación propia de WebKit en Safari, tal como describe el preprint analizado más adelante.
El hito que hace oportuno hablar de ello hoy es la cobertura entre navegadores. Como recuerda web.dev, Chrome y Edge admiten WebGPU desde la versión 113 en Windows, macOS y ChromeOS, mientras que en Android se requiere Chrome 121 y al menos Android 12. Firefox lo ofrece en Windows desde la versión 141 y en Mac con procesador ARM desde la 145; Safari lo introdujo con la versión 26 en todos los sistemas Apple. Las notas de Khronos sitúan Firefox en Windows en julio de 2025 y Safari en septiembre de 2025, añadiendo que Chromium amplió la compatibilidad en Linux a las GPU Intel de 12.ª generación y posteriores en enero de 2026. Se quedan rezagados Firefox en Linux y Android, aún en desarrollo según web.dev. Quienes desarrollan deben, por tanto, prever un plan de contingencia para quienes no figuren en estas listas.
Del flujo de descarga a los tokens
El recorrido de la IA en el navegador sigue una secuencia precisa. La página verifica que WebGPU exista y que la GPU sea adecuada; a continuación, descarga el modelo desde un servidor o una red de distribución de contenidos (CDN), lo conserva en el espacio del navegador y lo carga en la memoria gráfica. Cuando escribís, el texto se divide en tokens (fragmentos de palabras), los cálculos se ejecutan en la GPU mediante WebGPU y los tokens generados se recomponen en frases. Un detalle que a menudo se pasa por alto: WebGPU no descarga nada ni guarda nada, solo realiza el cálculo. El resto corresponde a las interfaces habituales de red y almacenamiento del navegador.
Librerías de JavaScript se encargan de ensamblar las piezas. WebLLM, nacido del proyecto MLC, ofrece una interfaz similar a las API de OpenAI y utiliza WebGPU para la tarjeta gráfica y WebAssembly para las tareas de la CPU. Transformers.js se apoya en ONNX Runtime, y wllama lleva al navegador los modelos de llama.cpp, creado originalmente para ejecutarse en CPU y dotado hoy de un motor secundario en WebGPU. La publicación de web.dev ya citada confirma que tanto ONNX Runtime como Transformers.js aprovechan WebGPU para la inferencia local.
En el cómputo interno se distinguen dos fases, y la diferencia es relevante. En la fase de prefill, el modelo lee todo el prompt de una vez, dominado por multiplicaciones entre matrices. En la fase de decode, produce un token cada vez, pasando el trabajo a multiplicar matrices por vectores. Las mediciones del preprint en un Apple M3, con un modelo de mil millones de parámetros comprimido a cuatro bits, muestran que las primeras ocupan el 92,6 por ciento del tiempo de prefill y las segundas el 89,9 por ciento del decode. El decode, además, está limitado principalmente por la velocidad de lectura de los pesos en la memoria, razón por la cual comprimirlos ayuda: se mueven menos bytes.
Aquí radica la diferencia entre acceso y rendimiento. WebGPU, señala el preprint, ofrece portabilidad funcional pero no portabilidad de rendimiento: el mismo código se ejecuta en todas partes, pero no a la misma velocidad en todas partes. Se requieren pesos comprimidos, cálculos optimizados para cada familia de GPU y una gestión cuidadosa de la memoria. En el primer inicio existe además un coste único: la compilación de programas para la GPU, que los autores estiman entre uno y cinco segundos.
Dónde se guardan los pesos
Tras la descarga, los pesos no desaparecen. La guía de Chrome sobre conservación de modelos recuerda su volumen: un archivo de 1,35 gigabytes, como una versión comprimida de Gemma 2B, se considera extremadamente pequeño para un modelo de lenguaje. Para mantenerlos en el dispositivo existen tres vías: la Cache API, el Origin Private File System y IndexedDB. El equipo de Chrome recomienda en general la primera y considera IndexedDB la peor opción para archivos grandes.
No se trata, por tanto, de un archivo que buscar en una carpeta común. El Origin Private File System es, según la misma guía, privado para el sitio e invisible para el usuario. Esto no significa que el contenido tenga un formato exótico: wllama, por ejemplo, conserva en ese espacio archivos en formato GGUF de llama.cpp, tal como relata el preprint. Simplemente no se ven desde el explorador de archivos del sistema operativo.
Cerrar la pestaña libera la memoria del sistema y la memoria de vídeo, pero los archivos permanecen en el disco. Cerrar el navegador no cambia nada: en la siguiente visita, el sitio puede volver a cargar el modelo desde la copia local. Su eliminación ocurre únicamente desde la configuración del navegador o por acción del propio navegador si el sitio no solicitó almacenamiento persistente y el espacio en disco escasea.
Cada sitio dispone de su propio espacio aislado. Las preguntas frecuentes de webllm.io, un kit de desarrollo independiente que se apoya en el motor de MLC y que no debe confundirse con el proyecto original, precisan que los modelos están aislados por origen, siendo inaccesibles para otros sitios y eliminables desde los ajustes, con descargas de entre 1,5 y 4,5 gigabytes según la potencia del dispositivo. De ello se deduce que el mismo modelo descargado desde dos sitios distintos ocupará espacio dos veces. El navegador se asemeja al castillo ambulante de Howl, la estructura de Miyazaki que camina llevando consigo multitud de puertas, cada una abierta a un lugar distinto y con su propia llave.
Quién paga el cálculo
Llegamos al aspecto económico. Si la inferencia ocurre en el dispositivo, el proveedor distribuye el modelo como un archivo estático y deja el consumo eléctrico, el calor y el tiempo de proceso a quien utiliza el servicio. Es un razonamiento lógico y no una medición directa, pero resulta sólido: cada sesión local es una sesión menos que facturar a un proveedor de GPU en la nube. Los autores del preprint señalan que la ejecución local puede mejorar la latencia y la eficiencia energética, citando estudios de terceros, lo que deja abierta una cuestión sin respuesta definitiva: ¿el balance energético global, entre unos pocos centros de datos y millones de portátiles, mejora realmente?
El servidor, en cualquier caso, no desaparece. Sigue siendo propietario de la página, las cuentas, las actualizaciones y los archivos del modelo. Y esos archivos pesan: el coste de ancho de banda para entregar varios gigabytes a cada nuevo visitante no se evapora, sino que se desplaza del cálculo a la transferencia de datos. No es casualidad que la documentación de webllm.io describa una arquitectura híbrida, con derivación a la nube cuando falta WebGPU o la tarjeta resulta insuficiente. El mismo texto advierte que la ejecución local requiere encabezados de aislamiento (COOP y COEP) porque utiliza memoria compartida, un requisito de configuración en el servidor que puede afectar a recursos externos incluidos en la página.
¿Quién gana y quién pierde en este escenario? Son hipótesis de trabajo. Ganan los proveedores de servicios ligeros que reducen su factura en la nube, los usuarios con tarjetas potentes que obtienen respuestas inmediatas y privacidad local, y los fabricantes de GPU, para quienes la memoria de vídeo se convierte en un argumento de venta. Pierden los usuarios con hardware antiguo, relegados a la nube o a una experiencia lenta, y los proveedores de infraestructura gráfica que dependen de la inferencia ligera.
Límites con las cifras en la mano
Los datos empíricos más completos disponibles hoy proceden del preprint Llamas on the Web, publicado en arXiv en mayo de 2026 por investigadores de la Universidad de California en Santa Cruz y Microsoft Research. Debe leerse con dos aclaraciones: es un trabajo pendiente de revisión por pares y los autores son los mismos que desarrollaron el motor de WebGPU para llama.cpp, por lo que evalúan su propio código. No obstante, el volumen de datos es notable: dieciséis dispositivos de ocho fabricantes, diez modelos y unas veinticinco horas de pruebas automatizadas.
El primer resultado ofrece una cura de realidad para quienes esperan milagros. Frente a los motores nativos de llama.cpp, WebGPU se queda claramente atrás en hardware dedicado: CUDA y Vulkan nativos lo superan por hasta 10 veces en prefill y 2,5 veces en decode, gracias al uso de núcleos tensor e instrucciones matriciales específicas del fabricante. En Apple Silicon, Metal nativo supera a WebGPU por más del doble en prefill y un 50 por ciento en decode. Pero el panorama no es unilateral: en Mac, WebGPU supera a Vulkan traducido vía MoltenVK hasta en un 59 por ciento en prefill y un 45 en decode; y en una tarjeta AMD, Vulkan nativo se queda por detrás de WebGPU por 3 veces en prefill, aunque supere a HIP nativo en decode. En GPU Intel, WebGPU supera a SYCL en un 23 por ciento en prefill, pero solo con las comprobaciones de seguridad desactivadas, una condición artificial en la navegación web real.
Esas comprobaciones de seguridad tienen un precio. Los compiladores de WebGPU inyectan verificaciones para evitar accesos fuera de límites de memoria y divisiones por cero. Al desactivarlas en las pruebas, se observa un impacto medio del 14 por ciento en prefill para modelos comprimidos y del 23 por ciento en precisión completa (alcanzando hasta un 42 por ciento en una RTX 5080), mientras que en decode el impacto oscila entre el 1 y el 5 por ciento. Es el precio del entorno aislado (sandbox): una página web nunca debe poder leer memoria fuera de sus límites asignados.
Por otra parte está WebLLM. Su artículo sostiene que puede mantener hasta el 80 por ciento del rendimiento nativo, mientras que el blog de MLC habla de hasta el 85 por ciento respecto a Metal en un MacBook Pro M3 Max con ambos motores compilados mediante la misma herramienta. No contradicen el preprint de Santa Cruz: evalúan frente a bases distintas y deben compararse con cautela.
Entre los motores de ejecución en navegador, las comparaciones del preprint favorecen al desarrollo de los autores frente a las alternativas. Su implementación genera texto entre un 45 y un 69 por ciento más rápido en decode en cuatro GPU de distintos fabricantes, utilizando entre un 29 y un 33 por ciento menos de memoria. Sin embargo, en prefill se queda atrás (entre un 21 y un 51 por ciento más lento) porque las instrucciones matriciales más rápidas, llamadas subgroup matrix, no están habilitadas en las versiones estables de los navegadores. Para WebLLM y Transformers.js, los autores señalan además picos de consumo de VRAM cercanos a los 10 gigabytes en ciertas configuraciones, atribuidos a posibles fugas de memoria.
En dispositivos móviles el margen es más estrecho. En un iPhone, una pestaña de Safari dispone de menos de 500 megabytes de memoria útil, y las GPU más modestas en iOS y Android solo pudieron ejecutar los cuatro modelos más pequeños del banco de pruebas, alcanzando entre 4 y 17 tokens por segundo en decode. En GPU móviles de gama alta, los modelos pequeños superan los 3.000 tokens por segundo en prefill y los 100 en decode, mientras que el modelo más grande probado (un Gemma 4 de unos 3 gigabytes) cae a 65 y 30 tokens por segundo.
La elección del navegador también introduce variaciones enormes. En un Mac con chip M3, el mismo modelo genera ~1 token por segundo en Firefox frente a los ~52 tokens por segundo en Chrome; los autores excluyeron Firefox de las pruebas principales por este motivo. Aunque es un dato puntual y no una norma universal, demuestra que "compatibilidad con WebGPU" no equivale a "rendimiento equivalente a Chrome".
Por último, influyen las limitaciones del lenguaje WGSL. Actualmente carece de soporte nativo para tipos bf16, int8, int16 e int4 que las GPU modernas ejecutan directamente, obligando a su emulación. Esto genera un efecto contraintuitivo documentado en el preprint: en WebGPU, la compresión de pesos sirve principalmente para ajustar el modelo a la memoria disponible y no para acelerar el cálculo; reducir de 4 a 2 bits en hardware de gama media disminuye la velocidad de decode en un 17 por ciento.
Privacidad con matices
La privacidad es la ventaja más destacada de WebGPU, siendo real pero condicionada. Conviene separar tres afirmaciones que el material promocional suele mezclar. La primera es que el cálculo se realiza localmente: WebGPU lo garantiza totalmente. La segunda es que la aplicación web no envía prompts, respuestas o telemetría a servidores externos: esto depende exclusivamente del desarrollador del sitio, no de la API. La documentación de webllm.io, por ejemplo, asegura que en modo estrictamente local no se transmiten datos de inferencia, pero el mismo producto incluye modos de respaldo en la nube, haciendo que la privacidad dependa de la configuración. Si la entrada del usuario se reenvía a servicios externos de búsqueda, moderación o registro, las garantías locales desaparecen.
La tercera es que el propio modelo esté protegido contra la extracción: en este caso, la respuesta es negativa. La guía de Chrome advierte que los pesos almacenados en la Cache API o en OPFS se pueden extraer fácilmente mediante las herramientas de desarrollo del navegador, y el cifrado no lo resuelve porque la clave debe entregarse inevitablemente al cliente. Quien necesite proteger pesos propietarios debe mantener el modelo en el servidor.
¿Navegador o ejecución nativa?
¿Dónde reside entonces la ventaja? Depende de los objetivos, tal como sintetiza la siguiente tabla.
Ambas opciones se aproximan progresivamente: el motor WebGPU de llama.cpp se incorporó al proyecto principal mediante más de cien contribuciones de la comunidad, llevando los modelos GGUF directamente al navegador. Los estándares web también evolucionan: las actualizaciones de Khronos destacan extensiones de subgrupos integradas en Chrome 144 y 145, independientes de las instrucciones matriciales previstas posteriormente. Las API de IA integradas de Chrome (Prompt, Summarizer, Translator), detalladas en su documentación oficial, ofrecen otra vía: modelos proporcionados por el propio navegador a los sitios web, en lugar de sitios que distribuyen sus propios pesos. Cómo coexistirá esta vía con WebGPU sigue siendo una cuestión abierta.
Vuestro PC como servidor
La primera conclusión es prudente: para obtener la máxima velocidad, ejecutar modelos masivos y mantener un control absoluto, WebGPU no sustituye a llama.cpp ni a LM Studio. Los datos demuestran que los motores nativos lideran la fase de prefill hasta por un factor de 10x, mientras que los dispositivos móviles solo gestionan modelos reducidos. La segunda conclusión es mucho más interesante: por primera vez, los principales navegadores se comunican directamente con la GPU, haciendo viable un nuevo modelo de distribución: una URL, una descarga inicial del modelo y el cálculo ejecutado íntegramente en la máquina del usuario.
Persisten desafíos: la fragmentación entre navegadores y controladores, la sobrecarga del entorno aislado, la disponibilidad de instrucciones matriciales de subgrupo en versiones estables y el impacto energético global de millones de GPU cliente frente a centros de datos centralizados. En resumen: WebGPU no transforma el navegador en un servidor de IA, sino en un entorno seguro donde vuestro propio ordenador se convierte en el servidor de vuestra IA.
Nota técnica: los datos de rendimiento proceden de un preprint no revisado por pares correspondiente a versiones de software de mayo de 2026. Las implementaciones de navegadores y motores evolucionan rápidamente; se recomienda verificar las cifras antes de utilizarlas en entornos de producción.