背景：裝置端 AI 的 GPU 碎片化難題
裝置端 AI 推論這幾年成為行動與桌面應用的重要戰場。開發者想把模型直接跑在使用者的手機、筆電或各種邊緣裝置上，以降低延遲、減少雲端成本並保護隱私，但真正落地時常遇到一個根本問題：GPU 硬體太多樣。不同廠牌的 GPU 架構、不同版本的驅動程式、不同平台偏好的底層圖形 API，讓開發者難以事先知道應用最終會跑在什麼硬體上。若針對單一平台深度最佳化，移植到另一個平台就得重寫大量邏輯；若只求通用，又容易犧牲效能。
Google 在 2026 年 10 月發布 ML Drift，正是針對這個問題而來。根據 InfoQ 作者 Sergio De Simone 在同年 10 月 25 日的報導，ML Drift 是一套開源、跨平台的 GPU 運算引擎，定位在裝置端 AI 與機器學習推論。它以 Apache 2.0 授權釋出，核心價值是把不同 GPU 硬體與低階 API 的複雜度抽象化，支援 OpenGL ES、OpenCL、Metal 與 WebGPU 等圖形與運算介面。它也是驅動 LiteRT 的核心 GPU 加速引擎；Google 將其開源，等於讓開發者能在此基礎上打造自訂的圖形與推論執行環境，應用範圍從傳統電腦視覺、音訊、深度處理，一路延伸到生成式 AI。
核心內容：ML Drift 的技術設計與相容策略
ML Drift 的目標很明確：為可攜性與效能建立新基礎。Google 說法是，它要同時提供傳統機器學習的穩定性與最先進生成式 AI 的峰值效能。為了達成這點，ML Drift 相較於過去 TensorFlow Lite 的 GPU delegate 做了多項技術調整，包括透過張量虛擬化實現統一著色器、可擴充的自訂操作，以及五維張量支援。所謂張量虛擬化，是把邏輯上的張量描述與實際的記憶體配置、硬體布局脫鉤，讓同一套著色器邏輯能跨不同 GPU 後端運作，減少為每種硬體重寫著色器的負擔。五維張量支援則讓需要更高維度表徵的空間模型與 transformer 模型，不必再靠 layout hacks 之類的權宜手法模擬，對模型設計與推論穩定性都有幫助。可擴充的自訂操作則讓開發者能加入自己的運算，不必被官方支援清單綁死。
在硬體最佳化方面，ML Drift 針對 Arm、Intel 與 Qualcomm Technologies 的 GPU 加入特定調整，以提高現代 GPU 的硬體使用率。在平台覆蓋方面，ML Drift 透過 Dawn 把推論能力延伸到 Windows 與 Linux。Dawn 是 Chromium 的 WebGPU 實作，提供統一的 API 模型，利用 WebGPU 的硬體抽象層，讓開發者不必直接面對 DirectX 或 Vulkan 等平台特定圖形 API。macOS 上則保留原生 Metal 後端。這種做法等於在作業系統與 GPU 驅動之間再墊一層可攜性介面，降低跨平台部署時的重複工程。
從 TFLite GPU delegate 到 LiteRT 的路線轉移
ML Drift 的推出也意味著舊路線的收尾。Google 表示將停止更新舊有的 TensorFlow Lite GPU delegate。對於已經存在的模型，官方建議遷移到 LiteRT ML Drift GPU accelerator，以維持向後相容。應用開發者可以直接使用 LiteRT ML Drift accelerator；而 GPU 與系統工程師則能存取其較低階的 C++ API，建構自訂的 GpuModel 運算圖並撰寫自訂著色器。這種分層設計讓不同角色的開發者能依需求選擇抽象層級，而不必被迫從頭處理底層細節。
實際部署成效與外部評價
Google 用 Gemma 模型在開發者級工作站硬體上進行基準測試，報告指出 ML Drift 的記憶體開銷比其他框架低 12%，比較對象包括 llama.cpp 與 MLX LM。Google 也強調，ML Drift 已經透過 Chrome、YouTube Shorts、Photos、Meet 等應用程式在數百萬台裝置上運行。在 YouTube Shorts 中，Android 與 iOS 上基於分割的特效，平均影格延遲最多降低 40%。在 Google Photos 中，計算攝影與分割管線最多加快兩秒。Adobe Lightroom 與 Photoshop 的某些 AI 照片編輯功能，例如 Select Subject、Select Sky 與 Adaptive Portrait，效能提升最多 30%。Snapchat 在 Android 上針對機器學習驅動的臉部與風格生成特效，模型延遲降低 30%，使其能採用更大的擴散模型。
外部評價方面，AI/ML 工程師 Pavithra Agraharam 在 LinkedIn 評論指出，原生五維張量支援不需要 layout hacks，對在邊緣 GPU 上執行空間與 transformer 模型是一大勝利；把邏輯張量與實體記憶體配置解耦，應能顯著減少即時推論期間的記憶體碎片化。不過，Tensorust 創辦人兼唯一開發者 Matthew Charles Vladislav Busel 則提出疑問：ML Drift 與近期 iPhone 上的 Core ML 相比，延遲與記憶體表現如何？畢竟那是目前多數人實際出貨所依賴的對象。Google 並未提供這方面的比較數據。
影響與限制
整體來看，ML Drift 的意義不只是另一個 GPU 加速函式庫。它把裝置端 AI 推論最麻煩的硬體碎片化問題，從應用層往上抽離，讓開發者能用相對一致的介面面對 OpenGL ES、OpenCL、Metal 與 WebGPU 等不同後端，並在 Arm、Intel、Qualcomm 等硬體上取得最佳化。對於已經在 LiteRT 生態系中的團隊，遷移路徑也相對清楚：應用層走 LiteRT ML Drift accelerator，底層則可用 C++ API 自訂運算圖與著色器。Google 以 Apache 2.0 開源，也讓社群與商業專案能在相同基礎上發展自訂執行環境，這對需要長期維護跨平台推論管線的團隊特別有吸引力。
限制也很明顯。首先，Google 提供的效能數字多來自自家應用與特定硬體情境，與 Core ML 等既有方案的直接比較仍付之闕如。其次，舊的 TensorFlow Lite GPU delegate 停止更新後，既有專案需要規畫遷移，並非零成本。第三，跨平台抽象層雖然降低可攜性負擔，但是否在所有驅動版本與 GPU 架構上都能維持穩定與峰值效能，仍取決於後續生態系驗證。ML Drift 讓裝置端 AI 的 GPU 路線更清楚，但真正的考驗在於開發者實際部署後，能否在不同裝置上兌現它所承諾的可攜性與效能。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。