安卓手机跑大模型：MLC LLM与llama.cpp实测对比及部署指南

写在前面：这阵子一直在折腾“手机本地跑大模型”这件事，网上提到最多的工具就是 Ollama。可真正把 Ollama 装进安卓设备之后，我遇到了模型下载慢、启动卡顿、CPU 推理速度拉胯、手机发热明显等一连串问题。后来换到 MLC LLM 和 llama.cpp 这两条路线，体验才算真正打开。

这篇文章会把这次完整的实测过程记录下来，对比安卓端几种主流 LLM 框架的优缺点，并给出可以直接操作的部署步骤、运行命令和排错思路。无论你是想在手机上跑一个私有聊天助手，还是想把大模型集成到自己的 Android App 里，都可以参考本文的方案。

1. 背景与核心概念

1.1 什么是安卓端 LLM 框架

大语言模型（LLM，Large Language Model）指的是 Qwen、Llama、Phi 这类经过大规模语料训练的模型。日常使用中，我们通常通过云端 API 调用它们，但很多场景下数据不方便出设备，或者希望完全离线使用，于是“本地部署”就成了一个刚需。

所谓安卓端 LLM 框架，就是一套能在手机上加载模型、执行推理、管理输入输出上下文、提供性能优化能力的软件方案。它通常包含几个部分：

• 模型文件：经过量化压缩后的模型权重，比如 GGUF、MLC 格式。
• 推理引擎：负责把用户输入变成 Token，再通过模型计算生成回复。
• 硬件加速层：利用手机的 CPU、GPU、NPU 来加速矩阵计算。
• 前后端接口：命令行工具、Android SDK 或 API 封装，方便上层调用。

1.2 安卓跑大模型的三个难点

在手机上跑大模型，光有框架还不够，硬件限制是绕不开的。

第一是内存。一个 7B 参数的模型，用 FP16 精度存储大约是 14GB，手机内存完全扛不住。所以必须使用 INT4、INT8 这类量化格式，把模型压到 3GB 到 5GB 左右，才能在手机上运行。

第二是算力。模型推理本质上是大量矩阵运算，手机 CPU 虽然也能算，但速度通常只有每秒几个 Token，体验很差。想要流畅，必须调用 GPU 或 NPU。

第三是功耗和散热。推理时芯片满载，手机会发热降频，导致推理速度进一步变慢。这也是端侧 LLM 框架需要在性能和功耗之间做权衡的原因。

所以，一个真正适合安卓的 LLM 框架，不仅要能加载模型，还要在架构上为移动端做了充足的优化。

1.3 Ollama 到底是什么，为什么在安卓上不合适

Ollama 是目前最流行的本地 LLM 运行工具，一条命令就能拉起 Llama、Qwen、DeepSeek 等模型，非常方便。它本质上是把模型下载、推理引擎、API 服务整合成了一个跨平台命令行工具。

但要注意，Ollama 官方支持的是 macOS、Linux、Windows，并不包含 Android。安卓端想跑 Ollama，通常需要先安装 Termux，再在 Termux 里通过 Linux 环境去安装 Ollama。这个方案存在几个明显问题：

• 安装复杂，而且官方安装脚本在 Termux 里经常遇到兼容性问题。
• Ollama 的推理后端没有针对移动端做专门的 Vulkan 优化，基本是 CPU 硬算。
• Ollama 的模型仓库和下载机制在手机上体验较差，经常卡在下载环节。
• 进程常驻、缓存策略偏向桌面场景，在手机上容易导致内存不足和发热。

所以“吊打 Ollama”这个说法，并不是否定 Ollama 本身，而是针对安卓这个特殊场景：有更适合的工具，实测体验差距确实很大。

2. 环境准备与版本说明

2.1 测试环境

本文涉及的实测流程，基于以下测试环境。AI 工具链更新很快，版本只代表写作时的状态，实际操作时请以你自己的环境为准。

如果你手头的手机内存只有 6GB，建议优先选择 1.5B 或 3B 级别的量化模型；如果是 12GB 以上内存的旗舰机，可以尝试 7B 模型的 INT4 量化版本。

2.2 需要掌握的基础知识

在开始之前，建议先了解几个基础概念，这样后面操作的时候不容易犯迷糊：

• Token：大模型处理文本的最小单位，一个 Token 可能是一个字、一个词或一个子词。
• 上下文窗口：模型一次能够看到的 Token 数量，比如 2048、4096。
• 量化：把 FP16 的权重压缩成 INT8、INT4 等低精度格式，减少内存占用和计算量。
• GGUF：llama.cpp 社区主推的模型格式，类似一个容器，把权重、分词器、超参数打包在一起。
• Vulkan：跨平台的 GPU 渲染和计算 API，在安卓上可以用于调用 GPU 加速推理。

如果你对 Linux 命令行比较熟悉，整个过程会顺畅很多；如果不太熟悉，也建议先跟着命令走一遍，再慢慢理解每个步骤。

3. 安卓端主流 LLM 框架横向对比

安卓端可用的 LLM 方案其实不少，下面从原理、安装方式、GPU 加速能力、上手门槛和适用人群几个维度，逐一分析各方案。

3.1 Ollama + Termux 方案

Ollama 本身是一款优秀的桌面端工具，但到了安卓上，通常只能通过 Termux 运行。

在 Termux 中安装 Ollama 的常见做法如下，不过不同设备上可能会有兼容性问题：

pkg update && pkg upgrade -y pkg install curl -y curl -fsSL https://ollama.com/install.sh | sh

这个安装脚本主要面向 Linux 桌面环境，在 Termux 的 Android 环境下经常出现 systemd 依赖、权限、文件路径等问题。即便强制安装成功，运行ollama serve也会占用较多内存。

实测体验中，Ollama 在安卓上更像是“能跑，但不适合跑”，主要问题包括模型下载仓库访问不稳定、CPU 推理速度慢、缓存策略导致内存压力大。

3.2 MLC LLM

MLC LLM 是由 Apache TVM 社区孵化的大模型推理方案，核心思想是“一次编译，到处运行”。它可以把模型编译成针对不同硬件后端（Vulkan、Metal、CUDA、WebGPU 等）优化的算子库，因此在安卓手机上能借助 Vulkan 调用 GPU。

MLC LLM 的优势非常明显：

• 提供可直接安装的 MLC Chat App，开箱即用。
• 对 Vulkan 后端做了深度优化，GPU 推理效率在安卓端处于第一梯队。
• 支持 Android、iOS、Web 等多端，适合做跨平台端侧 AI 应用。
• 支持 WebLLM，浏览器里也能跑模型。

缺点是模型格式和转换流程有一定门槛，如果要自己转换模型，需要理解 MLC 的编译和量化体系。对大多数用户来说，直接用官方 App 下载预编译模型是最省心的方式。

3.3 llama.cpp + Termux / NDK

llama.cpp 是开源社区最活跃的本地 LLM 推理引擎之一，纯 C/C++ 实现，依赖极轻，尤其适合嵌入式、桌面和移动端。它的 GGUF 模型格式生态非常丰富，大量模型作者都会直接提供 GGUF 版本。

在安卓端，llama.cpp 有两条路线：

• 在 Termux 里源码编译，通过命令行交互。
• 通过 NDK 编译成动态库，集成进 Android App。

这条路线的好处是自由度极高，模型格式统一、社区资源多、量化方案成熟、可定制程度高。缺点是所有细节都需要自己动手，编译、模型管理、输入输出都要处理。

3.4 MediaPipe LLM Inference

MediaPipe 是 Google 的跨平台机器学习框架，iOS、Android 都支持，它提供了一个 LLM Inference API，可以直接在安卓上加载 Gemma、Phi 等模型进行推理。对 Android 开发者来说，这套 API 的接入方式比较友好，有 Java/Kotlin 接口，能比较快地集成到现有工程。

但相比 MLC LLM 和 llama.cpp，MediaPipe 的 LLM API 对模型格式和模型来源有较多限制，也偏向“工程 SDK”而非“研究实验平台”，适合做产品化落地，不适合深度折腾和性能调优。

3.5 横向对比表格

从实测角度看，普通用户最推荐 MLC Chat，开发者做 App 集成时则可以在 llama.cpp 和 MLC LLM 之间选择。

4. 完整实测：把 LLM 跑在安卓手机上

这一章会给出三套完整的实测流程，分别对应“直接安装 App”“Termux 命令行玩模型”“集成到 Android 工程”三种需求。

4.1 方案一：安装 MLC Chat APK（推荐新手）

MLC LLM 官方提供了一个 MLC Chat App，安装流程非常简单。

先在 MLC LLM 的 GitHub Releases 页面找到 Android APK 文件，下载到手机后直接安装即可。注意一下，APK 版本更新比较频繁，不同版本的 UI 和模型下载方式可能有细微差别。

安装完成后打开 App，在模型列表中选择一个适合你设备的模型。这里建议从 2B、3B 级别的量化模型开始，比如 Qwen2.5-1.5B-Instruct q4f16 或 Phi-3-mini 的 INT4 版本。如果你用的是 12GB 内存旗舰机，也可以尝试 7B 模型的 q4f16 量化版本。

选择模型后，App 会自动下载模型文件，下载完成后会进入聊天界面。实测体验中，MLC Chat 的加载速度、首 Token 响应时间和生成速度，都比 Ollama + Termux 方案好很多。由于它通过 Vulkan 调用 GPU，手机不会长时间处于 CPU 满载状态，发热控制也更理想。

如果你希望对自己电脑上的模型做转换，MLC LLM 也提供了 Python 工具链。不过命令行在不同版本间变化较大，建议先使用mlc_llm --help查看当前版本的用法，再结合官方文档操作。只要理解了“模型权重 → 量化 → 编译到目标后端”这条链路，自定义模型并不困难。

4.2 方案二：在 Termux 中编译运行 llama.cpp

如果你喜欢折腾，想更深入地理解端侧推理，那么在 Termux 里自己编译 llama.cpp 是最好的方式。

4.2.1 安装 Termux 基础环境

Termux 是一个安卓终端模拟器，可以在手机上提供 Linux 环境。注意，Google Play 上的 Termux 已经停止维护，建议到 F-Droid 官网下载最新版本。

安装后打开 Termux，先执行系统更新：

pkg update && pkg upgrade -y

然后安装编译所需的基础包：

pkg install git cmake clang -y

这里解释一下：

• git用来拉取 llama.cpp 源码。
• cmake是项目构建工具，用于生成编译配置。
• clang是 C/C++ 编译器，llama.cpp 是纯 C++ 项目，必须依赖它。

如果你的设备存储空间比较紧张，可以只装这三个核心工具，不需要额外安装 NDK。

4.2.2 克隆并编译 llama.cpp

接下来拉取 llama.cpp 源码，并执行编译：

cd ~ git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j $(nproc)

参数解释：

• -B build表示在主目录下创建build目录存放编译产物。
• -DCMAKE_BUILD_TYPE=Release表示使用 Release 优化模式，保证推理性能。
• -j $(nproc)表示使用手机所有 CPU 核心并行编译，能明显缩短编译时间。

编译过程可能需要 10 到 30 分钟，具体时间取决于手机 SoC 的性能。编译完成后，build/bin目录下会出现llama-cli、llama-bench等可执行文件。

4.2.3 下载 GGUF 模型

llama.cpp 使用 GGUF 格式模型。国内用户可以从 ModelScope（魔搭社区）等平台搜索 GGUF 模型，下载后传到手机中，再放到 llama.cpp 目录下的models文件夹。

例如，下载一个 1.5B 级别的中文模型后，可以这样进入模型目录：

cd ~/llama.cpp mkdir -p models # 将模型文件放到 models 目录中 ls -lh models/

这里建议优先选择Q4_K_M这类 INT4 量化格式，它在体积和效果之间比较均衡。一个 1.5B 的 Q4_K_M 模型通常只有 1GB 左右，适合 8GB 内存设备运行。

4.2.4 运行模型推理

模型放好后，用llama-cli加载模型开始对话：

cd ~/llama.cpp/build/bin ./llama-cli -m ../../models/qwen2.5-1.5b-instruct-q4_k_m.gguf \ -p "用一句话介绍你自己" \ -n 128 \ -t 8

参数说明：

• -m指定模型路径。
• -p指定输入提示词。
• -n指定最大生成 Token 数，这里设为 128。
• -t指定线程数，8 线程是常见手机的合理配置，你可以根据手机核心数调整。

如果一切正常，模型会输出一段回答，并显示生成速度。实测中，1.5B 模型在 CPU 模式下也能达到可用的速度，但流畅度与 MLC LLM 的 GPU 方案仍有差距。

4.2.5 使用性能测试工具

llama.cpp 还提供了一个llama-bench工具，可以在同一条命令里测试不同配置下的性能：

cd ~/llama.cpp/build/bin ./llama-bench -m ../../models/qwen2.5-1.5b-instruct-q4_k_m.gguf -t 8

输出会包含模型的加载耗时、Prompt 处理速度（tokens/s）、生成速度（tokens/s）等指标。这些数据在比较不同量化级别和不同线程数时很有参考价值。

4.3 方案三：把 llama.cpp 集成到 Android App

如果你不想只在终端里玩，而是想把大模型能力集成到自己的安卓应用里，就需要通过 JNI 调用 llama.cpp 的 C++ API。

这里给出核心思路，完整工程需要结合你的项目实际来改造。

首先，在项目的CMakeLists.txt中把 llama.cpp 作为子模块引入：

cmake_minimum_required(VERSION 3.22.1) project(llm_demo) add_subdirectory(src/main/cpp/llama.cpp llama.cpp) add_library(native_llm SHARED src/main/cpp/native-lib.cpp) find_library(log-lib log) target_link_libraries(native_llm llama ${log-lib})

然后在native-lib.cpp中通过 JNI 暴露给 Kotlin/Java 层调用。核心调用逻辑大致是：

#include <jni.h> #include <string> #include "llama.h" extern "C" JNIEXPORT jstring JNICALL Java_com_example_llm_MainActivity_generate( JNIEnv *env, jobject, jstring modelPath, jstring prompt) { const char *model_path = env->GetStringUTFChars(modelPath, nullptr); const char *prompt_text = env->GetStringUTFChars(prompt, nullptr); llama_model_params model_params = llama_model_default_params(); llama_model *model = llama_load_model_from_file(model_path, model_params); // 初始化上下文、处理 Token、执行生成，得到输出结果 std::string result = "generated text"; env->ReleaseStringUTFChars(modelPath, model_path); env->ReleaseStringUTFChars(prompt, prompt_text); return env->NewStringUTF(result.c_str()); }

把模型放到 App 的assets目录或下载到应用私有目录后，即可在 Kotlin 中调用生成逻辑。集成时要注意几个问题：

• 模型加载和推理需要在子线程执行，不能在主线程跑。
• 建议使用流式输出方案，把已生成的 Token 逐个回调到 UI 层，避免界面等待。
• 每个新对话需要重新管理上下文，避免上下文窗口被旧内容占满。

这种方案的优点是完全可控，可以按自己的业务逻辑定制对话流程、流式输出和 UI 交互；缺点是开发成本较高，需要一定的 C++ 和 JNI 基础。

4.4 三套方案实测对比

从实测感受来说，MLC Chat 是最适合普通用户“拿来就跑”的方案；如果你需要更高的自由度，Termux 编译路线值得一试；如果你是移动端 AI 应用开发者，最终肯定要走到 Android 集成这一步。

5. 常见问题与排查思路

在实际部署过程中，有几个问题出现频率非常高，这里整理成表格并补充详细说明。

5.1 模型下载慢

无论 Ollama 还是 MLC Chat，模型下载都依赖网络环境。国内用户经常遇到下载慢或者中途失败的问题。

处理思路是：用电脑浏览器或下载工具从 ModelScope 等国内平台下载 GGUF 模型文件，然后通过文件管理器或 ADB 把模型拷贝到手机。具体路径因方案而异，只要最终让推理框架能加载到本地模型即可。

不建议等待一个迟迟无法完成的下载任务，本地导入更可控。

5.2 应用闪退或内存不足

端侧大模型对内存的需求比较苛刻。8GB 内存设备如果同时运行 App 和系统后台任务，很容易出现内存波动。

解决方法是换更小参数的模型，比如从 7B 降到 3B 再到 1.5B。也可以尝试不同的量化级别，比如Q4_K_S相比Q4_K_M模型体积更小，但效果略有损失。

5.3 推理速度慢

CPU 推理在 1.5B 模型上还可以接受，但在 7B 模型上体验就比较差了。想要提升速度，最直接的办法是利用 GPU。

MLC LLM 在安卓上默认使用 Vulkan 后端，效果明显。llama.cpp 如果需要 GPU 加速，需要根据编译选项和手机支持情况自行配置，要求更高一些。或者干脆选择量化程度更高的模型，也能在 CPU 上获得一定速度提升。

5.4 模型格式不兼容

不同框架使用的模型格式并不一样，Ollama 以自己的仓库存储模型，MLC 使用 MLC 格式，llama.cpp 使用 GGUF。如果换框架，需要先确认模型格式是否匹配。

最省心的办法是优先使用框架社区预编译好的模型文件，不要自己辗转转换，避免踩格式坑。

5.5 发热与降频

手机散热能力有限，长时间推理会导致 SoC 降频，推理速度断崖式下降。实测中，如果使用 MLC LLM 的 GPU 方案，发热会相对分散；如果 CPU 满载跑 7B 模型，手机很快就烫手。

建议把单次生成 Token 数限制在 256 或 512 以内，不要在手机上做长文本生成任务。测试过程中也可以让手机处于充电 + 散热背夹的状态，保证稳定输出。

6. 最佳实践与工程建议

6.1 根据内存选择模型

模型参数量只是参考，真正影响内存的是量化后的模型文件大小。一个经验判断是：模型文件大小尽量不要超过设备可用内存的一半，这样推理过程才不会因为内存不足而卡顿。

如果你主要做中文问答，优先选择中文语料微调过的模型，比如 Qwen 系列、Yi 系列，效果比直接使用通用英文模型好不少。

6.2 理解量化精度对性能的影响

模型精度是一个值得深入了解的话题。常见格式有 FP32、FP16、BF16、INT8、INT4 等。

• FP32：精度最高，但体积和内存占用最大，不适合端侧部署。
• FP16 / BF16：半精度，体积是 FP32 的一半，仍然是端侧很难承担的重量。
• INT8：体积是 FP32 的四分之一，精度损失较小。
• INT4：体积是 FP32 的八分之一，是端侧部署的主流选择。

量化带来的不仅是模型体积变小，推理速度也会提升，但同时会带来精度损失。比如算术题、逻辑推理类任务，INT4 的效果可能比 FP16 差一些。所以在端侧部署时，“用较小的量化模型保证流畅”和“用较大的高精度模型保证效果”之间需要做取舍。

6.3 端侧 AI App 的架构建议

如果你准备把 LLM 集成到自己的 Android 项目，建议从一开始就考虑好架构，避免后面反复重构。

建议把模型管理、推理引擎、UI 层解耦。模型文件不要放在assets里，除非模型只有几百 MB；更好的方式是在 App 首次启动后从应用私有目录加载，或者由用户从文件管理器手动选择。推理逻辑必须放在子线程，部分框架还支持流式输出回调，可以边生成边刷新 UI。同时要注意处理上下文窗口，对话超过窗口长度后，要么截断早期内容，要么做摘要压缩，否则模型会“忘记”前面的内容。

内存和电源管理也要留意。推理结束以后及时释放上下文和模型句柄，避免常驻内存；在低电量或高温情况下，要减少生成长度，甚至可以主动暂停推理任务。

6.4 安全、隐私与合规

端侧部署的一大价值就是数据不出设备，但这不意味着没有风险。

不要把敏感对话内容写入日志，也不要把模型文件放到外部存储的公共目录，防止其他应用读取。下载模型时选择官方或可信渠道，避免从不明网站获取模型文件，因为模型本身也可能被注入恶意内容。如果 App 需要网络权限，建议仅连接本地服务，不要无意义地上传任何用户输入。

6.5 关注开源协议

大模型和推理框架都有各自的许可证。使用 Qwen、Llama 等模型时，要遵守对应的开源协议，尤其是商用限制。llama.cpp 使用 MIT 许可证，比较宽松；MLC LLM 使用 Apache 2.0 许可证，同样适合商用。但模型本身的协议需要单独确认，不要只看框架许可证。

7. 总结与学习路线

这次实测下来，安卓端跑大模型，最值得推荐的是 MLC LLM 和 llama.cpp 这两条路线。

如果你追求开箱即用，直接安装 MLC Chat App，配合 Vulkan GPU 加速，体验远远好于 Ollama + Termux 组合。如果你喜欢折腾底层原理，在 Termux 里编译 llama.cpp，会加深你对模型加载、量化、Token 处理和推理性能的理解。如果你本来就在做 Android 开发，那么通过 NDK 集成 llama.cpp 或者使用 MLC 的 Android SDK，都能让你把大模型能力嵌入自己的业务中。

下一步可以按这个路径继续学习：

• 先动手跑通一个 1.5B 或 3B 模型，感受不同量化级别的效果差异。
• 再研究 GGUF 格式和量化原理，尝试用工具转换自己的模型。
• 然后把推理引擎封装成 Android SDK，做一个带 UI 的聊天应用。
• 最后可以往 RAG（检索增强生成）和 Agent 方向扩展，把端侧模型接上知识库和工具调用。

如果你也在安卓手机上折腾过本地大模型，欢迎在评论区聊聊你用的框架和踩过的坑。觉得本文对你有帮助的话，可以收藏备用，后续我会继续更新端侧 LLM 部署和优化相关的实战内容。