ML Drift becomes open source: Local AI on smartphones, browsers, and desktops

ML Drift is an engine for running local AI inference on GPUs: it helps an application run a model on the device. It is not a language model, does not contain the knowledge of an assistant on its own and does not automatically turn a program into an offline app.

On October 8, 2026, Google announced its standalone open source release. The engine was already present in the LiteRT ecosystem and in previous works: the news concerns the opening as a component that can also be used separately, not the birth of local inference. The ad maintains its focus on mobile and edge and describes Windows and Linux as a desktop preview. Official Google Developers announcement.

What is the difference between runtime and AI model?

The model represents what the system has learned and the kind of transformation it can perform. The runtime organizes the execution of that model in the available environment. To explain the distinction without confusing the components, you can think of a file and the program that opens it: knowing the features of the file does not prove that any program can use it properly.

ML Drift belongs to the level of execution. The official repository describes a GPU engine with backends such as OpenGL ES, OpenCL, Metal and WebGPU, distributed under the Apache 2.0 license. The availability of these paths does not equal the guaranteed compatibility of each model on each device. Concrete integration must be assessed together with the rest of the application. Official ML Drift Repository.

The comparison with EmbeddingGemma 2 makes the boundary clear: the latter is an embedding model for representing content, while ML Drift is an execution component. They are not alternatives to be placed in the same ranking. First you define the task, then you check the compatibility between the model, runtime and platform, without assuming that the existence of both is enough to integrate them.

What changes with the standalone release?

A separately usable component can be evaluated without necessarily adopting the entire environment of which it was a part. Google describes ML Drift as part of LiteRT and as a standalone library, with attention to generative load optimizations. It is an opportunity for those who develop applications and have to choose the path of inference, not a consumer service to be activated with a subscription. Description of the Google release.

For an SME this is relevant when there is already a concrete application problem: operating in places with uncertain connectivity, processing device information or integrating an AI function into a specific interface. The runtime name should not become the starting point of the project. If the task can be solved more simply with an ordinary function, introducing a model increases the work without a proven benefit.

The open source release also allows the code and distribution conditions to be examined. It does not automatically include support, business product maintenance, or future compatibility with any hardware. The team must decide how to update the component and what configurations to support. The cost of the project remains linked to the software you want to deliver and manage, in addition to the runtime license.

How to choose between local AI, cloud and a combination?

The choice depends on the task and the constraints, not on a general superiority of the venue. Processing on the device can be useful when the work has to go on without a network. A central service can simplify the management of shared sources. A combination can distribute some tasks on the device and others on the server, but requires making it understandable what happens when the connection is missing.

The theme of the Corporate Privacy in AI goes through all these options. Locale describes a place of execution; privacy also depends on what the app sends, stores, and syncs. To compare architectures you need to follow the path of the data, do not stop at the label chosen for the model.

What evidence is needed on smartphones, browsers, and desktops?

You have to try the task on the hardware that will really be used. A result obtained on a development configuration is not enough for a different device fleet. Model, accuracy, GPU, and drivers influence behavior; the Google ad describes platforms and backends, but does not authorize declaring identical performance on all systems. Conditions and scope described in the announcement.

The test should observe startup, processing, repeated use and interaction with the rest of the app. An acceptable response time in an isolated test may not describe the work while the person uses other functions. Memory, device consumption, and error management should also be considered. No universal values are given: the criteria must be set on the context of use and measured in the expected configuration.

The browser must verify the path actually available in the chosen environment, without inferring compatibility from WebGPU's presence among the backends alone. For desktops, the status distinction must be maintained: Google describes Windows and Linux as a preview in the ad. A production project must assess this limit before promising support for all locations in the organization.

How to tell if the quality depends on the model or execution?

An unhelpful answer can have different causes. The model may not be suitable for the task, the input content may be incomplete, or a run configuration may change the result. For this reason it is better to keep repeatable examples and change one element at a time. If you update your model, accuracy, and interface at the same time, it becomes more difficult to figure out which change helped.

The main criterion remains the work required. A classification must be correct on the expected cases; a generative function must produce results that the person can use or verify. A better technical measure does not compensate for insufficient quality. The test must also include what the app shouldn't do, such as turning a missing data into an answer presented with certainty.

This also applies to tools aimed at developers. The case of Copilot CLI with Ollama and local models is about another integration and does not automatically demonstrate the feasibility of an ML Drift-based app. The shared point is to separate model, execution path and accessible tools, verifying the task instead of judging only the "local" label.

Does the prototype work on the developer's computer, but not on the team's device?

Compare hardware configuration, GPU, driver, runtime version, model, and accuracy. Reduce the case to the task that fails and retain a repeatable input. Check the documented requirements before changing the prompt: the problem may belong to the execution or compatibility, not the way the request is formulated.

An app for out-of-office technicians: hypothetical scenario

Let's imagine a maintenance SME that wants to help technicians consult operational information in places where the connection is unstable. In this hypothetical scenario a local function could classify a note or support research on materials available on the device. Before choosing ML Drift, the team should define which part of the task requires a model and which can be handled by an ordinary search or field.

The evidence would use representative devices, with an authorized and recognizable archive as a version. The interface would show if the content is up-to-date and what operations the network requires. If the necessary material is not present, the app should say so instead of producing plausible instructions. The aim would not be to replace the responsibility of the technician, but to make verifiable information accessible under the conditions laid down.

The test would include repeated use during the work, in addition to the single demonstration. It would be observed if the app remains usable, how it handles an interruption and what happens when the connection returns. The final choice would depend on the behavior of the entire product. The availability of an open source runtime, by itself, would demonstrate neither the quality of the instructions nor the operational utility for the technicians.

A professional studio with desktop apps: hypothetical scenario

Consider a study that wants to prepare internal notes on confidential materials, without entrusting each processing to a remote service. In this second hypothetical scenario the project could evaluate a local function with a precise perimeter: assist the preparation of a draft and maintain a mandatory revision before professional use.

The test would start from the actual stations and the model suitable for the task. The team would verify that the documents used, the temporary copies and any logs follow the rules of the study. It would not be enough to observe that inference occurs on the computer: a synchronization or monitoring component might have a different path. The Data security in AI It also concerns these addictions.

For the desktop you would also evaluate the preview status indicated in the ad and the support that the studio is willing to support. A prototype can serve to understand feasibility without immediately turning into a promise of distribution to all stations. If the quality of the draft is not enough, the result of the test may be to narrow down the task, choose another architecture or maintain an ordinary procedure.

What parts remain to be designed to work without a network?

An offline app must have on the device what is needed for the task: model, authorized data and operating rules. It must also explain what information could be overcome. If a catalog changes, the local version does not update due to the runtime. You need a sync policy and understandable behavior when the update is not available.

Revocation of access requires a specific choice. A local copy can remain on the device even when changing server permissions, if the application does not foresee how to handle it. The project must therefore define content distribution, device access and material lifecycle. This is not a function to be assumed by reading the inference engine license.

The model update should also be designed. Before distributing a new version it is better to repeat the test cases and check that the app recognizes the configuration used. If the result changes, the team must be able to reconstruct which components were in use. This discipline is especially useful when a customer uses updated devices at different times and reports behavior that does not appear on the development machine.

What does the app have to show while the model is working?

The technical test should include the person's experience. A model that requires a wait must be inserted into an interface that distinguishes processing, ready result, and error. If the task can be interrupted, the undo command and the next state must be designed and tested. The runtime does not automatically decide which message is understandable to the user.

It is also useful to distinguish the first boot from later uses. Loading components, data availability, and retrieval after an interruption can affect the perceived path. It is not necessary to promise an abstract time: it is necessary to observe if the person can complete his work and if he understands what is happening. When the device does not meet the requirements, the app should explain the limit and offer the path expected by the project, rather than leaving a function seemingly blocked.

Mistakes that make the runtime choose too soon

The first is to call ML Drift "new Google model" and expect a ready chat. The second is to confuse the standalone release with the birth of the engine: the work was already present in the research, as shown by the previous CVPR paper on local GPU inference. The third is to transfer measurements of a configuration to different devices without proof.

Another mistake is estimating only the license and ignoring integration, updates and assistance. Finally, we must not turn local choice into an ideological constraint. An agent with persistent cloud activity, such as the one announced for Gemini agent, addresses different needs. The useful comparison concerns where the work must take place and what data are needed, not a universal winner between devices and servers.

The basics of AI Agents for Companies help to separate the goal of the process from the technology of execution: a local component can support a precise task without taking on the role of a complete agent on its own.

If your project requires AI on the device, we can prepare a Feasibility test for a local app on the expected task and hardware. We start with expected quality, available data and networkless behavior. Only then do we choose the runtime and dependencies, with criteria that make the decision to continue verifiable. If the component is to link to management software and archives, the path of Tailored Business Software It also includes these integrations.