1. 为什么我盯上了抽屉里那台吃灰的旧手机先说结论一台三年前的中端安卓机6GB 内存、骁龙 7 系芯片跑一个 1.5B 到 3B 参数量的小模型做本地推理日常问答、文本润色、简单代码补全完全够用。这不是理论推演是我自己折腾了大半个月之后的真实体感。事情的起因很朴素。我手头有一台换下来闲置的旧手机卖二手不值几个钱扔了又觉得可惜。与此同时我在主力电脑上一直用 Ollama 做本地大模型的日常调用写脚本、做批处理、给一些小工具接个本地推理后端用得很顺手。但电脑不可能一直开着有时候我只是想随手问个问题、跑个简单的文本处理专门开电脑就显得很重。于是就有了这个想法能不能把旧手机变成一台常驻的本地大模型服务器对外暴露一套和 Ollama 兼容的 API这样我在局域网里任何设备都能直接调它这个方向的核心工具就是OlliteRT。简单说它是一个能在安卓设备上跑大模型的运行时框架并且对外提供Ollama 兼容的 API 接口。这意味着你原来写给 Ollama 的调用代码改一下 base_url 就能直接打到手机上几乎零迁移成本。关键词里的Ollama、API、Android、本地大模型基本就是这条链路的四个支柱。这篇文章适合谁看三类人。第一类手里有闲置安卓设备、想物尽其用的折腾党第二类想入门本地大模型部署、但不想一上来就搞服务器和显卡的初学者第三类已经在用 Ollama、想扩展一个低功耗常驻节点的开发者。我会把整个部署链路、踩过的坑、参数怎么调、API 怎么对接全部摊开讲清楚。需要提前说明的是本文涉及的模型文件、工具链请务必通过正规渠道获取遵守相关软件许可和平台规则。下面进入正题。2. OlliteRT 到底解决了什么问题和直接装 Ollama 有什么区别2.1 安卓上跑大模型的三条路为什么我选了 OlliteRT在安卓设备上跑大模型市面上大致有三条技术路线我逐一试过或者调研过这里做个横向对比方便你判断自己该走哪条。路线代表方案优点痛点纯端侧推理库各类移动端推理框架轻量、启动快需要自己写调用层没有现成 API通用大模型运行时Ollama 桌面版思路生态成熟、模型多官方并不面向安卓移植成本高兼容 API 的移动运行时OlliteRT直接给 Ollama 兼容 API迁移成本低生态相对新文档需要自己摸索我最终选 OlliteRT核心理由就一个它把模型推理和API 服务这两件事打包好了。如果走纯推理库路线我还得自己写一个 HTTP 服务层把推理结果包装成 OpenAI 或 Ollama 的接口格式工作量不小而且容易在并发、流式输出这些细节上翻车。OlliteRT 直接省掉了这一层。这里要澄清一个常见误解很多人以为Ollama 兼容 API就是 Ollama 本身。不是的。Ollama 兼容指的是接口协议兼容——请求路径、请求体结构、返回格式对齐 Ollama 的习惯比如/api/generate、/api/chat这类端点。你的客户端代码不用改但底层跑的是 OlliteRT 自己的推理引擎。理解这一点很关键后面排查问题时才不会找错方向。2.2 旧手机的硬件底线内存比 CPU 更致命很多人一上来就问什么处理器能跑其实这是个伪命题。跑大模型内存RAM才是第一约束CPU 算力决定的是速度内存决定的是能不能跑起来。我整理了一份基于实测的经验对照注意这是经验值不同模型量化方式会有出入手机内存可跑模型规模量化后实际体验4GB0.5B 以下勉强容易 OOM6GB1.5B 左右可用速度一般8GB3B 左右比较舒服12GB 及以上7B 量化版可尝试发热明显为什么内存这么关键因为模型加载时权重需要常驻内存。一个 3B 参数的模型如果用 4-bit 量化权重大概占用 1.5GB 到 2GB 左右再加上推理过程中的 KV Cache、运行时开销实际峰值内存可能是权重的 1.5 到 2 倍。所以 6GB 内存的机器跑 3B 模型很容易在长上下文时被系统杀掉进程。提示安卓系统的内存管理比较激进后台应用容易被回收。部署时建议把 OlliteRT 相关的进程加入电池优化白名单并尽量保持前台或常驻通知降低被系统清理的概率。2.3 量化格式的选择别一上来就追求高精度模型量化是绕不开的话题。简单类比原始模型像一张无损大图量化就是把它压缩成体积更小、但肉眼几乎看不出差别的格式。常见的 4-bit 量化如 Q4 系列在体积和效果之间平衡得比较好是我在旧手机上的首选。为什么不选更高精度因为旧手机的内存和存储都紧张高精度模型体积翻倍加载慢、占用高收益却很小。也不建议选过于激进的低比特量化效果下降会很明显尤其是逻辑推理类任务。我的经验是在旧手机上Q4 系列是甜点区具体选哪个变体可以多试几个对比。3. 从零把 OlliteRT 跑起来环境准备与部署链路3.1 部署前的准备工作清单动手之前先把这些东西备齐能省掉大量来回折腾的时间。一台安卓设备建议安卓 10 及以上内存 6GB 起步充足的存储空间至少预留 5GB 到 10GB 给模型文件稳定的局域网环境手机和调用端要在同一网段模型文件通过正规渠道获取注意许可协议一个能查看日志的工具排查问题时非常关键这里重点说存储。模型文件动辄几个 GB如果手机存储本来就紧张建议先清理或者用支持扩展存储的设备。我一开始没注意模型下到一半空间不足白等了一场。3.2 安装与首次启动几个容易卡住的点安装本身不复杂但首次启动有几个坑我踩过提前说清楚。第一个坑是权限。OlliteRT 需要读取模型文件、监听网络端口涉及存储权限和网络权限。如果启动后 API 调不通先检查权限是不是没给全。第二个坑是端口占用。默认的 API 端口如果被其他应用占了服务起不来。可以在配置里换一个不常用的端口比如 11434 之外的端口避免和别的服务冲突。第三个坑是首次加载慢。第一次加载模型时系统要做一些初始化可能等几十秒甚至更久别以为卡死了就强退。耐心等看日志确认进度。启动成功后你会看到服务在监听某个端口。这时候在手机浏览器里访问一下本机的 API 地址能看到响应就说明服务活了。3.3 验证 API 是否真的兼容 Ollama这一步很关键别跳过。服务起来了不代表 API 就兼容得实际打一发请求验证。用 curl 在局域网另一台设备上测试假设手机 IP 是 192.168.1.100端口是 11434curl http://192.168.1.100:11434/api/generate -d { model: your-model-name, prompt: 你好简单介绍一下你自己, stream: false }如果返回结构里有response字段内容是一段正常的文本那基本就通了。如果报错重点看两个方向一是模型名对不对二是请求体格式是否符合 Ollama 的约定。注意不同版本的接口细节可能有差异遇到字段不匹配时优先对照你所用版本的接口说明而不是照搬网上的旧例子。4. 让 API 真正好用参数调优与客户端对接4.1 推理参数怎么调旧手机才能跑得稳API 通了只是第一步跑得稳不稳、快不快全看参数。下面这几个参数是我反复调过的重点。上下文长度context length。这是旧手机上最需要克制的参数。上下文越长KV Cache 占用越大内存压力越大。我一般从 2048 起步稳定后再往上加加到出现卡顿或崩溃就退回来。别一上来就设很大很容易直接把进程撑爆。温度temperature。控制输出的随机性。做事实性问答时调低比如 0.2 到 0.5做创意类文本时调高0.7 到 1.0。旧手机算力有限温度太高容易生成又长又飘的内容反而拖慢速度。最大生成 token 数。一定要设上限。不设上限的话模型可能一直生成下去旧手机扛不住。我一般设 512 到 1024够日常用了。流式输出stream。开启流式能让首字响应更快体验更好但对网络稳定性有要求。局域网内建议开启。我把常用配置整理成一张表方便你直接抄参数推荐值说明context length2048 起稳定后再加temperature0.2~0.7按任务类型调max tokens512~1024必须设上限streamtrue局域网建议开4.2 客户端代码迁移改一行 base_url 的事这是 Ollama 兼容 API 最大的价值所在。你原来调用 Ollama 的代码基本只需要改 base_url。以 Python 为例原来可能是这样import requests response requests.post( http://localhost:11434/api/generate, json{ model: your-model, prompt: 帮我写一段产品介绍, stream: False } ) print(response.json()[response])迁移到旧手机只改地址import requests response requests.post( http://192.168.1.100:11434/api/generate, json{ model: your-model, prompt: 帮我写一段产品介绍, stream: False } ) print(response.json()[response])就这么简单。如果你用的是封装好的客户端库通常也支持自定义 base_url改配置即可。4.3 局域网多设备调用的注意事项手机作为服务器和传统服务器有个本质区别它的网络行为更移动。几个实际会遇到的问题IP 会变。手机连的 WiFi 换了或者路由器重新分配IP 可能就变了。解决办法是在路由器里给手机绑定静态 IP或者用主机名访问。休眠会断。手机息屏后系统可能限制网络活动。要保证常驻可用得把应用加入白名单必要时保持充电和常亮。并发能力弱。旧手机不是服务器同时来几个请求就可能卡。建议在调用端做简单的串行化或限流别把它当高并发后端用。5. 实测中踩过的坑与排查链路5.1 服务起来了但请求超时一次完整的排查过程这是我印象最深的一次。服务明明显示在运行但局域网里请求一直超时。我没有直接瞎改配置而是按链路一步步排查。第一步确认服务本身活着。在手机本机浏览器访问 API 地址能通。说明服务没问题。第二步确认网络可达。从调用端 ping 手机 IP通。说明网络层没问题。第三步确认端口。用端口探测工具看那个端口是否真的在监听。发现监听是有的但只绑定了本地回环地址没有绑定到局域网网卡。这就是根因——服务默认只监听 127.0.0.1外部访问不到。第四步改配置让它监听 0.0.0.0重启服务问题解决。这个排查链路的价值在于从内到外逐层验证。先确认服务本身再确认网络再确认端口绑定最后才动配置。很多人一上来就乱改反而把问题搞复杂。5.2 模型加载失败内存不足的典型表现另一个高频坑是模型加载到一半失败。日志里通常能看到内存相关的报错。原因很直接模型太大或者上下文设太长内存不够。解决办法有几个方向换更小的模型、换更激进的量化、降低上下文长度、关掉其他占内存的应用。我的经验是先用小模型跑通全链路再逐步换大。一上来就上大模型很容易卡在加载阶段连 API 都验证不了挫败感很强。5.3 输出乱码或截断编码与 token 上限问题有时候返回的内容是乱码或者说到一半就断了。乱码多半是编码问题检查请求和响应的字符集设置。截断则通常是 max tokens 设太小或者上下文被截断。排查顺序先看是不是 max tokens 限制再看上下文长度最后看编码。这三个是最常见的原因。6. 旧手机做大模型服务器的边界与延展玩法6.1 它能做什么不能做什么把边界说清楚比一味吹嘘更有价值。它能做的局域网内的个人助手、文本处理、简单问答、给本地小工具提供推理后端、离线环境下的基础 AI 能力。它不适合做的高并发服务、复杂推理任务、长上下文文档分析、对延迟敏感的生产场景。认清这个边界你就不会对它有不切实际的期待用起来反而更顺。6.2 几个我实际在用的延展玩法第一个本地知识库问答。把常用文档切块配合检索让旧手机上的模型基于你的资料回答。因为数据不出局域网隐私性很好。第二个自动化脚本的推理节点。我有些定时脚本需要做文本分类、摘要直接调这台手机的 API省得开电脑。第三个多设备共享。家里几台设备都能连它相当于一个低功耗的私有 AI 节点。6.3 长期运行的稳定性维护最后说几个长期运行的经验。定期重启服务释放可能的内存碎片。监控手机温度过热会降频甚至关机。保持充电状态但注意电池健康。定期检查日志早发现早处理。我在实际使用中最大的体会是旧手机做大模型服务器核心不是性能而是够用且常驻。它不追求跑分追求的是随时可用、低功耗、数据可控。把预期放对位置这套方案的价值就出来了。如果你手里正好有闲置设备不妨按上面的链路试一遍从最小的模型开始跑通了再逐步加码。