On September 1, 2026, Hugging Face released @huggingface/kernels, a minimal JavaScript library that loads and runs optimized WebGPU kernels directly from the Hugging Face Hub. The launch includes an initial collection of 207 kernels published under the webgpu-kernels organization.

Each kernel ships as a versioned package containing its interface, WGSL shader templates, correctness tests, benchmark cases, and usage documentation — all discoverable on the Hub. The company also introduced Fleet, an in-browser benchmarking suite that runs correctness and performance checks on the user's GPU. With consent, each run privately contributes evidence to help the community spot device-specific failures and improve kernel selection across real-world hardware.

What's new

  • 207 WebGPU kernels covering operations used across ML architectures: matrix multiplications, normalizations, convolutions, attention primitives, quantization ops, and data-layout transforms.
  • Apache-2.0 licensed and published as individual repositories (e.g., webgpu-kernels/ai.onnx.Add) with a kernel card documenting semantics, inputs, outputs, attributes, supported data types, and ready-to-run examples.
  • Explicit contracts via manifest.json (operation contract), metadata.json (provenance), test.json (correctness cases), bench.json (benchmark/tuning cases), and parameterized *.wgsl.jinja shader templates.
  • JavaScript loader @huggingface/kernels (install via npm install @huggingface/kernels@preview) that downloads, prepares, and invokes kernels with typed tensor inputs; the loader derives output shapes and data types from the manifest.
  • Fleet benchmarking tool runs in the browser, scores kernels on local hardware, and crowdsources private performance/correctness evidence to improve variants and selection rules.

How it works

A kernel repository packages everything needed to inspect and evaluate the implementation without reading WGSL. The manifest.json defines inputs, outputs, attributes, type constraints, and shape derivation rules. Variants for the same operation (e.g., equal-shape vs. broadcasted addition) let the runtime pick the best implementation for the current call and device without changing the application-facing API. Versioning is separate from ONNX opsets or model revisions, so applications can depend on a stable JavaScript contract while kernel implementations evolve behind it.

Example bias-add call:

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

Performance compared to ORT WebGPU

Hugging Face benchmarked the collection against ONNX Runtime Web 1.30.0-dev (2026-08-26 build) on an Apple M4 GPU. Across 809 matching test cases (of 1,756 total), the new kernels were 2.57× faster by geometric mean and 1.90× faster at the median, with 629 wins, 176 losses, and 4 ties. Highlights:

  • Add: 3.52× speedup (0.064 ms vs 0.227 ms, 5 cases)
  • MatMul: 1.14× speedup (0.115 ms vs 0.131 ms, 29 cases)
  • Softmax: 2.11× speedup (0.114 ms vs 0.240 ms, 12 cases)
  • LayerNormalization: 2.22× speedup (0.061 ms vs 0.135 ms, 6 cases)

Outlier cases showed larger gains. A bilinear Einsum (i,ij,j size 4096) ran 10,000× faster (0.136 ms vs 1,396 ms). A row-wise CumSum over [256, 4096] was 301× faster (0.016 ms vs 4.784 ms). Timings measure GPU work only, excluding setup, compilation, and I/O. Results are for individual operations, not full models, and will vary across GPUs and browsers.

Why it matters

WebGPU provides a portable API across browsers, but portability does not guarantee performance. Workgroup sizes, memory access patterns, vectorization, and fusion strategies all affect speed. The optimal choice shifts with input shape, device, browser, and available WebGPU features. By making kernels individually discoverable, testable, benchmarkable, and versioned, Hugging Face creates a shared foundation that higher-level runtimes can build on. The team is working with ONNX Runtime Web to upstream improvements. Fleet extends the test lab from a handful of devices to the installed base of WebGPU-capable browsers, turning every opted-in run into signal for better variant selection and regression detection.

Our take

The kernel-as-repository model turns opaque shader blobs into auditable, versioned artifacts with contracts, tests, and benchmarks that travel with the code. If Fleet adoption scales, the crowdsourced evidence loop could solve WebGPU performance fragmentation across GPU vendors, driver stacks, and browser implementations — something no single vendor's test lab can cover.

Sources