Hugging Face 发布 200+ WebGPU 内核，本地 AI 推理提速最高超万倍

[

](https://huggingface.co#introducing-huggingfacekernels-200-webgpu-kernels-for-local-ai)

推出 @huggingface/kernels：200+ 个用于本地 AI 的 WebGPU 内核

在 GitHub 上更新

今天，我们发布这项工作的第一层： @huggingface/kernels，一个用于从 Hugging Face Hub 加载并运行优化 WebGPU 内核的极简库，同时还有一批初始集合：

207 个内核，位于

huggingface.co/webgpu-kernels。

该集合涵盖了各种机器学习架构和工作负载中使用的操作。更重要的是，每个内核都作为完整、带版本的包发布：其接口、着色器模板、正确性用例、基准用例和使用说明都一起存放在 Hub 上。

我们还推出了 Fleet，这是一个浏览器内 GPU 基准测试与测试套件，可在你的硬件上运行并给内核评分。除了你自己机器的结果之外，Fleet 还为社区提供了一种方式，可以从传统测试实验室永远无法覆盖的设备上贡献性能和正确性证据。在征得你同意的情况下，每次运行都会添加私有证据，帮助我们发现问题（错误结果、异常缓慢的用例等）、改进内核变体，并在真实硬件上做出更好的优化决策。

[

](https://huggingface.co#tldr)

TL;DR

207 个 WebGPU 内核，作为独立仓库发布在该组织中。采用 Apache-2.0 许可。webgpu-kernels

一个 JavaScript 加载器，@huggingface/kernels

，可直接从 Hub 下载、准备并运行内核。每个内核都有明确的契约和可复现的证据，包括清单、正确性测试、基准用例和 WGSL 着色器模板。Fleet，一个基于浏览器的基准测试工具，众包来自真实 GPU 的正确性和性能证据，以帮助我们改进内核及其变体。

[

](https://huggingface.co#why-start-with-kernels)

为什么从内核开始？

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

然而，可移植性并不自动意味着性能。两个着色器可以实现相同的操作并产生相同的输出，但在不同的加速器上表现却可能完全不同。工作组大小、内存访问模式、向量化、数据类型和融合策略都会影响性能。最佳选择还可能随输入形状、设备、浏览器和可用的 WebGPU 特性而变化。

这就是为什么内核构成了快速浏览器推理的基础层。更高层的运行时最多只能和它们所调度的操作一样高效。通过让这些操作可单独发现、可测试、可基准测试且带版本，我们就可以独立改进基础层，同时为上层的各层保持稳定的契约。

[

](https://huggingface.co#a-kernel-repository-not-just-a-shader)

一个内核仓库，而不仅仅是一个着色器

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

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

ai.onnx.Add 仓库将其清单、正确性和基准测试用例以及 WGSL 着色器模板打包在一起。在卡片背后，仓库包含了理解和评估实现所需的工件：

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

记录内核标识符、摘要和来源。metadata.json

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

包含基准测试和调优用例，代表用于评估内核的工作负载。bench.json

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

这种结构将着色器转变为可复用的软件工件。无需阅读 WGSL 即可检查接口，正确性和性能用例随实现一起提供，并且可以显式加载已发布的版本，而不是依赖于未版本化的文件 URL。我们的内核还可以作为参考实现，供构建自定义 WebGPU 内核或将这些操作集成到自己的运行时中的开发者使用。

[

](https://huggingface.co#loading-a-kernel-from-the-hub)

从 Hub 加载内核

从 npm 安装包：

npm install @huggingface/kernels@preview

运行这些内核需要支持 [WebGPU] 的浏览器。WebGPU 的可用性取决于浏览器、操作系统、GPU 和驱动程序。你可以在 JavaScript 中使用 "gpu" in navigator 来检查它是否可用。

@huggingface/kernels

提供了内核仓库与你的应用程序之间的桥梁。使用 Hub 仓库 ID 和契约版本调用 getKernel，然后用带类型的输入数据和张量形状调用返回的函数。下面是一个简单的偏置相加示例：

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] 的输出

。加载器根据清单契约和输入推导出该输出形状与逻辑数据类型，然后自动分配 c

。

对六个浮点数做加法，是刻意选择的最小演示。在这个规模下，GPU 往返的开销远大于数学运算本身。重点在于调用模式：对于那些优化内核真正能带来收益的重量级运算（例如矩阵乘法 ai.onnx.MatMul

），调用模式完全一样。只有仓库 ID 和输入会变。

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

version: 1

选项选择已发布的内核契约的版本 1。它独立于 ONNX 算子集、算子的 since_version

或模型修订版本。将这些概念分开，可以让应用依赖稳定的面向 JavaScript 的契约，而内核实现则在其背后演进。

[

](https://huggingface.co#how-fast-are-the-kernels)

这些内核有多快？

那么，优化内核究竟能带来多大差别？我们在 Apple M4 GPU 上，使用 ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a

，将我们的集合与 ORT WebGPU 进行了正面比较。我们从全部 207 个算子的 1,756 个测试用例开始，保留了双方输出一致且计时可靠的 809 个用例。

在这些比较中，我们的内核几何平均快 2.57 倍，中位数快 1.90 倍，其中 629 胜、176 负、4 平。以下是四个常见运算的详细情况：

有些单项优势要大得多。一个特别困难的双线性 Einsum 用例（i,ij,j

，大小为 4096）用我们的内核运行耗时 0.136 ms，而 ORT WebGPU 为 1,396 ms：快超过 10,000 倍。对 [256, 4096]

做逐行 CumSum 快 301 倍，为 0.016 ms 对 4.784 ms。这些是特殊用例，而不是你在各处都应期望的加速，但它们表明当通用实现遇到慢路径时，专用内核能带来多大帮助。

我们计时的是 GPU 本身完成的工作，不包括加载内核、创建会话、上传输入、编译着色器和读回输出等设置。非常短的工作负载自然更难测量，小用例也可能受益于 GPU 缓存，因此这些数字最好被理解为有用的比较，而不是对每个应用的承诺。

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

我们也在与 ONNX Runtime 团队合作，将这些改进上游化，以便让更广泛的 ONNX Runtime Web 生态受益。

[

](https://huggingface.co#from-one-device-to-a-fleet)

从单台设备到设备集群

WebGPU 的性能因 GPU、浏览器和驱动程序而异，因此单台机器的结果只能说明部分情况。Fleet 让任何人都能在浏览器中运行正确性和性能检查，并查看这些内核在其硬件上的表现。

在获得同意的情况下，每次运行都会以私密方式贡献证据，帮助我们识别特定设备的故障、比较不同变体，并改进选择规则。目标很简单：利用广泛的真实世界覆盖，让这些内核对每个人来说都更快、更可靠。

[

](https://huggingface.co#building-a-shared-foundation-for-webai)

为 WebAI 构建共享基础

最初的 207 个内核只是起点，而非终点状态。在 Hub 上独立发布内核，为我们提供了一个共同的地方来检查契约、比较实现、复现正确性检查并改进性能，而无需将每个着色器直接嵌入到每个运行时中。

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

内核页面，按平台筛选。

这些部分相互强化：

• 内核仓库定义了透明、带版本的操作契约。 @huggingface/kernels

使这些操作可以直接从 JavaScript 加载和运行。- Fleet 众包了真实世界的证据，覆盖的设备范围远超传统基准测试实验室所能覆盖的。- 每一次贡献的运行都可以揭示故障、指导调优、改进变体选择，并帮助验证未来的内核版本。

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

探索 WebGPU 内核集合，试用 @huggingface/kernels，并

加入 Fleet从你的设备贡献证据，帮助我们让这些内核对每个人来说都更好。