La mejora de velocidad de 2,57x en WebGPU de Hugging Face viene con 176 derrotas a cuestas

Hugging Face ha publicado 207 kernels de WebGPU bajo una nueva organización webgpu-kernels en su Hub, además de un cargador de JavaScript llamado @huggingface/kernels que los descarga y los ejecuta en el navegador. Una tercera pieza, Fleet, evalúa esos kernels en la GPU que el visitante tenga.

El lanzamiento llega con una cifra adosada: una mejora de velocidad de 2,57x en media geométrica medida frente al backend WebGPU de ONNX Runtime Web en un Apple M4, y de 1,90x en la mediana. Ambas cifras son reales. Ambas son más estrechas de lo que parecen.

Qué mide realmente el 2,57x

La comparación directa se ejecutó en una GPU Apple M4 contra ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a. Hugging Face partió de 1.756 casos de prueba que abarcaban las 207 operaciones, y luego conservó los 809 en los que ambas implementaciones producían salidas coincidentes y tiempos fiables. Los otros 947 casos no entran en la cifra.

La medición de tiempos cubre únicamente el trabajo de la GPU. La carga de kernels, la creación de sesiones, la subida de entradas, la compilación de shaders y la lectura de salidas quedan excluidas en ambos lados. Hugging Face advierte de que las cargas de trabajo muy cortas son difíciles de medir y que los casos pequeños pueden beneficiarse de la caché de la GPU, por lo que estas cifras se leen mejor como una comparación que como una promesa para una aplicación concreta. Un solo dispositivo en un solo navegador tampoco describe WebGPU, una advertencia que la propia empresa plantea.

Un Einsum de 10.000x y un CumSum de 301x

Dos entradas quedan muy lejos del agregado. Un Einsum bilineal de tamaño 4096 se ejecutó en 0,136 ms frente a los 1.396 ms de ORT WebGPU, una diferencia de más de 10.000x. Un CumSum por filas sobre una entrada [256, 4096] terminó en 0,016 ms frente a 4,784 ms, 301x. Hugging Face califica ambos de inusuales y los atribuye a una implementación general que cae en una ruta lenta.

Las operaciones ordinarias cuentan una historia más plana:

MatMul mejora 1,14x. Add gana por 3,52x, aunque sumar un puñado de flotantes no es donde se va el tiempo de inferencia. El lanzamiento no desglosa las 629 victorias por clase de operación, así que cuáles son las cargas de trabajo que más acelera la colección no es algo que resuelvan los datos publicados.

Las 176 derrotas

El recuento propio de Hugging Face es de 629 victorias, 176 derrotas y 4 empates. Las derrotas no son la columna que un artículo de lanzamiento está obligado a imprimir, y el lanzamiento no las explica. Sí señala que la mejor implementación cambia según la forma de la entrada, el dispositivo, el navegador y las funciones de WebGPU disponibles, que es el tipo de variabilidad que produce una columna de derrotas de este tamaño. Los datos de derrotas por operación no se publican, así que se desconoce si las derrotas se concentran en unos pocos kernels o se reparten por todo el conjunto.

Kernels empaquetados como contratos, no como shaders

Cada kernel es su propio repositorio con su propia ficha que documenta la semántica, las entradas, las salidas, los atributos, los tipos de datos admitidos y los archivos fuente. Detrás de la ficha hay cinco tipos de artefactos: manifest.json, la fuente de verdad del contrato de la operación; metadata.json para identificadores, digests y procedencia; test.json para casos de corrección; bench.json para casos de benchmark y ajuste; y archivos *.wgsl.jinja que contienen el WGSL parametrizado y especializado por petición y dispositivo.

El versionado del contrato se mantiene separado del versionado propio de ONNX. Una versión pasada a getKernel no es un opset, ni el since_version de un operador, ni una revisión de modelo, lo que permite que una aplicación dependa de una interfaz de JavaScript estable mientras las implementaciones de shaders se mueven por debajo. El kernel Add incluye cuatro variantes, para formas iguales, broadcasting vectorizado, procesamiento escalar y broadcasting general, ya que la suma con broadcasting necesita un indexado diferente.

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 cargador deriva la forma de salida del manifest y asigna el resultado, de modo que el patrón de llamada sigue siendo el mismo para las operaciones pesadas en las que los kernels realmente compensan. Hugging Face afirma que está trabajando con el equipo de ONNX Runtime para incorporar estas mejoras a ONNX Runtime Web. Si eso se concreta, las mejoras de velocidad dejan de ser un motivo para adoptar el cargador de Hugging Face y pasan a ser algo que los usuarios de ORT Web obtienen por defecto.

Fleet, el consentimiento y la distancia hasta un modelo

Fleet ejecuta comprobaciones de corrección y rendimiento en el navegador e informa de los resultados de la máquina local. Contribuir es opcional: con consentimiento, cada ejecución añade lo que Hugging Face llama evidencia privada, usada para encontrar fallos específicos de dispositivo, comparar variantes y mejorar las reglas de selección en hardware que un laboratorio de pruebas convencional no podría cubrir. El propio soporte de WebGPU varía según el navegador, el sistema operativo, la GPU y el controlador, y puede detectarse con "gpu" in navigator.

Nada de esto es un benchmark de modelos. Las mediciones son por operación, y un modelo que se ejecuta en el navegador es una secuencia de operaciones de GPU cuyo tiempo de ejecución solo puede ser tan eficiente como las operaciones que despacha. Elevar el suelo bajo Add, Softmax y LayerNormalization no garantiza que la capa superior reporte el mismo múltiplo.

Las partes que deciden si algo de esto importa son aburridas: si el trabajo de upstream en ONNX Runtime se concreta, si la evidencia de Fleet llega lo bastante rápido para arreglar lo que encuentra y si la columna de derrotas se reduce. Hugging Face la imprimió junto a las victorias, que no es como suelen escribirse los lanzamientos de kernels.