瀏覽器端 AI 推理（Browser Inference）的目標是讓 AI 模型能直接在使用者裝置上快速運行，而不需要依賴雲端伺服器。要達成這個目標，需要從模型表示法、執行計畫以及底層 GPU 操作等多個層面進行優化。其中，最底層的 GPU 操作直接決定了效能上限。雖然 WebGPU 提供了一個跨平台的 API，讓開發者能透過 WGSL（WebGPU Shading Language，一種用於編寫 GPU 著色器的語言）在現代瀏覽器中執行計算，但「可移植性」並不等同於「高效能」。
同樣的數學運算，在不同的硬體加速器、瀏覽器版本或驅動程式上，其執行效率可能天差地遠。影響因素包括工作群組大小（Workgroup sizes）、記憶體存取模式、向量化策略以及資料類型的選擇。因此，針對特定操作開發高度優化的算子（Kernels）至關重要。
核心內容：@huggingface/kernels 與算子庫
為了打破通用實作導致的效能瓶頸，Hugging Face 推出了 @huggingface/kernels 庫以及一個包含 207 個優化算子的集合。這套系統將每一個 GPU 算子視為一個獨立的軟體成品，而非單純的程式碼片段。
每個算子在 Hugging Face Hub 上都有專屬的儲存庫與說明卡，詳細記錄了該操作的語義、輸入輸出定義、支援的資料類型以及使用範例。例如，簡單的元素相加操作 ai.onnx.Add，不僅包含實作程式碼，還包含了 manifest.json（定義操作契約與形狀推導規則）、test.json（正確性測試案例）以及 bench.json（效能基準測試）。
最關鍵的技術在於 WGSL 著色器模板（*.wgsl.jinja）。系統會根據請求的具體形狀與裝置特性，動態產生最適合的著色器。這意味著當輸入資料形狀改變時，執行環境可以自動切換到更高效的變體（Variant），例如在等形狀相加時使用向量化路徑，而在廣播（Broadcasting）運算時使用不同的索引邏輯，而開發者在 JavaScript 層級調用的 API 則保持不變。
實務應用與效能提升
開發者可以透過 npm 安裝 @huggingface/kernels，並使用 getKernel 函式從 Hub 載入指定版本的算子。這種設計將 JavaScript 介面契約與底層實作分開，讓底層算子能持續演進而不會破壞上層應用程式的穩定性。
在效能測試方面，Hugging Face 將其算子庫與 ONNX Runtime (ORT) WebGPU 在 Apple M4 晶片上進行對比。結果顯示，在 809 個產出一致的測試案例中，Hugging Face 的算子在幾何平均值上快了 2.57 倍，中位數則快了 1.90 倍。
具體操作的提升幅度各異：基礎的 Add 操作快了 3.52 倍，LayerNormalization 快了 2.22 倍。而在某些極端案例中，提升幅度更為驚人，例如特定形式的 Einsum 運算比 ORT WebGPU 快了超過 10,000 倍，Row-wise CumSum 則快了 301 倍。這證明了當通用實作進入慢速路徑（Slow path）時，專門優化的算子能帶來決定性的效能突破。
群眾外包的測試體系：Fleet
由於 WebGPU 的效能極度依賴硬體與驅動程式的組合，單一實驗室的測試結果無法代表所有使用者。因此，Hugging Face 同時推出了 Fleet，這是一個在瀏覽器中運行的 GPU 基準測試與測試套件。
Fleet 允許全球使用者在自己的裝置上運行這些算子並回傳正確性與效能數據。在使用者同意的情況下，這些私有的執行證據將幫助開發團隊發現特定裝置上的錯誤（如計算結果不正確或異常緩慢的情況），進而優化算子變體並改進選擇規則。這種群眾外包（Crowdsourcing）的模式，讓 WebGPU 算子能在大規模真實世界的硬體環境中得到驗證。
影響與限制
這套算子庫為 WebAI 生態系建立了一個共享的基礎底層。透過將算子獨立化、版本化並在 Hub 上公開，開發者可以更輕鬆地比對實作、複現錯誤並提升效能，而無需將所有著色器直接內嵌在執行環境中。
然而，目前的效能數據僅針對單一操作（Individual operations）而非完整模型，且測試結果受 GPU 快取與環境影響，不能簡單地視為所有應用場景的保證。此外，WebGPU 的可用性仍受限於瀏覽器、作業系統與驅動程式的支援程度。
目前 Hugging Face 正與 ONNX Runtime 團隊合作，嘗試將這些優化成果回饋到上游生態系中，讓更多使用 ONNX Runtime Web 的開發者能直接獲益。這標誌著瀏覽器端 AI 推理正從「能跑」轉向「高效能」的階段。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。