Hugging Face anunció @huggingface/kernels el 1 de septiembre de 2026, junto con una colección inicial de 207 kernels WebGPU. La cifra importa menos que su encaje con el navegador, la GPU, las dimensiones de los tensores y la carga de trabajo de la aplicación.
Empieza por el entorno que vas a utilizar
Antes de comparar tiempos, verifica que el navegador de destino sea compatible con WebGPU. La disponibilidad depende del navegador, el sistema operativo, la GPU y el controlador, así que una prueba ejecutada en otro equipo puede producir un resultado diferente.
En una aplicación JavaScript, Hugging Face conecta un repositorio del Hub con la aplicación mediante getKernel. La llamada recibe un identificador de repositorio y una versión del contrato, y después acepta datos tipados y dimensiones de tensores. Registra esas entradas desde el principio: necesitarás repetir exactamente el mismo contrato cuando compares otra implementación.
Qué contiene realmente cada kernel
Cada kernel se distribuye como un paquete versionado con su interfaz, plantillas de shaders, pruebas de corrección, casos de benchmark e instrucciones de uso. Los 207 kernels son repositorios individuales de la organización webgpu-kernels y se publican bajo licencia Apache-2.0.
Por eso la interfaz y la versión del contrato forman parte de la evaluación, no son detalles para resolver después de medir la velocidad. También condicionan qué puede integrar la aplicación y con qué datos.
En una actualización del 6 de julio de 2026, Hugging Face describió Kernels como un proyecto para estandarizar el empaquetado, la distribución y el consumo de kernels personalizados. La actualización presentó además un tipo de repositorio del Hub llamado kernel, que identifica aceleradores compatibles, sistemas operativos y versiones del backend.
Usa esos datos de compatibilidad como filtro inicial y confirma el resultado en el hardware que ejecutará la aplicación. La compatibilidad declarada reduce candidatos; no sustituye la comprobación práctica.
La corrección va antes que la velocidad
Un resultado rápido solo sirve si las salidas coinciden. Hugging Face comparó su colección con ORT WebGPU usando ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a en una GPU Apple M4.
La comparación comenzó con 1.756 casos que cubrían las 207 operaciones, pero solo se conservaron 809 porque ambas implementaciones produjeron salidas concordantes y mediciones de tiempo fiables. Ese filtro marca el orden que conviene seguir en una evaluación propia: primero comprueba la salida esperada para los datos y dimensiones relevantes; después usa el tiempo para comparar candidatos.
Una ejecución aislada no demuestra una mejora útil si el caso de corrección correspondiente falla. En ese escenario, conservar la implementación alternativa es la decisión operativa, aunque el número de milisegundos parezca favorable.
Cómo leer las cifras publicadas
En las 809 comparaciones conservadas, Hugging Face informó de una aceleración media geométrica de 2,57× y una aceleración mediana de 1,90× frente a ORT WebGPU. La colección registró 629 resultados a favor, 176 en contra y cuatro empates.
Son cifras de operaciones individuales en la configuración indicada. No describen la velocidad de un modelo completo: otras operaciones, las transferencias y las tareas de preparación pueden determinar el resultado de extremo a extremo.
La diferencia entre operaciones también es amplia. Add registró 0,064 ms para el kernel de Hugging Face frente a 0,227 ms para ORT WebGPU en cinco casos, un factor de 3,52×. MatMul registró 0,115 ms frente a 0,131 ms en 29 casos, o 1,14×. Softmax registró 0,114 ms frente a 0,240 ms en 12 casos, mientras que LayerNormalization registró 0,061 ms frente a 0,135 ms en seis casos.
La operación y su forma deben permanecer visibles. Un caso bilineal de Einsum con tamaño 4096 registró 0,136 ms con el kernel de Hugging Face y 1.396 ms con ORT WebGPU, presentado como más de 10.000× más rápido. Un CumSum por filas sobre [256,4096] registró 0,016 ms frente a 4,784 ms, o 301× más rápido.
Estos valores pueden señalar candidatos prometedores, pero no deben generalizarse a todas las cargas de trabajo. Una gran mejora solo afecta al resultado completo si esa operación y esa forma aparecen con suficiente frecuencia y ocupan una parte suficiente del tiempo de ejecución.
Repite la comparación con el perfil de tu aplicación
- Enumera las operaciones y dimensiones de tensores importantes para la aplicación.
- Comprueba la disponibilidad de WebGPU, el contrato del paquete del kernel y sus datos de compatibilidad.
- Ejecuta los casos de corrección antes de utilizar los tiempos para elegir entre implementaciones.
- Compara la misma operación y dimensión con la alternativa disponible en la aplicación.
- Registra el navegador, el sistema operativo, la GPU, el controlador y la versión del backend junto con cada resultado.
- Decide solo después de comprobar si la operación medida tiene suficiente peso para afectar a la aplicación completa.
Este orden evita transformar una cifra alta a nivel de operación en una promesa sobre el modelo entero. Utiliza el candidato cuando la salida sea correcta y las dimensiones relevantes mejoren la carga de trabajo. Mantén la alternativa si falla la compatibilidad, divergen las salidas o la mejora medida no cambia de forma material el rendimiento de la aplicación.
Qué mide Fleet y qué deja fuera
Hugging Face lanzó Fleet como una suite de benchmarking y pruebas de GPU basada en el navegador. Ejecuta y evalúa kernels en el hardware del usuario. Con el consentimiento del usuario, cada ejecución aporta pruebas privadas de rendimiento y corrección que pueden ayudar a identificar fallos, comparar variantes y mejorar las decisiones de optimización.
Ese consentimiento debe obtenerse antes de utilizar Fleet con ese fin de recopilación de pruebas. Además, sus mediciones cubren únicamente el trabajo de la GPU: excluyen la carga del kernel, la creación de la sesión, las transferencias de entrada, la compilación de shaders y la lectura de la salida.
El límite cambia la interpretación del resultado. Un kernel que gane en Fleet puede ofrecer un beneficio de extremo a extremo menor cuando se incorporan las actividades excluidas. Mide la aplicación completa por separado si el tiempo de inicio, el movimiento de datos o la gestión de la salida forma parte de la experiencia visible para el usuario.
La integración con ONNX Runtime aún está pendiente
Hugging Face afirma que trabaja con el equipo de ONNX Runtime para integrar estas mejoras en el ecosistema de ONNX Runtime Web. Es una dirección declarada, no una integración completada.
La decisión práctica consiste en confirmar WebGPU y la compatibilidad, verificar las salidas antes de medir la velocidad y juzgar el resultado con las operaciones y dimensiones propias de la aplicación. La comparación publicada sirve para seleccionar candidatos, pero la decisión final requiere una medición de extremo a extremo.