旧手机吃灰这件事，估计每个人家里都能翻出两三台。前阵子我整理抽屉，翻出来一台骁龙 855 的老机器，屏幕有点老化，电池也不太行了，但 CPU 和内存还算能打。当时第一反应是拿去换不锈钢盆，后来转念一想，这玩意的算力其实比很多开发板强不少，为什么不拿来跑个大模型试试？于是就有了这次折腾——用 OlliteRT 在旧安卓机上部署大模型，顺便把性能调优的坑踩了一遍。这篇文章就是整个过程的完整记录，从环境准备、模型选型、部署步骤到性能调优，全部是实测出来的经验，不是纸上谈兵。如果你手里也有闲置的安卓设备，想让它发挥点余热，或者你对端侧大模型部署感兴趣，这篇内容应该能帮你少走不少弯路。
1. 为什么要在旧手机上跑大模型
1.1 端侧推理这件事到底值不值得做
先说结论：值得，但要看你的预期是什么。很多人一听到"手机跑大模型"，第一反应是"这不是找罪受吗"。确实，如果你指望在手机上跑出云端 API 那种流畅体验，那趁早放弃。但端侧推理有它不可替代的价值——数据不出设备、离线可用、没有网络延迟、不消耗 token 费用。这几个优势在特定场景下非常关键，比如隐私敏感的个人助手、网络不稳定的户外环境、或者单纯想研究模型推理机制的开发者。
从技术角度看，现在安卓设备的硬件条件比几年前好太多了。骁龙 8 系芯片的 NPU 算力已经相当可观，内存普遍 8GB 起步，UFS 3.1 的存储读写速度也够用。即便是几年前的旧旗舰，跑量化后的小参数模型完全没问题。我这次用的骁龙 855 配合 8GB 内存，跑 1B 到 3B 参数的量化模型，推理速度虽然谈不上快，但日常问答、文本摘要这类任务是可以接受的。
另外一个容易被忽略的点是：端侧部署的过程本身就是一次很好的学习机会。你会接触到模型量化、推理框架、算子优化、内存管理这些在云端部署时往往被封装掉的东西。把这些搞明白，对理解大模型的运行机制帮助很大。
1.2 OlliteRT 解决了什么痛点
在 OlliteRT 出现之前，安卓端跑大模型主要有几条路：一是用 TensorFlow Lite 自己转换模型，但支持的大模型架构有限，转换过程也麻烦；二是用 MLC LLM 这类方案，效果不错但编译链复杂，对新手不太友好；三是直接调云端 API，那就失去了端侧的意义。
OlliteRT 的思路不太一样，它把模型加载、推理调度、内存管理这些脏活累活封装起来，对外暴露相对简洁的接口。你可以把它理解成安卓端的"推理运行时"，类似桌面端的 Ollama 那种定位。它支持 GGUF 格式的量化模型，这意味着你可以直接用社区里现成的量化模型文件，不需要自己从头转换。对于想快速验证想法的人来说，这个门槛降低了很多。
它主要解决三个问题：第一是模型格式兼容，GGUF 是目前端侧量化模型的主流格式，生态最丰富；第二是硬件加速适配，能根据设备能力自动选择 CPU、GPU 或 NPU 后端；第三是内存管理，大模型加载对内存压力很大，OlliteRT 在内存分配和回收上做了不少优化，避免推理过程中被系统杀掉。
1.3 旧手机作为推理设备的真实定位
得把预期摆正。旧手机跑大模型，定位是"轻量级本地推理节点"，不是"替代云端服务"。适合的任务包括：短文本问答、简单的情感分析、关键词提取、文本分类、小规模的翻译。不适合的任务包括：长文档理解、复杂推理、代码生成、多轮长对话。
我实测下来，1B 参数的模型在骁龙 855 上，生成速度大概在每秒 5 到 8 个 token，3B 模型降到每秒 2 到 4 个 token。这个速度用来做交互式对话会有点卡，但做批处理任务（比如一次性处理一批文本）就完全够用。所以关键是想清楚你的使用场景，别拿它去做它不擅长的事。
还有一点，旧手机的散热是个大问题。持续推理会让 SoC 温度快速上升，然后触发降频，速度断崖式下跌。所以如果你要做长时间推理任务，散热措施必须考虑，这个后面会详细讲。
2. 部署前的环境准备与模型选型
2.1 设备要求与系统版本检查
不是所有安卓机都能跑。先说硬性门槛：系统版本建议 Android 10 及以上，因为 OlliteRT 依赖的一些底层 API 在低版本上不可用。内存最低 6GB，推荐 8GB 以上，因为模型加载后还要留出足够的运行内存，否则系统会频繁杀后台。存储空间至少预留 10GB，量化模型文件虽然不大，但加上运行时缓存和日志，空间消耗比想象中多。
CPU 架构方面，arm64-v8a 是必须的，32 位设备直接放弃。如果你的设备支持 GPU 加速（比如 Adreno 或 Mali 的较新系列），推理速度会有明显提升。NPU 支持则要看具体芯片和 OlliteRT 的适配情况，目前覆盖度还在完善中，不要抱太高期望。
检查设备信息可以用这几条命令，通过 adb 执行：
adb shell getprop ro.build.version.release adb shell getprop ro.product.cpu.abi adb shell cat /proc/meminfo | head -5 adb shell df -h /data第一条看系统版本，第二条看 CPU 架构，第三条看内存，第四条看存储剩余空间。这几项确认没问题再往下走，不然装到一半发现不兼容，白折腾。
2.2 模型格式与量化等级怎么选
GGUF 格式的量化等级很多，常见的有 Q4_0、Q4_K_M、Q5_K_M、Q8_0 等。数字代表量化位数，字母代表量化策略。简单理解：位数越低，模型越小、速度越快，但精度损失越大；位数越高，效果越好，但占用资源越多。
对于旧手机，我的建议是优先选 Q4_K_M。这个等级在精度和体积之间平衡得比较好，4 位量化配合 K 系列的分组策略，实际效果比早期的 Q4_0 好不少。如果你设备内存紧张，可以退到 Q4_0；如果内存充裕且追求效果，可以上 Q5_K_M，但速度会慢一些。
模型参数规模的选择，参考这个表：
| 参数规模 | 量化后体积 | 内存占用 | 骁龙 855 生成速度 | 适用场景 |
|---|---|---|---|---|
| 0.5B | 约 400MB | 约 1GB | 15-20 token/s | 分类、提取 |
| 1B | 约 700MB | 约 1.5GB | 5-8 token/s | 问答、摘要 |
| 3B | 约 2GB | 约 3GB | 2-4 token/s | 复杂问答 |
| 7B | 约 4GB | 约 6GB | 1 token/s 以下 | 不推荐 |
这个数据是我实测的，不同设备会有差异，但量级参考价值是有的。7B 模型在旧手机上基本没有实用价值，加载都费劲，别浪费时间。
2.3 模型文件的获取与校验
模型文件从社区平台下载，选 GGUF 格式的对应量化版本。下载完成后一定要校验文件完整性，因为大文件下载中断导致损坏的情况很常见。用 sha256 校验：
sha256sum model-q4_k_m.gguf对比下载页面提供的哈希值，一致才能用。我踩过一次坑，文件下载到 99% 断了，重新下载后没校验，结果加载时报了一堆莫名其妙的错，排查了半天才发现是文件损坏。
文件放置位置也有讲究。建议放在应用私有目录下，避免被其他应用或系统清理误删。路径类似/data/data/你的包名/files/models/。如果模型文件较大，注意安卓对单个应用存储的限制，必要时申请外部存储权限。
3. OlliteRT 的集成与部署实操
3.1 项目依赖配置与权限声明
集成 OlliteRT 的第一步是把依赖加进项目。在build.gradle里添加：
dependencies { implementation 'com.ollitert:runtime:1.0.0' implementation 'com.ollitert:backend-cpu:1.0.0' implementation 'com.ollitert:backend-gpu:1.0.0' }CPU 后端是必选的，GPU 后端根据设备情况选装。如果你的应用要上架应用商店，注意 GPU 后端可能会增加包体积，可以考虑用动态下发的方式。
权限方面，至少需要声明这几项：
<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WAKE_LOCK" />INTERNET 权限用于模型下载（如果做在线下载），READ_EXTERNAL_STORAGE 用于读取模型文件，WAKE_LOCK 用于防止推理过程中设备休眠。注意 Android 13 及以上，存储权限改成了细分的媒体权限，读模型文件建议用应用私有目录，避免权限适配的麻烦。
3.2 模型加载与推理接口调用
OlliteRT 的接口设计比较直观，核心就几个方法。先初始化运行时：
OlliteRuntime runtime = new OlliteRuntime.Builder() .setBackend(OlliteBackend.CPU) .setThreads(4) .setContextSize(2048) .build();setThreads设置推理线程数，一般设成 CPU 大核数量，骁龙 855 是 4 个大核，所以设 4。setContextSize是上下文窗口大小，越大占用内存越多，2048 对大多数场景够用。
加载模型：
Model model = runtime.loadModel("/data/data/包名/files/models/model-q4_k_m.gguf");这一步比较耗时，1B 模型大概需要 3 到 5 秒，建议放在后台线程执行，同时给用户一个加载进度提示。
推理调用：
InferenceRequest request = new InferenceRequest.Builder() .setPrompt("你好，请介绍一下你自己") .setMaxTokens(256) .setTemperature(0.7f) .setTopP(0.9f) .build(); InferenceResult result = model.infer(request); String output = result.getText();maxTokens控制生成的最大长度，别设太大，旧手机上生成越长越容易触发降频。temperature和topP是采样参数，调低会让输出更确定，调高更随机。
3.3 首次运行必做的冒烟测试
部署完别急着做复杂功能，先跑一个最小验证。我一般会做三步冒烟测试：
第一步，加载模型，确认不报错，记录加载耗时。如果加载就失败，多半是模型文件损坏或路径不对。
第二步，跑一个固定输入的推理，比如"1+1 等于几"，确认能正常输出。这一步验证推理链路是通的。
第三步，连续跑 10 次推理，观察内存占用和温度变化。这一步能提前发现内存泄漏和散热问题。
for (int i = 0; i < 10; i++) { long start = System.currentTimeMillis(); InferenceResult r = model.infer(request); long cost = System.currentTimeMillis() - start; Log.d("OlliteRT", "第 " + i + " 次推理耗时: " + cost + "ms"); }把每次耗时打出来，如果耗时逐次递增，说明有内存或散热问题，需要进一步排查。这个测试花不了几分钟，但能帮你避开后面很多坑。
4. 性能调优的实战手段
4.1 线程数与批处理大小的调参逻辑
线程数不是越多越好。安卓的 CPU 调度比较复杂，大核小核混在一起，线程开太多反而会因为调度开销导致性能下降。我的经验是：线程数设成物理大核数量，骁龙 855 是 4 个，骁龙 8 Gen 1 是 4 个（1 个 X2 超大核加 3 个大核），设 4 到 5 比较合适。
批处理大小（batch size）在端侧一般设 1，因为端侧推理通常是交互式的，没有批量请求。但如果你做的是批处理任务，可以适当调大，不过要注意内存占用会成倍增加。实测 1B 模型 batch size 从 1 调到 4，内存占用增加约 800MB，速度提升约 30%，这个取舍要看设备内存情况。
还有一个容易被忽略的参数是 KV Cache 的大小。它和上下文窗口相关，上下文设得越大，KV Cache 占用越多。如果内存紧张，可以适当减小上下文窗口，比如从 2048 降到 1024，内存能省下几百 MB。
4.2 GPU 加速的开启条件与实测效果
GPU 加速不是所有设备都能开。OlliteRT 的 GPU 后端目前主要支持 Adreno 和 Mali 的较新系列，具体支持列表要看官方文档。开启方式：
OlliteRuntime runtime = new OlliteRuntime.Builder() .setBackend(OlliteBackend.GPU) .setGpuLayers(20) .build();setGpuLayers控制有多少层跑在 GPU 上，设得越多 GPU 负载越高。不是所有层都适合放 GPU，因为 CPU 和 GPU 之间的数据传输有开销，层数设太多反而会变慢。我的经验是从 10 层开始试，逐步往上加，找到速度拐点。
实测下来，骁龙 855 的 Adreno 640 开启 GPU 加速后，1B 模型生成速度从每秒 6 token 提升到每秒 9 token 左右，提升约 50%。但功耗和发热也明显增加，持续推理 10 分钟后降频，速度反而掉到每秒 4 token。所以 GPU 加速适合短时突发任务，不适合长时间持续推理。
4.3 内存优化与后台保活策略
内存是旧手机跑大模型最大的瓶颈。几个优化手段：
第一，用largeHeap声明，在 manifest 里加上android:largeHeap="true"，能拿到更大的堆内存上限。但这不是万能药，系统内存紧张时该杀还是杀。
第二，及时释放不用的资源。推理完成后调用model.release()释放模型占用的内存，虽然下次加载又要花时间，但能避免被系统杀掉。
第三，用前台服务保活。把推理任务放在前台服务里，配合常驻通知，能大幅降低被杀的几率。但要注意，前台服务需要用户可见的通知，不能偷偷跑。
// 前台服务示例 startForeground(1, buildNotification("模型推理中"));第四，监控内存压力。用onTrimMemory回调感知系统内存状态，在内存紧张时主动释放缓存。
@Override public void onTrimMemory(int level) { if (level >= TRIM_MEMORY_RUNNING_LOW) { model.clearCache(); } }4.4 散热控制与持续推理的稳定性
散热是旧手机跑大模型绕不开的问题。骁龙 855 持续满载推理，10 分钟左右 SoC 温度就能到 45 度以上，然后开始降频。几个应对办法：
物理散热最直接。加个散热背夹，或者把手机放在金属散热板上，能明显延缓降频。我实测加了散热背夹后，持续推理 30 分钟速度只下降 20%，不加的话 10 分钟就掉一半。
软件层面，控制推理节奏。不要连续不断地推理，中间加个短暂间隔，让 SoC 有时间散热。比如每推理 5 次休息 2 秒，虽然总吞吐下降，但能维持更长时间。
降低推理负载。减小 maxTokens，降低上下文窗口，关闭 GPU 加速，这些都能减少发热。如果任务对速度不敏感，可以把线程数降到 2，牺牲速度换稳定性。
监控温度可以用adb shell cat /sys/class/thermal/thermal_zone*/temp，不同设备路径可能不同，找到 CPU 对应的那个 zone 就行。温度超过 42 度就该考虑降负载了。
5. 踩过的坑与排查实录
5.1 模型加载失败的几种典型原因
模型加载失败是最常见的坑，原因五花八门。我遇到过的有：
文件路径错误。安卓的路径和桌面不一样，/sdcard/和/storage/emulated/0/是同一个位置，但应用私有目录是/data/data/包名/，别搞混。用context.getFilesDir()获取私有目录路径最稳妥。
文件权限不足。放在外部存储的模型文件，需要运行时申请读取权限。Android 11 及以上还要处理分区存储，建议直接放私有目录省事。
模型格式不匹配。GGUF 有多个版本，老版本 OlliteRT 可能不支持新版本 GGUF。确认模型文件的 GGUF 版本和运行时兼容。
内存不足。加载 3B 模型需要约 3GB 可用内存，如果设备后台应用太多，加载会失败。加载前先清理后台，或者用ActivityManager检查可用内存。
排查时先看日志，OlliteRT 的报错信息还算详细，会提示具体是哪个环节出的问题。如果日志看不懂，用最小模型（0.5B）测试，排除是模型本身的问题还是环境问题。
5.2 推理速度突然变慢的排查链路
推理速度突然变慢，排查要按顺序来：
先看温度。温度过高触发降频是最常见原因。查温度，如果超过 42 度，基本就是散热问题。
再看内存。内存不足会触发频繁 GC，拖慢推理。用adb shell dumpsys meminfo 包名看内存占用，如果接近上限，就是内存问题。
然后看线程。线程数设置不合理，或者被系统限制，也会变慢。检查setThreads的值，以及系统是否对后台线程做了限制。
最后看模型。如果换了模型之后变慢，可能是模型量化等级变了，或者模型本身有问题。换回之前的模型对比测试。
这个排查顺序是从最常见到最罕见，能帮你快速定位问题。别一上来就怀疑代码，大部分性能问题都是环境和资源导致的。
5.3 应用被系统杀后台的应对
旧手机内存本来就紧张，跑大模型时应用被系统杀掉是家常便饭。应对手段：
前台服务是标配。把推理任务放前台服务，配合常驻通知，能大幅降低被杀概率。通知内容要如实说明，别搞欺骗性文案。
android:persistent="true"这个属性对普通应用无效，别指望它。它只对系统应用生效。
JobScheduler或WorkManager适合做延迟任务，但不适合实时推理，因为调度时机不可控。
最根本的办法还是降低内存占用。用更小的模型，减小上下文窗口，及时释放资源。内存占用降下来，被杀的概率自然就低了。
如果实在保不住，就做断点续推。把推理状态持久化，被杀后重启能接着跑。这个实现起来麻烦，但对付旧手机这种不稳定环境很有效。
6. 端侧推理的边界与后续玩法
6.1 旧手机跑大模型的能力天花板
得承认，旧手机跑大模型有明确的天花板。参数规模上，3B 基本是上限，7B 以上没有实用价值。速度上，交互式对话体验较差，批处理任务尚可。稳定性上，长时间推理受散热和内存限制，需要精心调优。
但这个天花板不是固定的。随着量化技术改进、推理框架优化、硬件加速适配完善，同样的硬件能跑的模型会越来越大，速度会越来越快。我这次用的 OlliteRT 版本比半年前的老版本，同样模型速度提升了约 40%，这就是软件优化的价值。
所以别因为现在跑不动 7B 就放弃，把环境搭好，等框架更新了直接换模型就行。端侧推理这个方向，软件优化的空间还很大。
6.2 从单机推理到多设备协同
单台旧手机能力有限，但如果你有几台闲置设备，可以考虑协同推理。思路是把模型分层，不同设备跑不同的层，通过网络传递中间结果。这个方案在学术上有研究，工程实现也有开源项目，但复杂度较高，适合折腾型玩家。
更实际的玩法是做任务分发。一台设备做推理，其他设备做数据预处理和后处理，各司其职。比如一台旧手机专门跑模型，另一台做 OCR 和文本清洗，组合起来能完成更复杂的任务。
还有一种玩法是模型蒸馏。用云端大模型生成训练数据，在旧手机上微调小模型，让小模型在特定任务上达到接近大模型的效果。这个路线对数据要求高，但效果上限也高。
6.3 这套方案还能迁移到哪些场景
旧手机跑大模型的这套方法，可以迁移到不少场景。比如电视盒子，很多盒子的硬件配置和旧手机差不多，刷个系统就能跑推理。比如开发板，RK3588 这类板子性能比旧手机还强，部署方式类似。比如车机，如果车机是安卓系统且能装应用，也能跑端侧模型。
核心思路是一样的：GGUF 量化模型加端侧推理框架，根据设备能力调整参数。把这套流程跑通一次，换设备就是改改配置的事。
我在实际使用中最大的体会是，端侧推理的价值不在于性能多强，而在于它把 AI 能力带到了没有网络、不方便上云的环境里。旧手机只是一个载体，真正有意思的是这种"把智能放到边缘"的思路。手里有闲置设备的，不妨试试，折腾的过程本身就挺有收获。
