端侧大模型上 Android：2026 年，手机里跑 LLM 已经不是科幻

端侧大模型上 Android：2026 年，手机里跑 LLM 已经不是科幻

两年前，"手机跑大模型"还是 PPT 里的概念。今天，Gemini Nano 已经内置进 Pixel 和 Galaxy，MediaTek、高通纷纷在 NPU 上做推理加速，llama.cpp 的 Android 移植早就跑通了 7B 模型。这件事已经从"能不能做"变成了"怎么做才好用"。

为什么端侧 LLM 值得关注

先说一个不那么显眼的趋势：云端 LLM 的 API 调用成本正在成为很多产品的头号账单。每次对话都要走一次网络，延迟、成本、隐私，三个问题同时摆在工程师面前。

端侧模型提供了一条不同的路：

隐私天然保障：用户输入的内容完全不离开设备，医疗、金融、日记类 App 的数据合规问题直接消解。

零网络依赖：飞行模式、弱网环境一样能用。对工具类 App 来说，这个体验提升是实实在在的。

延迟极低：本地推理没有网络 RTT，首 token 速度在高端机上可以做到 200ms 以内，比调云端 API 快了一个数量级。

当然，端侧也不是万能药——模型能力上限摆在那里，7B 以下的模型做复杂推理还是不如 GPT-4o。但对于很多场景：文本摘要、意图识别、本地问答、个性化回复建议……端侧模型已经够用了。

2026 年的技术格局

先梳理一下现在主流的几条路：

如果你是做产品的，优先考虑 MediaPipe LLM Inference API，Google 官方维护，兼容性最好，Gemma 2B 的效果对大多数 NLP 任务已经足够。如果你需要更大的模型或者完全掌控推理过程，再考虑 llama.cpp 的路子。

用 MediaPipe 跑 Gemma：最快的起步路径

来看一段真实可运行的代码。先在 build.gradle 加依赖：

implementation("com.google.mediapipe:tasks-genai:0.10.22")

然后初始化推理引擎，加载模型（模型文件需要提前下载到 assets 或本地路径）：

val options = LlmInference.LlmInferenceOptions.builder()
.setModelPath("/data/local/tmp/gemma-2b-it-cpu-int4.bin")
.setMaxTokens(1024)
.setTopK(40)
.setTemperature(0.8f)
.setRandomSeed(101)
.build()val llmInference = LlmInference.createFromOptions(context, options)

发起推理，支持流式输出：

llmInference.generateResponseAsync(
prompt,
object : LlmInference.LlmInferenceResultListener {
override fun onResult(partialResult: String, done: Boolean) {
// 流式更新 UI
runOnUiThread {
textView.append(partialResult)
}
if (done) {
// 推理完成
}
}
override fun onError(error: RuntimeException) {
Log.e("LLM", "Inference failed", error)
}
}
)

就这几十行，一个本地 LLM 推理的最小闭环就跑通了。Gemma 2B int4 量化版本只有 1.5GB 左右，在 Snapdragon 8 Gen 2 及以上的设备上，生成速度能达到 15-25 token/s，流式显示体验相当流畅。

模型文件怎么分发？

这是端侧 LLM 最绕不开的工程问题。1-2GB 的模型文件不可能打包进 APK，常见的方案有三种：

方案一：首次启动后台下载 用户安装后，在合适时机（Wi-Fi、充电）后台下载模型文件，存到 getExternalFilesDir() 或 getFilesDir()。简单直接，适合大多数场景。缺点是首次下载需要时间，用户体验有断层。

方案二：按需下载（Feature Delivery） 通过 Google Play 的 Dynamic Feature Modules 机制，把模型文件作为一个可选模块，用户触发特定功能时再下载。流量只在真正需要时产生，对不用 AI 功能的用户友好。

方案三：复用设备已有模型 这是最优雅的方案——Android 14 引入了 AICore 机制，Gemini Nano 由系统统一管理，多个 App 可以共用同一份模型文件，不重复占用存储。目前仅限 Pixel 8 及以上，但这是明显的方向。

💡 工程建议：做好模型下载的降级处理。端侧推理不可用时（下载失败、设备性能不足），自动 fallback 到云端 API。对用户来说体验无缝，对你来说风险可控。

性能调优：几个关键参数

端侧推理的性能瓶颈主要在两块：内存带宽和 NPU/GPU 利用率。几个实测有效的调优点：

量化精度选择：int4 量化比 fp16 快 2-3 倍，内存占用降低约 75%，但精度会有轻微损失。对大多数 NLP 任务，int4 是最佳平衡点。int8 是折中选择。

GPU 推理：MediaPipe 支持切换到 GPU delegate，在支持 OpenCL 的设备上能获得 30%-50% 的速度提升。代码里加一行：

.setAcceleratorName("gpu_accelerator")

批量处理 vs 实时流式：如果你的场景是后台任务（批量生成摘要、标签），关掉流式输出，用 generateResponse 同步接口，吞吐量会更高。

上下文长度控制：每次请求的 prompt 越短，推理越快。在 prompt engineering 上下功夫，去掉无关上下文，是最直接的优化手段。

哪些场景真的好用

聊了这么多技术，说几个我觉得端侧 LLM 在 App 里真正值得做的场景：

智能输入建议：类似 iOS 的预测文本，但更聪明。结合用户历史行为，在输入框实时给出个性化建议。隐私敏感，本地模型天然合适。

本地文档 / 笔记问答：把用户的笔记做 embedding 存到本地向量库（比如 Android 上的 Room + sqlite-vec），结合端侧 LLM 做 RAG，完全离线的个人知识库助手。

内容摘要：长文章、聊天记录的自动摘要，在阅读类、IM 类 App 里需求旺盛，本地摘要没有隐私顾虑，用户接受度高。

意图识别 / 语义路由：不需要 LLM 生成内容，只用它做分类。把用户输入分到不同业务模块，比传统 NLP 模型更鲁棒，模型还更小（可以用更激进的量化）。

还不成熟的地方

说句公道话，端侧 LLM 的生态现在还有不少坑：

设备碎片化依然是噩梦。同样是 Snapdragon 8 Gen 2，不同厂商的 NPU 驱动行为不一致，踩过 A 厂的坑不代表 B 厂没问题。测试矩阵要覆盖足够宽。

发热问题不容忽视。持续推理会让手机温度快速上升，触发系统降频。生产代码里必须做推理时间限制和温度监控，别让 LLM 把用户手机烤成暖手宝。

模型更新机制复杂。端侧模型一旦部署，更新就比云端麻烦得多——需要重新下载几百 MB 到几 GB 的文件，还要处理版本兼容。模型版本管理是个绕不开的工程问题。

端侧大模型不是云端的替代品，是补充。最好的产品设计是"端云协同"：简单任务走本地，复杂任务走云端，用户感知不到切换。

2026 年的判断

我觉得端侧 LLM 在 2026 年已经过了"早期尝鲜"阶段，进入了"工程化落地"阶段。芯片算力还在快速提升，模型量化技术越来越成熟，Gemma、Phi-3 这类专为端侧设计的小模型效果越来越好。

如果你在做 C 端 App，这是一个值得提前布局的方向。不是所有功能都适合上端侧 LLM，但那些"用户最频繁、最私密、网络最不稳定"的场景，值得认真评估一遍。

工具在这里，缺的只是合适的工程师把它用好。

— END — 觉得有用的话，点个在看 👇