手机已经能够运行大模型，但“成功输出第一个Token”和“可以交给用户长期使用”是两回事。
腾讯云开发者社区的一篇文章提到，Gemini Nano已经进入Pixel和Galaxy设备，llama.cpp的Android移植也能运行7B模型。到了App开发阶段，问题随即变得具体：模型加载时会不会触发OOM，推理算子是否真的落在NPU上，连续对话几分钟后还能不能保持响应速度。
这些问题通常不能靠换一个更大的模型解决。开发者要先把内存、计算路径和温控调度理顺。
模型还没运行，内存可能已经不够了
以FP16精度的7B参数模型为例，仅权重理论上就需要约14GB空间。手机标称内存不等于App可以自由使用的内存，Android里的Java堆、Native堆、图形资源和系统进程都在争夺有限空间。模型如果在Java层反复创建对象，或者JNI层的资源没有及时释放，很容易出现GC频繁、加载失败甚至直接崩溃。
第一步通常是量化。2024年10月26日举行的“端侧AI大模型开发与应用实践技术论坛”把量化、蒸馏和剪枝列为模型适配端侧设备的主要压缩手段。对Android App来说，INT8或INT4的价值很直接：减少模型体积，也降低加载和推理阶段的内存压力。
量化之后仍要控制加载过程。模型权重、KV Cache、激活值和业务侧数据不能毫无节制地同时驻留内存。更稳妥的做法是延迟初始化推理资源，在用户真正进入对话时再创建必要对象；退出页面或切换模型后，明确释放Native资源，不能只等Java层GC处理。
高频对话还会带来内存碎片。JNI层如果持续申请、释放大小不同的缓冲区，App运行一段时间后可能仍有剩余内存，却找不到合适的连续空间。可以预分配固定大小的Direct Buffer并循环复用，减少临时对象和跨层数据复制。模型加载、推理中断、页面销毁等路径都要覆盖到，否则一次异常退出就可能留下未释放资源。
模型本身也不必承担全部知识。固定业务资料可以放在本地检索层，例如使用SQLite配合FTS，或接入嵌入式向量数据库。模型负责理解和生成，知识内容按需取用。这样比把所有信息都塞进模型权重更适合移动端维护。
接入NPU后，先确认有没有偷偷回退
纯CPU推理容易接入，也方便调试，但持续运行时会占用大量计算资源。高通、联发科平台提供了NPU等专用单元，真正的难点在于：模型中的算子能否被底层后端完整支持。
Android NNAPI提供了统一接口，可以屏蔽部分硬件差异。不过，某个算子不受支持时，框架可能把它交给CPU或GPU。表面上看，模型仍然正常运行；实际结果却可能是延迟增加、功耗升高。排查性能时，不能只看“是否启用NNAPI”，还要检查每个计算节点最终落在哪个后端。
模型转换因此很关键。高通平台可使用SNPE等工具链，也可以通过AI Engine Direct调用Hexagon DSP；联发科平台则有对应的端侧工具。阿里云创业平台转载的终端侧AI文章也提到，高通的优化方法包括量化、编译器技术、硬件加速和AI引擎架构。这里没有一套模型文件通吃所有芯片的捷径，转换后的算子兼容性和回退情况都需要在目标设备上验证。
多模态模型还多了一层数据搬运成本。AtomGit开源社区的Android多模态模型实践涉及NDK 25c或26b等开发环境。落到执行链路上，图像预处理可以交给GPU，模型推理由NPU承担，尽量形成稳定的“GPU预处理＋NPU推理”流程。若图像、特征张量频繁在Java、C++、GPU和NPU之间复制，硬件加速带来的收益很容易被抵消。
发热之后，峰值性能没有太大意义
端侧推理的另一道门槛是持续负载。模型刚启动时速度正常，不代表连续对话后仍能维持同样表现。手机散热空间有限，系统触发热保护后会降低处理器频率，首轮测试得到的速度也就失去了参考价值。
应对发热，先从任务调度下手。后台摘要、图片标签生成等非实时任务，不必和前台聊天同时争夺资源。可以使用WorkManager或JobScheduler延后执行，并结合充电、网络等条件安排任务。前台也要限制并发，避免多个模型会话同时占用CPU、GPU和NPU。
生成长度同样需要约束。聊天界面可以采用Token流式输出，让用户尽早看到结果；设备持续高负载时，则缩短最大生成长度，或切换到更小的备用模型，例如从7B切换到3B。流式输出主要改善等待感，真正减少计算量仍要依靠更短的上下文、更少的生成Token和更轻的模型。
温控测试也不能只跑一轮。至少要覆盖连续多轮对话、前后台切换、模型重复加载以及多模态输入等场景。记录每轮生成耗时和是否出现降频，比单看首次响应更能说明App能否长期使用。
UI也需要承接这种波动。高负载时给出明确的生成状态和进度反馈，避免界面长时间静止。用户可以接受等待几秒，却很难判断一个没有反馈的页面究竟是在推理，还是已经卡死。
先定设备边界，再谈模型参数
Android端侧大模型开发不适合从“能塞进多大的模型”开始。更实际的顺序是：先确定目标设备和可接受的内存占用，再完成量化与模型转换；随后检查算子是否回退，最后用连续运行测试验证温度和响应速度。
如果7B模型只能在短时演示中保持流畅，换成3B并做好本地检索，往往更接近可交付的产品。端侧AI的价值来自离线运行、低网络依赖和本地数据处理，但这些优势必须建立在App不崩溃、手机不过热、响应时间可控的前提上。
参考资料：
