谷歌公开ML Drift，从打造小模型的角度读一读
一个翻译各设备不同GPU语言的引擎，以及只负责判断的小模型Vons
商业谷歌将端侧GPU引擎单独拆分公开
谷歌AI Edge团队以Apache 2.0许可证公开了ML Drift。这是一款在手机、笔记本电脑和浏览器内的GPU上运行AI模型的计算引擎。它原本是谷歌端侧运行时LiteRT底层负责GPU加速的组件，这次被作为独立库发布出来。据说YouTube Shorts、谷歌相册、谷歌Meet，以及Chrome中的Gemini Nano功能已经在这个引擎上运行。
我之所以把这则发布和Vons放在一起读，是因为这两个项目触及的是同一个层面。我正在开发一个名为Vons的小型判断模型。它是在大模型制定的计划框架内，从几个候选项中选出一个、或者回答“不选”的部件。模型文件64 MiB以下、能在CPU和浏览器中运行，是它的设计目标。所以ML Drift所处理的问题，也就是“如何在小型设备的GPU上运行模型”，正好与Vons的运行环境直接相连。
今天先说明ML Drift解决了什么问题，然后从打造Vons的立场，写一写这则发布在我看来意味着什么。
每款GPU说的话都不一样
在数据中心运行AI时，同型号的加速器是成排排列的。只要提前知道会在哪种芯片上运行，针对它做优化就行了。设备端的情况恰恰相反。应用一旦发布出去，就无法事先知道它会运行在哪家公司的GPU、哪个驱动版本之上。安卓主要用OpenCL和OpenGL ES，苹果设备用Metal，浏览器用WebGPU。即便要执行同样的运算，向GPU下达指令的语言也有四种之多。
谷歌此前的解法是TensorFlow Lite的GPU代理1。问题在于，每个后端都要单独维护着色器2，而张量3要以何种方式装入GPU的纹理或缓冲区，也被固定写死在各后端专属的代码里。如果有三个后端，就得维护三份相似的代码。张量维度也被限制在最多四维，因此像处理三维空间数据的模型那样需要五维张量时，就不得不用把形状硬塞进去的变通办法。
ML Drift: Next-Gen GPU AI/ML Inference at the Edge- Google Developers BlogGoogle AI Edge has introduced ML Drift, a high-performance, universal GPU compute framework designed to accelerate on-device AI and machine learning inference. By abstracting the complexities of hardwML Drift给出的答案可以归纳为四个方向。
张量虚拟化。 将模型所设想的张量形状，与其在GPU内存中实际的存放方式分离开来。着色器只用模板写一次，至于哪种GPU采用哪种存储方式，则在初始化阶段通过生成代码来决定。据仓库说明，这种通用着色器语言被称为UCL（Unified Compute Language），在执行时分别转换为GLSL、MSL、WGSL。这是一种只配一名翻译、却要译成四国语言的结构。
面向生成式模型的执行方式。 对话式语言模型在生成一次回答的过程中，工作方式会切换两次。一次性读入输入句子的预填充4阶段，瓶颈在于运算量；而逐个token输出答案的解码阶段，瓶颈在于从内存中取数据的速度。据说，ML Drift会在阶段切换时替换内核和数据布局，在解码阶段把KV缓存5的布局对齐到卷积运算上，并在内核内部对中间值进行量化，以减少不必要的内存往返。
五维张量与自定义算子。 默认支持五维张量，并开放了让开发者可以直接注册着色器的自定义算子框架。值得注意的是，这里还一并附上了面向编码智能体的SKILL.md使用说明。谷歌的解释是，智能体使用、注册并验证自定义着色器只需几分钟即可完成。
走出浏览器的WebGPU。 原本是为浏览器编写的WebGPU后端，被编译进Chrome的WebGPU实现Dawn中，从而使其也能在浏览器之外运行。由此，在Windows和Linux上无需单独应对DirectX或Vulkan，用同一套代码即可运行，而在Mac上则沿用原有的Metal后端。谷歌将这部分称为桌面预览版，并举出了本地运行的编码智能体作为应用场景。
谷歌公布的数字，该这样解读
性能数据也一并公布了。YouTube Shorts 把基于视频分割的效果迁移到 ML Drift 后，在安卓和 iOS 两端平均帧延迟最多降低了 40%；谷歌相册据称比以前的 GPU 委托（delegate）最多快了 2 秒。Adobe Lightroom、Photoshop 移动版的主体选择等功能，设备端性能最多提升 30%；Snapchat 镜头的人脸与风格效果，模型延迟改善了 30%。在 Gemma 模型基准测试中，据称内存占用比其他框架最多少 12%。
这些数字需要带着两点来读。首先，大部分都是“最多”。在哪种设备、哪种模型上测出的最高值，发布文中并未说明。其次，比较对象大多是谷歌自己以前的引擎。内存 12% 只写着“与其他框架相比”，具体比的是什么并不清楚。
把针对同一引擎的数字按时间顺序排列，这一点会更清楚。2025 年 5 月公布的 ML Drift 论文称，其速度比现有的开源 GPU 推理引擎快一个数量级（order of magnitude）。谷歌今年 1 月在 LiteRT 中加入 ML Drift 时公布的数字是，GPU 性能比 TFLite 快 1.4 倍。而这次发布中各应用的数字是 30%~40%。比较基准每换一次，数字的大小就跟着变。
比起数字，更应该重视的是运营层面的措辞。谷歌表示，不会再为 TFLite GPU 委托（delegate）添加新功能。据称现有模型迁移到 LiteRT 的 ML Drift 加速器后仍可照常运行，这实际上是一则换代通知。安卓端可以直接在独立的 LiteRT 包中使用，谷歌 Play 服务内置的 LiteRT 也将很快支持。硬件方面，据称 Arm、英特尔、高通共同优化了内核。
再说一下 Chrome 的情况。据悉，Chrome 在运行 Gemini Nano 的内置 AI API（Prompt、Summarize、Writer）中加入了 ML Drift。今年 5 月第 102 期中我们曾讨论过 Chrome 在未经用户同意的情况下下载 4GB 大小的 Gemini Nano 的问题，而这次公开的正是在笔记本 GPU 上实际运行该模型的引擎。引擎的公开与安装同意是两个独立的问题，这次发布并不能解答那个疑问。
Vons 处于什么位置
现在我转到自己的项目。Vons 代码仓库开头写的一句话是“Plan globally. Decide locally. Keep the host in control.”。意思是，计划由大模型在宏观层面制定，决策在靠近现场的地方做出，而执行权限则掌握在调用该模型的程序（宿主）手中。
结构是这样的：像前沿模型这样的规划器（planner）会给出当前状态，以及若干预先设定好的候选项。Vons 会返回一个结构化的答案，从中选择一个，或者选择不选（弃权）。它不会直接执行工具，也不会把模型自身给出的置信度当作执行许可。执行、策略以及用户同意，全都是宿主的职责。研究代码中同时包含一次性打分的 Direct 评分器，以及以扩散（diffusion）方式打分的条件式 Diffusion 评分器。
运行环境也设计得很小。英语优先，模型资产 64MiB 以下是设计目标，在 CPU、WASM 上运行，WebGPU 则是可选项。TypeScript SDK 使用 onnxruntime-web 在浏览器内进行推理。无论是 WASM 还是 WebGPU，都只会按声明的那一种方式运行，不会在加速器不可用时悄悄切换到另一种。我们还做了 Chrome 扩展程序版本，已于 9 月 25 日提交到 Chrome 网上应用店，截至撰写本文时仍在审核等待中。
INLEVEL9/Vons · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.不过，Vons 目前还只是 0.1.0 研究预览版。尚未发布训练好的权重，浏览器端的延迟和内存占用也还没有经过公开检验的数据。代码仓库里也特别注明，未测量的数值请理解为“无”，而不是零。
两个项目的交汇点
看向同一层，不代表在解同一个问题。把两者并排放在一起，差异会先浮现出来。
| 区分 | ML Drift | Vons |
|---|---|---|
| 本质 | GPU 运算引擎 | 判断模型与 SDK |
| 瞄准的模型 | 从视频特效到 Gemma 级别的生成式模型 | 64MiB 以下的小型打分器 |
| 想回答的问题 | 如何让这个模型在任何 GPU 上都能快速运行 | 如何在本地而非借助大模型来做出这个决策 |
| 执行路径 | OpenCL、Metal、WebGPU、OpenGL ES | onnxruntime-web 的 WASM、WebGPU |
ML Drift 所投入的大部分优化——也就是预填充与解码之间的切换、KV 缓存批处理——都是为持续生成 token 的大模型准备的。Vons 则是那种只对候选项打一次分就结束的模型，这些优化并不会直接作用于它。而且一般来说，在极小的模型上，把数据搬到 GPU、启动内核所产生的固定开销，可能比计算本身还要大，所以 GPU 并不总能胜过 CPU。Vons 把 WebGPU 设为可选项而非默认值，也和这层考量有关。
反过来，也有两者严丝合缝地咬合在一起的地方。Vons SDK 里内置了一个挂在编码代理上使用的本地 MCP6 服务器，这里刻意把 WebGPU 选项屏蔽掉了。原因是终端里启动的子进程无法获取浏览器的 WebGPU 适配器。所以要在 Vons 里使用 WebGPU，就得在浏览器或扩展程序内部直接调用 SDK。
Oswarld视角
我一直在说一句话。不是所有人、所有事都需要超级智能。每项工作和每种环境都有与之匹配的模型。
我的工作方式也是这样划分的。整体规划、编排、最初的设计图，现在仍然交给Claude或GPT-6来做。但耗时长、重复性高的工作，我转交给了DeepSeek或GLM。Vons是把这种分工再往下推一层的实验。大模型筛选出候选项，选哪一个由设备里的小模型来决定，而是否真正执行则由宿主来决定。
从这个角度来读ML Drift的发布，谷歌是在硬件这一侧做着同样的分工。 编写着色器的工作交给了拿着SKILL.md的编码代理，而像设备GPU碎片化这样小团队难以独自应对的层，则用通用引擎来覆盖。把模型做小是制作者的事，但不必再独自承担让这个模型在几十种GPU上运行的事，这样一条路算是多出来了。
不过引擎开放了，并不代表决定权也随之开放。正如我们在102期的Chrome案例中看到的那样，模型多容易被装进设备，和由谁来决定这个模型可以做什么，是两个不同的问题。Vons没有把置信度当作许可，而是把执行权留给宿主，这同样是针对第二个问题的设计。
结语
ML Drift 是一个将不同设备上各不相同的 GPU 语言统一翻译成一种语言的引擎，谷歌把它定为 TFLite 之后的默认路径。对于打造小型模型的一方来说，这次发布与其说是在公布性能数字，不如说更像是一条消息：通往设备 GPU 的路径正在被整理成一条。
💬 在读者您的工作中，有没有哪件事情，似乎不必调用大模型，让设备内的小模型自行判断就足够了？欢迎在评论中告诉我们。
📨 如果您身边有正在为端侧 AI 或智能体设计而苦恼的同事，请把这篇文章转发给他们。
参考资料与延伸阅读
核心来源
- Google AI Edge Team，《ML Drift: Next-Gen GPU AI/ML Inference at the Edge》，2026。··· 这是本文的一手资料。架构变更、各产品的性能数据、TFLite GPU 委托停止支持公告，全部出自这里。
- Google AI Edge，“google-ai-edge/ml-drift”，GitHub。··· 整理了 UCL、张量虚拟化、支持后端构成的官方 README。
- Jiuqiang Tang 等，“Scaling On-Device GPU Inference for Large Generative Models”，arXiv:2505.00232，2025.5。··· 首次公开 ML Drift 设计的论文，是“个位数倍”这一说法的出处。
- Paul Krill，“Google’s LiteRT adds advanced hardware acceleration”，InfoWorld，2026.1.28。··· ML Drift 接入 LiteRT 后出现的“较 TFLite 快 1.4 倍”这一数字的出处。
Vons
- Kwangseob Ahn，“inlevel9-com/Vons”，GitHub。··· 整理了研究预览版的范围与局限，以及论文、技术报告的链接。
- “@vons/decision-sdk README”，GitHub。··· 记录了 WASM、WebGPU 的选择方式，以及 MCP 服务器为何屏蔽 WebGPU 的原因。
值得一起阅读的往期内容
- 第102期《Chrome 那个 4GB AI 模型暴露出的安装同意问题》 ··· 这次公开的引擎，正是在 Chrome 内部运行的那个模型的故事。
- 第178期《Kimi K3 2.8 万亿参数，明明是开放权重为何还是跑不动》 ··· 探讨了需要服务器机架的巨型模型，和正走向设备端的小型模型，这两条方向相反的算力路径。
📝 术语说明
注释
-
委托（delegate）：TensorFlow Lite 中的一种连接组件，在模型执行过程中，把部分运算交给 GPU 等加速器代为计算。 ↩
-
着色器（shader）：在 GPU 上运行的小程序。原本用于绘制图形画面，现在也被用来让 GPU 执行 AI 运算。 ↩
-
张量（tensor）：AI 模型处理的多维数字集合。一张照片是宽、高、颜色构成的三维，多张照片打包在一起就变成四维。 ↩
-
预填充（prefill）与解码（decode）：语言模型一次性读入整个问题的阶段叫预填充，逐个 token 接续生成答案的阶段叫解码。 ↩
-
KV 缓存（KV cache）：为了避免语言模型重复计算此前已读取的内容，而预先存储中间结果的内存空间。上下文越长，占用就越大。 ↩
-
MCP（Model Context Protocol）：将 AI 代理（agent）连接外部工具或数据的方式加以标准化的协议。Vons 的 MCP 服务器，正是代理向 Vons 请求判断的接口。 ↩
你的观点会成为下一期的线索
欢迎留下你的经验与看法。