推論系統與開發工具
Google 推出 LiteRT.js，將原生 LiteRT 推論路徑帶進瀏覽器
LiteRT.js 透過 WebAssembly 封裝 Google 的跨平台推論執行期，並以 XNNPACK、WebGPU 與實驗性 WebNN 分別對應 CPU、GPU 與 NPU。它讓既有 `.tflite` 模型更容易移至用戶端執行，但效能與相容性仍高度取決於瀏覽器及裝置。
Google 發布 LiteRT.js，為 LiteRT 新增 JavaScript／TypeScript 介面，讓網頁直接載入、編譯及執行 `.tflite` 模型。這次改變的重點不是再造一套 JavaScript 運算核心，而是把原生 LiteRT 執行期編譯為 WebAssembly，將既有的算子最佳化、量化流程與硬體後端帶進瀏覽器。
CPU 路徑採用支援多執行緒與 SIMD 的 XNNPACK；GPU 路徑由 ML Drift 經 WebGPU 執行；NPU 則預計透過 WebNN 接入，目前在 Chrome、Edge 仍屬實驗功能。LiteRT Torch 可轉換 PyTorch 模型，AI Edge Quantizer 能按層配置量化方案。官方也提供 TensorFlow.js 互通套件，因此既有應用可保留前後處理程式，只替換模型執行層，降低遷移成本。
Google 表示，在視覺與音訊模型測試中，LiteRT.js 對其他 Web 執行期最高快約三倍；使用 GPU 或 NPU 時，相對其 CPU 路徑可達五至六十倍加速。不過這些數字來自受控環境中的 2024 年款 M4 MacBook Pro，不能直接外推至 Android 裝置、Windows PC 或不同瀏覽器；驅動、散熱、算子覆蓋與資料搬移都可能改變結果。
對工程團隊而言，價值在於把小型語言模型、物件偵測、語音處理、向量搜尋與影像增強移至用戶端，減少伺服器推論費用、往返延遲及原始資料外傳。然而模型權重仍須下載到裝置，既增加首次載入成本，也不能視為保護模型智慧財產的方案。
接下來應觀察 WebNN 是否形成跨瀏覽器一致的 NPU 介面、生成式模型的記憶體管理與算子覆蓋是否成熟，以及官方基準能否在更多硬體上重現。正式採用前，開發者仍需測量冷啟動、權重快取、峰值記憶體、回退至 WASM 的算子比例與端到端耗電。