手机本地跑大模型时代来了:Google AI Edge Gallery 全景拆解(原理、装机、Gemma 4 实测、Agent Skills 玩法一次讲透)

本文由 莫潇羽@无忆研习社(www.wuyi.wiki) 撰写,转载请注明出处。

快速摘要

结论先上桌:Google AI Edge Gallery 是谷歌官方做的一款"端侧大模型样板间"应用,Android 12+ / iOS 17+ 都能装,GitHub 上 Star 已经突破 22k,Fork 也有 2.2k 左右,Google Play 上线两个月 APK 下载量就破了 50 万。它把 Gemma 4 系列(E2B、E4B、26B A4B、31B Dense 这一整套开源权重)、Hugging Face 模型仓、LiteRT-LM 推理运行时、Agent Skills 智能体框架,全部塞进一个手机端的"沙盒"里,模型完全在你自己的手机上跑,加载完之后断网也能用。亮点功能至少有八个:带"思考过程可视化"的 AI Chat、能看图问问题的 Ask Image、离线语音转写的 Audio Scribe、用来调参的 Prompt Lab、可装可卸的 Agent Skills、能动手机系统的 Mobile Actions、当 demo 玩的 Tiny Garden,以及做模型基准测试的 Model Management。背后撑场子的是 LiteRT(TensorFlow Lite 的继任者)与 LiteRT-LM,配合 2-bit / 4-bit 量化、Per-Layer Embedding、KV 共享等一堆边缘优化,能把 Gemma 4 E2B 这种"5.1B 总参 / 2.3B 有效参"的小杯模型压到 1.5GB 内存以内跑起来。

想看完整拆解、原理、装机步骤、各功能怎么用、哪些手机跑得动、踩过哪些坑,往下翻就行。

一、Google AI Edge Gallery 到底是个什么东西

最近被问得最多的一个问题是:"现在的手机,真的能在本地跑大模型吗?"

说实话,过去一两年我自己也是云端调用派——OpenAI、Claude、智谱 GLM、通义千问的 API 各种切。直到我把 Google AI Edge Gallery 这个 App 装到手机上,看着一个二十几亿参数的开源模型在没插网线、关掉 WiFi 和移动数据的状态下回答我的问题,才真切感觉到端侧 AI 这件事已经不是 PPT 里的概念。

简单一句话定位它:这是一个谷歌官方维护、开源、免费的 App,专门用来"在你自己的手机上下载并运行各种开源大模型"。代码在 github.com/google-ai-edge/gallery,采用 Apache 2.0 协议,Android 端用 Kotlin 写的,iOS 端今年也已经同步上线 App Store。

它跟很多人熟悉的 ChatGPT App、Gemini App 不是一回事。后两者本质上是个"客户端",真正干活的模型在云端机房;而 Google AI Edge Gallery 走的是另一条路——模型权重直接下载到手机本地存储,推理也在手机芯片上跑完,提示词、图片、语音、聊天记录,一次也不会被传到任何服务器。这件事谷歌官方在 README 里写得很直白:"100% On-Device Privacy"。

它的另一层身份,是谷歌端侧 AI 技术栈的"展示橱窗"。底层用的是谷歌自家的开源运行时 LiteRT(TensorFlow Lite 的继任者),再上一层是专门为大语言模型优化的 LiteRT-LM,模型仓库直接对接 Hugging Face,整套链路是开源的、可以拆开来研究的。我自己折腾下来一个直观感受是,谷歌在做这个 App 的时候,目标群体里"开发者"的权重比"普通用户"高不少——它更像一个谷歌端侧 AI 平台的"门面",顺便让普通用户也能玩。

补充一点背景:谷歌为什么花这么大力气做这事?早在 Google I/O 上,他们就把"on-device generative AI"列为一个长期方向。开发者文档里反复强调三个关键词——隐私、延迟、成本——这三件事在云端 API 模式下解不掉,必须把模型推到设备本地。莫潇羽@无忆研习社 的判断是:接下来 2 到 3 年里,云端旗舰模型 + 端侧轻量模型的"混合 AI"形态会逐渐成为主流,谷歌这一手就是在抢"端侧"那一半的标准。

┌──────────────────────────────────────────────────────────┐
│        Google AI Edge Gallery 在整个技术栈里的位置         │
├──────────────────────────────────────────────────────────┤
│  应用层      │  AI Edge Gallery (本文主角)                │
│  框架层      │  LiteRT-LM(LLM 专用) + MediaPipe LLM API  │
│  运行时层    │  LiteRT(原 TensorFlow Lite)               │
│  模型层      │  Gemma 4 E2B/E4B/26B/31B、FunctionGemma 等  │
│  硬件层      │  CPU / GPU / NPU(高通、联发科等)            │
└──────────────────────────────────────────────────────────┘

二、为什么要把大模型搬到手机上跑(端侧 AI 的三个支点)

很多人第一反应是:"云端那么强,本地跑这点参数有什么意义?"我自己也问过这个问题,后来想明白了,其实不是要"取代云端",而是补一个云端补不了的洞。

隐私这一条,卡得最死

云端 API 这条路,数据必然上传。你跟模型聊的每一句话、扔给它看的每一张图、让它处理的每一段录音,都要先离开你的设备。这件事在轻度场景下没什么人在意,但只要话题往医疗病历、家庭照片、内部文档、个人日记、企业合同这几个方向偏一点,问题立刻就严重起来。

我有个做内审的朋友,公司明令禁止把任何工作内容贴到任何云端 AI 服务。这种场景下,本地跑一个能看懂中文长文的小模型,价值就完全不一样了——不是为了"特别强",而是为了"安全可用"。Google AI Edge Gallery 在这个赛道上的杀手锏就是"全程不联网也能跑",一次内网部署、一次离线推理,数据完全不出设备。

延迟这一条,体感差异极大

云端调用的延迟由三段组成:网络往返时间 + 服务端排队 + 模型推理。前两段是端侧推理完全没有的。

举个直观的例子:在地铁里、电梯里、信号弱的写字楼里、出差时的酒店 WiFi 下,云端 API 经常会卡上 3 到 5 秒才出第一个 token。本地推理虽然 token/s 比不过 H100 集群,但首 token 延迟低——往往按一下回车,字就开始往外蹦了。对"问完就要立刻看到结果"的场景(比如随手翻译、随手识图、随手语音转文字),端侧的体感优于云端。

成本这一条,长期看决定生死

云端 API 是按 token 计费的。一旦你想做一个"高频调用 + 重复使用"的产品,长期成本会是个不小的数字。端侧推理用的是设备本身的芯片算力,一次模型下载之后,推理本身没有按次费用。这件事对个人来说可能不痛不痒,但对要把 AI 能力嵌进自家 App 的开发者来说,意义重大。

我把上面三条整理成一张对比表,方便快速参考:

写到这里需要补一句:端侧不是要打败云端,两者是互补关系。谷歌自己的官方博客把 Gemma 4 和 Gemini 的关系写得很清楚——一个开源走端侧,一个闭源走云端,各自补对方解不掉的问题。

还有几个云端方案天生补不了的洞,值得专门拎出来说

第一是合规洞。国内不少行业(医疗、金融、律所、政务)对数据出域有非常硬的合规要求,云端方案要做合规适配往往牵扯到部署架构改造、合同条款修改、安全等保认证等一长串流程。端侧方案绕开了这些问题——数据从来没离开过设备,合规风险天然降低。这件事对于"想在受监管行业里把 AI 用起来的小团队"来说,意义比对个人用户大得多。

第二是带宽洞。一些场景下,网络不是"慢"或"断"的问题,而是"贵"的问题。比如户外作业、跨境出差、卫星网络环境、车联网弱信号区,流量成本和不确定性会直接把云端 API 这条路堵死。端侧方案在加载完模型之后,运行成本归零。

第三是稳定洞。云端 API 偶尔会出现"服务降级、限流、被排队"等情况,这件事在某些时间段(比如新产品发布日、热点事件爆发期)会被放大。端侧方案不存在"被限流"这件事,你的设备就是你自己的算力,跑多少次完全由你决定。

第四是时延敏感场景的洞。语音交互这种场景对延迟非常敏感,人类对语音对话的"自然感知阈值"大致在 300 毫秒以内,超过这个数字会感觉到明显卡顿。云端方案要做到这个延迟,服务器、网络、模型三方都得使劲;端侧方案天然没有网络这一段,只要芯片够快,300 毫秒以内不难做到。

把这几条加起来,你会发现端侧 AI 不是"小而美的边角料",而是云端 AI 永远盖不住的另一片天地。Google AI Edge Gallery 这个 App 之所以值得花时间研究,是因为它代表了这片天地里最前沿的工程实践。

三、Gemma 4 模型家族:谷歌端侧大模型的当家产品线

要把 Google AI Edge Gallery 用明白,不能不先把 Gemma 4 这个模型家族搞清楚。这是这个 App 当前主推的模型系列,也是端侧体验差异最大的那一环。

Gemma 是谷歌 DeepMind 开源的一系列大语言模型,跟闭源旗舰 Gemini 共享底层研究但权重完全公开,任何人都可以下载、微调、商用,许可证已经从 Gemma 自有协议换成了更宽松的 Apache 2.0。Gemma 1 / 2 / 3 一路迭代到 2026 年 4 月发布的 Gemma 4。

Gemma 4 一口气放出了四个尺寸

这里有几个名词要给新手解释一下,免得看着发懵:

• E2B / E4B 里的 E:Effective(有效)的缩写。这两个边缘模型用了一项叫 Per-Layer Embedding(逐层嵌入) 的技术,把模型里很大一块参数(嵌入层)拆出来按需加载到内存里。所以你看到的"总参 5.1B"其实跑起来"有效参"只有 2.3B,内存占用比传统的 5B 模型小一大截。
• 26B A4B 里的 A4B:Active 4B,意思是"总参 25.2B,但每次推理只激活 3.8B 左右"。这是 MoE(Mixture of Experts,专家混合)架构——模型内部有 128 个"专家",每次根据输入选择 8 个专家加 1 个共享专家来工作。优点是推理速度接近 4B 模型,但质量远超 4B。
• 128K / 256K 上下文:模型一次能"读"进去多少 token。128K 大约是 8 万到 10 万汉字,够塞进一本中等长度的书。

这套阵型最直观的感受是,谷歌把这条产品线从手机一路覆盖到工作站——E2B 给入门手机,E4B 给中高端手机和笔记本,26B A4B 给单卡 80GB H100 或者一些消费级显卡(量化之后),31B Dense 用来卷开源排行榜。Google AI Edge Gallery 这个 App 主要跑的就是 E2B 和 E4B 这两个边缘版。

边缘版有几个特别细节,值得拎出来说

• KV 缓存共享(KV Sharing):E2B 的 35 层里有 20 层共享 KV,E4B 的 42 层里有 18 层共享 KV。这不是模糊近似,是直接复用前面层精确算出来的 K/V 张量。原理是深层网络相邻层学到的 KV 表示往往高度相似,独立计算其实是冗余。这个优化只在边缘版上启用,大模型版本不开。
• 量化感知训练(QAT):谷歌额外发布了 QAT 版本的权重,在训练阶段就引入了量化噪声,4-bit 量化下精度损失非常小。配合 LiteRT 的 2-bit / 4-bit 支持,Gemma 4 E2B 在某些设备上能压到不到 1.5GB 内存就能跑。
• 多模态原生支持:E2B 和 E4B 在预训练阶段就把文本、图像、音频一起喂进去训练,不是后期"贴"上去的视觉模块。这也是为什么这两个模型能直接看图、听语音。

下面这个 Mermaid 图,大致画出 Gemma 4 边缘版的内部结构,新手可以对着图理解一下"为什么这么小的模型能这么能打":

flowchart TB
    A[输入: 文本/图像/音频] --> B[Tokenizer: 256K 词表]
    B --> C[Per-Layer Embedding<br/>按层加载,节省内存]
    C --> D{Transformer Stack}
    D --> E[Local Attention 层<br/>处理短窗口]
    D --> F[Global Attention 层<br/>处理全上下文]
    E --> G[KV Sharing<br/>复用上层 K/V]
    F --> G
    G --> H[QAT 量化权重<br/>2-bit / 4-bit]
    H --> I[输出: 文本/JSON 工具调用]

这个架构说白了就一句话:通过工程优化让小模型尽可能省内存、省算力,同时尽可能保留大模型的能力。Google AI Edge Gallery 之所以能在普通手机上把它跑起来,这套优化是关键。

几个延伸细节,理解 Gemma 4 的真实能力上限

谷歌给 Gemma 4 划的关键词不止"会聊天",还有 推理、代码、工具调用、长上下文、多模态、agent 工作流。这些能力背后是一组具体的工程取舍,值得多看两眼:

• 训练数据规模:Gemma 4 系列的训练 token 数量级在万亿级别,数据来源覆盖网页、代码、学术文献、对话语料、工具调用数据。这种数据配方是它在 agent 场景下表现稳定的基础——它见过大量"工具描述 + 调用示例 + 工具响应"的成对数据,所以输出 JSON 的格式稳定性远好于通用聊天模型
• 多模态原生融合:E2B 与 E4B 在预训练阶段就把图像、文本、音频一起训练,不是后期把视觉模块"贴"上去。视觉编码器基于 ViT,使用 2D RoPE 编码 patch 的二维空间位置,支持可变宽高比和可配置的 soft token budget(70 到 1120 tokens 之间)。这意味着你给它一张超宽截图、一张正方形头像、一张长条状的手机截图,它都能合理处理,不会强制裁剪到固定比例
• 混合注意力机制:Gemma 4 内部把 attention 分成 local 和 global 两种,local 处理短窗口,global 处理全上下文。global attention 是最耗资源的一段,谷歌在它上面叠了五重优化(压缩、稀疏化、分块计算等),最终把"长上下文 + 端侧"这件本来不可能的事撑住了
• Quantization-Aware Training(QAT):这是个区别于"训完再量化"的做法。模型在训练阶段就引入量化噪声,让它学会在低精度表示下保持输出质量。NVIDIA 已经发布了 Gemma-4-31B-IT-NVFP4(4-bit 浮点量化版本),精度损失非常小。后量化(GPTQ / AWQ)的工具链成熟、社区生态丰富,但理论上 QAT 能做到更小的精度损失
• 许可证:Gemma 4 全系列都是 Apache 2.0,商用、修改、二次分发都可以,这一点比上一代友好不少

需要打补丁说明一下:E2B 与 E4B 这两个边缘版本启用了 KV 共享、Per-Layer Embedding 等所有边缘优化,但 26B 与 31B 这两个大模型版本没有启用这些优化(num_kv_shared_layers=0)。谷歌的判断是:大模型每层独立计算 KV 的"信息增益"值得保留,KV 共享主要服务算力受限的边缘设备。这个细节告诉我们一件事——端侧优化不是"越多越好",而是"匹配场景才好"。

四、LiteRT 与 LiteRT-LM:撑起整个端侧推理的引擎

聊完模型,绕不开背后的运行时。如果说 Gemma 4 是"发动机",LiteRT 就是"变速箱+底盘"。

LiteRT 是什么

LiteRT 是 TensorFlow Lite 的继任者,谷歌已经把它定位成"下一代端侧 ML 与 GenAI 部署框架"。它继承了 TFLite 的全部能力——把模型转成轻量的 .tflite 格式、跑 CPU/GPU/NPU 推理、支持 Android/iOS/树莓派/嵌入式设备——同时新增了对生成式 AI 的专门优化。莫潇羽@无忆研习社 在做技术选型的时候踩过 TFLite 的不少坑,印象比较深的就是它对自定义算子支持一般、流式推理需要额外配置;LiteRT 在这两件事上都做了改进。

LiteRT 的特点可以简单概括为:

• 轻量:整个运行时几 MB,启动快、加载快
• 跨平台:Android、iOS、Linux、Web、嵌入式设备一套 API
• 硬件加速:CPU 用 XNNPack,GPU 用 ML Drift,NPU 接厂商专用 SDK(高通、联发科)
• 量化友好:原生支持 INT8、INT4 甚至 INT2 权重

LiteRT-LM 是 LiteRT 上专门做大语言模型的扩展

为什么要单独搞一层?因为 LLM 的推理逻辑跟传统视觉/语音模型不一样:它有 KV cache、有 prefill/decode 两个阶段、有自回归解码、有长上下文窗口、有工具调用。这些东西用通用运行时不好搞,所以谷歌在 LiteRT 上面又叠了一层 LiteRT-LM。

它给 Gemma 4 这类模型带来的能力提升,有几条可以记一下:

• 极致压内存:Gemma 4 E2B 在某些设备上能用 不到 1.5GB 内存 跑起来,靠的就是 LiteRT 对 2-bit 与 4-bit 权重的支持,加上 Per-Layer Embedding 的内存映射(memory-mapped)加载
• 动态上下文长度:同一个模型可以根据当前任务在 CPU 与 GPU 上切换,上下文窗口长度也可以动态调整,把 Gemma 4 的 128K 用满
• GPU 加速长序列:利用现代 GPU 的并行能力,Edge 版可以"在 3 秒内处理 4000 个输入 token、跨 2 个不同技能",这对 Agent Skills 这种需要预填一大段工具定义的场景至关重要
• NPU 通路:在支持的 SoC 上(高通 Dragonwing IQ8、骁龙 8 系列等),可以走 NPU 而不是 CPU/GPU,推理速度直接拔高一个数量级
• CLI 工具与 Python 绑定:litert-lm 提供命令行,Linux/macOS/树莓派都能用,开发者可以不写代码就先把效果跑起来

一组实测性能数据,可以感受一下端侧的能力天花板在哪里

NPU 跟 CPU 的差距,看 prefill 列就明白——接近 28 倍。这个差距背后是端侧 AI 这两年最大的硬件红利:手机 SoC 里专门为 AI 推理设计的 NPU 模块,算力增长非常快。

可以这么理解:LiteRT-LM 的存在,把"在手机上跑 LLM"这件事从"勉强能跑"推到了"流畅可用"。Google AI Edge Gallery 是 LiteRT-LM 的第一个完整应用案例,你装这个 App 等于一并体验了谷歌整套端侧 AI 技术栈。

LiteRT 的硬件后端,值得多说两句

很多人以为"端侧推理就是用 CPU 跑",其实早就不是了。LiteRT 在不同硬件上分别走不同后端,每条路的优化策略不一样:

• CPU 后端 XNNPack:谷歌自家的高性能算子库,深度利用了 ARM 的 NEON 指令集与 SIMD 并行。XNNPack 在矩阵乘法、卷积、量化算子上做了大量手工优化,在主流安卓 SoC 上的表现稳定可靠,是"兜底通路"
• GPU 后端 ML Drift:为移动端 GPU 设计的推理后端,利用 Vulkan/Metal API 把矩阵运算丢给 GPU。GPU 在长序列处理上比 CPU 快很多,Edge Gallery 处理图像、长上下文时会优先走这条路
• NPU 后端:在支持的 SoC 上(高通骁龙 8 Gen 系列的 Hexagon NPU、苹果 A 芯片的 Neural Engine、联发科天玑的 APU),LiteRT 会调用厂商专用 SDK,把推理交给专门的 AI 加速硬件。NPU 通路的 prefill 速度通常是 CPU 的几十倍,decode 速度也明显领先
• Web 后端:同一份模型还能编译成 WebAssembly,在浏览器里直接跑,这给"网页应用嵌入端侧 AI"打开了一条路

量化方面 LiteRT 支持得也比较全:

权重精度       内存占用比     精度损失      推荐场景
─────────────  ─────────────  ────────────  ──────────────────
FP16(基线)   100%           0             桌面/服务器
INT8           50%            < 1%          中高端手机
INT4           25%            1% ~ 3%       主流手机
INT2           12.5%          3% ~ 5%       低内存设备

这张表是个粗略量级,具体数字因模型和任务而异。Gemma 4 E2B 在 Edge Gallery 里默认走的就是 INT4 量化,加上 Per-Layer Embedding 的内存映射加载,内存峰值能压到 1.5GB 上下。

LiteRT 与 LiteRT-LM 的关系,可以这样理解

flowchart LR
    A[模型源文件<br/>HuggingFace .safetensors] -->|AI Edge Quantizer| B[量化转换]
    B --> C[.litertlm 文件]
    C --> D[LiteRT-LM 运行时]
    D --> E[LiteRT 核心运行时]
    E --> F[XNNPack CPU]
    E --> G[ML Drift GPU]
    E --> H[厂商 NPU SDK]
    F --> I[手机硬件]
    G --> I
    H --> I

简单说:模型用 AI Edge Quantizer 量化转格式 → LiteRT-LM 负责 LLM 特有的调度逻辑(KV cache、prefill/decode、tokenizer) → LiteRT 负责把张量计算丢给具体硬件。这套分层很清晰,开发者要替换某一层并不困难。

五、装机指南:从下载到第一次对话

理论铺完,聊点能上手的。我自己装了至少四遍,横跨 Android 和 iOS,把"小白也能跑通"的版本写在这。

第一步:确认你的设备能跑

最低硬件门槛:Android 12 及以上,或 iOS 17 及以上。这是官方写的。但能"装上"不代表"跑得动",真正影响体验的是:

• 运行内存(RAM):至少 6GB,推荐 8GB 以上。Gemma 4 E2B 在量化后大概占 1.5–2GB 内存,加上 App 自身和系统占用,6GB 以下的机器很容易直接 OOM 闪退
• 存储空间:至少留出 4–8GB 给模型文件
• 芯片代际:骁龙 8 Gen 1 或同级别芯片是比较舒服的起步,旗舰芯片(8 Gen 3、苹果 A17 Pro 及以上)体验明显更好;如果支持 NPU(高通的 Hexagon、苹果的 Neural Engine、联发科的 APU),走 NPU 通路速度还能再提一档

第二步:下载 App

App 的名字叫 Google AI Edge Gallery,有两条路径可以拿到。

如果是 iPhone 或 iPad,直接去 App Store 搜 "Google AI Edge Gallery",发布方 Google LLC 那个就是。安装之后第一次启动会拉一些必要的运行时文件。

如果是 Android,有两条子路:

• 应用商店路径:在能装 Google Play 的设备上,Play Store 搜同样的关键词就能下到正式版
• APK 直装路径:打不开 Google Play 的设备,可以去 GitHub Releases 页(github.com/google-ai-edge/gallery/releases/latest)下载官方签名的 APK,本地直接安装。莫潇羽@无忆研习社 实测下来,APK 装的版本和 Play Store 完全一致,只是某些 NPU 加速库需要根据自己手机型号选对应的子文件

需要小提醒的是:这个 App 在你升级版本时,要求先卸载旧版本再装新版本,谷歌 README 写明白了,旧版本不再向后兼容。

第三步:挑一个模型下载下来

打开 App,主界面是一个"功能瓦片"列表(AI Chat、Ask Image、Audio Scribe 等)。模型不会预装,你需要先去 Model Management 这个 tab 里挑一个下载。

新手建议路线:

• 先下 Gemma 4 E2B (int4 量化版):文件大概 1.5–2GB,绝大多数 6GB+ 内存的手机都能跑,响应速度尚可
• 机器够强再下 Gemma 4 E4B:文件 3GB 左右,需要 8GB+ 内存,质量明显比 E2B 好一档
• 想体验工具调用就额外下 FunctionGemma 270M:这个文件特别小,只有不到 200MB,专为 Mobile Actions 和 Tiny Garden 这两个 demo 准备

模型仓库走的是 Hugging Face,首次下载需要联网。下载完成之后,所有推理都在本地完成,可以直接断网用。

第四步:跑通你的第一个对话

回到主界面,点 AI Chat,顶部下拉菜单里选刚下载的模型,等几秒钟模型加载完毕(状态栏会显示"Loading..."→"Ready"),然后就可以开始聊了。

第一次对话我建议丢一句简单的:

请用三句话解释什么是 Per-Layer Embedding,要让初中生能听懂。

观察两件事:

• 首字延迟:正常应该在 1 秒以内,旗舰机会更快
• token 输出速度:E2B 在主流安卓旗舰上一般 8–15 tok/s,E4B 5–10 tok/s

如果首字延迟超过 5 秒或者直接闪退,说明你这台设备压力比较大,建议换更小的模型或者关掉 GPU 加速试试 CPU 模式。

六、八大功能模块拆解:每一个都讲一遍原理和怎么用

这是这个 App 最值钱的一部分。下面把官方目前提供的八大功能模块,逐一拆开讲。每一个都给出它在做什么、用了什么模型、怎么用、适合什么场景。

6.1 AI Chat 与 Thinking Mode(思考过程可视化)

最常规的多轮对话窗口,跟 ChatGPT App 长得差不多。区别在于右上角那个 Thinking Mode 开关。

打开 Thinking Mode 之后,模型在给你最终答案之前,会先输出一段它自己的"内心独白"——一步步推理的过程。这个能力目前限于 Gemma 4 家族(其他模型在 App 里是灰的)。

举个例子,你问它"一个长方形的对角线是 13,长是 12,宽是多少",在没开 Thinking Mode 的情况下它直接给你答案 5;打开之后,它会先写出"已知长方形对角线 (d=13),长 (a=12),根据勾股定理 (a^2 + b^2 = d^2),所以 (b = \sqrt{169 - 144} = 5)"这样一段推导,再给最终结论。

这个功能的价值我个人觉得比想象中大:

• 学习场景:你能看到模型怎么"想",对你自己理解题目反而是个加分项
• 调试场景:如果模型给了错答案,看一眼推理过程就知道它哪一步错了
• 不被骗:有些复杂问题,模型可能"猜对了答案但推理过程根本不对",看推理过程能识破这种情况

6.2 Ask Image:多模态识图问答

调用 Gemma 4 E2B 或 E4B 的多模态视觉能力,可以从相册选图、也可以现场拍照,然后问问题。最新版本支持单次会话最多上传 10 张图,可以多轮追问。

我自己最常用的几个场景:

• 拍一张外文菜单,让它翻译成中文并标注每道菜大概是什么口味
• 拍一张电路板,让它告诉我接口都是干什么的
• 截一张图表,让它把数据读出来

视觉编码器走的是 ViT 架构,2D RoPE 编码图像 patch 的二维空间位置,支持可变宽高比,token budget 在 70 到 1120 之间可配置。这套设计的好处是对长方形、正方形、超宽屏的图片都能处理,不会强行裁剪。

需要注意的是:端侧的视觉理解能力不如 GPT-4V、Claude 4.5 这种云端旗舰。识别物体、读取简单文字、回答常识问题没问题;识别人脸、读取手写字、理解复杂图表会差一些。

6.3 Audio Scribe:离线语音转写与翻译

录一段语音,或者上传一段音频,模型直接转成文字。还支持把转写出来的文字翻译成另一种语言。

这个功能的底层模型走的不是 Gemma 4,而是 Gemma 3n(谷歌另一个专门做音频的开源模型),通过 MediaPipe LLM Inference API 调用。整套链路同样全程离线,录音内容不上传任何服务器。

适合的场景比较具体:

• 出差访谈、用户调研的录音转写
• 看英文播客时,把其中一段截出来转成文字 + 中文翻译
• 隐私敏感的会议(比如内部讨论、医患对话),不想用云端转写服务

6.4 Prompt Lab:提示词调试工作台

一个专门给 Prompt Engineer 用的工作区。你可以丢一个 Prompt 进去,然后细粒度调 temperature(温度)、top-k、top-p、max tokens 这些参数,看看不同参数下输出有什么差别。

跟 AI Chat 的区别在于:Prompt Lab 是单轮的,不携带上下文。它的设计目标就是"针对单条 Prompt 找到最优参数",做完调试再把这套参数搬到 AI Chat 里用。

最新版本还支持 "Speculative Decoding"(推测解码,一种用小模型先猜、大模型再验证的加速技术)的开关,在 Prompt Lab 里可以打开试试效果。

6.5 Agent Skills:给模型装"插件"

这是 Gemma 4 时代谷歌主推的一个新能力,放在 Agent Skills 这个瓦片里。

它的逻辑很像 GPT 的 GPTs Actions、像浏览器的扩展插件——模型本身只懂文本对话,但通过外接"技能"(Skill),它能干很多额外的事情:

• Wikipedia 技能:模型回答问题之前先查一下维基百科,做事实校验
• Maps 技能:回答跟地理相关的问题时,顺便给你一张交互式地图
• Visual Cards 技能:把搜索结果以漂亮的可视化卡片形式呈现

这些技能是模块化的,可以在 App 里启用/禁用。更进一步,你还可以从一个 URL 加载自定义技能,或者去官方仓库的 GitHub Discussions 看社区分享的技能。

它的底层是 Gemma 4 的 结构化输出 + 函数调用 能力。当模型识别到某个问题需要调用工具时,它会输出一段标准 JSON,描述要调用哪个工具、参数是什么。Edge Gallery 拿到这段 JSON,在本地执行对应的函数,再把结果喂回给模型让它继续生成。整个过程都在手机上跑,没有任何服务器调用。

6.6 Mobile Actions:让 AI 操作你的手机

这是莫潇羽@无忆研习社 最感兴趣的一个功能,因为它指向了"端侧 AI Agent"的真正落地场景。

Mobile Actions 让你用自然语言操作手机的系统功能:

• "打开手电筒"
• "把音量调到 50%"
• "帮我打开计算器"
• "明天早上 7 点叫我起床"

背后跑的不是 Gemma 4,而是另一个更小的模型——FunctionGemma 270M,谷歌专门为函数调用微调的版本。它基于 Gemma 3 270M(2.7 亿参数)再做了 Mobile Actions 数据集的微调,准确率从基础版的 58% 提升到了 85%。

为什么要用一个这么小的模型?因为函数调用这件事不需要很强的"自然语言生成能力",它需要的是:

• 快速响应:你说一句话,1 秒内得给反应
• 稳定输出 JSON:不能给你随机生成一段乱码
• 极低内存占用:不能因为开个手电筒就吃掉 3GB 内存

270M 参数的模型完美命中这三点。在三星 S25 Ultra 上的 CPU 实测,基本是按一下回车立刻响应,内存峰值不到 500MB。

不过谷歌官方提了个安全提醒:让 AI 操作手机系统是有风险的(比如它可能误解你的意图、错操作),建议先看一遍说明再开。我的做法是只授权一些"低风险"功能(手电筒、闹钟、音量),涉及隐私的(短信、通讯录、支付)宁可手动操作。

6.7 Tiny Garden:一个有点意思的 demo 小游戏

实验性的小游戏,你跟 AI 说话,它帮你"种菜":

• "在第一行种向日葵"
• "给所有玉米浇水"
• "把熟了的西红柿收掉"

这个游戏本身没啥实用价值,但它演示了 FunctionGemma 270M 怎么把自然语言拆解成结构化的函数调用。比如 "Plant sunflowers in the top row and water them" 这一句话,模型会拆成两个连续的函数调用:plant_seed(crop="sunflower", row=1) 和 water_plots(row=1),再把网格坐标算清楚。

对开发者来说,这是个非常好的"端侧 Agent 能力展示"。如果你想做一个用自然语言控制的 App(比如智能家居、车载语音、儿童教育游戏),Tiny Garden 的代码就是参考样板。

6.8 Model Management 与 Benchmark:模型管理 + 性能基准测试

最后这个 tab 看上去最朴素,实际上对开发者最有用。它做两件事:

• 模型管理:你下载过的所有模型在这里,可以删除、可以查看磁盘占用、可以看模型卡片信息
• 基准测试(Benchmark):针对每个模型,在你这台设备上跑一遍标准化的性能测试,告诉你 prefill 速度、decode 速度、内存峰值、加载时间

跑一次大概几分钟,跑完会出一份报告。莫潇羽@无忆研习社 的建议是,新机到手第一件事就是跑一遍 Benchmark,你能立刻知道自己这台设备的端侧 AI 能力大概是个什么档次,后续选模型也有数。

下面这张表是一个简单的"功能 → 模型 → 适用场景"对照,装好之后可以照着这个表去试:

几个用得久了才发现的细节

Audio Scribe 的实际用法:它不只是录完一