LiteRT-LM Android 教程：端侧大模型接入路线与常见坑

2026-09-16

LiteRT-LM 不是“把一个模型文件放进 assets 就结束”的库。它解决端侧生成模型的运行问题，但一个能发布的 Android 应用还需要模型分发、完整性验证、状态管理、线程调度、生命周期和设备兼容。把这些层混在一个 Activity 或 Composable 里，Demo 可能能跑，真实用户很快会遇到卡死、重复加载和内存问题。

LiteRT 与 LiteRT-LM 的关系

LiteRT 是 Google 的端侧 AI 运行框架，覆盖移动、桌面、Web 与边缘平台的 CPU、GPU 和 NPU 路径。LiteRT-LM 在公开仓库中提供生成式模型的运行能力，并使用自己的模型包和 API。

官方的 LiteRT 框架说明适合了解整体栈；要确认 Gemma 的移动部署入口，应同时看 Gemma 移动部署文档和 Gemma 运行方式总览。版本变化快，依赖坐标和 API 形态必须以当前文档为准。

接入顺序

第一步：用最小输入确认模型包能加载

不要一开始就接相机、录音和数据库。先用固定短文本跑通加载与一次生成，记录模型初始化是否成功、输出是否结束、异常能否捕获。模型格式或运行时不兼容时，这个最小用例最容易定位。

第二步：把加载移出主线程

模型文件读取与运行时初始化都是长耗时任务。它们应进入协程和明确的后台调度，不应发生在 Compose 重组路径里。Composable 只观察状态，不能因为页面重新进入就创建第二个引擎实例。

第三步：限制并发

端侧模型通常不适合同时跑多次生成。InferenceEngine 应定义串行队列、取消规则和超时策略。用户连续点击按钮时，是取消上一条、排队还是拒绝新请求，需要产品明确决定，不能交给线程竞争决定。

第四步：处理生命周期

应用切后台、系统回收、Activity 重建和进程死亡都会发生。模型文件可以长期保留，但内存中的引擎实例不能假设永远存在。恢复时要从磁盘状态重新建立，而不是依赖某个单例仍活着。

第五步：再接多模态输入

文本路径稳定后，再加入图片、音频或函数调用。每增加一种模态，都应重新测峰值内存与连续运行稳定性。图片预处理尺寸、音频时长和上下文累积都会显著改变资源占用。

最常见的五类坑

模型文件存在，但加载失败

文件存在只证明下载路径里有东西，不证明版本、格式和内容正确。Cove 当前 E2B 配置记录了明确的预期文件长度；生产链路还应配合哈希与加载校验，并在失败后删除临时文件或损坏文件。

官网体积与真实下载不一致

模型权重、量化包和完整部署包可能是不同数字。对用户展示时必须标注口径；存储预检必须用真实交付文件，而不是模型卡上的近似值。

模拟器通过，真机失败

模拟器没有代表性的移动 NPU/GPU 环境。硬件 delegate、驱动与系统版本问题只能在真机暴露。发布门禁应包含目标芯片设备，而不只是 assembleDebug 成功。

首轮正常，连续生成后崩溃

这通常与缓存、上下文增长、资源未释放或温控有关。测试不能只跑一次固定 prompt，应包含连续生成、取消、重新加载和前后台切换。

把运行时异常直接显示给用户

底层异常适合日志，不适合原样展示。UI 应将它们归一为可行动状态，例如“模型文件损坏，请重新下载”“可用内存不足”“当前设备暂不支持硬件加速”。

最小测试矩阵

测试	至少覆盖什么
下载	断网、续传、空间不足、镜像切换
校验	长度不符、哈希不符、临时文件恢复
加载	首次、重复、切换模型、进程重启
推理	空输入、长输入、取消、连续生成
生命周期	后台、锁屏、旋转、低内存回收
设备	中端与旗舰各一台，CPU 回退至少一次

下一步

如果还没选模型，先读 Gemma 4 本地部署与 Cove 端侧模型横评。如果已经确定做手机端产品，则应尽快建立自己的真实设备基准，而不是复制别人的 tokens/s 数字。

本文最后核验于 2026-09-16。LiteRT-LM 仍在快速更新，示例代码和依赖版本应以官方当前文档为准；本文重点是不会随一次 API 改名而失效的工程边界与验证路线。

留言讨论

评论发布后会被人工复核，违规内容将被删除。

如果发表没有反应，可以前往联系我们告诉我们。