Golg这个App的全称我平时叫它“安卓本地小助手”，它不是接云端大模型接口的方案，而是把量化后的语言模型直接塞进手机，所有推理都在设备端完成。也就是说，你打开它之后关掉网络，照样能和AI聊天、问问题、让它帮你写一段文案。它解决的核心问题很明确：隐私、离线、不依赖服务器。如果你是安卓开发者，或者对端侧大模型感兴趣，想知道一台普通手机能不能跑起来本地AI聊天应用，这篇内容正好可以当一份实操参考。
这类应用最值得关注的不是“用了多强的模型”，而是“在不够强的手机上怎么把推理跑稳”。我做完第一版之后最大的感受是：挑战不在模型本身，而在模型适配、内存控制、流式输出和交互体验上。下面我把整个项目拆开讲一遍，从选型到落地，哪些能复用，哪些必须踩坑。
1. 先想清楚：本地AI聊天App和云端聊天应用到底差在哪
1.1 离线运行与隐私保护是第一优先级
云端聊天工具需要联网，你的问题会发送到服务器，再由服务端返回结果。虽然部署严格的服务也有加密和隐私约束，但很多场景下用户不放心，或者根本没有网络。本地AI聊天App最大的不一样，就是数据从头到尾不出设备。输入文本、上下文、生成的回复，全部停留在本机内存和存储里。这个特性让它可以用于个人笔记辅助、离线场合的临时问答，或者企业内部不想外发的信息整理。
我最初决定做这个App，起因很实际：在高铁上和地铁里经常没信号，又不想用那种会记录对话的在线聊天工具，于是想着不如把一个小模型装进手机里。做完发现，它不能替代云端大模型，但在轻量问答、头脑风暴、写短文案这类任务上，已经足够用了。
1.2 本地模型的能力边界：适合轻量问答，不适合复杂任务
受手机内存、处理器算力、模型体积限制，本地能跑得流畅的一般是1B到3B参数量的小模型，哪怕量化之后也只有几百MB到2GB左右。这类模型能完成常识问答、语言润色、简单总结、短文本生成、代码片段辅助。它会犯错，也会答非所问，尤其对最新信息不敏感。
实际开发时要清醒一点：不要拿它和云端几十B甚至上百B的模型比综合能力。这个App更适合定位成“随身轻量助理”，不是“万能问答专家”。我一开始想让它写一份完整行业分析报告，质量确实一般；让它总结一段会议纪要、改一段话术、查一个概念，效果就很稳。
所以，在项目规划阶段就要定好边界：哪些任务是它擅长且必须做好的，哪些功能只是实验性质。把不切实际的需求砍掉，后面开发会轻松很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：模型、推理框架与安卓工程怎么组合
2.1 选择哪种本地模型：参数量与量化格式
端侧模型的选型，我总结了一条朴素原则：先定内存预算，再选参数量，最后挑量化格式。手机可用内存如果只有4GB到6GB，就不要去想7B或13B模型，哪怕压缩了也很容易把系统拖垮。主流选择是0.5B到3B之间。
目前比较适合安卓端的中文聊天模型，可以看这些方向：
| 模型系列 | 常见参数量 | 中文表现 | 量化后体积参考 |
|---|---|---|---|
| Qwen2.5系列 | 0.5B / 1.5B / 3B | 较好，指令跟随强 | 0.5B约0.4GB，1.5B约1GB |
| Llama 3.2系列 | 1B / 3B | 英文强，中文一般 | 1B约0.6GB，3B约1.8GB |
| Phi系列 | 1.5B / 2B / 3.8B | 中英混合 | 1.5B约0.9GB左右 |
| MiniCPM系列 | 1.2B / 2.4B | 中文表现不错 | 体积看量化位宽 |
实际体积不只取决于参数量，还取决于量化格式。我之前在Android上用GGUF格式的4bit量化模型，速度和体积都能接受。如果设备内存很小，可以进一步用2bit量化，但输出质量会明显下降，建议还是从4bit起步。
一个常见坑是直接下载完整fp16模型，放到手机上直接爆内存。所以模型文件一定要预先转换或直接下载别人转好的GGUF格式。GGUF是llama.cpp生态通用的模型格式，在安卓端兼容性最好。
2.2 推理框架对比：llama.cpp、MLC-LLM、ONNX Runtime
安卓端跑本地大模型，目前主要有三条路线。我自己没有三条都做成成品，但都跑过Demo，差异比较明显。
llama.cpp
适合深度定制，支持Android编译，生态成熟，GGUF模型直接加载。你可以通过JNI调用C++接口，把模型加载、生成和释放都掌握在自己手里。缺点是集成相对原始，UI层要自己写，内存管理也要自己兜底。
MLC-LLM
更偏向封装包，提供现成Android library，能省掉很多C++层面的工作。它对部分模型做过了优化，流式输出体验好。缺点是自定义模型和自定义采样参数没有llama.cpp那么灵活。
ONNX Runtime
如果你原来就熟悉ONNX生态，也可以用ONNX Runtime Mobile跑量化模型。好处是跨平台相对统一，坏处是转模型格式要比GGUF麻烦一些，部分算子的移动端支持还有坑。
我给第一次做端侧推理的朋友的建议是：先用llama.cpp跑通整个流程，熟悉JNI、模型加载、生成参数、内存释放这些基础概念。等业务逻辑稳定了，再考虑换MLC减少工作量。
2.3 应用侧架构：Kotlin + Jetpack Compose + JNI
重头戏还是安卓App本身。我的工程结构大致分三层：
- UI层：Kotlin + Jetpack Compose，负责聊天界面、输入框、设置页、流式文字展示。
- 业务层：负责会话列表、聊天记录存储、上下文拼接、用户配置管理。
- 推理层：通过JNI调用llama.cpp的C++接口，只暴露加载模型、生成文本、释放模型三个核心方法。
这样分层的好处是：以后想换推理框架，只需要改推理层，不用动UI。我开发过程中经常只改C++侧做性能试验，UI完全不受影响。
第一个版本不用把UI做得多炫，能显示一条条消息、支持流式输出即可。设置页可以放模型路径、线程数、温度、上下文长度，方便调试。整个工程最麻烦的部分是JNI层的数据传递，因为C++生成的是字节数据，要转成Java字符串，还要考虑中文编码。
3. 安卓本地运行环境：硬件门槛与性能判断标准
3.1 你要准备什么设备：内存、CPU、电池、存储
很多人以为本地AI必须旗舰机，其实不是。我的第一台测试机是一台5年前的中端安卓机，8GB内存，处理器是骁龙778G级别，跑Qwen2.5-1.5B的4bit模型可以接受，每秒钟生成十几个token，发热轻微，能正常使用。如果用0.5B模型，甚至会快不少。
给个参考范围：
- 内存：建议至少6GB，8GB更稳。
- 存储：模型文件通常0.5GB到2GB，还要留出系统缓存空间。
- 处理器：中端以上即可，不要用太老的芯片。
- 电池：推理会持续占用CPU，建议开发板上测试，不要太过于纠结发热。
这里要说清楚：能跑不等于适合长期用。如果你只测一下加载速度和几句对话，4GB内存也可能带得动；如果连续多轮会话、又要同时开其他应用，系统后台很容易杀掉你的App。所以“能跑”和“生产可用”是两件事。
3.2 性能怎么看：首次加载、生成速度、内存占用、发热
我做测试时不会只盯着“能不能回答”，而是记录四类指标：
- 首次加载耗时：从选中模型到第一句回复可输入，持续时间。
- 生成速度：每秒生成多少token，这个单位通常叫 t/s。
- 峰值内存：App运行期间，系统的内存占用。
- 稳定程度：连续5轮问答是否崩溃或越答越慢。
终端上可以实时观察输出速度，同时看系统日志。手机厂商一般自带“开发者选项-内存”或者用adb查看，也可以直接用Android Studio的Profiler。我一般会先用小模型、短回复测速度，确认没问题后再切大模型。
普通手机上，1B到1.5B模型跑出6-15 tokens/s是比较正常的范围。再快当然更好，但在中端机上追求“快”没有上限，体验稳定更重要。
3.3 低端机如何降级：量化、短上下文、减小并发
如果你的测试机只有4GB到6GB内存，也不用直接放弃。可以从几个方面降级：选0.5B或1B模型；量化为Q4统一格式；把上下文长度从4096降到2048或1024；对话历史只保留最近几轮；关闭历史记录持久化功能；限制最大生成长度在256或512 token。
这些调整都能显著减少内存压力。尤其上下文长度是最被忽略的参数，它每加长一点，记忆体占用都会增加不少。低端机上不要硬撑长文本，宁可比预期短，也不要频繁被系统杀掉。
4. 核心开发流程：从模型加载到聊天窗口
4.1 模型准备：下载GGUF文件并调整存储位置
我建议不要提前把模型打包进assets目录。为什么？因为assets里的文件会经过压缩，而且安装包体积会变得很大。模型文件本来就几百MB到几个GB，直接放assets会导致APK巨大，安装耗时，读取也慢。
更合理的做法是把模型放在应用外部存储目录，例如Android/data/你的包名/files/models/或者用户可选的目录。首次启动时，可以做一个模型导入页，引导用户从网络下载或从电脑拷贝。这样版本升级时不会重复带模型，模型卸载也不会因为用户清理数据而失效。
下载模型时要注意完整性。GGUF文件如果没下载完，加载时多半直接报错。我在开发时吃过一次亏，文件小了十几个MB，反复排查才发现是下载中断导致，换了下载工具重新下载就好了。
4.2 编译原生库与JNI封装
如果要走llama.cpp路线，安卓端需要用到NDK编译。这个过程不难，但容易卡在NDK版本和构建配置上。我不写太深，只说关键点：
- Android Studio里配置NDK路径。
- 把llama.cpp核心源码作为一个子项目编译成动态库。
- JNI层只暴露几个必要函数：
loadModel(path, options)、generate(input)、stopGenerate()、releaseModel()。
generate不建议一次返回完整结果，因为长回复会让UI卡很久。正确做法是把生成过程放到子线程里面，通过JNI回调逐段返回文本，然后在Kotlin里追加到UI气泡中。
JNI函数签名建议这样设计：
kotlin复制external fun loadModel(modelPath: String, nThreads: Int, ctxLength: Int): Boolean
external fun generateResponse(prompt: String, temperature: Float, topP: Float): String
external fun stopGenerate()
external fun releaseModel()
这里的generateResponse是一次性返回，实际生产中最好写成流式回调。第一次Demo用同步方式可以，但上线再这样会被用户吐槽“字是一下子冒出来的”。
4.3 会话管理：系统提示词、历史上下文、清理策略
聊天App不能每次提问都把用户之前所有内容塞给模型。因为上下文窗口是有限的，塞多了不仅变慢，还可能让模型忘记后面的重点。我的做法是：
- 维护一个历史消息数组，每条记录角色和内容。
- 构造提问时，把系统提示词、最近N轮对话、当前问题拼接成一个prompt。
- N的取值要看模型和上下文长度，默认给4到6轮比较保险。
- 当历史消息超过N时，自动丢弃最早的对话。
这样每次提问的输入长度是可控的，内存也会稳定。
对话模板也要注意。不同模型的默认格式化方式不一样，比如Qwen系列要求模板里区分<|im_start|>这些标记。如果直接拼一段话丢给模型，输出很可能不按聊天格式走。最稳妥的做法是把llama.cpp对应模型的chat template按说明封装好，或者手动匹配模板。
4.4 流式输出与UI交互
流式输出对聊天体验影响很大。用户能看到一个字一个字蹦出来，会产生“正在思考”的感觉，也会觉得响应更快。开发时要用协程或子线程跑推理，不能在主线程上执行。
简单实现路径：
- 用户点发送后，清空输入框，把用户消息加入列表，创建一个空的AI消息对象。
- 启动一个子线程执行生成。
- C++端每生成一小段文本，通过JNI回调Kotlin。
- Kotlin拿到增量文本后，追加到AI消息的末尾，并触发Compose重组。
- 等生成结束，保存这条完整消息。
过程中要处理用户按“停止”按钮，以及模型想提前结束输出（通常它会输出一个结束符号）。不要把这个结束符号也显示给用户，要在封装层过滤掉。
5. 参数调优与稳定性优化
5.1 生成参数：温度、top_p、重复惩罚
模型不是加载完就能直接聊得舒服，采样参数影响非常大。我常用的参数范围如下：
| 参数 | 作用 | 我的经验值 |
|---|---|---|
| temperature | 控制随机性，越高越发散 | 0.7左右，创意任务可到1.0 |
| top_p | 累积概率采样，和温度配合 | 0.8到0.95 |
| repeat_penalty | 抑制重复内容 | 1.1到1.15 |
| max_tokens | 单次最大生成长度 | 256到512 |
如果你发现AI总是翻来覆去说同样的话，先把repeat_penalty调大一点。如果回答非常跳跃，就降低temperature。不要同时把temperature和top_p都调到很大，那样输出会很乱。
5.2 线程数与速度平衡
llama.cpp支持多线程推理，理论上线程越多越快，但手机CPU核心有限，线程太多反而会因为调度和过热降频而变慢。我测试时发现，8核手机上开到4到6个线程往往是最稳的点，再往上速度提升不明显。
可以在设置页暴露一个“线程数”选项，默认4，让用户根据机型手动调整。这个方法很土，但真的能解决一部分不兼容问题。
5.3 内存不足、崩溃、乱码问题的排查链路
我开发时遇到最多的问题不是模型输出差，而是App运行不稳定。如果你也遇到类似情况，建议按这个顺序查：
- 先看日志类型。崩溃日志、内存日志、加载日志各不相同。
- 再查模型文件完整性。核对文件大小和MD5。
- 然后确认上下文长度。输入内容是不是已经超过模型限制。
- 接着检查线程数和生成参数，参数异常有时会直接让模型输出停顿。
- 最后看存储空间和操作系统权限，路径不可写、权限拒绝也会默默失败。
如果是中文乱码，多半是JNI层的字符串编码没有转换好。C++读入的UTF-8和Java的字符串要统一编码，不能默认用本地区编码。我在早期版本里就犯过这个错，换了编码之后问题才消失。
还有一个容易忽略的点：生成过程中用户退出页面。如果页面销毁时还在用JNI生成，很容易导致崩溃。我后来在ViewModel里统一处理停止请求，界面销毁时主动调用stopGenerate()，等子线程真正结束再释放资源。
6. 实测经验与建议
6.1 我踩过的几个典型坑
这个项目从零到能聊天，我最想分享的不是炫技，而是几个花了很长时间才搞清楚的坑。
第一个坑是模型文件路径。我开始把模型放到assets里，结果一直加载失败，后来发现assets对大型二进制文件支持不友好，读取耗时高，部分机型还会OOM。改成了外部存储目录后，加载成功率和速度都好了很多。
第二个坑是上下文越长越容易胡言乱语。小模型本身能力有限，把几千字的历史都塞进去，它会抓到一堆无关信息，反而答非所问。现在我会主动截断历史会话，只保留最近几条有意义的对话。
第三个坑是系统后台回收。写聊天记录保存时，如果不用Room或者SQLite，只是存在内存里，一切换到后台再回来全没了。我加了SQLite存储之后，虽然实现繁琐一点，但不会被系统杀得前功尽弃。
6.2 单条对话和多轮对话的验证方式
发布前测试不能只聊一句“你好”。我一般按三步验证：
第一步，清空所有历史记录，问一个短问题，看首次加载时间和生成速度。
第二步，连续问5个不同类型的问题，比如解释概念、写文案、翻译、简答，观察答案是否正常切换。
第三步，连续对话20轮左右，不断打断、快速发送，看是否有卡死、无输出、内存暴涨。
如果这三大类都稳定，基本可以说明App在低负载场景是可用的。批量验证时我会写一个简单的脚本，把问题列表输入进去，记录每条耗时和返回长度，用来对比不同参数的效果。
6.3 后续可扩展的方向：语音输入、RAG、多模态
这个App做稳定之后，扩展空间其实很大。比如加入语音输入，通过Android的SpeechRecognizer识别用户语音，然后转成文本送入本地模型，回答后再用TTS播报，就能变成一个完全本地化的语音助手。也可以加入RAG流程，把本地文档切成片段，到了需要的时候检索相关片段再拼接给模型，让AI回答自己文件里的内容。再往后可以探索端侧多模态，比如让模型读取本地方案图和截图，但这一步对硬件要求会高很多。
给想动手的同学一个建议：第一版不要贪多。先把文本聊天的链路做深做稳，尤其是模型加载、流式输出、内存释放这三件事。它们才是安卓本地AI应用的地基，地基稳了，后面加什么功能都顺。
我个人更建议先从0.5B或1B模型开始，哪怕你觉得小模型不够聪明，也不要急着上大模型。先让App在各种机型上不崩溃，再逐步提升模型规模和上下文长度。端侧AI这条路，稳定性永远排在智能前面。