Announced 8 Oct 2026 · Sources checked
What did Google open-source, and when?
The dated announcement is the 8 October 2026 Google Developers Blog post. We opened that page on 9 October. It presents ML Drift as a cross-platform on-device GPU compute engine for AI and ML inference, released under Apache 2.0. Authors listed are Chintan Parikh, a product manager, and Juhyun Lee, a software engineer, writing for the Google AI Edge team.
The same post says ML Drift abstracts OpenGL ES, OpenCL, Metal and WebGPU so developers can target those backends without maintaining four shader codebases. It is described as the core GPU acceleration engine inside LiteRT, and also as a standalone library for custom graphics and inference runtimes. Those are Google’s product sentences.
The public repository is github.com/google-ai-edge/ml-drift. The GitHub API record we opened on 9 October showed an Apache-2.0 license, a README titled “Performant & Universal On-device GPU Compute,” and a last push stamp of 9 October 2026 at 00:00:03 UTC. The repository itself was created on 14 May 2026, so the 8 October news is the open-source announcement, not the first time the name existed inside Google’s stack. That distinction matters next to last week’s EmbeddingGemma 2 on-device release, which already pointed developers at LiteRT without opening this engine.
What does the engine actually change?
Google’s problem statement is hardware diversity. Datacenter inference, the post says, runs on relatively homogeneous accelerator clusters. Edge GPUs do not: architectures, drivers and low-level APIs vary, and the application does not know the device in advance. The older TensorFlow Lite GPU delegate is presented as the foundation that no longer matches current workloads, which now range from real-time vision, audio and depth models to high-parameter generative models.
The architectural claims in the post are specific. Tensor virtualization decouples a tensor’s logical shape from the physical GPU object — texture or buffer — so one shader template can be resolved at compile time for OpenGL, OpenCL and Metal. A custom-op framework exposes registration APIs and low-level shading-language access; Google says an agentic SKILL.md is included so coding agents can author and register shaders. 5D tensors, which the post says the TFLite GPU delegate hardcoded away, are described as first-class, with examples such as YOLO 11n, MobileViT v2 and Swin Transformer v2.
For autoregressive language models the post describes stage-aware execution. Prefill is treated as compute-bound; decode is treated as memory-bound. During decode, ML Drift is said to switch to a convolution-aligned KV-cache layout and to apply in-kernel activation quantization so activations are not written back to memory between steps. The README we opened lists FP16, INT8 and INT4 among the supported quantizations. Those are vendor descriptions of the runtime, not measurements we ran.
How do developers get it today?
The post splits users into two paths. Application developers are told to use the LiteRT ML Drift accelerator for partitioning, tensor virtualization and the LLM path. GPU and system engineers are told to build against the standalone C++ APIs, construct custom GpuModel graphs, and start from the OpenCL-on-Android and WebGPU-via-Dawn quickstarts in the repository. The README we opened matches that split: OpenCL, Metal, WebGPU via Dawn, and OpenGL ES 3.1+ are listed as backends, with Unified Compute Language (UCL) as the shader abstraction.
Migration language in the post is blunt. The legacy TFLite GPU delegate “will no longer receive new feature updates.” Google says existing models keep backward compatibility on the LiteRT ML Drift accelerator. For Android apps that ship an unbundled runtime to keep the binary small, ML Drift acceleration is “available today in standalone LiteRT packages” and “coming soon to LiteRT in Google Play Services.” Desktop Windows and Linux builds that reuse Dawn outside the browser are labeled an early snapshot. That is not the same readiness claim as a phone-sized LiteRT integration, and it is a different local-runtime story from NVIDIA and Microsoft’s RTX Spark Windows stack.
Arm’s 8 October companion post, by Bala Gattu, repeats the Apache-2.0 open-source line and says Arm co-designed Mali and Immortalis kernel, texture-cache and workgroup work with Google. The practical sentence for developers is Arm’s: if an app already uses LiteRT with GPU acceleration, or migrates from the TFLite GPU delegate, ML Drift is the execution path underneath. We did not verify those Mali patches commit-by-commit.
What performance numbers did Google publish?
The 8 October post is not a model card. Selected Gemma charts give the axes: 4-bit weights, fp16 KV cache, argmax sampling, sync every token. One edge figure uses prefill 512 / decode 128; a desktop snapshot uses prefill 8192 / decode 1024. Google says Gemma4 E2B “performs better on frameworks supporting cross KV sharing.” Those axes are Google’s.
In those Gemma benchmarks Google reports “up to 12% lower memory overhead than other frameworks.” An earlier LiteRT note, which this post points back to, had claimed an average 1.4× speedup over the legacy TFLite GPU delegate. We are dating today’s news to the open-source drop, not re-litigating that average. Quantization choices in the charts sit next to the usual quality-versus-size tradeoffs in our quantization explainer; they are not a substitute for measuring your own graph.
Product anecdotes in the same post are Google’s, or quotes of named partners. YouTube Shorts is said to have seen “up to a 40% reduction in average frame latency” after moving segmentation effects onto ML Drift. Google Photos is said to have seen “up to 2 sec speedup” versus the legacy GPU delegate. Adobe Lightroom and Photoshop are said to have taken Select Subject, Select Sky and Adaptive Portrait to “up to 30% faster” on mobile. Snap is said to have seen “30% model latency improvements” for face and style effects. Chrome is described as using ML Drift for Gemini Nano Built-In AI APIs. We did not reproduce those timings.
Who else is named in the hardware stack?
Beyond Arm, the post names Intel and Qualcomm as silicon partners. Intel’s line is native WebGPU compute and Xe Matrix Extensions (XMX) on Core Ultra processors with Xe3 graphics. Qualcomm’s line is optimized OpenCL kernels for Adreno GPUs. Those are partner acknowledgements in Google’s post, not independent silicon reviews.
The README’s “order-of-magnitude performance improvement relative to existing open-source GPU inference engines” is a stronger claim than the product anecdotes, and it is still a README sentence. We did not compare ML Drift with other open GPU runtimes. For readers choosing between on-device and hosted inference, the useful prior is still managed versus self-hosted AI: an open engine does not by itself decide where a workload should run.
A same-week on-device contrast, not a competitor chart, is Liquid’s open d1 decision models, which return calibrated answers in one pass. That is a different artifact from a GPU runtime. See our open d1 write-up if the question is “what small model can I actually download,” not “which shader compiler sits under LiteRT.”
What is not established?
We did not build ML Drift, run the Gemma charts, or time Shorts, Photos, Lightroom or Snapchat. We did not open Play Services package listings to confirm the “coming soon” GPU path. We did not verify Intel XMX or Qualcomm Adreno kernel diffs beyond the sentences on Google’s page.
The May 2026 repository creation date and the 8 October announcement can both be true: the tree can exist before a public launch post. The 9 October 00:00:03 UTC push we recorded is a last-updated stamp, not proof that every file landed that minute.
This is an evidence review of pages opened on 9 October. It is not a first-hand LiteRT integration and not a ranking of ML Drift against other GPU inference engines.
Common questions
Is ML Drift a new on-device model?
No. It is a GPU compute engine. Google says it already sat under LiteRT in shipping products. The 8 October news is that the engine is now on GitHub under Apache 2.0.
Can I use it without LiteRT?
Google says yes, through the standalone C++ APIs and GpuModel graphs in the repository. The documented default for application developers is still the LiteRT ML Drift accelerator.
Is the desktop path production-ready?
Not on the page we opened. Windows and Linux via Dawn are an early snapshot. Play Services packaging is listed as coming soon. The production anecdotes are mobile and Chrome.
What to remember
Clone github.com/google-ai-edge/ml-drift for the Apache-2.0 engine and use LiteRT when you want the packaged accelerator. Treat Shorts, Photos, Adobe, Snap and the Gemma charts as Google’s numbers until you time your own model.
Sources & further reading
How this story was made
Written by Kristian Kostov with AI assistance and checked against the linked sources. Company performance claims are attributed to the company. Analysis reflects AiLookout’s interpretation; we have not independently tested the products discussed. Cover photography is illustrative and does not depict the specific announcement or product.
Our editorial standards
