前言
"端侧 LLM"在 2025-2026 年真正从 PPT 落地到手机里。Qualcomm 8 Gen 3 / MediaTek Dimensity 9300+ / Apple A17 之后，几乎所有旗舰机都能跑 1B-3B 参数的量化模型。本篇不讲理论推导，讲清楚——哪些模型在 Android 上跑得动，怎么集成，怎么评估效果，以及为什么不是"越大越好"。
一、为什么要在端侧跑
云端 LLM 的局限：
端侧 LLM 给出的解法：
延迟降到 50ms 以下（首字 + 后续 token）
数据完全不离端
一次部署，零调用成本
离线可用
代价是模型能力受限——但 1B-3B 的模型在分类、摘要、提取、简单生成等任务上已经够用。
二、当前能在 Android 上跑的主流模型
Q4 量化（4-bit per weight）是当前在精度/大小之间最甜的折中点。
三、Android 端集成路径
3.1 三种主流方案
最常见的选型：MediaPipe 做 demo，llama.cpp 做量产。
3.2 MediaPipe LLM Inference 接入示例
// build.gradle.kts
implementation("com.google.mediapipe:tasks-genai:0.10.0")
// 加载模型
val modelFile = File(filesDir, "gemma-2b-it-q4.task")
if (!modelFile.exists()) {
assets.open("gemma-2b-it-q4.task").use { input ->
modelFile.outputStream().use { output -> input.copyTo(output) }
}
}
val options = LlmInference.LlmInferenceOptions.builder()
.setModelPath(modelFile.absolutePath)
.setMaxTokens(512)
.setTemperature(0.7f)
.setTopK(40)
.build()
val llm = LlmInference.createFromOptions(context, options)
// 推理
val response = llm.generateResponse("简要介绍 Kotlin 协程：")
模型文件首次启动从 assets 复制到内部存储，Android 默认权限保护。
3.3 llama.cpp 路径（进阶）
如果你需要更精细控制：
// 加载 .gguf 模型
val modelPath = File(filesDir, "llama-3.2-1b-q4.gguf")
val context = LLMContext.create(modelPath.absolutePath, nCtx = 2048)
// token-by-token 生成（流式）
private fun generate(prompt: String, onToken: (String) -> Unit) {
val tokens = context.tokenize(prompt)
context.eval(tokens)
val sb = StringBuilder()
val max = 256
var pos = tokens.size
repeat(max) {
val next = context.sample(topK = 40, temp = 0.7f)
sb.append(context.tokenToStr(next))
context.eval(listOf(next), pos)
pos++
if (next == context.eosToken()) return@repeat
}
onToken(sb.toString())
}
复杂度高，但生产环境可控——比如可以限制 CPU 线程数避免主线程抢资源。
四、性能瓶颈在哪里
4.1 内存是第一关
中端手机（8GB）跑 3B 模型时，内存会紧，建议：
用
Configuration.appBounds检测业务进入模型页面前释放图片缓存
限定 single-task killer 风险
4.2 跑分表现（参考）
iOS 端 A17 Pro 类似 8 Gen 3 的水准。低于这个级别的设备，建议只跑 1B 模型。
4.3 推理功耗
实测每 100 token 消耗：
8 Gen 3：约 0.8% 电量
8 Gen 2：约 1.4% 电量
长时间对话会发热，建议：
用
Choreographer.postFrameCallback监测帧率推理时降频（
setThreadCount(2)）限定最长对话 50 轮，自动保存上下文到磁盘，下次 resume
五、应用落地：端侧 LLM 能做什么
5.1 真正能用的场景
本地文本摘要：把长文章压成 80 字简介
意图分类：把用户输入分到若干 intent 上
智能搜索改写：模糊表达转具体 query
离线对话机器人：客服、知识库
PII 脱敏：把"张三，电话 13800000000"替换成标准格式
轻量翻译：1-3 句短文本翻译
5.2 不能用的场景
复杂推理（数学竞赛、代码生成 long function）
多轮长上下文（>8K tokens）
实时语聊类（端侧 ASR+TTS 完整链路还在演进）
5.3 Prompt 工程在端侧更关键
云端模型靠规模，端侧靠 prompt。一个简单的 prompt 模板就能让 1.5B 模型在分类任务上追平 7B：
val prompt = """
任务：判断输入文本属于下列类别中哪一类。
类别：天气、交通、餐饮、购物、其他
输入：今天上海会下雨吗？
答案：""".trimIndent()
val result = llm.generateResponse(prompt) // 输出 "天气"
Few-shot 在端侧一样有效，但要注意上下文成本：
val fewShot = """
类别：天气、交通、餐饮
输入：明天能见度如何？
答案：天气
输入：去机场堵不堵？
答案：交通
输入：附近有川菜吗？
答案：餐饮
输入：${userInput}
答案：""".trimIndent()
六、安全与合规要点
模型版权：Gemma、Llama、Phi 都需要遵守各自 license
输出合规：端侧 LLM 也会产生违规内容，UI 必须有"内容审核"入口
用户开关：建议放在"实验性功能"开关内，默认关闭，避免被审核挑刺
本地隐私：模型权重不是用户数据，按使用条款提供，注意不收集"用户输入喂模型"
更新策略：模型迭代上线要走应用市场审核，避免 OTA 偷偷换模型
七、未来一年的演进方向
1B 模型能力逼近 7B：Hugging Face 的 SmolLM、Microsoft 的 Phi 都在这条线
NPU 化加速：高通 Hexagon、联发科 APU 的 LLM 加速真正落地
更小量化（Q2、Q1）：1.5B Q2 模型可以在 6GB 内存手机上跑
多模态：端侧 VL：1.5B 量级的 vision-language 模型 2026 年会大规模商用
统一接口：类似 ONNX Runtime Mobile 跨厂商调优
小结
端侧 LLM 已经从"能跑"走向"能用"。Android 工程引入不复杂，但落地要算清楚：模型大小、手机内存、用户体验三者的账。建议从 1.5B 起步做 POE（Proof of Engineering），再决定是否上 3B。
下一篇进入 RAG（检索增强生成）在 Android 上的工程化——端侧 LLM + 本地知识库，怎么实现"把公司文档喂给手机"。
参考阅读
Google AI Edge：MediaPipe LLM Inference
Hugging Face：SmolLM / Phi-3 模型卡片
llama.cpp Android 集成示例