瀏覽器 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 數據迴流部分。