唐人Console

公开文章

Android 端侧大模型与行业终端实战合集计划

从手机 App 到教育平板、医疗终端、车机和行业设备，系统梳理 Android 端侧大模型的落地路线

Android 端侧大模型与行业终端实战合集计划

合集定位

合集名称：Android 端侧大模型与行业终端实战

目标读者：

  • 有 Android 开发经验，想切入 AI 应用落地的工程师
  • 对 Gemini Nano、ML Kit GenAI、MediaPipe、Gemma、LiteRT-LM 感兴趣的客户端开发者
  • 正在做教育平板、医疗终端、车机、工控手持、门店设备等行业 Android 终端的开发者
  • 想把 AI 功能真正接进行业设备，而不是只停留在手机 Demo 的开发者

核心目标：

用 10 篇文章，把 Android 端侧大模型从“为什么值得做”讲到“怎么做成真实行业终端功能”。

这不是纯概念科普合集，而是偏工程落地：

  • 每篇都有明确问题
  • 每篇都有技术路线判断
  • 中后段文章尽量配代码、Demo、性能数据或工程清单
  • 最后一篇收束成一个真实行业终端功能

当前技术判断

结合官方资料和当前生态，Android 端侧大模型可以分成四条技术路线，但真正落地时不能只盯普通手机 App。

更现实的判断是：

端侧 AI 的主战场，不一定是消费级手机 App，而是那些能控制设备、网络、场景和数据闭环的行业 Android 终端。

除非你是手机厂商、系统级应用、超级 App，或者能拿到足够强的设备覆盖和系统能力，否则普通手机 App 很难稳定保证模型可用、性能可控、体验一致。

但教育平板、医疗终端、车机、工控手持、门店 POS、自助机、会议屏、巡检设备这类 Android 终端不一样：

  • 设备型号更可控
  • 使用场景更明确
  • 数据更垂直
  • 网络条件更复杂
  • 隐私和合规要求更强
  • AI 功能更容易围绕业务闭环设计

所以这个合集后续会坚持一个原则：

从 Android 技术出发，但从行业终端场景落地。

路线 代表技术 适合场景 主要限制
系统级模型 Gemini Nano / Android AICore 隐私、本地、低延迟、系统统一模型管理 设备支持、API 能力、灰度限制
产品级快捷 API ML Kit GenAI 摘要、校对、改写、图片描述、语音识别等标准功能 可定制性弱，设备支持要检查
自带模型推理 MediaPipe LLM Inference / LiteRT-LM / Gemma 自定义模型、自定义体验、离线实验、私有场景 包体、内存、发热、性能调优
端侧知识增强 AI Edge RAG / Text Embedder / 本地向量库 本地知识库、文档问答、行业私有数据问答 数据切分、召回质量、存储和评测

我的判断是：

面向真实 Android 产品，优先顺序应该是：先判断设备和行业场景是否适合端侧，再用 ML Kit GenAI 快速做功能，再理解 Gemini Nano/AICore，再用 MediaPipe 或 LiteRT-LM 做开放模型实验，最后把 RAG 和端云协同接进行业业务。

不要一上来就追求“手机跑 7B 大模型”。那很酷，但不一定是产品里最先值得做的事。

更值得追问的是：

这个行业终端为什么必须在本地推理？它解决的是教育、医疗、车载、工业、门店里的哪一个真实问题？

推荐目录结构

文章/2026-07/android-on-device-llm-practice/
├── plan.md
├── 01-what-problems/
│   └── index.md
├── 02-technical-map/
│   └── index.md
├── 03-gemini-nano-first-feature/
│   └── index.md
├── 04-ml-kit-genai-product-feature/
│   └── index.md
├── 05-mediapipe-gemma-android/
│   └── index.md
├── 06-performance-benchmark/
│   └── index.md
├── 07-model-selection/
│   └── index.md
├── 08-on-device-rag/
│   └── index.md
├── 09-device-cloud-collaboration/
│   └── index.md
└── 10-real-app-feature/
    └── index.md

后续如果某篇文章需要配图或代码资源，就在该篇文章目录下继续创建：

images/
├── covers/
└── illustrations/

文章规划

01. Android 端侧大模型到底解决什么问题？

文章目标：先把读者从“手机跑大模型很酷”拉回到“端侧 AI 到底解决什么行业终端问题”。

核心观点：

端侧大模型不是为了替代云端大模型，也不是只为普通手机 App 服务，而是解决行业终端里云端不擅长的四类问题：隐私、离线、低延迟、低边际成本。

建议结构：

  • 从一个真实行业终端场景切入：教育平板、医疗终端、车机助手、本地文档问答
  • 端侧 AI 的四个价值：隐私、离线、低延迟、成本可控
  • 端侧 AI 的三个误区：不是更聪明、不是万能、不是所有普通手机 App 都适合做
  • Android 开发者为什么应该关注这件事
  • 为下一篇“技术路线全景图”埋钩子

可配图：

  • 端侧 AI 价值四象限：隐私、离线、延迟、成本
  • 行业终端落地地图：教育、医疗、汽车、工业、门店

02. Android 端侧大模型技术路线全景图

文章目标：建立全局地图，让读者知道 Gemini Nano、ML Kit、MediaPipe、LiteRT-LM、RAG 分别站在哪里。

核心观点：

Android 端侧大模型不是一条路线，而是一组分层能力：系统模型、产品 API、自带模型推理、本地知识增强、端云协同。落地时还要叠加行业终端约束：设备控制权、网络环境、数据边界、合规要求和业务闭环。

建议结构：

  • Android 端侧 GenAI 的五层结构
  • Gemini Nano / AICore：系统级共享模型
  • ML Kit GenAI：面向产品功能的高层 API
  • MediaPipe LLM Inference：把开放模型跑在移动端
  • LiteRT-LM：更偏生产化和跨平台的 LLM 运行层
  • RAG：让模型接入行业私有知识
  • 端云协同：端侧不是单打独斗

可配图：

  • Android 端侧大模型技术栈分层图
  • 行业终端适配决策图

03. 使用 Gemini Nano 做第一个端侧 AI 功能

文章目标：带读者完成第一个基于 Gemini Nano / AICore 的端侧 AI 功能认知与接入准备。

核心观点：

Gemini Nano 的重点不是“自己打包一个模型”，而是通过 Android AICore 使用系统级模型能力，让模型管理、更新、安全和硬件加速尽量交给系统。

建议结构：

  • Gemini Nano 是什么
  • AICore 在 Android 里的角色
  • 适合做什么：摘要、建议、改写、轻量 Prompt 任务
  • 接入前必须检查：设备支持、系统版本、模型可用性、API 状态
  • Demo 设计：本地输入一段用户笔记，生成 3 条任务建议
  • 常见坑：设备不支持、模型没下载、延迟波动、输出不可控

实战产出：

  • 一个最小可运行 Demo
  • 一份设备兼容性检查清单

04. 用 ML Kit GenAI 快速做产品级小功能

文章目标：从“能跑模型”切换到“能快速上线一个用户感知明确的小功能”。

核心观点：

如果目标是快速做产品功能，ML Kit GenAI 往往比直接调底层模型更适合作为第一站。

建议结构：

  • ML Kit GenAI 的定位：面向具体任务的高层 API
  • 当前适合的功能：摘要、校对、改写、图片描述、语音识别
  • Streaming 和 non-streaming 怎么选
  • Demo 设计一：聊天输入框一键润色
  • Demo 设计二：文章内容一键摘要
  • 产品侧注意事项：加载状态、失败兜底、用户可编辑、结果确认

实战产出：

  • 一个“输入框改写/校对”小功能
  • 一套产品级 UI 状态：可用、不可用、生成中、失败、重试

05. MediaPipe LLM Inference：把 Gemma 跑在 Android 上

文章目标：进入自带开放模型路线，让读者理解“把模型放进 App 跑”的完整链路。

核心观点：

MediaPipe LLM Inference 适合理解端侧 LLM 推理的底层过程：模型文件、后端选择、上下文长度、内存占用、首 token 延迟。

建议结构：

  • 为什么要自己跑 Gemma，而不是只用 Gemini Nano
  • MediaPipe LLM Inference 的角色
  • Gemma 模型格式：.task / .litertlm
  • CPU / GPU backend 怎么选
  • Demo 设计：本地问答或文本续写
  • 常见问题：模型太大、加载慢、内存高、发热、不同设备表现差异大

实战产出：

  • 一个 Gemma on Android Demo
  • 记录初始化耗时、首 token 延迟、输出速度、内存占用

06. 端侧大模型的性能指标怎么测？

文章目标：让读者知道端侧大模型不能只看“能不能跑”，更要看“跑得是否可用”。

核心观点：

端侧大模型的性能评测，至少要看初始化时间、prefill 速度、decode 速度、首 token 时间、峰值内存、功耗、温度和失败率。

建议结构：

  • 为什么端侧 AI 的评测比云端更复杂
  • 关键指标解释：
    • 初始化时间
    • Time To First Token
    • Prefill tokens/s
    • Decode tokens/s
    • 峰值内存
    • 电量和温度
    • 成功率和超时率
  • adb / Android Studio Profiler / 自定义日志怎么配合
  • 不同输入长度如何影响性能
  • 如何做一张设备测试表

实战产出：

  • 一份 Android 端侧 LLM benchmark 模板
  • 一组测试脚本或日志埋点方案

07. 模型选择：1B、2B、3B、7B 到底怎么选？

文章目标：解决读者最容易踩坑的问题：模型越大不一定越适合行业终端。

核心观点：

Android 上选模型，本质是在效果、速度、内存、包体、功耗、设备覆盖率和行业场景之间做取舍。

建议结构：

  • 参数量不等于产品效果
  • 1B 级别：适合轻量分类、改写、简单问答、低端设备实验
  • 2B / E2B：适合多数端侧文本功能的起点
  • 3B / 4B / E4B：适合稍复杂的问答、总结、指令理解
  • 7B 及以上：更像高端设备/实验场景，产品化要谨慎
  • 量化精度的影响：体积、速度、效果
  • 如何用行业任务反推模型，而不是用模型反推功能

实战产出：

  • 一张“任务类型 -> 推荐模型范围 -> 风险点”的选择表

08. 端侧 RAG：让行业终端拥有自己的本地知识库

文章目标：把端侧 LLM 从“通用聊天”拉到“理解行业本地数据”。

核心观点：

端侧 RAG 的价值不是让小模型变聪明，而是让它能基于设备本地资料、行业知识库和用户现场数据回答问题，同时尽量不把敏感数据发到云端。

建议结构：

  • RAG 是什么：检索增强生成
  • Android 端侧 RAG 的基本流程：
    • 导入数据
    • 切分文本
    • 生成 embedding
    • 存入本地向量库
    • 根据问题检索相关片段
    • 拼接上下文给 LLM
  • MediaPipe Text Embedder / AI Edge RAG SDK 的角色
  • Demo 设计：教育资料 / 医疗说明书 / 车载手册 / 设备维修文档问答
  • 难点：中文分段、召回质量、上下文长度、隐私授权、增量索引

实战产出：

  • 一个行业终端本地知识库问答 Demo
  • 一份 chunk 策略和召回评测表

09. 端云协同：端侧 AI 不应该单打独斗

文章目标：建立正确架构观，不把端侧和云端对立起来。

核心观点：

真正可用的行业 AI 终端，往往是端侧负责隐私、即时、离线和现场任务，云端负责复杂推理、多模态重任务、模型管理和跨设备同步。

建议结构：

  • 为什么端侧 AI 不能包打天下
  • 端侧适合：隐私数据、短文本、实时建议、离线兜底、现场知识检索
  • 云端适合：复杂推理、大上下文、多模态、持续学习
  • 三种协同模式：
    • 端侧优先，失败上云
    • 云端主导，端侧预处理
    • 端侧 RAG + 云端大模型总结
  • 安全和隐私：什么数据不能出端，什么数据可脱敏上云
  • Demo 设计：行业终端本地先检索和摘要，复杂问题再经过权限确认请求云端模型

实战产出：

  • 一个端云路由策略
  • 一个行业终端 AI 功能降级方案

10. 把端侧大模型做成一个真实行业终端功能

文章目标：收束合集，把前面能力组合成一个完整行业终端产品功能。

建议功能方向：

优先选择“本地知识库 + 场景助手 + 端云协同”的组合，做一个真实可演示的行业终端功能：

功能名：教育平板本地学习助手

功能描述：

  • 学生或老师导入本地课件、错题、讲义
  • 设备在端侧生成 embedding 并建立索引
  • 用户可以在无网或弱网环境下提问
  • 简单问题由端侧模型回答
  • 复杂讲解经过用户确认后走云端
  • 输入框支持端侧改写、摘要和学习建议

这个终局 Demo 先选教育平板，是因为它比普通手机 App 更符合端侧 AI 的落地条件：设备相对可控、内容相对垂直、隐私和离线都有真实需求，功能边界也比较容易说清楚。

文章结构：

  • 需求拆解
  • 技术选型
  • 架构设计
  • 数据流
  • UI 状态
  • 性能评测
  • 隐私和权限说明
  • 最终效果
  • 哪些地方还能继续优化

实战产出：

  • 一个完整行业终端 Demo
  • 一张架构图
  • 一份性能报告
  • 一份端侧 AI 行业终端产品化 checklist

建议发布节奏

周期 文章 目标
第 1 周 01、02 建立认知和技术地图
第 2 周 03、04 跑通 Gemini Nano / ML Kit 产品级小功能
第 3 周 05、06 跑通开放模型，并开始做性能评测
第 4 周 07、08 深入模型选择和端侧 RAG
第 5 周 09、10 完成端云协同和真实行业终端功能

如果时间有限，也可以按 2 周一篇来做，保证每篇都有代码和截图。

合集素材池

官方资料

需要重点追踪的变化

  • Gemini Nano / AICore 的设备支持列表
  • ML Kit GenAI 的可用 API 和设备覆盖
  • MediaPipe LLM Inference 支持的模型格式和后端
  • LiteRT-LM 的 Android Kotlin API、NPU/GPU 支持和模型格式
  • Gemma 系列模型尺寸、量化版本和移动端表现
  • AI Edge RAG SDK 的成熟度和本地向量检索方案

统一文章风格

这个合集建议采用“轻松口语 + 工程实战”的风格：

  • 开头用真实 Android 行业终端场景引入
  • 不堆论文术语
  • 每篇都说明“这个技术适合什么、不适合什么”
  • 每篇都给一个可以落地的小 Demo，并说明它更适合普通手机 App 还是行业终端
  • 关键概念用图讲清楚
  • 结尾给下一篇预告，形成追更感

后续可扩展选题

  • Android 端侧 AI 的权限和隐私设计
  • 端侧 AI 功能如何做灰度发布
  • 如何给 AI 输出做 UI 兜底
  • 端侧模型下载、缓存和版本更新策略
  • Android 端侧大模型与 Flutter/KMP 的结合
  • 端侧 AI 在教育平板、医疗终端、车机、工控手持、门店设备里的真实场景
  • 教育平板上的本地错题问答和学习建议
  • 医疗终端上的本地资料检索和文书辅助
  • 车机上的离线语音助手和用车手册问答
  • 工业巡检设备上的维修知识库和现场记录总结
  • 中文端侧 RAG 的切分、召回和评测
  • 用 AI Edge Gallery 反向学习端侧模型产品设计

合集最终交付物

完成 10 篇后，建议沉淀成：

  1. 一个完整的 Android 行业终端 Demo
  2. 一份端侧大模型技术路线图
  3. 一套性能 benchmark 模板
  4. 一份模型选择指南
  5. 一份端侧 RAG 最小实现
  6. 一份端云协同架构 checklist

这个合集如果做扎实，会很适合沉淀成“唐人 Console”的 Android + AI 代表性内容。

关注公众号

不错过后续文章和配套资源

扫码关注「唐人Console」，获取文章更新、配套资源和领取入口。 需要解锁时，文章页会生成专属口令。

唐人Console二维码扫码关注