Hugging Face has just published a new layer for accelerating artificial intelligence directly in the browser: @huggingface/kernels, a JavaScript library that lets you load and run optimized WebGPU kernels from the Hub. The initial collection includes 207 kernels with versioned contracts, correctness tests, and reproducible benchmarks.
The idea? Local AI applications shouldn’t have to rely only on generic implementations. In the browser, a common operation such as a matrix multiplication or normalization can run in very different ways depending on the GPU, browser, and data size.
What WebGPU kernels are
When an AI model runs in the browser, it eventually becomes a long sequence of operations executed on the GPU: matrix multiplications, convolutions, attention, quantization, normalization, and data transformations, among many others.
WebGPU provides a common API for accessing modern GPUs from the browser, while WGSL is the language used to write the shaders that execute those operations. However, the fact that an operation is compatible with WebGPU doesn’t mean it will be fast.
Two shaders can produce exactly the same result and have completely different performance. The size of the workgroups, the way memory is accessed, vectorization, data types, and the combination of operations all directly affect speed.
In addition, the best implementation can change depending on tensor shapes, the device, the browser, and the available WebGPU features. That’s why optimized kernels are a fundamental building block for efficient local inference.
A high-level runtime can only be as fast as the operations it executes underneath.
207 kernels published as complete packages
Each kernel is available as an individual repository within the webgpu-kernels organization on Hugging Face. All are published under the Apache-2.0 license and include specific documentation known as a kernel card.
The card describes:
- The operation it implements.
- Its inputs, outputs, and attributes.
- The expected tensor shapes.
- The supported data types.
- The available variants for different devices and sizes.
- Ready-to-run examples with
@huggingface/kernels.
Each repository also includes the files needed to inspect, test, and measure the implementation:
manifest.json: defines the operation’s contract, its inputs, outputs, type restrictions, and rules for deriving shapes.metadata.json: records the kernel identifier, its fingerprints, and its provenance.test.json: contains cases for checking that the results are correct.bench.json: includes benchmark and performance-tuning cases.*.wgsl.jinjafiles: parameterized templates that generate WGSL shaders adapted to a specific request and device.
This approach turns a shader into a reusable software artifact. The interface can be inspected without reading all the WGSL code, tests travel alongside the implementation, and applications can load specific versions instead of relying on unversioned files.
How to use @huggingface/kernels
The library can be installed from npm with:
npm install @huggingface/kernels@preview
To run the kernels, you need a browser with WebGPU support. Availability depends on the browser, operating system, GPU, and installed drivers.
You can check whether WebGPU is available from JavaScript:
"gpu" in navigator
Then, getKernel loads a kernel from the Hub using its repository identifier and a contract version. The result is a function that accepts typed data and tensor shapes.
For example, this code adds two tensors using ai.onnx.Add:
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 tensor is expanded through broadcasting along the first dimension. The result has the shape [2, 3], and the runtime derives that shape and automatically allocates the c output based on the kernel contract.
This example is intentionally small. To add six numbers, the cost of sending data to the GPU may be greater than the cost of performing the operation. The value lies in the same usage pattern, which also applies to heavy operations such as ai.onnx.MatMul.
The Add operation includes variants for equal shapes, vectorized broadcasting, scalar processing, and general broadcasting. The runtime can select the most suitable variant without requiring the application to change its API.
Separate ONNX versions
The { version: 1 } parameter identifies the version of the contract published by Hugging Face. It is not the same as an ONNX opset, an operation’s since_version field, or a model revision.
Separating these concepts allows an application to depend on a stable contract while the internal implementations evolve. In other words, the shader can improve without forcing changes to the code that uses it.
Hugging Face reports improvements over ORT WebGPU
Hugging Face compared its kernels with ONNX Runtime WebGPU on an Apple M4 GPU, using ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a.
The team started with 1,756 test cases distributed across the 207 operations and retained the 809 cases in which both implementations produced matching results and reliable measurements.
Hugging Face’s kernels were:
- 2.57 times faster in geometric mean.
- 1.90 times faster at the median.
- Winners in 629 cases.
- Slower in 176 cases.
- Tied in 4 cases.
These were some of the results by operation:
| Operation | Cases compared | Hugging Face WebGPU kernel | ORT WebGPU | Speedup |
|---|---|---|---|---|
| Add | 5 | 0.064 ms | 0.227 ms | 3.52x |
| MatMul | 29 | 0.115 ms | 0.131 ms | 1.14x |
| Softmax | 12 | 0.114 ms | 0.240 ms | 2.11x |
| LayerNormalization | 6 | 0.061 ms | 0.135 ms | 2.22x |
There were also exceptional cases. A bilinear Einsum operation with a size of 4096 took 0.136 milliseconds with the Hugging Face kernel, compared with 1.396 milliseconds with ORT WebGPU—a difference of more than 10,000 times.
In another case, a row-wise CumSum operation on a matrix with shape [256, 4096] was 301 times faster: 0.016 milliseconds compared with 4.784 milliseconds.
These numbers should be interpreted carefully. The measurements correspond to work performed directly on the GPU and do not include kernel loading, session creation, input transfer, shader compilation, or result reading.
They also do not represent the performance of complete models. The figures can change significantly between GPUs, browsers, and drivers. A benchmark on an Apple M4 does not guarantee the same results on a Windows computer, an Android phone, or an integrated GPU.
Hugging Face is also working with the ONNX Runtime team to bring these improvements to the ONNX Runtime Web ecosystem.
Fleet tests the kernels on real hardware
To expand coverage beyond the devices available in a laboratory, Hugging Face is introducing Fleet, a test and benchmarking suite that runs directly in the browser.
Fleet lets kernels run on each user’s hardware and collects information about their performance and correctness. With consent, each execution contributes private evidence that can help detect:
- Incorrect results on specific devices.
- Particularly slow variants.
- Differences between browsers and drivers.
- Problems with specific sizes or data types.
- Better rules for selecting kernels.
The proposal is reminiscent of a collective compatibility test, but focused on AI operations. Why does that matter? Because there is an enormous variety of GPUs and configurations that a traditional laboratory test could never fully cover.
Fleet’s results can help determine when it makes sense to use a vectorized implementation, when to choose a general path, and which variant works best for each device family.
A foundation for local AI in the browser
Publishing these 207 kernels is only the beginning. By hosting the implementations independently on the Hub, Hugging Face is creating a shared space for inspecting contracts, comparing alternatives, reproducing tests, and optimizing operations without having to integrate every shader directly into every runtime.
The collection also connects with the Hub’s broader kernel ecosystem, which includes implementations for CUDA, ROCm, Metal, and other platforms. This allows developers to explore and filter these artifacts in much the same way they already discover models and datasets.
The pieces serve different functions, but they reinforce one another:
- Repositories define transparent, versioned contracts.
@huggingface/kernelsmakes it easier to load and run operations from JavaScript.- Fleet gathers performance and correctness evidence from real hardware.
- Contributed executions help improve future variants and versions.
For those developing AI applications in the browser, this means having a more modular and observable layer. For people who use these tools without being specialists, it can translate into models that work faster and more reliably without sending every piece of data to a server.
Local AI doesn’t depend only on larger models. It also needs small, well-tested operations adapted to the device where they run. With @huggingface/kernels, Hugging Face is trying to turn this invisible part of the infrastructure into an open, measurable, and reusable component.