端侧 AI 革命
当 AI 不再需要服务器 — 理解这件事为什么颠覆了整个行业
你的手机里已经藏着一个 AI 大脑
想象一下:你打开 Google AI Edge Gallery 应用,说了一句话,AI 立刻回答了你——全程没有联网。没有请求云服务器,没有上传你的数据,一切在你手机的芯片上完成。
这不是魔法,这是端侧 AI(On-Device AI)。而 Google AI Edge Gallery 这个开源项目,就是迄今最完整的端侧 AI 落地案例展示台。
全球 54 亿手机用户,每个人的口袋里都有一台超级计算机。端侧 AI 意味着这些算力终于可以被直接利用——零延迟、零网络依赖、完全隐私保护。
当你点击"AI Chat"时,发生了什么?
想象你是一名邮差,负责在城市的不同部门之间传递消息。传统 AI 的做法是:每次你要问一个问题,邮差必须先飞到旧金山的 Google 数据中心,取回答案,再飞回来。而端侧 AI 是:把整个"图书馆"搬进你的手机,邮差在楼下就能找到答案。
你输入文字或语音
本地模型处理请求
芯片执行推理
结果直接显示
整个过程不超过 100 毫秒,你的数据从未离开手机。
Gallery 能做什么?认识 8 个核心功能
AI Chat
本地运行的多轮对话,支持 Thinking Mode 展示推理过程
Ask Image
拍照后让 AI 识别物体、解读图片内容
Audio Scribe
实时语音转文字与翻译,完全离线
Prompt Lab
测试不同提示词,调节 temperature 和 top-k 参数
Mobile Actions
用 AI 控制手机操作,全部本地执行
Tiny Garden
用自然语言种植虚拟花园的实验性迷你游戏
Agent Skills
给 LLM 配备工具:Wikipedia、地图、视觉摘要卡
Benchmark
测试每个模型在你设备上的真实性能
三个技术支柱
端侧 ML 的核心 API 集合——就像是 AI 运行的"操作系统"
LiteRT 是为移动设备优化的轻量推理运行时,让大模型能在小设备上高效运行
直接从 HF Hub 搜索和下载模型,无需手动配置
一个典型的 GPT-4 级别模型需要数百 GB 内存。端侧模型(如 Gemma 4 系列)通过量化技术可以把尺寸压缩到 2-4GB,适合在手机上运行。
知识检验:端侧 AI 基础
你正在开发一个医疗问诊 AI 应用,用户的健康数据极度敏感。采用端侧 AI 架构最主要的好处是什么?
在 Gallery 架构中,LiteRT 的职责是什么?
Gallery 架构解析
认识代码里的"演员"——每个组件是谁、负责什么
就像乐队:每个人负责不同的乐器
Galaxy Gallery 是一个 Android 应用,用 Kotlin 编写,采用了 MVVM 架构模式。代码被整齐分成多个层,就像一支乐队:每个声部各司其职,互不干扰。
UI 层 — 用户看到的界面
ViewModel 层 — 业务逻辑
Data 层 — 数据定义
Runtime 层 — AI 推理引擎
代码解读:Task 是什么样子的?
每个 AI 功能(聊天、图片分析、语音转录)在代码里都是一个 Task 对象。让我们读一读它的定义:
data class Task(
val id: String,
val label: String,
val category: CategoryInfo,
val description: String,
val models: MutableList<Model>,
val docUrl: String = "",
)
定义一个"任务"的模板(类似表格的字段定义)
id:任务的唯一标识符,如 "llm_chat"
label:界面上显示的名称,如 "AI Chat"
category:这个任务属于哪个分类(LLM 类还是实验类)
description:在任务界面顶部显示的说明文字
models:这个任务支持的 AI 模型列表(可以有多个)
docUrl:可选的技术文档链接,默认为空
Kotlin 的 data class 自动帮你生成比较、复制、打印等功能。一行代码顶 Java 里几十行。这是为什么现代 Android 开发都用 Kotlin 的原因之一。
组件如何对话:一次"加载模型"对话
用户点击下载 Gemma,背后的组件是怎么协作的?
代码结构一览
用户的下载进度条需要更新,这个更新请求应该由谁来处理?
模型加载与推理流水线
从下载到回答:一条消息是如何被处理的
就像在印钞机里放纸
想象一台老式印刷机。模型加载就像把印版安装进机器——这需要一些时间,但只做一次。推理(Inference)就像印刷——每次都很快,因为机器已经准备好了。
在 Gallery 中,当你选择一个模型并点击初始化,推理引擎被加载到内存中,之后每条消息的响应速度才会很快。
LlmModelHelper 接口:定义"推理引擎规范"
Gallery 支持多种底层推理引擎(LiteRT-LM 和 AICore)。为了让上层代码不需要关心底层差异,代码定义了一个接口(Interface):
interface LlmModelHelper {
fun initialize(
context: Context,
model: Model,
onDone: (String) -> Unit,
systemInstruction: Contents? = null,
)
fun runInference(...)
fun resetConversation(...)
fun cleanUp(model: Model)
}
定义一份"规范书":所有推理引擎都必须遵守
initialize:启动引擎,加载指定的模型
context:Android 应用的上下文(访问文件、内存等)
model:要加载的具体模型对象
onDone:加载完成后要调用的回调函数
systemInstruction:给 AI 的系统级指令(如"你是个助手")
runInference:执行一次推理(处理用户输入)
resetConversation:清空对话历史,重新开始
cleanUp:释放内存,卸载模型
Streaming 输出:为什么 AI 是一个字一个字出现的?
你有没有注意到 AI 回答时文字是流式出现的,而不是等一会儿然后全部出现?这是流式输出(Streaming)技术。
在 Gallery 的代码中,推理回调函数的签名揭示了这一机制:
typealias ResultListener =
(partialResult: String,
done: Boolean,
partialThinkingResult: String?) -> Unit
ResultListener 是一个回调函数类型的别名
partialResult:当前这一批新生成的文字(每次一小段)
done:是否已经全部生成完毕?true = 结束了
partialThinkingResult:Thinking Mode 下的推理过程文字(可选)
回调(Callback)是异步编程的核心概念。模型推理很耗时,不能让程序停下来等。传入一个回调函数,让引擎在完成时主动通知我们。
多硬件后端:NPU 还是 GPU?
LiteRT-LM 后端
通用方案:支持所有 Android 12+ 设备,使用 GPU 加速,兼容性最广
AICore 后端
高性能方案:利用 NPU(神经处理单元)加速,仅限支持的旗舰 Android 设备
你想让 Gallery 支持第三种推理引擎(比如 Qualcomm AI Engine)。在当前架构下,最正确的做法是什么?
UI Demo 模式
Gallery 如何设计可扩展的 AI 功能演示界面
就像乐高积木:Task + Model + Screen
Gallery 的 UI 设计遵循一个清晰的模式:每个 AI 功能(Task)对应一个 Screen,每个 Screen 可以切换不同的 Model。就像乐高——积木形状固定(接口一致),但可以拼成各种形状(不同功能)。
用户看到所有 Task 的卡片,按 Category 分组(LLM、实验类等)
导航到对应的 Screen(如 LlmChatScreen、AskImageScreen),顶部显示任务描述
ModelManager 组件让用户在 Task 支持的模型列表中选择,触发下载和初始化
根据 Task 类型,UI 提供不同的交互方式(文字输入、相机、麦克风)
模型配置的可视化:Prompt Lab 里的参数
Prompt Lab 功能让用户直接调整 AI 的行为参数。这些参数在 Gallery 里被定义为 ConfigValue 类型,每个任务的 Model 对象包含一个配置列表:
temperature
Temperature:控制输出随机性(0.0 = 确定,1.0 = 随机),影响创意程度
topK
Top-K:每次选词时考虑的候选数量(越小 = 越保守)
maxOutputTokens
最大输出Token 数:控制回答长度上限
systemInstruction
系统指令:告诉 AI 扮演什么角色、遵守什么规则(如"你是个助手,回答要简洁")
如果你用 AI 写代码,temperature 应该接近 0(保证准确)。如果写创意文案,temperature 可以调高(增加创造力)。Gallery 把这些参数可视化,让你不用改代码就能实验。
Agent Skills:让 LLM 调用真实工具
Gallery 的 Agent Skills 系统展示了如何给 LLM 添加工具调用能力。在代码里,每个 Skill 是一个 ToolProvider,传给 LlmModelHelper.initialize():
fun initialize(
context: Context,
model: Model,
tools: List<ToolProvider> = listOf(),
enableConversationConstrainedDecoding:
Boolean = false,
)
初始化函数,接受可选的工具列表
tools:给 AI 配备的工具清单(默认为空,不带工具)
List 意味着可以带多个工具:搜索 + 地图 + 日历
constrainedDecoding:是否约束 AI 只能按特定格式输出
这使得 Gallery 中同一个模型可以无工具 / 带工具两种模式
拖拽配对:认识 Gallery 的各个 Screen
多轮对话界面,支持 Thinking Mode,文字来回交流
调用相机或相册,让 AI 描述、分析图片内容
测试模型性能:token 速率、首字延迟等指标图表
单轮测试工作台,可调 temperature / top-k 参数
社区贡献了一个新的 AI Skill(比如"查股票价格")。Gallery 是如何让 LLM 能使用这个新技能的?
构建自己的端侧 AI 应用
从 Gallery 学到的模式,直接用于你的下一个项目
Gallery 是一份最佳实践教材
学完 Gallery 的架构,你已经掌握了端侧 AI 应用的完整蓝图。这套模式不只适用于 Android——理解这些原则,你在指导 AI 构建任何端侧应用时都能做出更好的决策。
接口隔离(Interface)+ 数据驱动(Data Classes)+ 响应式 UI(ViewModel + StateFlow)+ 插件化扩展(ToolProvider)。这四个模式是现代移动 AI 应用的基石。
构建端侧 AI 应用的决策清单
手机端:2-4GB 量化模型(Gemma 2B/4B)。平板/高端机:可考虑 7B。用 Gallery Benchmark 功能在目标设备上测试。
需要最广兼容性:LiteRT-LM。需要最高性能(仅高端机):AICore。参考 Gallery 的接口抽象,支持运行时切换。
参考 Gallery 模式:下载 → 加载 → 推理 → 卸载。及时释放内存,尤其在应用切换到后台时。
使用 ResultListener 回调模式,每收到 partialResult 就更新 UI,不要等全部完成。用户体验差距巨大。
当设备不支持端侧推理时,回退到 API 云端调用。Gallery 的架构已经为这种切换做好了准备。
常见陷阱与解法
找出端侧 AI 集成中的问题代码:
// 用户点击"发送"按钮后的处理
sendButton.setOnClickListener {
modelHelper.runInference(inputText, callback)
outputText.text = result
}
综合测验:你准备好构建端侧 AI 了吗?
你的端侧 AI 应用上线后突然病毒式传播,用户从 1 万增长到 100 万。你的服务器账单会怎样变化?
如果你的 AI 应用要支持一个 3GB 的模型,最佳的分发方式是什么?
你现在理解了端侧 AI 的核心原理、Google AI Edge Gallery 的完整架构、LiteRT 推理流水线,以及可以直接应用到项目中的设计模式。当你下次告诉 AI 助手"帮我构建一个端侧 AI 应用"时,你知道该问什么、该怎么引导它了。