共计 6336 个字符，预计需要花费 16 分钟才能阅读完成。
桌面端跑本地模型这件事，我已经习以为常了。[[Ollama]] 装好，ollama run 一下，或者打开 [[LM Studio]] 点两下，一个还算能用的模型就在自己机器上转起来了。但手机端我一直是抗拒的，或者说，一直觉得那是个玩具。几年前试过几个第三方 App，要么模型小到答非所问，要么跑起来手机烫得能煎蛋，体验完就卸载，没留下什么印象。直到最近我重新装了一次 Google AI Edge Gallery，翻了翻它这一年多的更新记录和官方基准数据，才发现这块地方的变化比我以为的要大。变化不在于「手机能跑大模型了」这个结论本身，而在于跑的方式、能跑的规模，以及围绕它长出来的那一套东西，已经不太像一年前那个样子了。
它到底是个什么东西
先把定位说清楚，因为这一点很容易误会。Google AI Edge Gallery 不是一款面向普通用户的 AI 助手产品，它是 Google AI Edge 团队做的一个官方 showcase，说得直白点就是官方样板间。仓库建立于 2025 年 3 月底，托管在 GitHub 的 google-ai-edge/gallery 下，Apache 2.0 协议，写到现在积累了 24382 个 Star 和 2605 个 Fork，代码主要是 Kotlin。README 里到现在还挂着 experimental Beta release 的标签，这个标签不是谦虚，是应该认真对待的提示。
它的传播路径挺有意思，能看出 Google 对这个东西的期待在变。最早是 2025 年 I/O 上随 Gemma 3n 一起亮相，那会儿只能从 GitHub 下 APK，属于典型的开发者玩具，但光是 APK 就被下载了超过 500000 次，这个数字显然超出了「给开发者看看」的范畴。到 2025 年 9 月，Audio Scribe 功能上线，同时 App 进了 Google Play 开放测试，后来又上了 iOS App Store，现在连 macOS 版本都能下载了。一个 showcase 项目做到全平台分发，说明 Google 想让它承担的角色比最初大得多——它既是给开发者看的技术演示，也在事实上成了普通人接触端侧 AI 最低门槛的入口。
为什么我觉得这个项目值得花时间看？因为端侧推理这件事，讨论的人多，能拿出可复现数据的少。市面上大量文章停留在「隐私好、离线可用、延迟低」这种正确但空洞的层面，而 Gallery 这个项目最实用的地方恰恰在于，它把模型下载、参数调节、性能测量这三件事做进了同一个界面，你可以在自己那台具体的手机上，得到一组属于自己的数字。这比看任何评测都管用，因为端侧性能对硬件的依赖程度，远远超过云端 API。
从 MediaPipe 到 LiteRT-LM 的换血
如果只关注 App 的功能列表，很容易错过这一年多最重要的变化：底层运行时被整个换掉了。
早期版本跑在 MediaPipe LLM Inference API 上，这套 API 本身没什么问题，能用，Google 自己的文档里也详细写了 Android 集成方式。但它有个结构性尴尬——MediaPipe 的设计初衷是通用的多媒体机器学习管线，处理姿态估计、手势识别这类任务，LLM 推理是后来硬塞进去的一块，抽象层次并不贴合。现在打开 Google 官方文档，MediaPipe LLM Inference API 页面顶上明晃晃写着 maintenance-only mode，建议迁移到 LiteRT-LM 的 Kotlin API。
接替它的 LiteRT-LM 是专门为这件事造的轮子，Google 把它定位成 production-ready 的编排层，跑在 LiteRT 这个轻量运行时之上。这次换血带来的实际差别，我觉得有三点值得说。
第一是硬件加速的覆盖面。LiteRT-LM 在 Android 上同时支持 CPU、GPU 和 NPU 三种后端，iOS 和 macOS 支持 CPU 与 GPU，Windows 的 NPU 支持还在路上，连 Raspberry Pi 这类 IoT 设备都能跑 CPU 推理。对端侧场景来说，能不能吃到 GPU 和 NPU，几乎直接决定了体验是「可用」还是「能跑」。
第二是能力边界的扩张。多模态不再是附加项，视觉和音频输入是一等公民；Tool Use 和 function calling 有原生支持，而且配了 constrained decoding 来提高结构化输出的准确率。这一点很关键，小模型自由生成 JSON 时错误率高得离谱，约束解码基本是端侧做 Agent 的必要条件，不是锦上添花。
第三是开放性。LiteRT-LM 是完全开源的运行时，Google 在博客里也明说了迁移的动机之一就是给开发者更多的灵活性和透明度。它支持的模型不只有自家的 Gemma，Llama、Phi-4、Qwen 都在列表里。对于想把端侧推理集成进自己 App 的开发者来说，Gallery 的价值就在于它是这套 API 的活参考实现，源码摆在那里，照着抄就行。
功能拆开来看
Gallery 现在的功能模块不少，但价值密度差别很大，我按我自己的判断排个序。
模型管理与基准测试
这是我认为整个 App 里最有价值的部分，也是最容易被功能列表里那些花哨名字盖过去的部分。它内置了一个模型列表，可以直接从 [[HuggingFace]] 的 LiteRT Community 下载经过转换优化的模型，也支持导入自己的 .litertlm 或 .task 文件，最近还加了从 Hugging Face 社区 URL 导入 LiteRT-LM 模型的能力。
真正好用的是 benchmark。每次推理它都会记录首字延迟、prefill 速度、decode 速度这些指标，你可以在自己的设备上把几个候选模型挨个跑一遍，直接比较。做端侧应用选型的时候，这个功能省下的时间是实打实的，因为同一个模型在不同 SoC 上的表现差异可以到好几倍，任何第三方评测都替代不了在目标机型上亲自跑一次。
聊天与思考模式
多轮对话是基本盘，值得一提的是新加的 Thinking Mode，可以把模型逐步推理的过程展示出来。这个功能目前只在支持的模型上可用，从 Gemma 4 家族开始。
我对这个功能的看法可能和宣传口径不太一样。官方说它适合理解复杂问题的解决过程，这话没错，但在端侧场景下我觉得它还有个更实际的用途——诊断。小模型答错的时候，你光看最终答案往往不知道它错在哪一步，是理解偏了、检索不到知识、还是推理链断了。把思考过程摊开，至少能判断这个模型是不是完全不适合你的任务，还是只需要改改提示词。
看图问答与语音转写
Ask Image 走的是多模态路线，调摄像头或相册里的图片，让模型识别物体、解读画面、回答关于图像的问题。Audio Scribe 则是把录音实时转写成文本，还能翻译，全程不联网。
这两个功能是我觉得端侧价值最扎实的场景，理由很简单：图像和音频都是隐私浓度极高的数据类型。文字提示词发到云端，多数人心理上还能接受；把家里的照片、会议录音传上去，顾虑就完全不同了。端侧推理在这里解决的不是延迟问题，也不是成本问题，而是「敢不敢用」的问题，这是它相对云端真正不可替代的地方。
提示词实验室
Prompt Lab 是个单轮任务的工作台，可以细粒度调 temperature、top-k 这些参数。功能上不复杂，但对开发者来说是刚需——端侧模型比云端模型对参数敏感得多，同一个提示词在 temperature 0.2 和 0.8 下的输出质量可能是天壤之别，有个地方能快速试错很重要。
Agent 技能与手机操作
Agent Skills 是这一轮更新里最有野心的部分。它让模型从单纯的对话者变成能调工具的助手，内置了 Wikipedia 事实查证、交互式地图、可视化摘要卡片这些能力，还能从 URL 加载模块化的 skill，社区在 GitHub Discussions 上贡献的也能直接用。
Mobile Actions 和 Tiny Garden 这两个功能背后是同一个东西——一个 FunctionGemma 270m 的微调版本。前者做离线的设备控制和自动化任务，后者是个用自然语言种菜收菜的小游戏。我一开始觉得种菜这个东西纯属好玩，后来想了想反倒觉得它挺聪明：用一个只有 289 MB 的模型做游戏 demo，恰恰是在演示 function calling 在极小模型上的可行性。真正的信息藏在参数量里——如果 270m 的模型能稳定输出正确的函数调用，那么很多轻量自动化场景根本不需要动辄几个 GB 的大模型。
官方性能数据怎么读
Google 在 LiteRT-LM 文档里给了一份相当详细的基准表，下面这些是官方数据，不是我的实测结果。以主推的 Gemma-4-E2B 为例，模型体积 2583 MB：
| 设备 | 后端 | Prefill (tk/s) | Decode (tk/s) | 首字延迟 (秒) | 峰值内存 (MB) |
|---|---|---|---|---|---|
| Samsung S26 Ultra | CPU | 557 | 47 | 1.8 | 1733 |
| Samsung S26 Ultra | GPU | 3808 | 52 | 0.3 | 676 |
| iPhone 17 Pro | CPU | 532 | 25 | 1.9 | 607 |
| iPhone 17 Pro | GPU | 2878 | 56 | 0.3 | 1450 |
| MacBook Pro M4 Max | CPU | 901 | 42 | 1.1 | 736 |
| MacBook Pro M4 Max | GPU | 7835 | 160 | 0.1 | 1623 |
| Raspberry Pi 5 16GB | CPU | 133 | 8 | 7.8 | 1546 |
这张表里有几个细节，我觉得比表面的数字更值得琢磨。
首先是 prefill 和 decode 的分化极其严重。S26 Ultra 上开 GPU，prefill 从 557 涨到 3808，接近 7 倍；但 decode 只从 47 涨到 52，几乎没动。这不是实现上的缺陷，是这两个阶段的计算特性决定的——prefill 批量处理输入 token，是计算密集型任务，GPU 的并行能力能充分发挥；decode 一次只出一个 token，瓶颈在内存带宽而不是算力，堆并行度没什么用。这个结论的实际含义是：如果你的应用要处理长输入（长文档摘要、大段代码分析），GPU 后端收益巨大；如果只是短问短答，用户感知到的输出速度基本由 decode 决定，开不开 GPU 差别不大。
其次是内存占用的反直觉现象。S26 Ultra 上 CPU 后端峰值内存 1733 MB，GPU 后端反而只有 676 MB，少了一半多。但 iPhone 17 Pro 上完全相反，CPU 是 607 MB，GPU 是 1450 MB。这说明峰值 CPU 内存这个指标在不同平台上统计口径不一样，GPU 后端把权重放进显存后，Android 上从 CPU 侧的统计里「消失」了，而 iOS 的统一内存架构下它仍然被算进去。看这类数据的时候，跨平台横向对比内存数字意义不大，同平台纵向比才有参考价值。
再看模型规模的代价。同样在 S26 Ultra 上，E2B 的 CPU decode 是 47 tk/s，E4B 掉到 18 tk/s，降了六成，而模型体积只从 2583 MB 涨到 3654 MB。上一代的 Gemma-3n-E2B 在 S24 Ultra 上 CPU decode 只有 16 tk/s。这两个对比放在一起看很有意思：一个是同代不同尺寸的取舍，一个是隔代的进步幅度。结论是端侧选模型时，参数量每上一档，速度惩罚都是非线性的，而等一代新模型带来的收益，可能比换一台新手机更划算。
最后是 FunctionGemma 那一行。289 MB 的模型，在 S25 Ultra 上 CPU prefill 2238 tk/s，decode 154 tk/s，比所有对话模型快一个数量级。它不能陪你聊天，但如果任务只是「把这句话变成一个函数调用」，这个速度意味着几乎零感知延迟。这也印证了我前面对 Tiny Garden 的判断。
上手和避坑
系统要求先看清楚，Android 12 及以上，iOS 17 及以上。有 Google Play 的直接从商店装，国内用户或者装不了 Play 的，去 GitHub Releases 页面下最新的 APK 手动安装，装的时候系统会弹未知来源警告，正常允许即可。iOS 在 App Store 搜 Google AI Edge Gallery 就有，macOS 版本也可以从 README 里的链接下载。
首次使用要下模型，这一步会跳转到 [[HuggingFace]]。这里有个新手常卡住的地方：[[Gemma]] 系列模型需要先在 Hugging Face 上同意 Google 的使用许可并提交访问申请，没做这一步下载会失败。申请通常很快通过，但确实是个额外步骤，第一次遇到容易以为是网络问题。
存储空间要有心理准备。一个 E2B 级别的模型接近 2.6 GB，E4B 是 3.6 GB，想多存几个对比测试的话，十几 GB 很容易就没了。手机存储紧张的话，建议先只下一个小模型试水，Gemma3-1B 只有 1005 MB，Qwen3-0.6B 更是只要 586 MB，先确认自己的使用场景成不成立，再考虑上大的。
模型选择上我的建议是从任务反推，而不是从参数量出发。需要多模态（看图、听音频）就必须选 Gemma 3n 或 Gemma 4 这类支持多模态的；只做结构化输出和函数调用，FunctionGemma 这种小家伙反而是最优解；要通用对话质量，那就在设备扛得住的前提下选最大的。千万别默认「越大越好」，端侧的速度惩罚会直接毁掉交互体验。
几个要提前想明白的期望管理。第一，这些模型是为移动端深度蒸馏和量化过的，精度上的损失是真实存在的，拿它和云端的 Gemini 或 Claude 比问答质量没有意义，两者不在一个赛道。网上关于这个 App 的实测口碑两极分化，很大程度上就是期望错位造成的——抱着「手机版 ChatGPT」的心态去用，失望是必然的。第二，持续推理是重负载，长时间对话会发热，手机降频之后速度还会往下掉，官方的 benchmark 数字是短时峰值，不代表连续使用的稳定水平。第三，它的定位是试验场，功能迭代快但也可能不稳定，别把它放进任何依赖可靠性的工作流里。
谁应该装一个
如果你是要做端侧 AI 集成的开发者，这个几乎是必装。它是 LiteRT-LM 最完整的参考实现，源码开放，benchmark 能在目标机型上直接跑，比读文档快得多。
如果你只是对本地模型好奇，想知道自己手机的算力边界在哪，那也值得装一个玩玩，成本就是几个 GB 的存储和半小时时间。看着一个几 GB 的模型在飞行模式下回答问题，那种感觉确实和调 API 不太一样。
如果你想要的是一个日常可靠的 AI 助手，那还是老实用云端服务。桌面端有本地需求的话，[[Ollama]] 和 [[LM Studio]] 的成熟度和模型选择都远超手机端，没必要在小屏幕上和一个蒸馏过的小模型较劲。
最后
我对 Google AI Edge Gallery 最大的改观，不在于它某个功能做得多惊艳，而在于它把端侧 AI 从一个模糊的概念变成了一组可以测量的数字。prefill 和 decode 的分化、参数量与速度的非线性关系、GPU 加速在不同阶段的收益差异，这些东西不亲手跑一遍很难有体感，而 Gallery 恰好把测量的门槛降到了点几下屏幕。
至于端侧模型能不能取代云端，我觉得这个问题本身就问错了。看完这些数据我更倾向于认为，两者的边界会沿着数据敏感度来划，而不是沿着能力强弱来划。照片、录音、剪贴板、通知这类东西留在设备上处理，复杂推理和长上下文交给云端，中间用 function calling 打通——FunctionGemma 那 289 MB 跑出 154 tk/s 的数字，某种程度上就是在给这个分工方案做背书。
这个项目还挂着 Beta 标签，功能会变，模型会换，今天写的性能数字过几个月大概就旧了。但它示范的那条路——把运行时开源、把基准测量交给用户、把 skill 生态交给社区——我觉得比任何单个功能都更值得关注。等哪天手上有合适的设备，我会补一篇真机实测，把官方数字和真实体感对一对，那大概会比这篇更有意思。
