移动端本地大模型与私有知识库搭建实战指南

把大模型塞进手机这件事，我从去年就开始折腾。一开始用的是云端API，后来发现两个问题让人越来越难受：一是数据无论如何都要过别人的服务器，哪怕脱敏也总觉得别扭；二是地铁、高铁、飞机上断网的时候，一个能用的助手都叫不出来。于是我把目标定成“所有东西都跑在本地，手机离了网也能用”，最终搭起了一套移动端本地知识库加大模型的组合，效果超过我预期。这篇文章就是把我踩过的坑、试出来的方案、实测的性能数据，从头到尾写清楚，给想在手机或者平板上跑本地大模型和私有知识库的朋友一个可以直接参考的落地路线。

先说结论：移动端完全能跑，但和PC、服务器上的玩法完全不一样。模型不能贪大，知识库的“向量化”和“检索”工作要提前想清楚放在哪一侧做，推理引擎也要挑对。下面我就按照“为什么这么选、具体怎么做、实际跑起来什么问题最多”的顺序来写，你可以直接对照自己的硬件条件选择路线。

1. 移动端部署的底层逻辑与可行性判断

1.1 手机跑大模型卡在哪：内存、算力与内存带宽

很多人觉得手机跑大模型不现实，是因为把PC上跑模型的标准带过来了。PC动辄32GB、64GB内存，显卡显存几十GB，手机这边普遍是8GB、12GB、16GB内存，看起来完全不是一个量级。但对大模型推理来说，关键瓶颈其实是内存带宽，不是单纯的算力。

大模型生成token的过程是自回归的，每生成一个token，都要把模型权重完整读一遍。这个读取速度由内存带宽决定。手机SoC的内存带宽一般是多少？旗舰芯片大概在60GB/s到100GB/s之间，中端芯片更低，30GB/s到50GB/s。一个7B参数、Q4量化后的模型大约4.5GB，理论上每秒能生成的token数就是带宽除以模型体积：90GB/s除以4.5GB，大约20 tokens/s。这其实已经是一个可用的速度了。

所以“能不能跑”的核心判断公式就变成：模型文件大小必须小于可用内存，内存带宽决定了生成速度的下限。这也是为什么我建议移动端优先选1.5B到7B之间的小模型，而不是14B、32B这样的大参数模型。参数越大，内存装不下，速度也会掉到没法看的水平。

1.2 端侧模型选型：跑得动又够好用的小模型

移动端模型选型是个平衡艺术。我试过几条路线，先说结论：对话类场景，Qwen2.5系列是当前这个阶段端侧最优选之一。原因主要有三点：中文能力强，指令跟随好，GGUF量化版本非常全，从0.5B到72B都有现成的量化文件，尤其1.5B和3B的Q4版本在手机上跑得很舒服。

具体文件大小可以提前估算，一般来说Q4_K_M量化下，1.5B大约1.1GB，3B大约1.9GB，7B大约4.4GB。如果你的手机是8GB内存，建议最高3B；12GB以上可以试试7B，但要保证后台应用清干净。16GB内存的旗舰机型，7B是甜点位，14B还是算了，速度会掉到5 tokens/s左右，体验很差。

除了Qwen2.5，Llama 3.2 1B/3B也是个好选择，英文场景表现很好，中文差一些。Phi-3.5 mini在推理能力上不错，但生态不如Qwen方便。还有一个思路是用DeepSeek-R1的蒸馏小模型，比如Distill-Qwen-1.5B，代码和数学推理有明显增强，适合知识库偏技术文档的场景。建议手头留一个“对话模型”加一个“嵌入模型”，后面做知识库要用。

1.3 三条部署路线：全端侧、端云混合与局域网调度

我开始想的是“一步到位全端侧”，也就是模型、知识库、推理全部在手机本地完成。后来在实际使用中意识到，不是所有场景都需要绝对离线，于是我把方案拆成了三条路线，各有适用场景：

• 全端侧：模型和知识库都在手机本地，完全断网可用。适合隐私强敏感内容，比如个人日记、病历、会议纪要。代价是模型规模受限，效果上限不高。
• 端云混合：知识库在本地，模型优先请求本地，如果手机跑不动就自动切换云端API。适用日常通用问答，兼顾效果和隐私。
• 局域网调度：手机作为客户端，模型和知识库跑在家里的PC或NAS上，手机通过局域网访问。这个方案跑大模型完全没有硬件压力，但离了家就没法用。

本文核心讲的是第一条路线，因为这是最硬核、最完整的技术闭环。后面涉及局域网方案时我会单独标注，方便你按需参考。

2. 本地模型推理引擎：选型和实战

2.1 Android首选方案：Termux环境下的极简部署

先讲Android，因为Android生态开放，可以跑完整Linux环境。我用的是Termux加Ollama的组合。Ollama本身主要面向桌面和服务器，但官方Release里有linux-arm64的二进制，Termux可以直接跑。这是我试过的最省事的方式，不需要自己编译llama.cpp，也不需要折腾LD库。

具体操作步骤：

bash复制# 1. 安装Termux，并更新基础包
pkg update && pkg upgrade -y

# 2. 安装必要工具
pkg install curl wget git -y

# 3. 下载Ollama的linux-arm64二进制
# 从GitHub Release页面找到对应版本，替换下面的版本号
wget https://github.com/ollama/ollama/releases/download/v0.5.x/ollama-linux-arm64.tgz
tar -xzf ollama-linux-arm64.tgz

# 4. 放到PATH目录下
mv ollama /data/data/com.termux/files/usr/bin/

# 5. 启动服务，默认监听11434端口
ollama serve

服务起来之后，另开一个Termux会话拉取模型：

bash复制# 拉取对话模型，这里用1.5B Q4量化版本
ollama pull qwen2.5:1.5b-instruct-q4_K_M

# 拉取嵌入模型，后面知识库要用
ollama pull nomic-embed-text

这里有个坑要提醒你：Termux里跑服务端，Ollama默认会读取当前用户目录下的.ollama/models，建议你在启动前先看一眼磁盘剩余空间，一个模型加一个嵌入模型总共要预留3GB左右。Termux的数据目录如果空间不够，可以用软链接把模型目录指到外部存储，但外部存储的IO性能会影响加载速度，实测SD卡比机身存储慢很多，能用机身存储就别动这个念头。

2.2 iOS路线：快捷指令与局域网联调方案

iOS的本地部署难度比Android高一个量级，这主要是系统沙箱机制导致的，Termux这种Linux环境在iOS上没法运行。我目前用的方案不是“全端侧”，而是“手机端交互 加 局域网模型调度”，实际体验很好。

具体是这样做：我家里有一台Mac mini，装了Ollama，模型和知识库都跑在Mac上，然后iPhone通过局域网访问。iOS这边我用的是一个支持自定义API地址的客户端，把API Base URL填成http://家里Mac的局域网IP:11434，就能把模型能力接到手机上。

如果你想保持“知识库在手机本地”，只把大模型推理放局域网，也可以在手机上装SQLite加向量插件做检索，然后把检索到的资料和问题一起发到局域网模型一次性生成回答。这个模式的好处是数据不经过外网，隐私安全还说得过去。

再补充一个更硬的方案：用Swift写一个App，嵌入llama.cpp的iOS版本，模型文件放在App沙盒里。这是真正的iOS全端侧方案，但开发成本高，适合有编程基础的人。对大多数人来说，如果你的核心诉求是“手机上能用自己的知识库和模型”，局域网调度的体验已经非常接近全端侧了，不必和自己较劲。

2.3 嵌入模型的选择：中文场景下的一个小坑

部署完对话模型，接下来要处理知识库。知识库的核心是“语义检索”，而语义检索依赖嵌入模型。这里有一个非常容易被忽略的坑：很多开源嵌入模型的中文效果很差。比如nomic-embed-text在英文长文本检索上表现很好，中文场景下经常出现“明明词都对，语义就是匹配不上”的问题。

如果你的知识库主要是中文内容，建议直接用中文优化的嵌入模型，比如bge-small-zh-v1.5。这个模型只有100MB左右，嵌入维度512，在手机端跑非常快，中文效果比通用模型好不少。Ollama里可以直接用ollama pull bge-small-zh-v1.5拉取，最终每个文本片段都会变成一个512维的向量。

维度大小有讲究。我之前以为维度越高越好，后来发现移动端要综合权衡：768维的嵌入在计算相似度时耗时更久，存储也更大。512维做知识库检索完全够用，所以别盲目追求高维度。记住了，嵌入模型和对话模型是两个独立的模型，都要单独拉取，很多人第一次弄的时候以为只装一个模型就能全部搞定，结果检索那一步一直报错。

3. 知识库的工程化落地

3.1 移动端向量存储选型：为什么推荐SQLite加vec0

知识库的数据结构本质上是“文本片段加向量”，所以需要一个向量数据库。PC上常用ChromaDB、FAISS、Milvus，这些在移动端都不好用，要么太重，要么依赖过多服务。

我最终选择的是SQLite加sqlite-vec扩展。SQLite是移动端最成熟的嵌入式数据库，sqlite-vec是它的向量搜索扩展，支持用SQL语句直接创建向量表、插入数据、查询最近邻，整个东西就是一个库文件，不用起服务，没有网络开销，完美匹配手机场景。

建表语句很简单：

sql复制-- 先加载扩展，不同平台加载方式略有不同
.load ./vec0

-- 创建向量表，embedding列指定为float[512]
CREATE VIRTUAL TABLE documents USING vec0(
    id INTEGER PRIMARY KEY,
    chunk_text TEXT,
    chunk_source TEXT,
    embedding float[512]
);

这里有几个细节要注意。第一，维度必须写死，和你的嵌入模型输出维度保持一致，bge-small-zh是512，nomic-embed-text是768，写错维度会直接报错；第二，vec0表的查询语法和普通SQLite略有差别，查询最近邻时要用ORDER BY distance加LIMIT k的固定写法；第三，向量搜索返回的是id和距离，关联原始文本还需要join普通表，所以我建议把文本字段直接放在向量表旁边，省一次join操作。

3.2 知识入库流程：分块、向量化与批量同步

知识库不是把整篇文档丢进去就完事的，必须分块。分块的目的有两个：一是让检索到的片段足够聚焦，二是把文本长度控制在嵌入模型的输入上限内。我常用的是固定长度加重叠窗口的分块方式，中文字符按500字一块，重叠50字。

以Python脚本为例，分块逻辑大概是：

python复制def chunk_text(text, chunk_size=500, overlap=50):
    chunks = []
    start = 0
    while start < len(text):
        end = min(start + chunk_size, len(text))
        chunks.append(text[start:end])
        if end == len(text):
            break
        start = max(0, end - overlap)
    return chunks

分块之后，要把每个块转成向量。这里有一个非常实用的建议：大批量知识库入库操作，不要在手机上做。我一开始图方便，直接在手机Termux里写Python脚本逐条调用嵌入API，结果几千条文本跑了一个多小时，手机还发烫。后来改成“PC端批量向量化，导出向量文件，手机端直接导入”，效率提升了十倍不止。

PC端我用的还是Ollama的嵌入接口，脚本也简单：

bash复制curl http://localhost:11434/api/embeddings \
  -d '{"model": "bge-small-zh-v1.5", "prompt": "这里是文本片段内容"}'

把批量结果存成JSON或CSV，再导入手机的SQLite表里。手机端只负责查询，不做重计算。这个“重活外移、轻活端侧”的思路，是移动端知识库工程化的核心原则。

3.3 检索与排序：向量检索加关键词兜底

知识库能不能给出有用的回答，一半看分块，一半看检索。只做向量检索，在垂直领域很容易翻车，原因是向量检索对专业术语和精确匹配不敏感。比如你检索“Q4量化”，它有可能把“Q8量化”相关的片段列在前面，因为语义相似度高，但“Q4”这个具体数字反而被稀释了。

我最后采用的是混合检索方案：向量检索召回Top20，再用关键词过滤或BM25分数加权排序一次，最后取Top5输入给大模型。这个方案不需要额外的搜索引擎，SQLite里做个简单的关键词匹配就行，核心代码是：

sql复制-- 向量检索Top 20
SELECT id, chunk_text, distance
FROM documents
WHERE embedding MATCH :query_embedding
ORDER BY distance
LIMIT 20;

拿到这20个候选之后，再用关键词命中的比例做一下排序插值，比如命中关键词加0.1分，距离排名前5加0.2分，最后综合得分取Top5。实测混合检索比纯向量检索的问答准确率至少提高20%到30%，尤其适合知识库里有大量数字、型号、专业名词的场景。

3.4 Prompt组装与问答输出

检索到内容后，最后一公里是把资料塞进Prompt交给大模型。这段组装逻辑直接影响回答质量，我踩过几个坑之后总结出下面这个模板：

code复制你是我的本地知识助手。请严格依据下面提供的资料回答问题。
如果资料中没有相关内容，直接回答“知识库中未找到相关信息”，不要编造。

【资料】
- 片段1：...
- 片段2：...
- 片段3：...

【问题】用户的问题

这里有几个关键点。第一，必须明确告诉模型“不知道就说不知道”，否则大模型会一本正经地编答案，这是RAG最常见的幻觉来源；第二，资料片段不要超过5个，每个控制在几百字，否则上下文塞得太多，模型反而抓不住重点；第三，问题和资料之间的顺序不要乱，先给角色设定，再给资料，最后给问题，顺序颠倒会导致回答质量显著下降。

4. 完整实操：手机端知识库问答系统的搭建记录

4.1 环境准备与模型准备

我用一台12GB内存的Android旗舰机做测试，系统为Android 14，已安装Termux并完成Ollama部署。模型方面拉取了两个：对话模型用的是qwen2.5:3b-instruct-q4_K_M，文件约1.9GB；嵌入模型用的是bge-small-zh-v1.5，文件约100MB。

拉取完成后，先用一个简单命令验证对话模型是否正常：

bash复制ollama run qwen2.5:3b-instruct-q4_K_M "你好，请用一句话自我介绍。"

正常情况下，手机本地生成这段话的速度大约在12到15 tokens/s，也就是半秒钟一个字，体感可以接受。如果速度低于5 tokens/s，说明模型超出设备能力了，建议降到1.5B再试。

4.2 数据库建表与数据导入

接下来在Termux里安装Python和SQLite环境：

bash复制pkg install python sqlite -y
pip install numpy

然后从网上下载sqlite-vec的源码编译安装，或者直接在GitHub Release里拿预编译的扩展文件，放到$PREFIX/lib目录下。加载扩展并建表：

python复制import sqlite3

conn = sqlite3.connect("kb.db")
conn.enable_load_extension(True)
conn.load_extension("./vec0")

conn.execute("""
CREATE VIRTUAL TABLE IF NOT EXISTS documents USING vec0(
    id INTEGER PRIMARY KEY,
    chunk_text TEXT,
    chunk_source TEXT,
    embedding float[512]
);
""")

数据导入我走的是CSV文件方案。先在PC端把所有文档分块、向量化、写成CSV，然后把文件传到手机的~/storage/downloads/目录，再在Termux里执行导入：

python复制import csv
import sqlite3
import numpy as np

conn = sqlite3.connect("kb.db")
conn.enable_load_extension(True)
conn.load_extension("./vec0")

with open("chunks.csv", "r", encoding="utf-8") as f:
    reader = csv.DictReader(f)
    for idx, row in enumerate(reader):
        embedding = np.frombuffer(bytes.fromhex(row["embedding_hex"]), dtype=np.float32)
        # 512维，8字节一个float，总共2048字节
        conn.execute(
            "INSERT INTO documents (id, chunk_text, chunk_source, embedding) VALUES (?, ?, ?, ?)",
            (idx, row["text"], row["source"], embedding.tobytes()),
        )
conn.commit()

这里有个细节：向量字段写入的时候必须用二进制字节串，不能直接传list。我最初直接在SQL里传Python list，结果sqlite-vec不认，查了半天才意识到要转成bytes。

4.3 端侧查询脚本

建好库之后，写一个查询脚本。这个脚本要做三件事：给用户问题算向量、从库里检索Top5片段、连同问题一起发给本地大模型生成回答。

完整代码如下：

python复制import json
import sqlite3
import numpy as np
import requests

OLLAMA_URL = "http://127.0.0.1:11434"

def embed_text(text):
    r = requests.post(f"{OLLAMA_URL}/api/embeddings", json={
        "model": "bge-small-zh-v1.5",
        "prompt": text
    })
    return np.array(r.json()["embedding"], dtype=np.float32).tobytes()

def search(query_embedding, k=5):
    conn = sqlite3.connect("kb.db")
    conn.enable_load_extension(True)
    conn.load_extension("./vec0")
    cur = conn.execute(
        """
        SELECT id, chunk_text, distance
        FROM documents
        WHERE embedding MATCH ?
        ORDER BY distance
        LIMIT ?
        """,
        (query_embedding, k),
    )
    return cur.fetchall()

def generate_answer(question, contexts):
    context_text = "\n".join(
        f"- 片段{i+1}：{ctx[1]}" for i, ctx in enumerate(contexts)
    )
    prompt = (
        "你是我的本地知识助手。请严格依据下面提供的资料回答问题。\n"
        "如果资料中没有相关内容，直接回答“知识库中未找到相关信息”，不要编造。\n\n"
        f"【资料】\n{context_text}\n\n"
        f"【问题】{question}"
    )
    r = requests.post(f"{OLLAMA_URL}/api/generate", json={
        "model": "qwen2.5:3b-instruct-q4_K_M",
        "prompt": prompt,
        "stream": False,
    })
    return r.json()["response"]

if __name__ == "__main__":
    q = input("请输入问题：")
    q_vec = embed_text(q)
    results = search(q_vec, k=5)
    answer = generate_answer(q, results)
    print(answer)

这个脚本跑起来之后，整个链路就通了。实测单次问答的时间大概在：查询向量几十毫秒，向量检索十毫秒，模型生成几秒到十几秒，整体体验和早期云端小模型差不多。

4.4 跑通后的调优与效果验证

脚本跑通只是第一步，把效果调稳才是关键。我做了三个维度的验证。

第一，检索召回测试。选10个知识库里的常见问题，逐个判断Top5片段里有没有正确答案。如果召回率低于80%，优先调分块策略，把块从500字减小到300字试试，或者把重叠从50字加到100字。

第二，问答准确性测试。对每个问题跑三轮，看答案是否稳定。不稳定的话，把Prompt里“不要编造”的表述加强为“即使你觉得能推测，也必须基于资料原文，资料没有就直说不知道”。

第三，生成速度验证。模型推理速度受手机温度影响很大，刚开机时12到15 tokens/s，连续用20分钟之后可能掉到8 tokens/s。这是端侧大模型的正常热衰减，不是bug。如果要缓解，可以把模型的num_ctx从2048改成1024，上下文缩短后生成速度会有明显回升。

5. 常见问题与避坑清单

5.1 模型和内存相关

最大的坑是OOM。我一开始直接在12GB内存的机器上拉7B模型，结果Ollama加载模型时直接被Android系统杀掉，进程没了，一点提示都没有。后来才明白，系统保留内存和后台应用占用的内存远比想象的多，可以实际用的不到一半。8GB机型老老实实用1.5B，12GB机型用3B，16GB机型才建议上7B。

另外要注意，Ollama加载模型需要预留比模型文件更大的内存空间，因为模型加载后还有KV Cache等运行时开销。经验值是模型文件大小的1.3到1.5倍。也就是说4.4GB的7B模型，加载时实际占用可能达到6GB左右。

5.2 检索质量相关

如果你发现回答经常跑题，先别怪大模型，先查检索结果是不是就有问题。我遇到最多的情况是：嵌入模型选错，中文分块太碎，或者查询向量和入库向量维度不一致。还有一个容易忽视的点，是上下文混入无关片段后，模型会被“带偏”，所以宁可少给片段，也不要给不相关的。

我的经验是，检索出来的片段如果相似度距离都大于0.8，大概率是没检索到相关内容，这时候应该直接回答“知识库未找到相关信息”，而不是硬着头皮穷举候选。

5.3 端侧运行稳定性相关

发热降频是最影响体验的。手机跑模型超过两三分钟，温度上来后SoC会自动降频，生成速度肉眼可见地变慢。建议一次问答控制在20秒以内，连续问答不超过10轮就停下来歇一会儿。如果你需要长时间用，可以考虑给手机加散热背夹，实测能把生成速度稳定在高位，降频现象明显减少。

另一个烦人的问题是锁屏杀后台。Ollama服务在Termux后台跑，锁屏一段时间可能被系统回收。解决办法是在Termux里使用termux-wake-lock保持唤醒：

bash复制# 保持Wake Lock，防止后台被杀
termux-wake-lock

同时在系统电池设置里把Termux设为“不受限制”，双管齐下，后台被杀的概率会大幅降低。

5.4 实测数据速查表

表格里的速度是我在室温25度、手机静置状态下的实测值，发热后普遍会掉两到三成。整体来说，最适合移动端日常使用的是1.5B和3B这两个档位。0.5B虽然快，但理解能力太弱，知识库问答经常答非所问；7B在手机上属于“能跑但勉强能玩”的状态，不推荐作为主力。

我自己折腾下来最满意的一套组合是Qwen2.5 1.5B做日常问答加bge-small-zh做知识库检索，速度快、发热少、还能应付大多数知识库问题。手机上的本地大模型并不是要替代云端大模型，它是在断网、隐私敏感、轻量查询这些场景下把体验兜住的一个方案。最后再分享一个小技巧：知识库的批量入库尽量在PC上完成，手机端只保留查询和生成，这个分工能帮你省掉九成麻烦。