在 Android 上跑大模型，我踩过的那些推理加速坑

有人问过我在 Android 上跑大模型和在服务器上跑有什么本质区别我想了一下说服务器上你在意的是吞吐手机上你在意的是不要把电池榨干、不要让用户等三秒、不要因为内存不够直接崩。本质区别不是算法是你的对手从慢变成了死。这篇文章想聊的就是这件事怎么在 Android 上把一个 LLM 塞进去还能让它活得好看。不讲理论讲工程路径讲我觉得值得或不值得的取舍。为什么端侧推理看起来容易做起来难先说一个反常识的事模型参数量不是端侧部署最大的障碍内存访问模式才是。一个 7B 参数的模型INT4 量化后大概 3.5GBPixel 8 有 12GB RAM听起来没问题。但推理时Transformer 的 KV Cache 是随 context length 线性增长的。你跑一个 512 token 的对话KV Cache 可能额外吃掉 500MB。跑 2048 token再翻四倍。更麻烦的是Android 上的内存是被多个进程共享的。系统随时可能因为内存压力把你的进程 kill 掉或者触发 LMKLow Memory Killer把 KV Cache 所在的 allocation 回收掉。你以为在推理实际上在赌系统不会在这个时间点发神经。所以端侧 LLM 工程的第一个教训是不要用服务器的眼光评估能不能跑要用嵌入式工程师的眼光评估跑的时候会不会死。推理框架选哪个给个直接答案目前 Android 端侧推理主要有这几条路•MNN阿里文档最全中文社区最活跃对 LLM 的专项优化MNN-LLM更新频繁是我目前首推的方案•llama.cpp跨平台之王Android 可以通过 JNI 调用量化格式支持最丰富但 Android GPU 加速需要自己搭 Vulkan backend工作量不小•MediaPipe LLM Inference APIGoogle 官方出品接入成本最低但支持的模型列表有限自定义空间小•ONNX Runtime Mobile适合你的模型已经是 ONNX 格式的场景配合 NNAPI EP 可以走 NPU 加速但 LLM 类模型的支持还在跟进中•ExecuTorchMetaPyTorch 官方的移动端推理方案2025 年后成熟度大幅提升Llama 3 有官方支持值得关注我的判断如果你想快速上手、用中文资料、跑 Qwen/ChatGLM 这类国产模型MNN 是最省心的选择。如果你想要更底层的控制权、更广的模型兼容性llama.cpp JNI 是更合适的底层。MediaPipe 适合做 demo不适合做生产级应用。MNN-LLM 接入从模型转换到首次推理说具体一点用 MNN-LLM 跑 Qwen2.5-1.5B 的完整流程是这样的第一步模型转换MNN 需要把 HuggingFace 格式的模型转成 .mnn 格式。官方提供了llm_export工具# 安装依赖 pip install transformers torch MNN # 导出并量化为 INT4 python -m MNNTools.llm_export \ --path Qwen/Qwen2.5-1.5B-Instruct \ --dst_path ./qwen2.5_1.5b_int4 \ --quant_bit 4 \ --quant_block 128 \ --lm_quant_bit 8注意--lm_quant_bit 8LM head最后的词表投影层建议用 8-bit用 4-bit 的话输出概率分布会有明显的质量下降这个取舍是值得的——LM head 本身参数量不大8-bit 增加的体积可以忽略。第二步把模型文件打进 APK模型文件比较大有几种策略• 首次启动从 CDN 下载推荐避免 APK 超限• 放在 assets 里只适合 50MB 的超小模型• 用 Android App Bundle 的 asset delivery按需下载最优雅但接入成本较高下载后放到getExternalFilesDir()下注意用 SHA256 校验文件完整性别让用户用了个截断的模型文件疑惑为什么输出乱码。第三步JNI 初始化和推理调用MNN 提供了 Android AARGradle 依赖加上去之后核心调用如下// build.gradle (app) dependencies { implementation com.alibaba.android:MNN:2.9.0aar implementation com.alibaba.android:MNN-LLM:2.9.0aar } // LLM 初始化建议在 IO 线程 class LLMEngine(private val modelDir: String) { private var llm: MNNLLMSession? null fun init(): Boolean { val config MNNLLMConfig().apply { modelPath modelDir // 优先 GPU不可用时 fallback 到 CPU backendType MNNBackendType.GPU // 控制 KV Cache 最大占用单位MB kvCacheMemLimit 512 } llm MNNLLMSession.create(config) ?: return false return true } // 流式推理callback 在推理线程回调 fun chat(prompt: String, onToken: (String) - Unit, onDone: () - Unit) { llm?.generateAsync(prompt, object : MNNLLMSession.TokenCallback { override fun onToken(token: String, isDone: Boolean) { if (isDone) onDone() else onToken(token) } }) ?: onDone() } fun release() { llm?.release() llm null } }几个细节值得说•kvCacheMemLimit一定要设不然默认值在长对话场景下会把内存撑爆• GPU backend 在部分骁龙设备上首次初始化需要 2-3 秒做 shader 编译建议做预热App 启动时静默 init•generateAsync的 callback 不在主线程UI 更新要切回来量化方案的取舍INT4 不是终点大多数教程告诉你量化到 INT4 就行但工程实践里情况更复杂。我的实测数据Pixel 8, Qwen2.5-1.5B量化方案模型大小首 token 延迟生成速度主观质量FP163.0 GB850ms12 tok/s基准INT81.5 GB520ms19 tok/s几乎无损INT4 (block128)830 MB310ms28 tok/s轻微下降INT4 (block32)900 MB340ms25 tok/s基本与INT8持平这里有个反直觉的地方block size 越小量化粒度越细精度越高但速度反而略慢因为反量化开销变大了。block128 是速度和质量的甜点也是 MNN 的默认值一般不用改。另一个值得关注的点是混合精度量化Mixed Precision。简单说就是对模型里敏感度高的层用高精度不敏感的层用低精度。最近 ArXiv 上关于多教师知识蒸馏和可靠性感知量化的论文都在往这个方向走。工程上MNN 现在已经支持按层配置量化 bit 数# 混合精度前几层和最后几层用 INT8中间层用 INT4 python -m MNNTools.llm_export \ --path Qwen/Qwen2.5-1.5B-Instruct \ --dst_path ./qwen2.5_1.5b_mixed \ --quant_bit 4 \ --quant_block 128 \ --lm_quant_bit 8 \ --mixed_quant true混合精度在 1.5B 这个量级上提升有限但对 3B 以上的模型相比纯 INT4 质量提升比较明显值得一试。NNAPI 和 GPU 加速用还是不用这是被问得最多的问题之一我直接给结论GPU 加速OpenCL/Vulkan强烈推荐但要做 fallback。NNAPI走 NPU谨慎使用坑多。原因如下GPU 在矩阵乘法上有天然优势MNN 的 OpenCL backend 在骁龙 8 系旗舰上能给 LLM 带来 2-3 倍的速度提升。OpenCL 的兼容性比 Vulkan 好Android 6.0 基本都有Vulkan 要求 Android 7.0但部分厂商的 Vulkan 驱动实现有 bug。我的建议是优先尝试 OpenCL失败了再 fallback CPU。NNAPI 问题就复杂多了。NNAPI 是 Google 提供的 NPU/DSP 统一接口理论上能让骁龙 Hexagon DSP、天玑 APU 参与推理。但 LLM 的计算图比传统 CNN 复杂得多很多算子在 NNAPI 里没有原生实现会自动 fallback 到 CPU——这意味着数据要在 CPU 和 NPU 之间来回搬运反而比纯 CPU 更慢。更糟糕的是各厂商 NNAPI 实现的差异性非常大同一个模型在小米上跑得好好的到 OPPO 上直接 crash。如果你不打算为每个厂商单独测试就老老实实用 GPU。// 带 fallback 的 backend 选择策略 fun selectBackend(): MNNBackendType { return try { // 先尝试 OpenCL val testConfig MNNLLMConfig().apply { modelPath modelDir backendType MNNBackendType.OPENCL } val testSession MNNLLMSession.create(testConfig) if (testSession ! null) { testSession.release() MNNBackendType.OPENCL } else { MNNBackendType.CPU } } catch (e: Exception) { Log.w(LLM, OpenCL unavailable, fallback to CPU: ${e.message}) MNNBackendType.CPU } }KV Cache 管理最容易被忽视的性能杀手我见过不少接入了 LLM 的 Android App开始用还挺流畅对话到后期越来越卡最后 OOM 崩掉。根因几乎都一样没有管 KV Cache。KV Cache 是 Transformer 推理的历史记录。随着对话轮次增加它线性增长。对于 1.5B 的模型单条对话跑到 2000 token 时KV Cache 大约占 300-400MB。再来几个并发对话内存直接顶。工程上的应对策略•滑动窗口截断保留最近 N 轮对话超出部分从头重新 prefill。实现简单但用户会感觉模型失忆•对话摘要压缩超出限制时用模型自身生成历史摘要把 KV Cache 重置到一个摘要当前的较短上下文。质量更好但需要额外一次推理•硬限制 context length在导出模型时限制最大 sequence lengthMNN 支持在 export 阶段设置彻底断掉 KV Cache 无限增长的可能实际项目里我倾向于组合方案export 时设 max_seq_len1024运行时再做滑动窗口避免边界情况踩坑class ConversationManager(private val maxTokens: Int 800) { private val history mutableListOf() private var totalTokens 0 fun addMessage(role: String, content: String, tokenCount: Int) { history.add(Message(role, content, tokenCount)) totalTokens tokenCount // 超出限制时从最早的 user/assistant 对开始裁剪 while (totalTokens maxTokens history.size 1) { // 保留 system promptindex 0 val removed history.removeAt(1) totalTokens - removed.tokenCount } } fun buildPrompt(systemPrompt: String, newUserInput: String): String { val sb StringBuilder() sb.append(\n$systemPrompt\n) for (msg in history) { sb.append(\n${msg.content}\n) } sb.append(\n$newUserInput\n\n) return sb.toString() } } data class Message(val role: String, val content: String, val tokenCount: Int)温度控制与采样策略不只是创意旋钮很多人把 temperature 理解成创意调节这没错但在端侧推理里它还有另一层含义温度越低生成越确定越快。Greedy 解码temperature0, argmax是最快的解码策略在固定输出场景比如结构化数据提取、代码补全下推荐使用。Top-P 采样在温度 0.7-0.9 时有比较好的质量但每步都要做 softmax sampling速度慢 10-15%。另一个值得关注的是 speculative decoding推测解码。思路是用一个更小的 draft 模型快速生成候选 token再用大模型做验证不通过的丢掉重来。理论加速比可以达到 2-3 倍。MNN 目前还没有原生支持但 llama.cpp 已经有稳定实现。如果你的场景对延迟极度敏感这个方向值得深入。一个完整的推理流程图App 启动↓检查模型文件 / 下载↓Backend 探测OpenCL → CPU↓模型加载 预热推理↓用户输入 → Prompt 构建↓流式 Token 生成 → UI 更新↓KV Cache 管理滑动窗口内存超限→ 裁剪历史 / 生成摘要 OOM/Crash→ 降级到更小模型或云端 API云端 fallback别和自己较劲最后说一个工程上的务实建议不要把端侧推理做成孤立功能要和云端 API 形成互补架构。用户手机可能是红米 Note内存 6GB装了一堆 App你的 1.5B 模型在这台设备上大概率会被 OOM 终结。这不是失败是现实。合理的架构是优先走端侧低延迟、离线可用、保护隐私在以下情况自动切换到云端 API• 设备可用内存 2GB通过 ActivityManager.getMemoryInfo 检测• 端侧初始化失败• 用户请求需要超长上下文 2048 token• 用户主动选择高质量模式端侧 云端的混合策略才是当下 Android AI 应用的正确姿势。纯端侧是理想混合是工程。写在最后端侧大模型部署是一个仍在快速演进的领域。今天你写的 MNN 代码可能明年就有更好的方案替代。但有些东西不会变内存约束、设备碎片化、用户对响应速度的期待——这些是 Android 工程的底色不管上面跑什么模型都逃不掉。我觉得接下来值得持续关注的方向是speculative decoding 在移动端的落地以及基于 LoRA 的端侧个性化微调——后者已经有论文证明在 1B 以下模型上可行一旦框架层面有成熟支持用户本地训练自己的助手就从科幻变成了工程问题。那才是端侧 AI 真正有意思的起点。如果对端侧 AI 开发感兴趣欢迎留言交流。下篇打算聊聊 LoRA 微调在 Android 上的可行性。