Hugging Face published 207 WebGPU kernels and a loader that pulls them from the Hub

Hugging Face released @huggingface/kernels on September 1, 2026, together with 207 WebGPU kernels published as individual repositories in the webgpu-kernels organization on the Hub. A kernel here is the program that performs one operation on the GPU — elementwise addition, matrix multiplication, softmax — and the same repository holds its interface contract, correctness cases, benchmark cases, and parameterized WGSL shader templates. The package itself is a loader: you ask for a repository ID and a contract version, and you get back a function you call with typed arrays and tensor shapes.

What a kernel repository holds

A shader that lives inside a runtime cannot be inspected, versioned, or replaced on its own. Publishing every operation as its own repository changes that. The manifest defines inputs, outputs, attributes, type constraints, and the rules for deriving the output shape, so an application can read the contract without reading any WGSL. Correctness cases and benchmark cases travel in the same repository, so the evidence for a kernel and the kernel itself cannot drift apart.

The version number applies to the contract JavaScript sees, not to an ONNX opset and not to a model revision. Hugging Face keeps those separate on purpose: an application depends on the contract it was written against, and the implementation behind it can be rewritten while the call stays the same.

• Install it with npm install @huggingface/kernels@preview.
• getKernel takes a Hub repository ID and a contract version, and returns a callable function.
• Inputs arrive as typed arrays with tensor shapes, and the loader allocates the output itself.
• The published ai.onnx.Add kernel ships four variants: equal shapes, vectorized broadcasting, scalar processing, and general broadcasting.
• Every repository carries manifest.json, metadata.json, test.json, bench.json, and *.wgsl.jinja shader templates.
• Running any of it needs a browser with WebGPU, which JavaScript tests for with "gpu" in navigator.

What the measurement shows, and what it leaves out

Hugging Face put its collection against ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a, running on an Apple M4 GPU. It started from 1,756 test cases across all 207 operations and kept the 809 where both sides produced matching outputs and reliable timings. On those, the company reports its kernels 2.57x faster by geometric mean and 1.90x faster at the median, with 629 wins, 176 losses, and 4 ties.

The per-operation table is more modest than that headline. Elementwise addition ran in 0.064 ms against 0.227 ms, a gap of 3.52x. Matrix multiplication, the operation that takes the largest share of real inference, ran in 0.115 ms against 0.131 ms, which is 1.14x. Softmax came out 2.11x faster and layer normalization 2.22x.

Two results sit far outside that range. A bilinear Einsum at size 4096 took 0.136 ms against 1,396 ms, more than 10,000x faster, and a row-wise cumulative sum over a 256 by 4096 tensor was 301x faster. Hugging Face describes both as unusual cases where a general implementation falls onto a slow path, not as speedups to expect.

The limitation is written into the post, and it matters to anyone reading the number as a promise. The timings cover work on the GPU itself and exclude loading kernels, creating sessions, uploading inputs, compiling shaders, and reading outputs back. They are single operations, not models. This suggests the difference on a real page will be smaller than 2.57x, though the post publishes no model-level figure.

Why the browser needed this layer

WebGPU gives every modern browser the same API and WGSL gives them the same shader language, but portability is not speed. Two shaders can compute the same result and behave entirely differently depending on workgroup size, memory access pattern, vectorization, data type, and fusion. The best choice moves with the input shape, the device, the browser, and the WebGPU features available.

Alongside the kernels, Hugging Face released Fleet, a suite that runs and scores them in the visitor's own browser. With consent, each run contributes correctness and performance evidence from real hardware, which is the part no test lab can buy. The company says it is working with the ONNX Runtime team to upstream the improvements into that project.