🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

Este artículo revela que la sobrecarga de despacho de WebGPU, en lugar de la calidad del kernel, es el cuello de botella principal para la inferencia de LLM de lote único en navegadores, demostrando que las mediciones simples sobreestiman los costos debido a la confluencia de sincronización y concluyendo que reducir el recuento de despachos mediante la amortización es la estrategia de optimización más efectiva.

Autores originales: Jędrzej Maczan

Publicado 2026-08-11

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Jędrzej Maczan

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando ejecutar un videojuego masivo y complejo en una computadora, pero tienes que hacerlo a través de un gerente muy estricto y consciente de la seguridad que no te deja tocar el hardware directamente. Este es el mundo de ejecutar Inteligencia Artificial (específicamente Modelos de Lenguaje Extensos, o LLM) dentro de un navegador web. Estos modelos son los cerebros detrás de los chatbots que pueden escribir historias, resolver matemáticas y mantener conversaciones. Para hacer que funcionen rápido en tu laptop o teléfono sin necesidad de una supercomputadora, los desarrolladores usan una herramienta especial llamada WebGPU. Piensa en WebGPU como un traductor universal que le permite a tu navegador hablar con la tarjeta gráfica de tu computadora (la parte que usualmente renderiza videojuegos) para que pueda realizar las matemáticas pesadas de la IA.

Sin embargo, hay un inconveniente. En el pasado, cuando los desarrolladores intentaban hacer que estos modelos de IA fueran más rápidos, se enfocaban en hacer más eficientes los pasos matemáticos individuales (llamados "kernels"), como pulir el motor de un coche. Pero este artículo hace una pregunta diferente: ¿Qué pasa si el coche está bien, pero el conductor pierde demasiado tiempo subiendo y bajando del vehículo? En el mundo del navegador, cada paso matemático requiere un "dispatch" (un envío): una solicitud enviada desde el navegador a la tarjeta gráfica para comenzar a trabajar. El gran misterio era: ¿Cuánto tiempo se desperdicia realmente solo enviando estas solicitudes, frente al tiempo dedicado a hacer las matemáticas reales? Comprender esto es crucial porque si desperdiciamos demasiado tiempo solo pidiéndole a la computadora que trabaje, el chatbot se sentirá lento y pesado, sin importar qué tan inteligente sea la matemática.

El atasco de "parar y seguir"

El investigador en este artículo descubrió que todos habían estado midiendo la velocidad de estas solicitudes de IA de forma errónea. Imagina que estás cronometrando cuánto tiempo le toma a un repartidor entregar un paquete. Si cronometras desde que sale del almacén, conduce hasta la casa, deja el paquete y luego conduce de regreso al almacén para recoger el siguiente, estás midiendo el viaje completo de ida y vuelta. Pero en el mundo real de la IA, el conductor no regresa al almacén después de cada paquete. Deja toda una pila de paquetes de una sola vez, y solo regresa una vez al final.

El artículo muestra que las mediciones anteriores eran como cronometrar ese viaje completo de ida y vuelta por cada paquete. Estaban confundiendo el tiempo que toma enviar la solicitud (el dispatch) con el tiempo que se pasa esperando a que la computadora diga "Está bien, he terminado" (sincronización). Este "tiempo de espera" es enorme, como una pausa de 450 microsegundos. Cuando los investigadores agregaron este tiempo de espera a cada paso, pensaron que el costo de enviar una solicitud era aproximadamente 20 veces mayor de lo que realmente era.

Al utilizar un nuevo método llamado "dispatch secuencial", el autor logró calcular cómo cronometrar solo el acto de enviar la solicitud, sin la larga espera intermedia. Descubrieron que el costo real es mucho menor: entre 24–36 microsegundos en algunos sistemas (Vulkan) y 32–71 microsegundos en otros (Metal). Curiosamente, este costo es el mismo si la computadora usa números "float32" o "float16" (dos formas diferentes de almacenar números decimales), lo que demuestra que el retraso proviene de las reglas del navegador, no de la matemática en sí.

El verdadero cuello de botella: Demasiadas paradas

Una vez que supieron el costo real de una sola solicitud, el equipo se preguntó: "¿Realmente importa esto?". Para averiguarlo, realizaron un experimento controlado. Tomaron un modelo de IA estándar y cambiaron la forma en que se empaquetaba. En lugar de enviar 876 pequeñas solicitudes a la tarjeta gráfica para procesar una palabra de texto, "fusionaron" (pegaron) algunos de los pasos para que la tarjeta solo tuviera que recibir 564 solicitudes.

Aquí está la clave: no hicieron que la matemática dentro de las solicitudes fuera más rápida. No cambiaron el código para que fuera más inteligente o usara menos memoria. Simplemente redujeron la cantidad de veces que el navegador tenía que llamar a la puerta de la tarjeta gráfica.

El resultado fue: la IA fue un 53% más rápida. El tiempo que tomó generar la primera palabra de una respuesta cayó de 71.4 ms a 41.6 ms.

Este experimento demostió que, en la configuración más común (procesar una palabra a la vez, conocida como "tamaño de lote 1" o "batch size 1"), el mayor problema no es que la matemática sea demasiado lenta o que la memoria esté demasiado llena. El problema es simplemente que hay demasiados "llamados a la puerta". El autor descartó explícitamente la idea de que un mejor código matemático o un menor uso de memoria fuera la razón de la mejora de velocidad. Lo único que cambió fue el número de dispatches.

Qué significa esto para el futuro

El artículo concluye que, si queremos que los chatbots de IA funcionen con fluidez en los navegadores, debemos dejar de intentar perfeccionar cada paso matemático individual y empezar a enfocarnos en agruparlos. Es como darse cuenta de que, para que un camión de reparto llegue más rápido a una casa, no deberías solo hacer que el conductor corra más rápido; deberías simplemente asegurarte de que lleve una caja más grande para no tener que hacer tantos viajes.

El autor sugiere que la solución reside en la "amortización de dispatch" (dispatch amortization), una forma elegante de decir que necesitamos repartir el costo de esos "llamados a la puerta" sobre muchas tareas para que el retraso no afecte tanto. Señala que esto podría requerir cambios no solo en el software que ejecuta la IA, sino potencialmente en las propias reglas de WebGPU, quizás permitiendo que el navegador acepte un "grafo de comandos" (una ruta pre-planificada) en lugar de verificar cada paso individualmente.

Aunque estos hallazgos se basan en hardware específico (como la NVIDIA RTX 5090) y en una forma específica de ejecutar la IA, el mensaje es claro: por ahora, el secreto para una IA más rápida en tu navegador no es un motor más rápido; son menos paradas.

Resumen Técnico: Medición y Reducción de la Sobrecarga de Despacho en WebGPU para la Inferencia de LLM

Planteamiento del Problema

Los Grandes Modelos de Lenguaje (LLM) se están desplegando cada vez más en entornos de navegador y de borde (edge) utilizando WebGPU como un estándar multiplataforma. Mientras que la ingeniería de rendimiento existente para estos sistemas se centra en la cuantización, la optimización de kernels y la eficiencia de memoria, el coste del despacho de operaciones de WebGPU permanece insuficientemente caracterizado.

Se ha identificado un problema crítico: las mediciones de rendimiento estándar de "operación única" —cronometrar una sola operación de principio a fin— confunden el coste del propio despacho con el coste de la sincronización completa GPU-CPU. En la decodificación autorregresiva del mundo real, la sincronización ocurre solo una vez por token, no una vez por operación. En consecuencia, las mediciones de operación única sobreestiman el coste por despacho en aproximadamente 20 veces, ocultando el verdadero cuello de botella del rendimiento. Además, no está claro si las limitaciones de rendimiento en un tamaño de lote (batch size) de 1 se deben a la calidad del kernel (eficiencia del shader) o al mero número de despachos requeridos.

Metodología

El autor introduce un método de medición de despacho secuencial para aislar el coste marginal real de un solo despacho.

Medición Secuencial: En lugar de cronometrar una sola operación con sincronización inmediata, el método envía $N$ operaciones idénticas a la cola y realiza una única sincronización al final del proceso. El tiempo total se divide por $N$ , amortizando el coste de la sincronización de una sola vez y revelando el verdadero sobrecoste de despacho.
Experimento de Fusión Controlada: Para determinar el impacto del recuento de despachos frente a la calidad del kernel, el autor realizó un experimento de fusión de kernels. Fusionaron grupos de operaciones para reducir el recuento de despachos por pasada hacia adelante de 876 a 564. Crucialmente, los shaders WGSL subyacentes (lógica de computación) permanecieron sin cambios, y la reducción en el tráfico de memoria intermedia fue insignificante (<1.8 MB, <1 µs). Esta configuración aísla el recuento de despachos como la única variable.
Implementación: Las mediciones se realizaron utilizando torch-webgpu, un backend personalizado de PyTorch, a través de múltiples proveedores de hardware (NVIDIA, AMD, Apple, Intel) y backends (Vulkan, Metal, Dawn, wgpu).

Resultados Clave

1. Coste Real por Despacho

Utilizando el método secuencial, el autor midió el coste real por despacho, encontrando que es independiente del tipo de dato (float32 frente a float16):

Vulkan: 24–36 µs por despacho.
Metal: 32–71 µs por despacho.
Sobreestimación: Las mediciones de operación única sobreestiman estos costes en ~20x (por ejemplo, midiendo ~497 µs en Dawn, donde ~450 µs se atribuyen a la sincronización).

2. El Recuento de Despachos como el Cuello de Botella

El experimento de fusión controlada demostró que reducir el recuento de despachos mejora significamente el rendimiento sin alterar la calidad del kernel:

La reducción de despachos de 876 a 564 resultó en un incremento del 53% en el rendimiento (tokens por segundo).
El Tiempo hasta el Primer Token (TTFT) cayó de 71.4 ms a 41.6 ms.
Dado que la computación y el tráfico de memoria se mantuvieron constantes, el autor concluye que el recuento de despachos, y no la calidad del kernel, es el cuello de botella primario para la inferencia de LLM con un tamaño de lote de 1.

3. Desglose de la Sobrecarga

El análisis de los componentes de la sobrecarga de despacho reveló que la sumisión del búfer de comandos (command buffer submission) es el factor dominante:

Submit: ~12.9 µs (40% del tiempo total de CPU).
Encoder Create/Finish: ~12.5 µs combinados (39%).
Configuración de Pipeline/Bind Group: <1.5 µs cada uno.
Esto indica que el cuello de botella principal reside en la sobrecarga de la API al enviar los comandos, más que en la configuración de los pipelines o la vinculación de recursos.

Significancia y Reivindicaciones

El artículo afirma llenar un vacío en la ingeniería de rendimiento de WebGPU al caracterizar la sobrecarga de despacho, un factor que previamente se dejaba como "trabajo futuro" en estudios de vanguardia como LlamaWeb.

Estrategia de Optimización: Para la inferencia con tamaño de lote 1 en WebGPU, la estrategia de optimización efectiva es reducir el recuento de despachos (mediante fusión o amortización) en lugar de optimizar kernels individuales.
Implicaciones de la Especificación: El autor sugiere que ganancias de rendimiento más profundas podrían requerir cambios en la propia especificación de WebGPU. Proponen mecanismos de amortización de despacho análogos a los CUDA Graphs (captura y repetición de grafos de comandos) para evitar la revalidación y re-sumisión de cada operación, aunque reconocen que esto debe sopesarse frente a los modelos de seguridad de los navegadores que exigen la validación por operación.
Limitaciones del Alcance: El autor señala modestamente que sus resultados de fusión causal son específicos para la plataforma probada (RTX 5090, Dawn, Vulkan) y para un tamaño de lote de 1. No pretenden que estos resultados sean universales para todos los tamaños de lote, señalando que la computación del kernel comienza a dominar en tamaños de lote más grandes.

En conclusión, el trabajo establece que los benchmarks de operación única son engañosos debido a la confusión con la sincronización e identifica la reducción del recuento de despachos como la ruta crítica para lograr una inferencia de LLM de alto rendimiento y práctica basada en el navegador.