Ejecutar LLM en el navegador con WebAssembly y WebGPU

Abre una página web sin instalar nada, sin cuenta y sin conexión a ningún servidor de IA, y empieza a chatear con un bot cuyas respuestas se generan por completo en tu propio portátil. Nada sale de tu equipo, no hay factura de API y puedes desenchufar el cable de red justo después de que cargue la página sin que el chatbot lo note.

No es una visión para dentro de cinco años. Funciona hoy, en la misma pestaña que usas para el correo. Lo hacen posible dos tecnologías que suelen tratarse por separado aunque juntas son mucho más potentes: WebAssembly y WebGPU.

Si pasas la mayor parte del día con JavaScript, quizá esos nombres te suenen a motores de videojuegos o a cosas del equipo de gráficos. En realidad están cambiando lo que es un navegador: de un simple renderizador de páginas a una plataforma para cómputo real y, cada vez más, para inferencia de IA local.

Por qué JavaScript necesita ayuda

JavaScript cumple bien con aquello para lo que se creó: manipular el DOM, gestionar eventos y llevar la lógica de la aplicación. Pero dale algo realmente pesado, como decodificar vídeo, procesar imágenes, simular física o ejecutar una red neuronal, y empiezan a verse las grietas. La recolección de basura y el tipado dinámico hacen que el lenguaje sea cómodo de escribir, y también pasan factura cuando cada milisegundo de CPU cuenta.

La respuesta habitual solía ser mandar el trabajo pesado a un servidor. Subes la imagen, se procesa en remoto, descargas el resultado. Ese patrón tiene un coste. La factura del servidor crece con cada usuario nuevo, la latencia de red hace que la interfaz se sienta lenta y los datos del usuario tienen que salir de su dispositivo, lo que ya es un problema de privacidad en sí.

WebAssembly y WebGPU no sustituyen a JavaScript. Le dan al navegador una potencia que nunca tuvo.

WebAssembly en pocas palabras

Wasm, abreviatura de WebAssembly, define un formato binario compacto que ejecuta una máquina virtual basada en pila. La idea es ofrecer a los lenguajes de alto nivel un destino de compilación portable, para que las aplicaciones web se acerquen a la velocidad nativa.

Nunca se pensó solo para la web. Se ejecuta en un sandbox con memoria segura y, cuando está incrustado en una página, respeta las políticas same-origin del navegador, pero también puede funcionar en entornos que no tienen nada que ver con la web.

En la práctica, el flujo es así:

• Partes de C, C++, Rust o cualquier lenguaje que tenga un compilador compatible con Wasm.
• Se compila a un archivo .wasm, que es bytecode binario y no JavaScript, mucho más cercano al lenguaje máquina.
• El navegador ejecuta ese bytecode en su propio sandbox, a velocidades que el JavaScript compilado con JIT no alcanza.
• Wasm llama a JavaScript y viceversa, así que no reescribes toda la aplicación: solo trasladas las partes pesadas.

Figma usa Wasm en su motor de renderizado, y esa es una de las grandes razones por las que editar diseños en el navegador resulta tan fluido como en una aplicación de escritorio. La versión web de Google Earth también funciona con él, y varios motores de juego de nivel AAA pueden exportar directamente a Wasm.

Lo que conviene retener es que Wasm se ocupa del cómputo. Acelera la lógica pesada, pero no da acceso directo a la GPU. Para el paralelismo masivo y los gráficos hace falta otro compañero.

WebGPU, el sucesor de WebGL

Si has trabajado con WebGL, WebGPU es su sucesor, y es más que una mejora incremental. Se diseñó desde cero para corresponderse con las API de GPU modernas, como Vulkan, Metal y Direct3D 12. WebGL, en cambio, envuelve el ya veterano OpenGL ES.

La documentación de MDN describe la API como una forma de que los desarrolladores web usen la GPU del sistema para cómputo de alto rendimiento y para renderizar gráficos complejos en el navegador. Las diferencias con WebGL son profundas:

• WebGL se construyó en torno a dibujar en un canvas y nunca se le dio bien el cómputo de propósito general en GPU (GPGPU).
• WebGPU trata los compute shaders como ciudadanos de primera, no como un añadido de última hora.
• Ofrece control de bajo nivel mediante conceptos como GPUAdapter, GPUDevice y GPUQueue, mucho más cerca de las API gráficas nativas.
• Como se corresponde directamente con las API de GPU modernas, su sobrecarga es muy inferior a la de WebGL, que lo traduce todo a través de una vieja capa de OpenGL.

El efecto práctico es que una GPU que antes solo servía para renderizar escenas 3D en juegos de navegador puede usarse para mucho más: entrenar modelos pequeños, ejecutar inferencia de redes neuronales, procesar imágenes en paralelo y correr grandes simulaciones físicas, todo mediante compute shaders en el navegador.

Dos capas que encajan

Es fácil pasar por alto que Wasm y WebGPU no compiten. Se complementan.

• Wasm se encarga de la orquestación y de la lógica pesada en la CPU. Eso incluye analizar el modelo, tokenizar, gestionar la memoria y todo el código complejo que las herramientas de machine learning suelen escribir en C++ o Rust.
• WebGPU se encarga de la ejecución masivamente paralela. Es decir, las enormes operaciones matriciales que forman el núcleo de cualquier red neuronal y que solo con la CPU irían a paso de tortuga.

Juntas hacen técnicamente viable un LLM dentro de una pestaña del navegador. Sin WebGPU, el modelo sería desesperadamente lento en la CPU. Sin Wasm, la lógica del runtime sería difícil de optimizar en JavaScript puro.

WebLLM como ejemplo real

Una de las demostraciones más claras es WebLLM, del equipo de MLC AI. Es un motor de inferencia de LLM dentro del navegador, acelerado con WebGPU y sin ningún servidor. Además es totalmente compatible con el formato de la API de OpenAI, así que si ya llamas a chat.completions, casi no hay nada nuevo que aprender. Un uso simplificado sería así:

import { CreateMLCEngine } from "@mlc-ai/web-llm";

// Callback to track model download & loading progress
const initProgressCallback = (progress) => {
  console.log(progress.text);
};

// A small model already compiled into MLC format
const selectedModel = "Llama-3-8B-Instruct-q4f32_1-MLC";
async function main() {
  const engine = await CreateMLCEngine(selectedModel, {
    initProgressCallback,
  });
  const reply = await engine.chat.completions.create({
    messages: [
      { role: "user", content: "Explain WebGPU in one sentence" },
    ],
  });
  console.log(reply.choices[0].message.content);
}

main();

Esto es lo que ocurre entre bastidores:

• CreateMLCEngine descarga los pesos del modelo, ya comprimidos y cuantizados, junto con la biblioteca Wasm que contiene la lógica de inferencia.
• La capa Wasm tokeniza, gestiona el contexto de la conversación y orquesta todo el proceso de inferencia.
• Las pesadas operaciones matriciales que forman el corazón de cada forward pass se ejecutan como compute shaders de WebGPU, aprovechando el paralelismo de la GPU de tu dispositivo.
• Todo se queda dentro del sandbox del navegador, así que ni los prompts ni los datos del usuario salen del dispositivo.

El resultado es un chatbot privado por defecto, que funciona sin conexión una vez que el modelo está en caché y que no carga un servidor que de otro modo tendrías que pagar. Desarrolladores independientes y equipos pequeños pueden lanzar funciones de IA sin una factura de GPU en la nube que se dispara con el tráfico.

Más allá de los modelos de lenguaje

Wasm junto con WebGPU llega mucho más lejos que los LLM. Otras áreas ya lo aprovechan:

• Procesamiento de imagen y vídeo: filtros complejos, eliminación de fondo y escalado que antes requerían un viaje al servidor ahora se ejecutan en tiempo real en el cliente.
• Visión por computador: detección de objetos o reconocimiento facial directamente desde la cámara, sin que ningún flujo de vídeo salga del dispositivo.
• Ciencia de datos interactiva: cálculos numéricos intensos al estilo de NumPy dentro de notebooks en el navegador.
• Juegos y simulaciones 3D: tanto Unity como Unreal están incorporando la exportación a WebGPU, lo que acerca mucho el renderizado en el navegador a lo que ofrecen las versiones nativas.
• CAD y diseño 3D en el navegador: manipular modelos 3D complejos sin software de escritorio.

Límites que hay que prever

Antes de convertir cada backend de IA en uno del lado del cliente, ten en cuenta estas limitaciones:

• El soporte en navegadores no es universal. WebGPU viene activado por defecto en Chrome, Edge y las versiones recientes de Safari, pero en Firefox sigue siendo experimental y hay que activarlo con un flag.
• La primera descarga puede ser grande. Incluso un modelo pequeño tiene que llegar antes al navegador del usuario, así que cuida esa primera experiencia, normalmente con un indicador de progreso claro.
• El hardware sigue mandando en el rendimiento. Un portátil de oficina con gráficos integrados no se acerca a una GPU dedicada de gama alta, así que elige un modelo acorde con tu público real.
• La depuración cambia. Ya no persigues fallos en una lógica de servidor que controlas. Depuras código que se ejecuta en una variedad enorme e impredecible de dispositivos cliente.

Nada de esto es motivo para evitar la tecnología. Solo recuerda que ejecutar en el cliente también exige una arquitectura bien pensada.

Por qué este impulso parece distinto

Muchas tendencias web se desvanecen, pero en esta casi todos los grandes fabricantes de navegadores reman en la misma dirección. Google, Apple, Microsoft y Mozilla desarrollan juntos estos estándares en el W3C, así que no es la apuesta de un único proveedor que podría abandonarse sin hacer ruido.

La frontera entre aplicación web y aplicación nativa sigue difuminándose. Un navegador que antes solo mostraba documentos ahora puede con cómputo serio e incluso con inferencia de IA, sin instalación, sin servidor adicional y con una privacidad notablemente mejor, porque los datos del usuario nunca tienen que salir del dispositivo.

Si hasta ahora veías Wasm y WebGPU como un terreno gráfico de nicho, prueba un pequeño experimento. Carga un modelo compacto con WebLLM en un proyecto personal y comprueba qué se siente al tener una IA que funciona en tus propias manos y no en el servidor de otro. Como siguientes pasos, el código está en el repositorio de WebLLM, el estándar en webassembly.org y, como referencia, la página de la API WebGPU en MDN.