每日突破性工具推薦｜ML Drift

ML Drift：Google 開源跨平台端側 GPU 推論引擎

推薦理由：Google AI Edge 於 2026-10-08 宣布以 Apache 2.0 開源 ML Drift。其突破不只是提升某個模型的速度，而是以統一的張量虛擬化、shader 模板及分階段推論最佳化，降低不同 GPU API 與硬體間的移植成本。

1. 定位與適用情境

ML Drift 是用於 on-device AI/ML inference 的 GPU compute engine，也是 Google LiteRT 的 GPU 加速核心。支援 OpenGL ES、OpenCL、Metal 與 WebGPU 等後端；既可隨 LiteRT 使用，也可作為獨立函式庫整合至自製圖形或推論執行環境。

適合行動裝置上的影像分割、相片處理、即時視訊特效、裝置端語言模型與桌面端本地 AI 推論。它不是訓練框架、網頁 UI 框架，也不是雲端 GPU 排程器。

2. 突破性重點

張量虛擬化（Tensor Virtualization）：將邏輯張量座標與實體 GPU texture/buffer 配置解耦，讓統一的 shader 模板在初始化階段映射到不同硬體後端，減少維護多套 shader 的成本。
可擴充 Custom Op：提供自訂運算註冊與底層 shading language 接入，並以 agentic SKILL.md 協助撰寫、註冊與驗證 custom shader；仍需開發者進行效能及正確性驗證。
5D Tensor：突破舊版 TFLite GPU delegate 偏重 4D tensor 的限制，改善 3D 卷積、時空模型等複雜工作負載的 GPU 路徑。
LLM 分階段最佳化：區分 KV cache prefill（偏計算密集）與逐 token decode（偏記憶體頻寬密集），切換 kernel 與資料布局；decode 路徑採用專門的 KV cache layout 與 in-kernel activation quantization。
桌面 WebGPU 路徑：藉由 Dawn 讓 WebGPU 後端在瀏覽器外運行，擴展 Windows、Linux 桌面推論的可攜性；桌面支援仍應依官方標示的成熟度評估。

3. 核心架構與運作方式

典型流程為：模型轉換或匯入 LiteRT → 建立編譯後執行圖 → ML Drift 將運算映射到 GPU kernels → 統一 shader 模板與張量虛擬化處理各 GPU API 的記憶體/座標差異 → 依裝置能力與模型運算執行 GPU 推論。

在生成式模型上，執行階段還會根據 prefill 或 decode 的不同瓶頸選擇適合的 kernel 與資料布局。這與單純把 CPU operator 逐一移植成 GPU shader 的方法不同。

4. 主要優勢與量測結果

跨平台工程效率：減少 OpenGL ES、OpenCL、Metal、WebGPU 後端重複開發。
可整合性：可透過 LiteRT 使用，也提供獨立整合方向。
實際產品驗證：Google 公布其已用於 Chrome、Google Photos、YouTube Shorts、Meet 等產品。
官方案例：Google 表示 YouTube Shorts 相關分割特效平均影格延遲最多降低約 40%；部分 Google Photos 工作流程相對舊 GPU delegate 加快最多約 2 秒；特定桌面 Gemma benchmark 的記憶體開銷最多降低約 12%。這些是特定硬體、模型與工作負載的結果，不應推論所有裝置皆有相同比例提升。

5. 與同類工具比較

工具	主要定位	ML Drift 相對優勢	取捨
舊 TFLite GPU delegate	傳統 TensorFlow Lite GPU 加速	更一致的跨後端 shader、5D tensor、生成式模型專用最佳化	需驗證舊模型的運算相容性與遷移成本
ONNX Runtime	多平台推論 Runtime，具多種 Execution Provider	ML Drift 聚焦端側 GPU 底層與 LiteRT 整合	ONNX Runtime 的模型生態與部署選項較廣
WebGPU 原生開發	自行控制 GPU compute/shader	減少直接處理多平台 GPU API 與推論 kernel 的工作	原生 WebGPU 在特殊演算法上可能提供更細緻控制
Core ML	Apple 生態的端側 ML	ML Drift 的跨 Android/桌面等平台策略更廣	專注 Apple 平台時 Core ML 的系統整合通常更直接

6. 缺點與限制

硬體與運算覆蓋率仍需實測：不同 GPU、driver、量化格式與 operator 可能有相容性差異；不能只看官方平均 benchmark。
導入成本：既有 ONNX/Core ML 或自製 runtime 需要評估模型轉換、custom op、工具鏈與維護負擔。
成熟度不均：行動端是核心重點，部分桌面 WebGPU 能力仍屬持續擴展的方向。
效能非普遍保證：大型模型仍受限於裝置記憶體、功耗、散熱及 GPU 頻寬。
底層工具複雜度：若只是要在 App 裡快速部署模型，直接使用 LiteRT 上層 API 通常更合適。

7. 適合與不適合

適合：端側推論框架作者、跨 Android/iOS/桌面的 AI 應用團隊、需要低延遲即時視覺效果的產品、要開發特殊 GPU operator 的工程師。

不適合：只部署雲端 LLM API 的團隊、完全不需要 GPU 的輕量工作負載、無法承擔跨裝置測試的短期專案，以及需要完整模型訓練平台的使用者。

8. 結論

ML Drift 值得關注的關鍵是架構統一，而非單一跑分。 它把端側 GPU 推論中最難維護的多後端 shader、tensor layout 和 LLM prefill/decode 最佳化集中成可重用引擎。若專案以 LiteRT 或跨平台 on-device AI 為核心，值得進行小規模基準測試；一般 App 開發者則可優先從 LiteRT 的高階 API 開始。