Hugging Face Ships 207 WebGPU Kernels—And a Crowdsourced Benchmark Fleet

Hugging Face's WebAI team just dropped something that should make everyone building in-browser AI sit up and pay attention: @huggingface/kernels, a library of 207 WebGPU kernels published as individual, versioned repositories on the Hub. Each kernel is a complete package—shader templates, correctness tests, benchmark cases, and usage docs—and the whole collection is Apache-2.0 licensed.

What makes this interesting isn't just the kernel count. It's the structure. Every operation lives in its own repo at huggingface.co/webgpu-kernels, with an explicit contract, reproducible test cases, and performance benchmarks that travel with the implementation. You're not downloading a blob of WGSL and hoping it works. You're loading a versioned artifact with a stable API.

And then there's Fleet, the in-browser benchmarking suite that lets anyone run these kernels on their hardware and—with consent—contribute performance and correctness evidence back to the project. It's crowdsourced GPU profiling, and it's exactly the kind of unsexy infrastructure work that makes fast browser inference possible.

Why Kernels Are the Foundation

Browser inference eventually bottoms out in GPU operations: matrix multiplications, normalizations, attention primitives, quantization ops, data-layout transforms. WebGPU gives you a portable API, WGSL gives you a common shader language, but portability doesn't guarantee performance.

Two shaders can implement the same operation, produce identical output, and perform completely differently across devices. Workgroup sizes matter. Memory access patterns matter. Vectorization strategies, data types, fusion choices—all of it affects performance, and the optimal configuration changes with input shape, device, browser, and available WebGPU features.

This is why kernel libraries exist. Higher-level runtimes can only be as fast as the operations they dispatch. By making those operations individually discoverable, testable, benchmarkable, and versioned, you can improve the foundation without breaking the layers above.

What a Kernel Repository Looks Like

Each kernel has its own repo and kernel card. Take ai.onnx.Add, which implements elementwise addition with multidirectional broadcasting. It's one of the simplest ops in a neural network—used everywhere from residual connections to bias addition.

The repository contains:

• manifest.json — the operation contract (inputs, outputs, attributes, type constraints, shape derivation rules)
• metadata.json — kernel identifier, digests, provenance
• test.json — correctness cases for validating the implementation
• bench.json — benchmark cases representing real workloads
• *.wgsl.jinja — parameterized WGSL templates that generate shaders for specific requests and devices

This structure turns a shader into a reusable software artifact. The interface is inspectable without reading WGSL. Correctness and performance cases travel with the code. Published versions can be loaded explicitly instead of depending on an unversioned file URL.

Even simple operations need variants. Equal-shape addition can use a direct vectorized path. Broadcasted inputs need different indexing logic. The published Add kernel includes variants for equal shapes, vectorized broadcasting, scalar processing, and general broadcasting. The runtime selects an implementation that fits the current call and device without changing the application-facing API.

Loading and Running a Kernel

The usage pattern is straightforward. Install from npm:

npm install @huggingface/kernels@preview

Then load a kernel from the Hub and invoke it with typed input data:

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],
  },
});

The second input is broadcast across the first dimension, producing an output with shape [2, 3]. The loader derives the output shape and logical data type from the manifest contract and the inputs, then allocates the output automatically.

The version: 1 option selects version 1 of the published kernel contract—separate from ONNX opset versions or model revisions. Applications depend on a stable JavaScript-facing contract while kernel implementations evolve behind it.

Performance: Benchmarks Against ORT WebGPU

Hugging Face ran head-to-head comparisons with ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a on an Apple M4 GPU. Starting with 1,756 test cases across all 207 operations, they kept the 809 cases where both sides produced matching outputs and reliable timings.

Across those comparisons, the Hugging Face kernels were 2.57x faster by geometric mean and 1.90x faster at the median, with 629 wins, 176 losses, and 4 ties.

A few highlighted operations:

Some individual wins were dramatic. A bilinear Einsum case (i,ij,j with size 4096) ran in 0.136 ms versus 1,396 ms with ORT WebGPU—more than 10,000x faster. A row-wise CumSum over [256, 4096] was 301x faster at 0.016 ms versus 4.784 ms.

These extreme cases are outliers, not typical performance. They show what happens when a general implementation hits a slow path and a specialized kernel can help. The timings measure GPU work only, excluding setup like loading kernels, creating sessions, uploading inputs, compiling shaders, and reading outputs back.

These are also single-operation results, not end-to-end model inference. Exact performance will vary across GPUs and browsers, which is why Fleet matters.

Fleet: Crowdsourced GPU Profiling

WebGPU performance varies across GPUs, browsers, and drivers. Results from one machine tell part of the story. Fleet lets anyone run correctness and performance checks in the browser and see how the kernels behave on their hardware.

With consent, each run privately contributes evidence that helps spot device-specific failures, compare variants, and improve selection rules. The goal: use broad, real-world coverage to make the kernels faster and more reliable for everyone.

This is unsexy infrastructure work, but it's exactly what's missing from most WebGPU projects. You can't optimize for devices you don't have. Fleet turns every user into a potential test device.

What This Means for WebAI

The initial 207 kernels are a starting point. Publishing kernels independently on the Hub creates a common place to inspect contracts, compare implementations, reproduce correctness checks, and improve performance without embedding every shader directly into every runtime.

The collection sits alongside kernels for CUDA, ROCm, Metal, and other platforms on the Hub Kernels page, filterable and explorable like any other Hub artifact.

Hugging Face is also working with the ONNX Runtime team to upstream these improvements so they can benefit the broader ONNX Runtime Web ecosystem.

For developers building browser-based AI, this is the kind of foundation that matters. Transformers.js and other runtimes can only be as fast as the operations they dispatch. Versioned, testable, benchmarked kernels with crowdsourced performance data give the whole ecosystem a better substrate to build on.

The WebAI stack is still early, but projects like this—unglamorous, foundational, open—are what make fast browser inference possible. If you're building in-browser AI, run Fleet on your hardware. If you're optimizing WebGPU workloads, these kernels are reference implementations worth studying. And if you're just following the space, watch what happens when the community starts contributing performance evidence from devices Hugging Face could never cover in a conventional test lab.