Hugging Face於9月1日釋出@huggingface/kernels，這是一套JavaScript載入函式庫，用來從Hub下載、準備並執行最佳化過的WebGPU核心。同時上線的還有207個已調校好的GPU運算元，涵蓋矩陣乘法、正規化、卷積、注意力機制的基本運算、量化運算與資料排列轉換，橫跨多種機器學習架構，授權採用Apache-2.0。
組織方式是這套東西最特別的地方：每個核心都以獨立儲存庫發布，各自帶著介面定義、著色器樣板、正確性測試與效能基準資料。放上Hub之後，一個運算元和一個模型在版本管理、下載與引用上走的是同一套機制。
809組對照測試
效能數據是與ORT WebGPU 1.30.0-dev版本直接比較，樣本為809個測試案例：幾何平均加速2.57倍，中位數加速1.90倍，勝負紀錄為629勝176敗4平。拆到個別運算元來看，Add快3.52倍，Softmax快2.11倍，LayerNormalization快2.22倍。
粗略換算下來勝率大約是78%。幾何平均2.57倍明顯高於中位數1.90倍，代表加速幅度的分布是右偏的——少數運算元加速特別多，把平均值拉高了。實際負載能感受到的提速，機率上會比較接近中位數這一檔,而不是宣傳裡最亮眼的那個數字。這不影響結論的方向，只是把期待值擺回原位。
搭配核心一起推出的還有一款名為Fleet的瀏覽器內建效能測試工具,構想是眾包:誰的機器跑過,效能與正確性的證據就回饋一份。WebGPU的硬體碎片化程度比伺服器端CUDA嚴重許多,內顯、獨顯、行動裝置GPU與不同瀏覽器實作之間表現差異很大,光靠實驗室裡幾台機器測不出全貌。把測試分散給使用者做,是務實的解法。
為什麼卡在核心這一層
瀏覽器端跑模型的吸引力一直很明確:運算發生在使用者裝置上,伺服器不用出算力錢,資料也不必離開本機。落地卡關的原因通常不在模型格式,也不在推理框架,而是在下面那一層——核心。同一個Softmax,寫得好和寫得普通,差別就在能不能做到即時運算。
過去這一層只能跟著推理執行環境整體升級。想換一個更快的注意力機制實作,通常得等框架推出新版本。拆成獨立儲存庫之後,運算元變成可以單獨替換、單獨回滾、單獨改進的單位。針對特定GPU最佳化的矩陣乘法核心,理論上可以只換給某個模型用,不必動到其餘任何程式碼。
呼叫方式也壓得很精簡,拿到核心物件之後直接當函式用:
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });執行的前提是瀏覽器支援WebGPU,偵測方式只要一行:"gpu" in navigator。
對端側工具的意義
這波更新受益的對象很具體:做純瀏覽器影像處理、本機語音轉文字、離線翻譯、隱私敏感型工具的團隊。這類產品的商業模式建立在伺服器只發送靜態檔案、不用負擔運算成本上,能塞進瀏覽器的模型規模,直接由核心效能決定。核心整體快上一倍,可用模型的參數量上限就往上挪一階,原本要等三秒的操作能壓進一秒內完成。
保守的部分也要講清楚。基準比較的對象是ORT WebGPU的一個開發版本,對手也在持續迭代;207個核心聽起來不少,但涵蓋的是常見運算,遇到冷門架構還是得自己寫。WebGPU在各瀏覽器上的支援度雖然已經鋪開,但行動裝置端的實作品質參差不齊,跨裝置表現還是得自己拿Fleet之類的工具測一遍。
把核心做成可定址、可版本化、可眾包驗證的資產,比單純快一倍這件事影響更深遠。模型權重早就是這樣流通的,基礎設施程式碼跟上來,只是時間問題。
參考來源:Hugging Face官方部落格、CocoLoop、Hugging Face Hub儲存庫;207個核心數量、809個測試案例、幾何平均2.57倍與中位數1.90倍加速、629勝176敗4平的勝負紀錄及個別運算元倍率,均依官方公告核對,勝率與分布偏態部分為編輯部粗略估算。