Hugging Face开源200+ WebGPU内核赋能本地AI

今天，我们发布该计划的第一层成果：@huggingface/kernels，这是一个用于从 Hugging Face Hub 加载和运行优化 WebGPU Kernel 的轻量库，同时在 huggingface.co/webgpu-kernels 上线了首批 207 个 Kernel。

该集合覆盖了各类机器学习架构和workload中使用的操作。更重要的是，每个 Kernel 都以完整的版本化包形式发布：其接口、Shader 模板、正确性用例、基准测试用例和使用说明都一并存在于 Hub 上。

我们还上线了 Fleet，这是一款浏览器内 GPU 基准测试和测试套件，可在你的硬件上运行 Kernel 并评分。除了你自身机器的结果外，Fleet 还为社区提供了一种贡献性能和正确性证据的途径，覆盖了我们传统测试实验室永远无法覆盖的设备。在你同意的前提下，每次运行都会私有地贡献证据，帮助我们发现故障（错误结果、病态慢速case等）、改进 Kernel 变体，并在真实硬件上做出更好的优化决策。

207 个 WebGPU Kernel，以独立仓库形式发布在 webgpu-kernels 组织下。Apache-2.0 许可。

一个 JavaScript 加载器 @huggingface/kernels，直接从 Hub 下载、准备和运行 Kernel。

每个 Kernel 都有明确的契约和可复现的证据，包括 Manifest、正确性测试、基准测试用例和 WGSL Shader 模板。

Fleet，一个基于浏览器的基准测试工具，通过真实 GPU 上的众包正确性和性能证据，帮助我们改进 Kernel 及其变体。

为什么从 Kernel 入手？

在浏览器中运行的模型最终会变成一系列 GPU 操作：矩阵乘法、归一化、卷积、注意力原语、量化操作、数据布局转换，以及更多。WebGPU 通过一个可移植的 API 使这些操作在现代浏览器中可用，而 WGSL 则为执行这些操作的 Shader 提供了一种通用语言。

然而，可移植性并不自动等同于性能。两个 Shader 可以实现相同的操作并产生相同的输出，但在不同加速器上的表现却可能完全不同。Workgroup 大小、内存访问模式、向量化、数据类型和融合策略都会影响性能。最优选择也会因输入形状、设备、浏览器和可用的 WebGPU 功能而异。

这就是为什么 Kernel 是快速浏览器推理的基础层。更高级的运行时其效率上限取决于它们分派的操作。通过让这些操作各自可发现、可测试、可基准测试和可版本化，我们可以在保持上层稳定契约的同时，独立地改进基础层。

一个 Kernel 仓库，而非仅有一个 Shader

集合中的每个 Kernel 都有其自己的仓库和 Kernel Card。Card 记录了操作的语义、输入、输出、属性、支持的数据类型、源文件，以及一个可直接运行的 @huggingface/kernels 示例。

例如，ai.onnx.Add 实现了具有多方向广播的元素级加法。它是神经网络中最简单的操作之一，从残差连接到加偏置无处不在。它的 Card 记录了两个输入、广播后的输出形状、支持的数据类型，以及针对不同形状和设备的可用变体。

ai.onnx.Add 仓库将其 Manifest、正确性和基准测试用例以及 WGSL Shader 模板打包在一起。

在 Card 背后，仓库包含理解和评估实现所需的产物：

manifest.json 是操作契约的事实来源。它定义了输入、输出、属性、类型约束和形状推导规则。

metadata.json 记录了 Kernel 标识符、摘要和出处。

test.json 包含正确性用例，因此可以针对预期行为检查实现。

bench.json 包含代表用于评估 Kernel 的workload的基准测试和调优用例。

*.wgsl.jinja 文件包含参数化的 WGSL 实现，用于为特定请求和设备生成 Shader。

这种结构将 Shader 转化为可重用的软件产物。接口无需阅读 WGSL 即可检查，正确性和性能用例随实现一起分发，发布的版本可以显式加载而不依赖无版本的文件 URL。我们的 Kernel 还可以作为开发人员构建自定义 WebGPU Kernel 或将这些操作集成到自身运行时的参考实现。

从 Hub 加载 Kernel

从 npm 安装包：

npm install @huggingface/kernels@preview

运行这些 Kernel 需要支持 WebGPU 的浏览器。WebGPU 可用性取决于浏览器、操作系统、GPU 和驱动程序。你可以用 JavaScript 通过 "gpu" in navigator 来检查。

@huggingface/kernels 在 Kernel 仓库和你的应用之间提供了桥梁。用 Hub 仓库 ID 和契约版本调用 getKernel，然后用类型化的输入数据和张量形状调用返回的函数。下面是一个小的 bias-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],
  },
});

第二个输入沿第一个维度广播，生成形状为 [2, 3] 的输出。加载器从 Manifest 契约和输入推导出输出形状和逻辑数据类型，然后自动分配 c。

对六个浮点数做加法是刻意设计的最小可行演示。在这个大小下，GPU 往返开销远大于计算本身。关键是调用模式：当优化的 Kernel 真正发挥作用的重量级操作（如矩阵乘法 ai.onnx.MatMul）上时，调用模式完全相同。只是仓库 ID 和输入变了。

即便是这个基础操作也说明了 Kernel 为什么需要变体。等形状加法可以使用直接的向量化路径，而广播输入需要不同的索引逻辑。发布的 Add Kernel 包含等形状、向量化广播、标量处理和通用广播的变体。运行时可以选择适合当前调用和设备的实现，而无需更改应用层面的 API。

version: 1 选项选择已发布 Kernel 契约的版本 1。它独立于 ONNX opset、operator 的 since_version 或模型修订版。将这些概念分离让应用可以依赖一个稳定的 JavaScript 层面的契约，而 Kernel 实现在其背后演进。

这些 Kernel 有多快？

那么，优化后的 Kernel 实际上能带来多大差异？我们在 Apple M4 GPU 上将我们的集合与 ORT WebGPU 正面交锋，使用的是 ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a。我们从 1,756 个测试用例开始，涵盖全部 207 个操作，最终保留了 809 个双方都产生匹配输出且计时可靠的用例。

在这些比较中，我们的 Kernel 几何平均快 2.57 倍，中位数快 1.90 倍，629 胜 176 负 4 平。下面是四个常见操作的详细对比：

一些个别胜出要大得多。一个特别困难的 双线性 Einsum（i,ij,j，尺寸 4096）在我们的 Kernel 上仅用 0.136 毫秒，而 ORT WebGPU 用时 1,396 毫秒：快了超过 10,000 倍。一个在 [256, 4096] 上的行级 CumSum 快了 301 倍，0.016 毫秒对 4.784 毫秒。这些是异常case而非你应该期望的普遍加速，但它们展示了当通用实现撞上慢速路径时，专用的 Kernel 可以带来多大帮助。

我们计时的仅限 GPU 上完成的工作，排除了加载 Kernel、创建会话、上传输入、编译 Shader 和读回输出等设置开销。非常短的工作负载自然更难测量，小case可能受益于 GPU 缓存，所以这些数字最好理解为有意义的对比，而非对每个应用的承诺。

它们也是针对单个操作的结果，而非完整模型。确切性能会因 GPU 和浏览器而异，这就是 Fleet 对构建更全面的图景如此重要的原因。

我们还正在与 ONNX Runtime 团队合作将这些改进上游化，以使更广泛的 ONNX Runtime Web 生态系统受益。

从一台设备到一个舰队

WebGPU 性能因 GPU、浏览器和驱动程序而异，所以一台机器的结果只能说明部分情况。Fleet 让任何人都能在浏览器中运行正确性和性能检查，并了解 Kernel 在其硬件上的表现。

在同意的前提下，每次运行都会私有地贡献证据，帮助我们发现设备特定的故障、比较变体和改进选择规则。目标很简单：利用广泛、真实的覆盖范围，让每个人的 Kernel 更快、更可靠。

为 WebAI 构建共享基础

首批 207 个 Kernel 是一个起点，而非终态。在 Hub 上独立发布 Kernel 为我们提供了一个共同的地方来检查契约、比较实现、重现正确性检查，以及在不为每个运行时嵌入每个 Shader 的情况下改进性能。

该集合也是 Hub 更广泛的 Kernel 生态系统的一部分：在 Kernels 页面上，WebGPU Kernel 与 CUDA、ROCm、Metal 和其他平台的 Kernel 并列，可以像 Hub 上的任何其他产物一样进行过滤、排序和探索。

各个部分相互强化：

Kernel 仓库定义了透明、版本化的操作契约。

@huggingface/kernels 使这些操作从 JavaScript 加载和运行变得简单直接。

Fleet 通过比传统基准测试实验室覆盖范围广得多的真实设备众包真实世界的证据。

每次贡献的运行都可能揭示故障、指导调优、改进变体选择，并帮助验证未来的 Kernel 版本。

这是我们浏览器推理栈下一步的低层基础。我们很高兴将这些 Kernel 连接到更高级的模型工具链上，继续扩展操作覆盖范围，并让快速本地推理在整个 WebAI 生态系统中更容易使用。

探索 WebGPU Kernel 集合，试用 @huggingface/kernels，并加入 Fleet 从你的设备贡献证据，帮助我们让 Kernel 为每个人变得更好。