01 先说那个不敢上传的文件夹

每个做技术的人手里都有几个这种文件夹：客户名单、内部接口文档、家里的证件扫描件、写了半年的日记。

放云端 NotebookLM 很方便，但那几个文件夹，你不敢拖进去。AI 联网服务再怎么承诺加密，文件一上传就离开了你的硬盘，这件事本身没有回头路。

所以真正的问题是：能不能在断网的状态下，让 AI 回答你文件夹里的问题。

答案是可以，而且不需要买显卡。这篇是我在这台 8 线程的 Intel 笔记本上，把一套「不联网知识库」从零跑通的全过程，每一步都带数字。

02 整套东西只有三层

先把架构说清楚，后面所有实测都按这三层走：

• 推理层：读你的资料、写回答。本文用 llama.cpp（132,940 星 / MIT / C++），最新构建 b12020，版本号 0.8.0-dev；
• 向量层：把文档变成数字，好让"意思相近"能被算出来。本文用 nomic-embed-text-v1.5 的 Q4_K_M 量化版，84,106,624 字节；
• 界面层：拖文件进去、像聊天一样提问。本文用 SurfSense（16,692 星 / Apache-2.0 / v2.2.5），一个自称"可物理隔离运行的开源 NotebookLM 替代品"。

为什么推理层选 llama.cpp 而不是 Ollama？Ollama 底下跑的就是 llama.cpp，多包了一层服务和管理界面；LM Studio 是闭源 GUI。裸引擎的好处是你知道每一个字节从哪来，而且它的 Windows 预编译包只有 24MB，解压就能跑。

图片说明：一个 24MB 的压缩包里，14 个 CPU 后端在等你的 CPU 自报家门。

03 装：24MB 拆开看

从 Releases 下载 llama-b12020-bin-win-cpu-x64.zip，24,574,627 字节，解压后 52 个条目、60.6 MB：22 个 exe、29 个 dll，外加一份 LLVM 的 OpenMP 许可证。最大的单文件是 llama-connect.exe，10.9 MB。

图片说明：24MB 的压缩包里带 14 个 CPU 指令集后端，程序启动时自己挑一个。

最有意思的是那 14 个 ggml-cpu-*.dll：sse42、sandybridge、ivybridge、haswell、skylakex、cascadelake、icelake、alderlake、zen4……同一个计算核心，按 CPU 指令集编译了 14 遍。启动时程序自己挑一个，本机日志里写的是 loaded CPU backend from ggml-cpu-icelake.dll，我没有指定过任何参数。

想用显卡就得换 CUDA 包：主包 279,944,190 字节，外加一个 cudart 包 391,443,627 字节，合计比 CPU 版大 27 倍。没有 N 卡的话，CPU 版就是全部。

04 实测一：检索这层

先说结论：这一层完全成立，但中文的准确率没有想象中高。

llama.cpp 的包里没有单独的嵌入工具，嵌入由 llama-server 提供，加一个 --embedding 参数，它就只开放向量接口。把 nomic 模型喂给它，请求 200 段中文文本，实测 6.40 秒算完，平均每秒 31.3 段，每段输出一个 768 维的浮点数组。

图片说明：200 段中文建库 6.4 秒，进程全程只有一条本地监听连接。

「不联网」这句宣传是可以验证的。我用 psutil 数了这个进程的全部网络连接：1 条，LISTEN 127.0.0.1:8101，连向外部 IP 的是 0 条。所有计算都在内存里完成，一个字节都没出去。

然后是最关键的问题：检索准不准。我写了 10 条互不相同的知识入库，出了 5 个问题，用余弦相似度排序：

• Top1 命中 3 次，Top3 命中 5 次；
• nomic 官方要求入库加 search_document:、查询加 search_query: 前缀，但在中文上实测加与不加，命中率都是 3/5；
• 真正兜住准确率的，是取前三段一起喂给模型，不是前缀。

整个脚本只有三步：文本切块、调 /v1/embeddings 拿向量、算余弦排序。没有数据库，没有框架，向量直接存成 Python 列表，10 条知识 5 个问题秒出结果。

一个 10 条知识的小库尚且如此，几百段真实文档更得靠 Top3 兜底。这一步如果你只想验证可行性，100 行 Python 就够了，不必急着上重型框架。

图片说明：Top1 命中 3 次，Top3 命中 5 次，加不加官方前缀结果一样。

05 实测二：喂资料前后，模型判若两人

我用 Qwen2.5 的 0.5B 和 1.5B 两个量化模型做了同一组对照，问题是一个只有资料里才有答案的细节：某个 zip 文件有多少字节。

不给资料时，两个模型都编，且编的方向完全不同：0.5B 说预编译包是"用于编译和链接的预编译代码"，1.5B 说"一般在几十 KB 到几百 KB 之间"。语气都很自信。换一个更日常的问题，0.5B 甚至把 RAG 解释成了"React Native App 的缩写"。

把检索到的三段资料塞进上下文之后，两个模型都一字不差地答出了 24574627 字节。0.5B 用了 38.5 t/s，1.5B 用了 17.6 t/s。

llama-bench 的标准数据更能说明取舍（8 线程 CPU）：

pp 是读资料，tg 是逐字生成。知识库场景里读资料是大头，而回答往往就几十个字，所以 0.5B 的体验反而更好：加载 3.5 秒、常驻内存 495.7 MiB、一次问答 0.75 秒。

图片说明：8 线程纯 CPU 上两个模型的 llama-bench 成绩。

图片说明：同一问题，不喂资料时两个模型各编各的，喂了资料都答对。

06 最后一块：把界面接上去

到这一步，底座是两个命令行服务。要让它变成"知识库"，还差一个能拖文件的界面。

SurfSense 的 README 里有一句关键的话，是它在对比 NotebookLM 时写的：模型支持「任意兼容 OpenAI 的 API，或本地模型」，文档「不会离开你的电脑，除非你选择远程模型」。而 llama-server 起的恰好就是 OpenAI 兼容服务，本机实测 /v1/chat/completions 正常返回答案。

也就是说，把 http://127.0.0.1:8080/v1 填进去，理论上就是一条完全不出网的链路。

图片说明：三层拼起来才是完整的不联网知识库，界面层的对接判断来自接口契约。

但要如实说明：SurfSense 依赖 PostgreSQL 加 pgvector 和一层前端构建，这篇没有真把它部署起来，对接判断来自接口契约和仓库取证，不是端到端实测。它能吞的格式不少：PDF（含扫描页 OCR，认中文）、Word、Excel、PowerPoint、CSV、图像、Markdown，还有录音转写。它有 10 个官方插件（网页抓取、YouTube、Reddit 这些），那部分需要许可证，14 天免费。

07 什么时候别用它

• 要写长文别用。纯 CPU 逐字生成 17~39 t/s，写一篇 800 字回答要等半分钟以上，体验远不如云端；
• 要强推理别用。0.5B 连 RAG 是什么都说不清，1.5B 也只是勉强能照抄资料。本地小模型的价值是"照着材料说"，不是"替你想"；
• 对检索精度要求高就别只靠向量。中文 Top1 命中 3/5 是实测结果，必须配 Top3、关键词过滤或重排；
• 没有 N 卡又想加速，别下 CUDA 包，671MB 装完还是跑不起来，CPU 版反而更省事；
• 只想验证可行性，别直接上 SurfSense。PostgreSQL 加 pgvector 的部署成本，够你先写 100 行脚本跑通全流程了。

总结评价

推荐指数：⭐⭐⭐⭐☆（扣一星：纯 CPU 的中文生成质量还撑不起"直接出答案"，得靠资料喂）

一句话：llama.cpp 是本地 AI 的地基，24MB、免安装、MIT，检索和生成两层都能在这台笔记本上真跑通。

适用人群：手里有不敢上传的文档、能接受 20 t/s 生成速度、愿意写百来行脚本的人。

不适用人群：想要开箱即用图形界面的、需要强推理能力的、以及指望它在纯 CPU 上复现云端体验的。

阅读原文：点击这里​