El 1 de septiembre Hugging Face publicó @huggingface/kernels, una biblioteca cargadora en JavaScript para descargar, preparar y ejecutar kernels WebGPU optimizados desde el Hub. Junto con ella llegaron 207 kernels de GPU ya afinados, que cubren multiplicación de matrices, normalización, convolución, primitivas de atención, operaciones de cuantización y transformaciones de disposición de datos, en distintas arquitecturas de machine learning. La licencia es Apache-2.0.
La forma de organizarlo es lo más inusual del proyecto: cada kernel se publica como un repositorio independiente, con su propia definición de interfaz, plantillas de shader, pruebas de corrección y datos de benchmark. Una vez en el Hub, un kernel y un modelo se versionan, descargan y referencian con el mismo mecanismo.
809 comparaciones de referencia
El rendimiento se midió frente a ORT WebGPU 1.30.0-dev, con 809 casos de prueba: una aceleración media geométrica de 2,57 veces, una mediana de 1,90 veces, con un resultado de 629 victorias, 176 derrotas y 4 empates. Desglosado por kernel, Add fue 3,52 veces más rápido, Softmax 2,11 veces y LayerNormalization 2,22 veces.
Haciendo cuentas por encima, la tasa de victorias ronda el 78%. Que la media geométrica de 2,57 esté claramente por encima de la mediana de 1,90 indica que la distribución de las ganancias de velocidad está sesgada hacia la derecha: unos pocos kernels aceleran muchísimo y arrastran la media hacia arriba. La mejora que realmente se nota en cargas de trabajo reales probablemente esté más cerca de la mediana que de la cifra más llamativa del anuncio. Eso no cambia la conclusión, solo recoloca la expectativa donde corresponde.
También llega una herramienta de benchmark que corre dentro del propio navegador, llamada Fleet, pensada como crowdsourcing: cada máquina que la ejecuta devuelve evidencia de rendimiento y corrección. La fragmentación de hardware de WebGPU es mucho mayor que la de CUDA en el servidor: GPUs integradas, GPUs dedicadas, GPUs móviles y distintas implementaciones de navegador dan resultados muy dispares, algo que unas pocas máquinas de laboratorio no pueden captar. Repartir las pruebas entre los usuarios es la salida práctica.
Por qué el cuello de botella está en los kernels
El atractivo de ejecutar modelos directamente en el navegador siempre ha sido claro: el cálculo ocurre en el dispositivo del usuario, el servidor no paga la factura de cómputo y los datos no necesitan salir del equipo. Lo que suele frenar la adopción no es el formato del modelo ni el framework de inferencia, sino la capa de kernels que hay debajo: con la misma función Softmax, la diferencia entre una implementación buena y una mediocre es la diferencia entre poder ir en tiempo real o no.
Antes, esta capa solo se podía actualizar junto con todo el runtime de inferencia. Para pasar a una implementación de atención más rápida, normalmente había que esperar a una nueva versión del framework. Al separarse en repositorios independientes, los kernels se convierten en unidades que se pueden sustituir, revertir y mejorar de forma individual. Cambiar, para un modelo concreto, un kernel de multiplicación de matrices optimizado para cierta GPU no debería requerir, en teoría, tocar el resto del código.
La forma de invocarlos también quedó muy compacta: se toma el objeto del kernel y se usa directamente como una función:
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });El requisito previo es que el navegador soporte WebGPU, algo que se comprueba con una sola línea: "gpu" in navigator.
Lo que significa para las herramientas en el dispositivo
Los beneficiados de esta actualización son bastante concretos: equipos que hacen edición de imagen puramente en el navegador, transcripción local, traducción sin conexión, herramientas sensibles a la privacidad. El modelo de negocio de estos productos se basa en que el servidor solo entrega archivos estáticos, sin asumir coste de cómputo, así que el tamaño de modelo que cabe en el navegador depende directamente del rendimiento de los kernels. Con los kernels, en conjunto, el doble de rápidos, el techo de parámetros de modelo viable sube un escalón, y una operación que antes tardaba tres segundos puede quedar en uno.
También hay que dejar claro el lado cauto. La comparación de benchmark se hizo contra una versión dev de ORT WebGPU, y ese rival también sigue mejorando; 207 kernels suena a mucho, pero cubre operaciones comunes, y ante arquitecturas poco habituales todavía hay que escribirlos a mano. El soporte de WebGPU ya está extendido entre navegadores, pero la calidad de implementación en móviles es desigual, y el comportamiento entre distintos dispositivos hay que comprobarlo uno mismo con herramientas como Fleet.
Convertir los kernels en recursos direccionables, versionados y verificables por crowdsourcing tiene un impacto más duradero que simplemente duplicar la velocidad. Los pesos de los modelos llevan tiempo circulando así; que la infraestructura de código lo alcance era solo cuestión de tiempo.
Fuentes: blog oficial de Hugging Face, CocoLoop, repositorios de Hugging Face Hub; las cifras de 207 kernels, 809 casos de prueba, la aceleración media geométrica de 2,57x y la mediana de 1,90x, el marcador de 629-176-4 y los factores por kernel se cotejaron con el anuncio oficial; la tasa de victorias y la lectura sobre el sesgo de la distribución son estimaciones de la redacción.