A Hugging Face lançou em 1º de setembro o @huggingface/kernels, uma biblioteca loader em JavaScript para baixar, preparar e executar kernels WebGPU otimizados vindos do Hub. Junto vieram 207 kernels de GPU já ajustados, cobrindo multiplicação de matrizes, normalização, convolução, primitivas de atenção, operações de quantização e transformações de layout de dados, em várias arquiteturas de machine learning. A licença é Apache-2.0.
A forma de organização é o ponto mais incomum do projeto: cada kernel é publicado como um repositório independente, com sua própria definição de interface, templates de shader, testes de correção e dados de benchmark. Uma vez no Hub, um kernel e um modelo passam a ser versionados, baixados e referenciados pelo mesmo mecanismo.
809 comparações de referência
O desempenho foi medido diretamente contra o ORT WebGPU 1.30.0-dev, com base em 809 casos de teste: aceleração média geométrica de 2,57 vezes, mediana de 1,90 vez, com placar de 629 vitórias, 176 derrotas e 4 empates. Olhando kernel por kernel, Add ficou 3,52 vezes mais rápido, Softmax 2,11 vezes e LayerNormalization 2,22 vezes.
Fazendo as contas por cima, a taxa de vitórias fica em torno de 78%. A média geométrica de 2,57 claramente acima da mediana de 1,90 indica que a distribuição dos ganhos de velocidade é assimétrica à direita — poucos kernels aceleram muito e puxam a média para cima. O ganho que se sente de fato em cargas de trabalho reais provavelmente fica mais perto da mediana do que do número mais chamativo do anúncio. Isso não muda a conclusão, só recoloca a expectativa no lugar certo.
Junto vem também uma ferramenta de benchmark que roda dentro do próprio navegador, chamada Fleet, com uma lógica de crowdsourcing: cada máquina que roda o teste devolve evidências de desempenho e correção. A fragmentação de hardware do WebGPU é bem maior do que a do CUDA no lado servidor — GPUs integradas, GPUs dedicadas, GPUs móveis e diferentes implementações de navegador produzem resultados bem diferentes, e algumas máquinas de laboratório não dão conta de captar esse quadro completo. Distribuir os testes entre os usuários é a saída prática.
Por que o gargalo está na camada de kernels
O apelo de rodar modelos direto no navegador sempre foi claro: o cálculo acontece no dispositivo do usuário, o servidor não paga a conta de processamento e os dados não precisam sair da máquina. O que costuma travar a adoção normalmente não é o formato do modelo nem o framework de inferência, mas a camada de kernels logo abaixo — a mesma função Softmax, bem escrita ou apenas razoável, é o que separa rodar em tempo real de não rodar.
Antes, essa camada só evoluía junto com todo o runtime de inferência. Para trocar por uma implementação de atenção mais rápida, geralmente era preciso esperar uma nova versão do framework. Separados em repositórios independentes, os kernels viram unidades que podem ser trocadas, revertidas e melhoradas isoladamente. Trocar, para um modelo específico, um kernel de multiplicação de matrizes otimizado para determinada GPU não deveria, em tese, exigir tocar em mais nada do código.
A forma de chamada também ficou bem enxuta — basta pegar o objeto do kernel e usá-lo direto como uma função:
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });O pré-requisito é o navegador suportar WebGPU, o que se verifica com uma única linha: "gpu" in navigator.
O que isso significa para ferramentas no dispositivo
Quem se beneficia desta atualização é bem específico: equipes que fazem edição de imagem só no navegador, transcrição local, tradução offline, ferramentas sensíveis a privacidade. O modelo de negócio desses produtos depende de o servidor entregar apenas arquivos estáticos, sem arcar com custo de computação — e o tamanho de modelo que cabe no navegador é determinado diretamente pelo desempenho dos kernels. Com os kernels no geral duas vezes mais rápidos, o teto de parâmetros de modelo viável sobe um degrau, e uma operação que antes levava três segundos pode caber em um segundo.
É preciso registrar também o lado mais cauteloso. A comparação de benchmark foi feita contra uma versão dev do ORT WebGPU, e o concorrente também está evoluindo; 207 kernels parece muita coisa, mas cobre operações comuns — arquiteturas incomuns ainda exigem escrever na mão. O suporte a WebGPU já está disponível na maioria dos navegadores, mas a qualidade de implementação em dispositivos móveis varia bastante, e o comportamento entre diferentes aparelhos ainda precisa ser testado com ferramentas como o Fleet.
Transformar kernels em recursos endereçáveis, versionados e verificados por crowdsourcing tem um impacto mais duradouro do que simplesmente dobrar a velocidade. Os pesos de modelos já circulam dessa forma há tempos; a infraestrutura de código acompanhar era só questão de tempo.
Fontes: blog oficial da Hugging Face, CocoLoop, repositórios do Hugging Face Hub; os números de 207 kernels, 809 casos de teste, aceleração média geométrica de 2,57x e mediana de 1,90x, o placar de 629-176-4 e os fatores por kernel foram conferidos no anúncio oficial; a taxa de vitórias e a leitura sobre a assimetria da distribuição são estimativas da redação.