浏览器 AI 提速：200+ GPU 内核不预编译、按设备现生成
浏览器里跑 AI 没有「通用最优内核」：kernel 是算子在具体硬件上的实现，设备不同、最优就不同。200+ 内核不是写死的程序，而是按你的设备在浏览器里现生成的模板。
核心论点 · 点时间戳可跳到原声
算子负责定义，内核负责在硬件上跑
逐字稿先分清两个概念：模型是一大张算子图，一个算子只是数学定义——加法就是 A+B；kernel 则是把定义落到特定硬件上的实现。同一个 add，浏览器里走 WebGPU / WGSL，其他生态则对应 CUDA 或 Metal kernel。两者常被混着说，但速度差恰恰出在后者：底层 kernel 快，整张推理图才可能快。这也解释了为什么值得为一个简单运算反复打磨内核，而不是笼统地调「通用数学库」。
发布的是 Jinja 模板，不是写死的内核
做法上的区别值得注意：仓库里不是一个个写死的 WGSL 文件，而是若干 Jinja 模板，里面用 if/else 描述不同设备的分支。执行时，库会校验模板、选定合适的数据类型与工作组大小，再渲染成对当前 GPU 适配器最合适的 WGSL 去跑。例如同一个加法函数，左边数据类型窄、工作组小；右边因设备支持更宽的数据类型和更大的工作组，同为 add 却跑得更快。官方发布 200 多个内核条目，真正交付的是「把内核按硬件现做」的能力。
注意力机制在浏览器里只要约 20 行 JS
演示把抽象落回实际：在浏览器里跑一小段注意力机制，只写了约 20 行 JavaScript。流程是文本→token→向量，但 token 的向量不能独立看，要在上下文里看其他 token 对它的影响。代码做的事只是从 Hub 调入 matmul、softmax、add、layer normalization 四个 kernel，剩下的调度与 GPU 数据交换都被 Hugging Face Kernels 库藏起来。重活全在 kernel 层，这才是「在浏览器里做本地推理」门槛下降的原因。
整片波浪动画其实只是一次矩阵乘法
同一个演示给出了直观对照：128 道波穿过 1024×1024 的矩阵，每个格子的颜色都是一个矩阵乘法算出的 RGBA。画面里一百多万个像素的动画在 WebGPU 下跑到约 60fps——60 并不是计算上限，只是 requestAnimationFrame 把渲染锁在 60，内核自己约能算到 400fps。同一套逻辑改用普通 JavaScript 跑，帧率大约只剩 6.75fps。差距不在数学，而在有没有人把它写成贴着这块 GPU 的实现——这正是那批内核在做的事。
Fleet 借测试把用户设备变成调优数据源
Fleet 表面上是个基准测试页：任何人都能跑自己的 GPU，看它在对比中表现如何。但项目方说得直白：团队只有自己手头的几台设备，真实世界却有成千上万种 WebGPU 设备，可能存在他们没想过的边界情况——某些 kernel 在你这台机器上表现不佳，甚至直接失败。Fleet 会把真实设备上的运行数据收回去继续优化，优化完的内核又因开源回到所有用户手里。你点一次 Run Benchmark，不只是看分数，还在替项目做一轮真实环境适配测试。
原话 · 已逐字校验
the kernel is the implementation that can actually run the operation.
kernel 就是那个能真正把运算跑起来的实现。
we don't ship WGSL files. We do ship Jinja files, so Jinja templates.
我们不发布 WGSL 文件，而是发布 Jinja 文件，也就是 Jinja 模板。
we basically have implemented an attention mechanism in pure JavaScript.
我们基本上只用纯 JavaScript 就实现了一个注意力机制。
We only need one kernel. We only need the matrix multiplication.
我们只需要一个 kernel，只需要那一次矩阵乘法。
All of that data is so valuable for us.
所有这些数据对我们来说都极其宝贵。
数字与实体
| 发布的 WebGPU kernels 数量 | 200+ | 0:03 |
| 开场动画编码单元数 | 约 8000 个 | 0:03 |
| 实现注意力所需 JS 行数 | 约 20 行 | 7:12 |
| 波浪动画矩阵规模 | 1024 行 × 1024 列 / 128 条波 | 8:12 |
| 波浪动画像素数 | 超过 100 万个 | 8:12 |
| GPU 实际帧率 | 约 60 fps（受 requestAnimationFrame 限制） | 8:12 |
| GPU 理论上可达到的帧率 | 约 400 fps | 9:14 |
| 纯 JavaScript 同任务帧率 | 约 6.75 fps | 9:14 |
术语
- kernel内核
- 一个算子在特定硬件上的实现；同一个加法在不同 GPU 上要跑不同的 kernel。
- WGSLWebGPU 着色语言
- WebGPU 环境下编写 kernel 的语言，是浏览器里与 GPU 沟通的桥梁。
- JinjaJinja 模板
- Python 模板引擎；HF 用 .jinja 文件描述内核，运行时再按设备渲染成 WGSL。
- WebGPUWebGPU
- 浏览器访问 GPU 的新一代 API，本地 AI 推理在浏览器端的计算底座。
- requestAnimationFramerequestAnimationFrame
- 浏览器驱动动画帧的循环回调，通常让画面帧率封顶在约 60fps。
收听指南
在浏览器里跑 LLM、做高性能前端 AI 应用的工程师，以及关注 WebGPU、WASM 本地推理方案的技术决策者。
开场 Demo 的代码讲解和结尾发布渠道介绍可倍速，重点看内核模板机制与 Fleet 数据回流部分。