手机本地跑大模型+知识库：从选型到部署的完整RAG实践

去年年底我出差途中遇到一个很尴尬的场景：笔记本电脑没电，高铁上的信号时有时无，想查一份自己整理的旧项目资料，云端笔记转圈圈刷不出来。当时我就在想，如果这台手机本地就装着一个知识库和一套能跟我对话的大模型，是不是就不用看网络脸色了？回来后我认真折腾了大半个月，把"移动端部署本地知识库 + 大模型"这条链路完整跑通了。这篇教程就按我的实操过程拆开讲，从手机选型、模型选择、环境搭建到知识库接入，每一步怎么做、为什么这么做、踩过哪些坑，尽量交代得清清楚楚。适合两类人看：一类是手里有大量笔记、PDF、技术文档，想随时离线检索问答的普通用户；另一类是刚接触大模型部署，想拿手机当实验田，用最低成本理解"模型 + 知识库"整套逻辑的开发者。

1. 先把话说清楚：手机跑大模型，边界到底在哪里

1.1 为什么手机也能跑大模型

先破除一个流传很广的误解：很多人觉得大模型是"数据中心专属"，手机这种小身板不可能跑得动。这个说法在四五年前成立，但现在的旗舰手机确实已经具备本地推理的能力。大模型推理的本质可以粗略理解为反复进行矩阵乘法运算——把输入的向量和模型的权重矩阵做一次又一次计算。手机SoC里的GPU和NPU（神经网络处理单元）恰好就是干这个活的，尤其是NPU，专门为这类算子做了硬件加速。所以算力本身不是最要命的瓶颈，真正的瓶颈是另外两样：内存容量和内存带宽。

内存容量的逻辑很简单：模型文件必须先完整加载到内存里，推理时才能被读取。一个70亿参数的模型，如果用FP16精度存储，权重文件大约占14GB，这对手机来说完全不现实。但量化技术把这个大麻烦解决了一大半。量化就是原本用16位浮点数存权重，压缩成8位、4位表示，精度的损失在可接受范围内。一个7B模型用4bit量化后，体积能压到4GB左右，手机完全塞得下。内存带宽则决定模型生成文字的速度，同样是7B模型，在不同手机上跑出来的token/s（每秒生成token数）能差好几倍，这就是原因。

这里给一个参考估算：4bit量化后的7B模型，实际运行时大概需要4.5GB到5GB内存（包括上下文缓存和激活值），所以手机运行内存在8GB以上才能比较从容；3B、1.5B这类更小的模型，三四GB内存也能跑。所谓"跑得动"和"跑得舒服"是两码事，往下看你就会知道怎么取舍。

1.2 你的手机属于哪一档：动手前先判断

动手之前，花三分钟确认三件事：运行内存（RAM）、可用存储空间、芯片平台。运行内存直接决定你能跑多大模型，建议至少8GB起步；可用存储空间至少要留10GB，因为一个模型文件少说三四GB，后面知识库的向量数据也会占掉几百MB；芯片平台影响推理速度和稳定性，高通骁龙8系、联发科天玑9000系、苹果A系列/M系列在NPU和驱动适配上都更成熟。

怎么判断你的手机属于哪一档？打开设置找到"关于手机"，看"运行内存"和"存储"这两行就行。我把档位和选型建议整理成一张表：

实测下来的经验是：内存不足的时候，手机系统会开始杀后台进程，大模型推理很容易被"截胡"，表现就是等半天刚出答案，结果输出到一半被系统中断。所以正式跑之前，先清理一遍后台App和通知栏应用，能明显提高成功率。

1.3 移动端真正值得选的模型清单

我把目前移动端比较现实的模型选择整理成了一张表，你自己对照着挑就行：

第一次在手机上部署，我的建议是：别贪大，先跑通再说。选一个1.5B到4B级别的模型当"探路队"，把全流程跑顺之后，再考虑上7B。因为模型越大，内存压力越大、发热越明显、速度越慢，如果第一步就卡在下载或推理崩溃上，很容易把兴致磨没了。我自己的习惯是用小模型验证链路，一切都稳定了再换更聪明的模型，成功率远高于一上来就挑战最高参数。

2. 环境搭建实操：从Termux到Ollama跑通第一个模型

2.1 为什么选Termux + proot方案，而不是其他App

想在这台机器上本地跑模型，本质上是需要一个能运行Linux服务、并且能下载大文件的终端环境。目前手机上主要有几条路：直接用一些"集成了模型的一体化App"、用Ollama的官方移动端、或者在Termux里装完整Linux环境再跑Ollama。一体化App用起来确实省事，但普遍有个问题：模型是内置写死的，想换模型、换知识库、看日志都难，扩展性很差。Ollama官方移动端目前还在快速迭代阶段，功能边界变化快，如果求稳，我更推荐用Termux这条路。

Termux是Android上最流行的终端模拟器，它的本质不是在App里跑一个小壳子，而是提供了一个真实的Linux环境，可以通过设置包管理器安装各种软件。配合proot-distro工具，还能在Termux里运行一个完整的Ubuntu用户空间。Ollama本身就是一个面向Linux的命令行服务，所以在Ubuntu环境里安装、运行，等于把PC上的成熟方案平移到了手机上，后续不管是换模型、调参数、写脚本，都是同一套玩法。

这条路唯一的缺点是要敲命令、有一个proot虚拟化层带来的一点点性能损耗（大概10%到20%）。但对"本地知识库 + 大模型"这种以查资料和问答为主的使用场景，这个性能损耗完全可以接受。既然目标是搞懂整套逻辑，稍微多点操作换来完全可控的环境，我觉得非常值。

2.2 一步一步安装：命令与细节

**第一步：装Termux。**注意，Termux一定要从它的官方渠道（F-Droid应用商店或GitHub发布页）下载，不要用Google Play那版，因为Play版早就停止维护了。安装好之后先执行：

bash复制termux-setup-storage

这条命令会弹出存储权限请求，允许之后Termux才能读取手机内部存储，后面把PDF、Markdown文档放进知识库目录要用到。

**第二步：更新基础环境和安装proot。**Termux刚装好，先做一次完整升级，顺便装proot-distro：

bash复制pkg update && pkg upgrade -y
pkg install proot-distro -y

**第三步：安装Ubuntu容器。**这一步会自动下载一个Ubuntu用户空间镜像，大概几百MB，需要有Wi-Fi或者稳定网络：

bash复制proot-distro install ubuntu

安装完成后，登录进Ubuntu环境：

bash复制proot-distro login ubuntu

登录成功之后，你会发现命令提示符变成了类似root@localhost的样式。这时候你的操作环境已经是一个完整的Ubuntu系统了。

**第四步：在Ubuntu里安装Ollama。**在登录进去的Ubuntu里面依次执行：

bash复制apt update && apt upgrade -y
apt install curl -y
curl -fsSL https://ollama.com/install.sh | sh

脚本执行完成后，Ollama就装好了。启动服务：

bash复制ollama serve

如果看到类似Listening on 127.0.0.1:11434的输出，说明Ollama已经在后台运行了。serve命令会占住当前终端，建议让它在这个终端里跑着，另外再开一个新的Termux窗口登录Ubuntu去执行后面的命令。

这里有一个新手容易困惑的地方：为什么从https://ollama.com/install.sh这个地址下载安装脚本是安全的？因为Ollama是开源项目，官方安装脚本就是向GitHub的发布页请求对应架构的二进制包，这属于标准的开源软件分发方式。手机上如果下载速度慢，多半是网络环境问题，建议避开高峰时段或换一个网络再试。

2.3 拉取模型并完成第一次对话

Ollama运行起来之后，拉取模型就一句话。以Qwen3的4B版本为例：

bash复制ollama run qwen3:4b

第一次执行会先下载模型文件，4bit量化版的体积大概在2.5GB左右。下载完成后会自动进入交互式对话界面，你随便问一句"你是谁"，能看到它正常回复就说明链路已经通了。

这时候可以做一个简单测试，来直观感受性能和资源占用。打开第三个Termux窗口，登录Ubuntu后用htop或free -h查看内存占用：

bash复制apt install htop -y
htop

你会看到Qwen3:4b模型在推理时大约占掉3GB到4GB内存，CPU占用率可能冲到几核满载，手机温度也会明显上升。这些都很正常。测试完如果想让模型退出前台运行，直接输入/bye退出对话，但模型文件依然保留在本地，下次ollama run启动会很快，因为不用再下载了。

3. 知识库的本质：分块、向量化与检索

3.1 一个图书馆理员的类比，讲明白知识库的底层逻辑

在动手搭知识库之前，必须先理解它背后的逻辑。你可以把知识库想象成一个图书馆，把大模型想象成一位只会"自由发挥"的馆员。如果用户直接问馆员问题，他只能凭自己的"通识记忆"回答，你的私人资料他完全没看过。而"知识库 + 大模型"要做的事，相当于先派很多助手把你的私人资料读一遍，整理成一张张便签，按照内容相似度摆放在合适的架子上；用户提问时，再根据和问题最像的几十张便签，连同问题一起交给馆员，让他以此为素材组织答案。

这个流程在技术上叫RAG（Retrieval-Augmented Generation，检索增强生成）。落地的关键点有三个：第一步"分块"，把你的长文档切成一个个几百字的片段；第二步"向量化"，用一个嵌入模型把每个片段转换成一组几百维的向量数值；第三步"检索"，用户提问时把问题也转成向量，通过余弦相似度计算，找到向量空间里最接近的几个片段。这三个步骤缺了哪个，你搭出来的东西都不是真正的知识库，而只是一个普通聊天机器人。

3.2 嵌入模型与向量检索：手机端如何选

既然要把文档片段转成向量，就需要一个嵌入（embedding）模型。Ollama除了能跑对话模型，也支持嵌入模型。在手机上拉一个轻量级的嵌入模型，完全做得到。我常用的组合是：

bash复制ollama pull bge-m3

这个模型的体积大概1.2GB，参数规模不大，但中英文混合场景的表现都还不错。你也可以选择更小的nomic-embed-text，大概0.3GB，速度更快，但复杂语义的理解会弱一些。嵌入模型不像对话模型那样需要"生成文字"，它只是把文本变成长串数字，所以对内存的消耗远低于对话模型。

向量存到哪里？移动端不用上重型向量数据库。我的做法是：先把分块好的文本和对应向量存成一个JSON文件（或者用SQLite），查询的时候用numpy或者jina-hub这类轻量库做余弦相似度计算。对于几百个文档片段来说，这种"最土"的办法不仅够用，而且速度极快，不需要任何额外服务。等你的片段规模到了几万级别，再考虑迁移到专业的向量数据库，那是后话。

3.3 文档准备与预处理：避开白建库的坑

知识库能不能用，不是看你有多少文档，而是看切出来的片段质量。这一步踩坑的人非常多，我总结几个高发问题：

**第一，PDF扫描件必须做OCR。**如果你的PDF本质上是图片（比如扫描书籍、别人发的截图型文档），直接分块得到的全是乱码或空文本，知识库等于白建。在手机上处理，我建议先用手机自带的文档扫描或OCR工具转成可复制文本，或者干脆优先使用Markdown、TXT这类纯文本格式。

**第二，分块参数要合理。**一般RAG工具里都有两个参数：chunk_size（每个块的大小）和chunk_overlap（相邻块的重叠量）。我实践的取值是中文场景chunk_size设为300到500字左右，overlap设为50到100字。太小了语义不完整，太大了检索噪音高、会把不相关的内容卷进来。如果你在PC上用过LangChain、LlamaIndex，这个概念是一样的，只是移动端可以选更轻量的脚本实现。

**第三，个人知识库里最容易忽略的是"问题视角"。**一篇文档里的关键信息往往藏在表格、列表、代码块里，纯文本分块时这些格式可能会丢。我自己的建议是对重要表格单独提取成一段描述性文本，而不是让分块工具硬生生把表格拆散。

4. 把知识库接到大模型上：RAG链路配置与调优

4.1 RAG完整流程：一次提问的"漫长"旅程

理解完整的RAG流程之后，你配置起来会非常有数。一次提问实际经历了以下六步：

1. 用户输入一个问题，比如"上个月的项目验收报告里，关于延迟问题有哪些结论？"
2. 系统调用嵌入模型，把这个问题转换成向量。
3. 系统拿这个向量去知识库的向量索引里做相似度检索，找出最相关的5到10个文档片段。
4. 系统把检索到的片段和用户问题拼在一起，组成一段"增强后的提示词"。
5. 系统把这整段提示词发送给大模型（比如Ollama里的qwen3:4b）。
6. 大模型阅读提示词中的片段，结合上下文组织出自然语言回答。

这个过程可以全部手动实现，也可以借助工具。我建议小白至少在手动脚本里跑一遍这个流程，因为只有亲眼看到"问题被拼进提示词、检索出来的片段是什么"，你才会知道后面接到的回答为什么是可靠的、什么时候有可能是幻觉。

4.2 不想写代码：用Dify可视化搭一个知识库应用

如果你完全不想碰代码，又想用图形界面管理知识库，目前比较成熟的方案是在一台性能稍微宽裕的设备上部署Dify，然后手机通过浏览器访问。Dify是一个开源的LLM应用开发平台，内置了知识库管理、RAG流水线、聊天界面，部署方式最常用的是Docker。在PC或者老笔记本上执行：

bash复制docker compose up -d

Dify启动后，在配置页面把模型API地址填成你的Ollama地址。这里有个关键细节：如果是同一台机器上的Ollama，地址填http://localhost:11434就行；如果手机浏览器要访问部署在PC上的Dify，那手机和PC需要在同一个局域网内，Dify里填模型地址时记得填PC在局域网内的IP，比如http://192.168.1.10:11434，而不是localhost。

在Dify里创建知识库、上传文档、选用Ollama提供的嵌入模型做索引，最后再创建一个"聊天助手"应用，把知识库关联进去，整个过程都是点选式操作。手机浏览器打开Dify的Web界面，就像用一个小型企业级知识库App一样。它唯一的门槛是Dify本身对设备要求比Ollama高，不太适合直接装在手机上，所以把它当"家里的知识库服务器"用是最合理的定位。

4.3 提示词与生成参数的实际调优建议

知识库链路跑通之后，你会开始在意回答质量。我建议从三个参数入手调整：

**温度（temperature）。**默认值一般是0.7，但做知识库问答时我会降到0.2到0.3。温度越低，模型越倾向输出确定性内容，幻觉越少。知识库场景追求的是"复述准确信息"，而不是"发挥创意"，所以低温更合适。

**上下文数量（top_k或top_n）。**每次检索返回给模型的片段数量，我一般设为5到8个。片段太少，答案容易漏信息；片段太多，模型会"注意力涣散"，反而被不相关的东西带偏。Dify里可以直接调整检索设置，手动脚本里改一下列表切片长度就行。

**引用来源。**这个容易被忽略但特别重要。如果你用的工具支持"引用来源"，一定要打开。回答末尾附上"出自哪份文档第几节"，不只是让你确认答案是靠谱的，更是帮你发现知识库里的分块质量问题——如果某次回答引用了明显不相关的片段，说明分块或检索条件需要调整。我至今保留着这个习惯，它能快速定位问题，省去很多无谓的排查时间。

5. 实测翻车清单：内存、发热、速度与进阶玩法

5.1 内存不足：最常翻车的环节

移动端跑知识库和大模型，最常出现的翻车现场就是内存不足。我这里说的内存不足，不仅仅是"跑不起来"这么简单，它有一整套渐进症状：模型加载到一半进程被杀、对话时打字都卡顿、回答生成到一半直接被系统中断。遇到这些情况，先用free -h看一下当前内存到底还剩下多少。

解决办法按优先级排列：第一，换更小的模型。4B不行就换3B，3B不行就换1.5B。这个代价最小。第二，限制上下文长度。对话历史越长，上下文缓存占的内存越大。很多工具有num_ctx参数，默认可能是2048或4096，如果只是知识库问答，把它设成1024或2048，内存占用立刻降下来。第三，保证存储空间充裕。模型运行时的交换分区依赖存储，存储太满会拖慢所有操作。

5.2 发热降频：为什么模型越跑越慢

很多人第一次在手机上跑7B模型，会体验到"刚开始很快，过了几分钟越来越慢"的邪门现象。这不是模型的问题，而是手机在发热降频。处理器温度超过安全线之后，SoC会主动降低频率来保护硬件，推理速度自然就掉下来。我实测过，同一台手机跑7B模型，刚启动时能到6到8 token/s，连续跑五分钟后可能跌到3 token/s左右，体感非常明显。

想缓解这个问题，几个土办法实测有效：跑模型时把手机壳摘掉，让热量散得更快；不要把手机放在被子、沙发这种导热差的地方；选量化程度更低的模型文件，比如从Q4_K_M换成Q4_0，虽然精度稍有损失，但计算量更小。另外，如果知识库回答这种任务对实时性要求不高，可以把一次大任务拆成多次小任务，让手机有喘息的间隔。不要把"速度不能和PC比"理解成手机不行，而是要在设备能力边界内做合理的任务规划。

5.3 进阶玩法：把手机变成"遥控器"

当你把手机上的小模型跑顺手之后，很容易产生一个疑问：我的PC或者家里的旧电脑性能强得多，能不能让手机变成一个"遥控器"，随时调用家里那台机器上的大模型和知识库？完全可以。Ollama本身默认只监听127.0.0.1，你要做的只是把它的监听地址改成局域网地址，具体做法是在启动Ollama时设置环境变量：

bash复制OLLAMA_HOST=0.0.0.0:11434 ollama serve

然后手机上的客户端或脚本，把API地址从http://127.0.0.1:11434改成http://192.168.x.x:11434（填PC的局域网IP），就能在手机上调用家里那台PC的算力了。同理，Dify部署在PC上之后，手机浏览器直接访问其Web界面就是完整的企业级知识库体验。

更进一步，你还可以在PC上用Docker把Dify、PostgreSQL、向量数据库这些组件编排起来，再把手机端的文档通过Dify的API自动同步上去。这样手机上随手拍的PDF、碎片化笔记，回到家就能进入知识库并完成索引，第二天通勤路上就可以直接问。整套体系跑通之后，手机既是移动端推理节点，也是整个家庭知识库的入口，价值就远不止"能跑个小模型"这么简单了。

我自己的感受是：移动端玩大模型这件事，最难的不是技术，而是"接受手机算力的边界，并且把任务类型对应到合适的模型上"。知识库查询这种碎片化、实时性的任务，交给手机上的小模型，体验其实不错；深度推理和长文生成，交给局域网里的大机器，两不耽误。折腾这套东西半年多，我最常用的场景，还是那个让我当初下决心的场景——高铁上、地铁里，没有信号的时候，打开手机问答，它调出我自己写过的资料，稳稳地告诉我答案。这种"不管在哪儿，自己的资料都能问"的确定性，才是整套方案最大的价值所在。