Hugging Face acaba de publicar una nueva capa para acelerar la inteligencia artificial directamente en el navegador: @huggingface/kernels, una biblioteca JavaScript que permite cargar y ejecutar kernels WebGPU optimizados desde el Hub. La colección inicial incluye 207 kernels con contratos versionados, pruebas de corrección y benchmarks reproducibles.
¿La idea? Que las aplicaciones de IA local no tengan que depender únicamente de implementaciones genéricas. En el navegador, una operación tan común como una multiplicación de matrices o una normalización puede ejecutarse de formas muy distintas según la GPU, el navegador y el tamaño de los datos.
Qué son los kernels WebGPU
Cuando un modelo de IA funciona en el navegador, termina convirtiéndose en una larga secuencia de operaciones ejecutadas en la GPU: multiplicaciones de matrices, convoluciones, atención, cuantización, normalizaciones y transformaciones de datos, entre muchas otras.
WebGPU ofrece una API común para acceder a las GPU modernas desde el navegador, mientras que WGSL es el lenguaje utilizado para escribir los shaders que ejecutan esas operaciones. Sin embargo, que una operación sea compatible con WebGPU no significa que sea rápida.
Dos shaders pueden producir exactamente el mismo resultado y tener un rendimiento completamente diferente. El tamaño de los grupos de trabajo, la forma de acceder a la memoria, la vectorización, los tipos de datos y la combinación de operaciones influyen directamente en la velocidad.
Además, la mejor implementación puede cambiar según la forma de los tensores, el dispositivo, el navegador y las funciones de WebGPU disponibles. Por eso, los kernels optimizados son una pieza fundamental para construir inferencia local eficiente.
Un runtime de alto nivel solo puede ser tan rápido como las operaciones que ejecuta por debajo.
207 kernels publicados como paquetes completos
Cada kernel está disponible como un repositorio individual dentro de la organización webgpu-kernels en Hugging Face. Todos se publican con licencia Apache-2.0 y documentación específica, conocida como kernel card.
La tarjeta describe:
- La operación que implementa.
- Sus entradas, salidas y atributos.
- Las formas esperadas de los tensores.
- Los tipos de datos compatibles.
- Las variantes disponibles para diferentes dispositivos y tamaños.
- Ejemplos listos para ejecutar con
@huggingface/kernels.
Cada repositorio también incluye los archivos necesarios para inspeccionar, probar y medir la implementación:
manifest.json: define el contrato de la operación, sus entradas, salidas, restricciones de tipos y reglas para derivar formas.metadata.json: registra el identificador del kernel, sus huellas digitales y su procedencia.test.json: contiene casos para comprobar que los resultados sean correctos.bench.json: incluye casos de benchmark y ajuste de rendimiento.- Archivos
*.wgsl.jinja: plantillas parametrizadas que generan shaders WGSL adaptados a una solicitud y dispositivo concretos.
Este enfoque convierte un shader en un artefacto de software reutilizable. La interfaz puede inspeccionarse sin leer todo el código WGSL, las pruebas viajan junto con la implementación y las aplicaciones pueden cargar versiones específicas en lugar de depender de archivos sin versionar.
Cómo usar @huggingface/kernels
La biblioteca puede instalarse desde npm con:
npm install @huggingface/kernels@preview
Para ejecutar los kernels necesitas un navegador con soporte para WebGPU. La disponibilidad depende del navegador, el sistema operativo, la GPU y los controladores instalados.
Puedes comprobar si WebGPU está disponible desde JavaScript:
"gpu" in navigator
Después, getKernel carga un kernel desde el Hub usando su identificador de repositorio y una versión del contrato. El resultado es una función que recibe datos tipados y las formas de los tensores.
Por ejemplo, este código suma dos tensores usando ai.onnx.Add:
import { getKernel } from "@huggingface/kernels";
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });
const { c } = await add({
a: {
data: new Float32Array([1, 2, 3, 4, 5, 6]),
shape: [2, 3],
},
b: {
data: new Float32Array([10, 20, 30]),
shape: [3],
},
});
El segundo tensor se expande mediante broadcasting a lo largo de la primera dimensión. El resultado tiene forma [2, 3], y el runtime deriva esa forma y reserva automáticamente la salida c a partir del contrato del kernel.
Este ejemplo es pequeño a propósito. Para sumar seis números, el coste de enviar datos a la GPU puede ser mayor que el de realizar la operación. El valor está en el mismo patrón de uso, que también se aplica a operaciones pesadas como ai.onnx.MatMul.
La operación Add incluye variantes para formas iguales, broadcasting vectorizado, procesamiento escalar y broadcasting general. El runtime puede seleccionar la variante más adecuada sin que la aplicación tenga que modificar su API.
Versiones separadas de ONNX
El parámetro { version: 1 } identifica la versión del contrato publicado por Hugging Face. No es lo mismo que un opset de ONNX, el campo since_version de una operación o una revisión del modelo.
Separar estos conceptos permite que una aplicación dependa de un contrato estable mientras las implementaciones internas evolucionan. En otras palabras, el shader puede mejorar sin obligar a cambiar el código que lo utiliza.
Hugging Face reporta mejoras frente a ORT WebGPU
Hugging Face comparó sus kernels con ONNX Runtime WebGPU en una GPU Apple M4, utilizando ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a.
El equipo comenzó con 1.756 casos de prueba distribuidos entre las 207 operaciones y conservó los 809 casos en los que ambas implementaciones produjeron resultados coincidentes y mediciones confiables.
Los kernels de Hugging Face fueron:
- 2,57 veces más rápidos en media geométrica.
- 1,90 veces más rápidos en la mediana.
- Ganadores en 629 casos.
- Más lentos en 176 casos.
- Empatados en 4 casos.
Estos fueron algunos resultados por operación:
| Operación | Casos comparados | Kernel WebGPU de Hugging Face | ORT WebGPU | Aceleración |
|---|---|---|---|---|
| Add | 5 | 0,064 ms | 0,227 ms | 3,52x |
| MatMul | 29 | 0,115 ms | 0,131 ms | 1,14x |
| Softmax | 12 | 0,114 ms | 0,240 ms | 2,11x |
| LayerNormalization | 6 | 0,061 ms | 0,135 ms | 2,22x |
También hubo casos excepcionales. Una operación Einsum bilineal con tamaño 4096 tardó 0,136 milisegundos con el kernel de Hugging Face frente a 1.396 milisegundos con ORT WebGPU, una diferencia superior a 10.000 veces.
En otro caso, una operación CumSum por filas sobre una matriz de forma [256, 4096] fue 301 veces más rápida: 0,016 milisegundos frente a 4,784 milisegundos.
Conviene interpretar estos números con cuidado. Las mediciones corresponden al trabajo realizado directamente en la GPU y no incluyen la carga de kernels, la creación de sesiones, la transferencia de entradas, la compilación de shaders ni la lectura de resultados.
Tampoco representan el rendimiento de modelos completos. Las cifras pueden cambiar de forma importante entre GPU, navegador y controlador. Un benchmark en un Apple M4 no garantiza los mismos resultados en una computadora con Windows, un teléfono Android o una GPU integrada.
Hugging Face también está trabajando con el equipo de ONNX Runtime para incorporar estas mejoras al ecosistema de ONNX Runtime Web.
Fleet prueba los kernels en hardware real
Para ampliar la cobertura más allá de los dispositivos disponibles en un laboratorio, Hugging Face presenta Fleet, una suite de pruebas y benchmarks que funciona directamente en el navegador.
Fleet permite ejecutar kernels en el hardware de cada usuario y obtener información sobre su rendimiento y corrección. Con consentimiento, cada ejecución aporta evidencia privada que puede ayudar a detectar:
- Resultados incorrectos en dispositivos concretos.
- Variantes especialmente lentas.
- Diferencias entre navegadores y controladores.
- Problemas con tamaños o tipos de datos específicos.
- Mejores reglas para seleccionar kernels.
La propuesta recuerda a una prueba colectiva de compatibilidad, pero enfocada en operaciones de IA. ¿Por qué es importante? Porque existe una enorme variedad de GPU y configuraciones que una prueba de laboratorio tradicional nunca podría cubrir por completo.
Los resultados de Fleet pueden ayudar a decidir cuándo conviene usar una implementación vectorizada, cuándo elegir una ruta general y qué variante funciona mejor para cada familia de dispositivos.
Una base para la IA local en el navegador
La publicación de estos 207 kernels es solo el comienzo. Al alojar las implementaciones de forma independiente en el Hub, Hugging Face crea un espacio común para inspeccionar contratos, comparar alternativas, reproducir pruebas y optimizar operaciones sin tener que integrar cada shader directamente en todos los runtimes.
La colección también se conecta con el ecosistema más amplio de kernels del Hub, que incluye implementaciones para CUDA, ROCm, Metal y otras plataformas. Así, los desarrolladores pueden explorar y filtrar estos artefactos de manera similar a como ya descubren modelos y datasets.
Las piezas cumplen funciones distintas, pero se refuerzan entre sí:
- Los repositorios definen contratos transparentes y versionados.
@huggingface/kernelsfacilita cargar y ejecutar operaciones desde JavaScript.- Fleet reúne evidencia de rendimiento y corrección en hardware real.
- Las ejecuciones aportadas ayudan a mejorar variantes y versiones futuras.
Para quienes desarrollan aplicaciones con IA en el navegador, esto significa tener una capa más modular y observable. Para quienes usan estas herramientas sin ser especialistas, puede traducirse en modelos que funcionan de forma más rápida y confiable sin enviar cada dato a un servidor.
La IA local no depende únicamente de modelos más grandes. También necesita operaciones pequeñas, bien probadas y adaptadas al dispositivo donde se ejecutan. Con @huggingface/kernels, Hugging Face intenta convertir esa parte invisible de la infraestructura en un componente abierto, medible y reutilizable.