Hugging Face WebAI 團隊的目標是讓瀏覽器推論既快速又好用。這需要多層次的努力：模型需要適合瀏覽器的表示方式，執行時需要建立高效的執行計畫，而底層的個別 GPU 操作則需充分利用各種裝置和瀏覽器實作。

今天，我們發布了這項努力的第一層成果：@huggingface/kernels，這是一個輕量級函式庫，用於從 Hugging Face Hub 載入並執行優化的 WebGPU 核心函式庫。同時，我們也在 huggingface.co/webgpu-kernels 上提供了最初的 207 個核心函式庫集合。

這個集合涵蓋了廣泛機器學習架構和工作負載中使用的操作。更重要的是，每個核心函式庫都以完整、版本化的套件形式發布：其介面、著色器模板、正確性測試案例、基準測試案例和使用說明都一同存放在 Hub 上。

我們也同步推出了 Fleet，這是一個瀏覽器內的 GPU 基準測試和測試套件，可以在您的硬體上執行並評分這些核心函式庫。除了您自己機器的結果，Fleet 還為社群提供了一種方式，可以貢獻我們在傳統測試實驗室中無法涵蓋的裝置的效能和正確性證據。在您同意的情況下，每次執行都會增加私人證據，幫助我們發現故障（不正確的結果、異常緩慢的案例等）、改進核心函式庫變體，並在真實世界的硬體上做出更好的優化決策。

簡而言之：

207 個 WebGPU 核心函式庫，以獨立儲存庫的形式發布在 webgpu-kernels 組織中，採用 Apache-2.0 授權。

一個 JavaScript 載入器，@huggingface/kernels，可以直接從 Hub 下載、準備和執行核心函式庫。

每個核心函式庫都有明確的合約和可重現的證據，包括清單、正確性測試、基準測試案例和 WGSL 著色器模板。

Fleet，一個基於瀏覽器的基準測試工具，透過眾包方式收集真實世界 GPU 的正確性和效能證據，以幫助我們改進核心函式庫及其變體。

為什麼從核心函式庫開始？

模型在瀏覽器中運行最終會變成一系列的 GPU 操作：矩陣乘法、正規化、卷積、注意力原語、量化操作、資料佈局轉換等等。WebGPU 透過可攜式 API 在現代瀏覽器中提供這些操作，而 WGSL 則為執行它們的著色器提供了一種通用語言。

然而，可攜性並不自動意味著效能。兩個著色器可以實作相同的操作並產生相同的輸出，但在不同的加速器上表現卻完全不同。工作組大小、記憶體存取模式、向量化、資料類型和融合策略都可能影響效能。最佳選擇也可能隨著輸入形狀、裝置、瀏覽器和可用的 WebGPU 功能而改變。

這就是為什麼核心函式庫構成了快速瀏覽器推論的基礎層。高階執行時的效率只能與其調度的操作一樣高。透過使這些操作能夠獨立地被發現、測試、基準測試和版本化，我們可以在保持其上層穩定合約的同時，獨立改進基礎。

不僅僅是著色器，而是一個核心函式庫儲存庫

集合中的每個核心函式庫都有自己的儲存庫和核心函式庫卡片。卡片記錄了操作的語義、輸入、輸出、屬性、支援的資料類型、原始檔案以及一個可立即執行的 @huggingface/kernels 範例。

例如，ai.onnx.Add 實作了具有多向廣播功能的元素級加法。它是神經網路中最簡單的操作之一，從殘差連接到添加偏差都隨處可見。其卡片記錄了兩個輸入、廣播後的輸出形狀、支援的資料類型以及適用於不同形狀和裝置的變體。

ai.onnx.Add 儲存庫將其清單、正確性與基準測試案例以及 WGSL 著色器模板打包在一起。

在卡片背後，儲存庫包含理解和評估實作所需的構件：

manifest.json 是操作合約的真實來源。它定義了輸入、輸出、屬性、類型約束和形狀推導規則。

metadata.json 記錄了核心函式庫識別碼、摘要和來源。

test.json 包含正確性測試案例，因此可以根據預期行為檢查實作。

bench.json 包含基準測試和調優案例，代表用於評估核心函式庫的工作負載。

*.wgsl.jinja 檔案包含參數化的 WGSL 實作，用於為特定請求和裝置生成著色器。

這種結構將著色器轉變為可重用的軟體構件。無需閱讀 WGSL 即可檢查介面，正確性和效能案例隨實作一起傳播，並且可以明確載入已發布的版本，而不是依賴未版本化的檔案 URL。我們的核心函式庫也可以作為開發人員建構自訂 WebGPU 核心函式庫或將這些操作整合到其自身執行時的參考實作。

從 Hub 載入核心函式庫

從 npm 安裝套件：

npm install @huggingface/kernels@preview

執行這些核心函式庫需要支援 WebGPU 的瀏覽器。WebGPU 的可用性取決於瀏覽器、作業系統、GPU 和驅動程式。您可以在 JavaScript 中使用 "gpu" in navigator 進行檢查。

@huggingface/kernels 提供了核心函式庫儲存庫與您的應用程式之間的橋樑。呼叫 getKernel 並傳入 Hub 儲存庫 ID 和合約版本，然後使用類型化的輸入資料和張量形狀調用返回的函數。這是一個小的偏差加法範例：

```javascript

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],

},

});

```

第二個輸入在第一個維度上進行廣播，產生形狀為 [2, 3] 的輸出。載入器從清單合約和輸入中推導出該輸出形狀和邏輯資料類型，然後自動分配 c。

對六個浮點數進行加法運算是刻意選擇的最小示範。在這個大小下，GPU 往返成本遠高於數學運算本身。重點在於呼叫模式：對於優化核心函式庫真正發揮作用的重量級操作，例如矩陣乘法 (ai.onnx.MatMul)，呼叫模式保持完全相同。只有儲存庫 ID 和輸入會改變。

即使是這個基本操作也說明了為什麼核心函式庫需要變體。等形狀的加法可以使用直接向量化路徑，而廣播輸入則需要不同的索引邏輯。已發布的 Add 核心函式庫包含等形狀、向量化廣播、純量處理和通用廣播的變體。執行時可以選擇適合當前呼叫和裝置的實作，而無需更改面向應用程式的 API。

version: 1 選項選擇已發布核心函式庫合約的版本 1。它與 ONNX opset、運算子的 since_version 或模型修訂版是分開的。將這些概念分開，可以讓應用程式依賴穩定的 JavaScript 介面合約，同時核心函式庫實作在其背後演進。

核心函式庫有多快？

那麼，優化的核心函式庫究竟能帶來多大的差異？我們在 Apple M4 GPU 上，使用 ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a，將我們的集合與 ORT WebGPU 進行了正面比較。我們從所有 207 個操作的 1,756 個測試案例開始，並保留了 809 個雙方產生匹配輸出和可靠計時的案例。

在這些比較中，我們的核心函式庫在幾何平均數上快了 2.57 倍，中位數上快了 1.90 倍，其中有 629 次獲勝，176 次失敗，4 次平手。以下是四個常見操作的詳細比較：

| 操作 | 比較案例 | 我們的 WebGPU 核心函式庫 | ORT WebGPU | 加速倍數 |

|:---------------|:---------|:-----------------------|:-----------|:---------|

| Add | 5 | 0.064 ms | 0.227 ms | 3.52x |

| MatMul | 29 | 0.115 ms | 0.131 ms | 1.14x |

| Softmax | 12 | 0.114 ms | 0.240 ms | 2.11x |

| LayerNormalization | 6 | 0.061 ms | 0.135 ms | 2.22x |

一些個別的勝利要大得多。一個特別困難的雙線性 Einsum 案例（i,ij,j，大小為 4096）使用我們的核心函式庫運行僅需 0.136 毫秒，而使用 ORT WebGPU 則需要 1,396 毫秒：快了超過 10,000 倍。對 [256, 4096] 進行逐行 CumSum 則快了 301 倍，從 4.784 毫秒降至 0.016 毫秒。

這些是異常案例，而不是您應該在所有地方都期望的加速，但它們顯示了當通用實作遇到慢速路徑時，專用核心函式庫能提供多大的幫助。

我們測量的是 GPU 本身完成的工作時間，不包括載入核心函式庫、建立會話、上傳輸入、編譯著色器和讀回輸出等設定時間。非常短的工作負載自然更難測量，小案例也可能受益於 GPU 快取，因此這些數字最好被視為有用的比較，而不是對每個應用程式的承諾。

它們也是個別操作的結果，而不是完整模型的結果。確切的效能會因 GPU 和瀏覽器而異，這就是為什麼 Fleet 對於建立更廣泛的圖景如此重要。

我們也正在與 ONNX Runtime 團隊合作，將這些改進上游，以便它們能惠及更廣泛的 ONNX Runtime Web 生態系統。

從單一裝置到艦隊

WebGPU 效能因 GPU、瀏覽器和驅動程式而異，因此單一機器的結果只說明了部分情況。Fleet 讓任何人都能在瀏覽器中執行正確性和效能檢查，並查看核心函式庫在其硬體上的表現。

經同意後，每次執行都會私下貢獻證據，幫助我們發現特定裝置的故障、比較變體並改進選擇規則。目標很簡單：利用廣泛的真實世界覆蓋範圍，使核心函式庫對每個人都更快、更可靠。

為 WebAI 建立共享基礎

最初的 207 個核心函式庫是一個起點，而不是終點。在 Hub 上獨立發布核心函式庫，為我們提供了一個共同的地方來檢查合約、比較實作、重現正確性檢查並改進效能，而無需將每個著色器直接嵌入到每個執行時中。

這個集合也是 Hub 更廣泛核心函式庫生態系統的一部分：在核心函式庫頁面上，WebGPU 核心函式庫與 CUDA、ROCm、Metal 和其他平台的核心函式庫並列，可以像 Hub 上的任何其他構件一樣進行篩選、排序和探索。

Hub 核心函式庫頁面上的所有 207 個 WebGPU 核心函式庫，按平台篩選。

各個部分相互強化：

核心函式庫儲存庫定義了透明、版本化的操作合約。

@huggingface/kernels 使這些操作可以從 JavaScript 輕鬆載入和執行。

Fleet 透過眾包方式收集了比傳統基準測試實驗室所能涵蓋的更廣泛裝置的真實世界證據。

每次貢獻的執行都可以揭示故障、指導調優、改進變體選擇，並幫助驗證未來核心函式庫版本。

這是我們瀏覽器推論堆疊中下一步的底層基礎。我們很高興能將這些核心函式庫連接到更高層次的模型工具，繼續擴大操作覆蓋範圍，並使快速本地推論在整個 WebAI 生態系統中更易於使用。

探索 WebGPU 核心函式庫集合，試用 @huggingface/kernels，並加入 Fleet 貢獻您裝置的證據，幫助我們讓核心函式庫對每個人都更好。