推論與開發工具
LiteRT.js 把 LiteRT 原生推論堆疊帶進瀏覽器,串接 WebGPU、Wasm 與實驗性 WebNN
Google 發布 LiteRT.js,讓網頁應用直接執行 `.tflite` 模型,並依裝置使用 CPU、GPU 或 NPU。它把瀏覽器端 AI 從 JavaScript 核心推向跨平台原生執行堆疊,但效能與相容性仍高度依賴瀏覽器及硬體。
Google 將裝置端推論框架 LiteRT 延伸至瀏覽器,推出 JavaScript/TypeScript 綁定 LiteRT.js。與過去主要依賴 JavaScript 核心的網頁推論方案不同,新執行期透過 WebAssembly 導入 LiteRT 的原生最佳化堆疊:CPU 路徑使用 XNNPACK,GPU 由 ML Drift 經 WebGPU 執行,NPU 則瞄準 WebNN。現有 `.tflite` 模型可在瀏覽器內完成載入、編譯與推論;PyTorch 模型也能先由 LiteRT Torch 轉換,並搭配逐層量化工具縮減模型與運算量。
這項改變的重要性不只在「離線執行」。模型與輸入資料留在客戶端,可降低伺服器推論成本、網路往返延遲及敏感資料外送風險,也讓物件偵測、音訊處理、向量搜尋和影像增強更接近即時互動。LiteRT 儲存庫採 Apache 2.0 授權,並將 WebGPU、Wasm 網頁推論列為正式能力;官方亦展示 YOLO、Depth Anything V2 與 Real-ESRGAN 等工作負載。
Google 宣稱,在一台 2024 年款 M4 MacBook Pro 的受控瀏覽器環境中,LiteRT.js 對部分傳統視覺與音訊模型最多比其他網頁執行期快 3 倍;WebGPU 或經 Apple Core ML 的 WebNN 路徑,相對 CPU 可達 5 至 60 倍加速。這些不是跨裝置通用結論:瀏覽器驅動、GPU 能力、散熱及算子覆蓋都會改變結果,而且 Chrome、Edge 的 WebNN 仍屬實驗功能。
工程團隊下一步應在目標裝置矩陣上量測冷啟動、模型下載、峰值記憶體、能耗與尾端延遲,而非只比較單次推論。也要追蹤 WebNN 的標準化與瀏覽器落地、生成式模型的算子覆蓋,以及量化後的品質退化;這些因素將決定 LiteRT.js 能否從展示案例進入大規模產品。