Hugging Face 发布 207 个 WebGPU 内核：让本地 AI 推理更接近浏览器原生能力

Hugging Face 发布了 207 个 WebGPU 内核和 Fleet 浏览器基准工具，将浏览器端 AI 推理的底层矩阵运算、卷积、注意力等算子打包为可版本化、可测试的软件包，旨在提升不同 GPU/浏览器组合下的本地推理性能和可重复性。官方测试在部分用例上显示显著加速，但实际端到端收益仍依赖内核覆盖、跨设备验证和上层运行时整合。

Hugging Face 正在把浏览器端 AI 推理的优化工作进一步下沉到 GPU 操作层。公司 WebAI 团队于 2026 年 9 月 1 日发布 @huggingface/kernels，并在 Hugging Face Hub 上推出首批 207 个 WebGPU 内核，同时上线浏览器 GPU 基准测试工具 Fleet。

这套组合的重点并不在于再提供一个模型运行时，而是把矩阵乘法、归一化、卷积、注意力和量化等底层操作，整理成可发现、可测试、可复现和可版本化的软件包。Hugging Face 表示，这些内核采用 Apache-2.0 许可证，分别发布在 webgpu-kernels 组织下。

浏览器推理的瓶颈，不只在模型大小

近年来，Transformers.js 等工具已经可以借助 WebGPU，让模型直接在浏览器中使用本地 GPU。Hugging Face 的文档显示，开发者可以在加载模型时将设备设为 webgpu，运行文本嵌入、语音识别和图像分类等任务，而无需把数据先发送到服务器。

不过，WebGPU 提供的是跨浏览器的计算接口，并不意味着同一段着色器在所有硬件上都能达到相同性能。工作组大小、内存访问方式、向量化、数据类型和算子融合策略，都会影响最终速度；最佳实现还可能随输入形状、GPU、浏览器和驱动变化。

因此，一个浏览器端模型最终能跑多快，很大程度上取决于运行时调用的底层 GPU 操作。Hugging Face 此次选择从内核层切入，意在让上层运行时可以在保持稳定接口的同时，独立替换和优化这些基础组件。

每个内核都被包装成可验证的软件包

Hugging Face 强调，发布内容不是一批孤立的 WGSL 着色器，而是拥有独立仓库和说明卡片的完整内核包。以 ai.onnx.Add 为例，它实现神经网络中常见的逐元素加法，并支持包括广播在内的不同输入形状。

每个仓库包含以下几类信息：

• manifest.json：定义输入、输出、属性、类型约束和形状推导规则，是操作契约的来源；
• metadata.json：记录内核标识、摘要和来源信息；
• test.json：提供正确性测试用例；
• bench.json：提供用于基准测试和调优的工作负载；
• *.wgsl.jinja：保存可针对请求和设备生成着色器的参数化实现。

这种结构把“能运行的着色器”变成了更容易审查和复用的工程制品。开发者无需先阅读完整 WGSL 代码，就可以了解接口、支持的数据类型以及验证方式；应用也可以显式依赖某一个契约版本，而不是引用一个随时可能变化的文件地址。

JavaScript 加载器与 Fleet 如何工作

开发者可以通过 npm 安装预览版：

npm install @huggingface/kernels@preview

之后通过仓库 ID 和契约版本加载内核。例如，下面的代码调用 ai.onnx.Add，并将一个形状为 [3] 的数组广播到形状为 [2, 3] 的输入上：

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

加载器会根据内核清单和输入数据推导输出形状，并自动分配输出。Hugging Face 还指出，同一个操作可以拥有多个变体：等形状加法、向量化广播、标量处理和通用广播可能采用不同实现，但应用侧接口无需改变。

与内核发布同步上线的 Fleet 则试图解决另一个问题：实验室里的单台设备无法代表真实用户使用的 GPU、浏览器和驱动组合。用户可以在浏览器中运行正确性与性能测试，查看内核在自己设备上的表现；在获得同意后，运行结果还可以以隐私方式贡献给项目，用于发现设备特定故障、比较内核变体和调整选择规则。

官方测试显示部分操作有明显加速

Hugging Face 在一台 Apple M4 GPU 上，将这批内核与 ONNX Runtime WebGPU 进行比较。测试从 207 个操作的 1,756 个用例开始，最终保留双方都能产生匹配结果且计时可靠的 809 个用例。

官方给出的总体结果是：按几何平均计算，Hugging Face 的 WebGPU 内核快 2.57 倍；按中位数计算，快 1.90 倍。比较结果包括 629 次胜出、176 次落后和 4 次打平。

个别特殊用例的差距更大。例如，一个尺寸为 4096 的双线性 Einsum 用例，Hugging Face 内核耗时 0.136 毫秒，而 ORT WebGPU 为 1,396 毫秒；一个形状为 [256, 4096] 的逐行 CumSum 用例则快了 301 倍。

这些数字需要谨慎解读。测试测量的是 GPU 实际执行时间，不包括加载内核、创建会话、上传输入、编译着色器和读回输出等开销；它们还是单个操作的结果，不等于完整模型的端到端速度。短任务和小输入尤其容易受到固定调度成本以及缓存状态影响。

Hugging Face 也表示，团队正与 ONNX Runtime 合作，尝试将这些改进上游化，让更广泛的 ONNX Runtime Web 生态可以受益。

从“能在浏览器运行”走向“在不同设备上稳定运行”

这次发布的意义，在于浏览器端本地 AI 的竞争重点正在从“是否可以运行”转向“能否在复杂硬件环境中稳定、高效地运行”。对于开发者来说，@huggingface/kernels 提供了从 Hub 按需加载底层操作的方式；对于 Hugging Face 来说，独立仓库、可重复测试和 Fleet 反馈构成了一个持续改进的基础设施。

Hugging Face 过去也曾通过 Transformers.js 的 WebGPU 支持推动浏览器端推理。此次内核项目更接近该生态的底层：它不直接决定使用哪一个模型，而是试图改善模型运行过程中反复调用的基础 GPU 操作。类似的“把优化能力收回框架”的方向，也出现在 Hugging Face 将 Nunchaku 4-bit 扩散推理接入 Diffusers的尝试中：让原本分散在专用后端或复杂编译流程中的性能优化，更接近主流开发工作流。

但目前仍有几个问题没有答案。207 个内核覆盖范围能否跟上不断扩展的模型架构，Fleet 收集的跨设备证据能否转化为可靠的自动选择规则，以及官方测试中的收益能否稳定复现在不同浏览器和 GPU 上，都需要后续版本和更多公开数据验证。

就目前而言，Hugging Face 发布的是浏览器 AI 基础设施的一层新底座，而不是对所有本地模型都有效的统一加速承诺。它能否成为 WebAI 的共享性能层，将取决于内核覆盖、跨设备测试和上层运行时整合能否同步推进。

来源：Hugging Face 官方博客《Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI》；WebGPU 内核集合；@huggingface/kernels npm 包；Fleet 浏览器测试工具。