公开文章
Android 端侧大模型技术路线全景图
Android 端侧大模型实战第二篇：从模型文件、量化、分发、加载、推理引擎到性能采样，梳理行业终端本地部署路线
Android 端侧大模型技术路线全景图
大家好，我是唐人。
上一篇我们先把方向定下来：
端侧大模型，不应该只盯普通手机 App。
真正更适合端侧 AI 的，往往是教育平板、医疗终端、车机、工控手持、门店设备这类行业 Android 终端。
原因也很现实：设备型号更可控，网络环境更复杂，数据更垂直，也更有机会把模型预装、下载、校验、升级和性能调优做成一套闭环。
所以第二篇，我们不写 App 层的按钮、页面、ViewModel。
这篇只聊一件事：
Android 行业终端上，端侧大模型从模型文件到本地推理，中间到底经过哪些环节？
一、端侧大模型不是 API 接入，而是本地部署链路
如果把端侧大模型理解成“调一个 AI 接口”，那路就走窄了。
真正落到 Android 设备上，它更像一条本地部署链路：
模型选择
-> 模型转换 / 量化
-> 模型文件分发
-> 本地加载
-> 推理后端选择
-> Token 生成
-> 性能采样
-> 降级 / 上云
这里每一步都会影响产品能不能跑起来。
模型太大，设备装不下。
量化不合适，效果掉太多。
加载太慢，用户打开功能先等十几秒。
backend 选错，GPU 没吃上，CPU 烫得飞起。
没有性能日志，线上出了问题只剩一句“用户说很慢”。
这才是端侧 AI 真正麻烦、也真正有价值的地方。
二、先从模型配置开始
假设我们要给一台教育平板预置一个本地错题提示模型。
不要先写业务代码。
我会先定义模型配置。
{
"model_id": "gemma-2b-it-q4",
"model_path": "models/gemma-2b-it-q4.litertlm",
"sha256": "replace-with-real-hash",
"min_ram_mb": 6144,
"preferred_backend": "GPU",
"fallback_backend": "CPU",
"context_length": 2048,
"max_output_tokens": 256,
"temperature": 0.3
}
这段配置看起来很普通，但它比写一个“AI 助手类”重要。
因为行业终端部署模型，最先要回答的是这些问题：
- 模型文件在哪里？
- 是
.task、.tflite，还是.litertlm？ - 模型有没有做 hash 校验？
- 低于多少内存不允许加载？
- 优先跑 GPU 还是 CPU？
- GPU 失败以后怎么 fallback？
- 上下文长度限制多少？
- 单次最多生成多少 token？
这才是本地部署的第一层。
App 层只是壳，模型配置才是端侧能力的入口。
三、Android 上几条路线怎么摆？
现在再看 Gemini Nano、ML Kit、LiteRT-LM、MediaPipe，就会清楚很多。
它们不是同一种东西。
Gemini Nano / AICore 更像系统托管模型。
如果设备支持，模型管理、更新、安全和硬件加速尽量交给系统。适合系统级能力、设备可控的终端，但你不能假设所有 Android 设备都有。
ML Kit GenAI 更像高层任务 API。
它适合快速验证摘要、改写、校对、图片描述这类功能，但它不是底层本地部署主线。用它验证产品价值可以，别把它当成你掌控模型文件和推理引擎的方案。
LiteRT-LM 是现在更值得重点关注的本地 LLM 路线。
Google AI Edge 文档把它定位成面向 LLM 的生产化运行和编排层，强调 Android Kotlin API、跨平台、高性能，以及 CPU/GPU/NPU 等硬件后端。
MediaPipe LLM Inference 仍然值得了解，但现在 Android 文档已经明确提示维护模式，新功能和优化会集中到 LiteRT-LM。
所以新项目里，我会把 MediaPipe 当成理解历史路线和存量 Demo 的材料，而不是新主线。
一句话：
想快速验证功能，看 ML Kit；想系统托管，看 Gemini Nano；想自己带模型做本地部署，新项目优先看 LiteRT-LM。
四、加载模型时，真正要关心的是 backend 和 fallback
本地部署不是把模型文件放进目录就结束。
你还要决定它怎么跑。
enum class InferenceBackend {
CPU,
GPU,
NPU
}
data class LocalModelConfig(
val modelPath: String,
val sha256: String,
val preferredBackend: InferenceBackend,
val fallbackBackend: InferenceBackend,
val contextLength: Int,
val maxOutputTokens: Int,
val temperature: Float
)
行业终端里，我会把 backend 选择写得非常明确。
比如教育平板可以优先 GPU，失败后回退 CPU。
车机如果有专用 NPU，可能要优先走 NPU。
医疗终端如果稳定性要求高，宁愿慢一点，也要优先选择更可控的后端。
伪代码大概是这样：
fun chooseBackend(config: LocalModelConfig, device: DeviceProfile): InferenceBackend {
if (config.preferredBackend == InferenceBackend.NPU && device.hasNpu) {
return InferenceBackend.NPU
}
if (config.preferredBackend == InferenceBackend.GPU && device.hasGpu && device.ramMb >= 6144) {
return InferenceBackend.GPU
}
return config.fallbackBackend
}
这类代码比业务路由更重要。
因为端侧模型能不能跑稳，很多时候就卡在这里。
五、性能采样必须从第一天就做
端侧大模型不能只看“能不能生成文字”。
行业终端里，至少要记录这些指标：
- 模型加载耗时
- 首 token 时间
- prefill tokens/s
- decode tokens/s
- 峰值内存
- backend 类型
- 设备温度
- 是否 fallback
- 推理是否超时
日志可以先很朴素：
data class InferenceMetrics(
val modelId: String,
val backend: InferenceBackend,
val loadMs: Long,
val firstTokenMs: Long,
val prefillTokensPerSec: Float,
val decodeTokensPerSec: Float,
val peakMemoryMb: Int,
val fallbackUsed: Boolean,
val success: Boolean
)
真正上线后，你需要的不是“我感觉这个模型挺快”。
你需要的是一张表：
设备型号 | 模型 | backend | 首 token | decode/s | 峰值内存 | 温度 | 成功率
只有这张表出来，模型选择才不是拍脑袋。
六、行业终端选型：先问能不能控制设备
如果我现在要做一个行业终端端侧 AI 项目，我会按这个顺序问：
- 设备型号能不能控制？
- 模型能不能预装或受控下载？
- 本地存储够不够？
- RAM 是否够加载目标模型？
- 有没有 GPU / NPU 可用？
- 弱网或无网时必须保留哪些能力？
- 哪些结果必须人工确认？
- 性能指标怎么采样和回传？
这些问题没想清楚，不要急着选模型。
特别是普通手机 App，很多时候第一问就卡住了：
你根本控制不了用户设备。
这也是为什么我反复强调，端侧大模型更适合行业终端。
教育平板可以预装模型。
车机可以绑定硬件平台。
医疗终端可以走统一设备管理。
工控手持可以固定系统镜像。
这才是本地部署真正有机会跑稳的地方。
七、这一篇先定地图
第二篇我们先不展开具体 SDK。
只先把底层路线定住：
模型配置 -> 模型分发 -> 本地加载 -> 后端选择 -> 推理生成 -> 性能采样 -> 降级策略
后面每一篇，都应该围绕这条链路往下钻。
第三篇如果写 Gemini Nano，就不能只写“怎么调 API”，而要讲清楚 AICore 托管模型的边界、设备支持、模型状态和失败兜底。
第五篇如果写 LiteRT-LM / Gemma，就要真正进入模型文件、加载配置、backend、tokens/s 和内存。
第六篇性能评测，就要把日志和 benchmark 表格跑出来。
这才是“Android 端侧大模型实战”该有的味道。
我是唐人。
下一篇，我们开始拆第一条路线：Gemini Nano / AICore。
参考资料
关注公众号
不错过后续文章和配套资源
扫码关注「唐人Console」，获取文章更新、配套资源和领取入口。 需要解锁时，文章页会生成专属口令。
扫码关注