你在网页里打开一个本地 AI 应用，模型不用把数据传到云端，却可能迟迟不给结果。问题未必出在模型太大，也可能只是某一步基础计算走了慢路。就像厨房已经备齐食材，切菜、搅拌这些小动作却没有趁手工具，整顿饭还是快不起来。
Hugging Face 想补的正是这些底层工具。它在 2026 年 9 月 1 日发布了预览版 @huggingface/kernels，首批开源 207 个 WebGPU 内核。WebGPU 是浏览器调用本机 GPU 做通用计算的标准；“算子”是矩阵乘法、归一化等模型基本计算，“内核”则是让 GPU 真正执行这些计算的底层程序。内核更快，上层模型推理才有机会更快。
需要先说明：本专题的项目事实均来自 Hugging Face 自己的发布、博客及相关帖子，尚无独立复现。“世界最快”是发布方的表述，现有材料不足以把它写成公认结论。
它开源的不只是一堆代码
据 Hugging Face 介绍，这 207 个内核覆盖常见机器学习操作，并且每个内核都作为独立、带版本的软件包发布在 Hugging Face Hub 上。开发者可以按需取用，不必搬走整套库。
每个包还包含接口清单、正确性测试、基准案例、使用说明，以及用 WGSL 编写的模板。WGSL 是 WebGPU 使用的着色器语言，负责描述 GPU 实际执行的计算。同一个算子可以针对不同输入形状和设备准备不同实现。项目采用 Apache-2.0 许可证。
配套的 JavaScript 加载器负责下载、准备和运行内核。只要浏览器与设备支持 WebGPU，计算就能在用户设备上完成。不过，“本地运行”不等于所有模型、浏览器和硬件已经获得支持，也不代表每种环境都有同样的性能。
207 个内核，究竟快了多少？
Hugging Face 在 Apple M4 GPU 上，把 207 种操作的 1,756 个案例与 ONNX Runtime Web 对比。ONNX Runtime Web 是模型运行时——负责加载模型、安排运算并调度底层内核的软件层。
最终，只有 809 个输出一致且计时可靠的案例进入速度汇总。按官方报告，这部分案例的几何平均速度提升为 2.57 倍，中位数为 1.90 倍。几何平均更适合汇总倍率；中位数则表示，一半案例的加速高于 1.90 倍，另一半低于它。
最夸张的案例反而更像一则警示。某个规模为 4096 的双线性 Einsum——一种按指定规则组合张量的计算——在专用内核上约耗时 0.136 毫秒，在对照实现中约为 1396 毫秒，相差超过一万倍。Hugging Face 特意强调，这是异常的慢路径事故，不能代表整套模型通常会有如此提升。它说明的是另一件事：一个不起眼的算子一旦走上糟糕路径，就可能拖慢整个浏览器 AI 应用。
为什么这次开源值得关注？
浏览器本地 AI 过去缺的不只是模型，也包括一套可复用、可测试的 GPU 基础件。网页应用开发者当然可以自己优化，但重复编写两百多种底层计算既昂贵，也很难覆盖不同设备。把内核拆成独立软件包，并附上测试和基准，相当于为模型运行时提供一批可以逐件检查、替换和升级的标准零件。
Hugging Face 还表示，正尝试把这些优化上游合入 Transformers.js、ONNX Runtime Web、LiteRT.js 等项目。这里的“上游合入”是让改进进入广泛使用的模型运行时，而不是只停留在单独示例中。但这项工作仍在推进，不能写成已经完成。
设备差异是下一道难题。官方同时推出了浏览器内测试工具 Fleet，让用户在不同 GPU、浏览器和驱动环境里验证正确性与性能，并在同意后贡献结果。最初 1,756 个案例中有 947 个未进入速度汇总，也说明一台 Apple M4 无法代表真实世界。Fleet 的作用，就是把测试从单一实验环境扩展到更多实际设备。
局限与未知
- 现有速度数据来自 Hugging Face 在 Apple M4 GPU 上的自测，材料没有提供第三方复现。
- 测试只计算算子在 GPU 上的执行时间，不含加载、会话创建、数据上传、着色器编译和结果读取，因此不能直接等同于完整应用快 2.57 倍。
- 相关优化仍在尝试进入主流运行时。它们最终能覆盖哪些模型、浏览器和硬件，以及真实端到端收益多大，还要等待更广泛的测试。
这次发布真正重要的地方，不是一个醒目的“最快”头衔，而是浏览器本地 AI 得到了一批成体系、可测试、可继续集成的底层零件。如果这些内核经受住更多设备验证，并顺利进入常用运行时，它们才可能把整个浏览器 AI 生态的性能基线一起抬高。