ollama本地部署知识库需要联网吗

很多人搭本地知识库就是为了数据不出内网，结果发现装的时候要联网、拉模型要联网，就以为整套东西都离不开网。其实联网和离线是分环节的：有的环节只在第一次碰网，有的环节每次都要碰，还有的环节本来可以永久断网。这篇按搭建顺序把每个环节过一遍，告诉你哪些能提前缓存、哪些必须留一条外网通道、什么情况下断网方案根本不成立。

很多人搭本地知识库的出发点就是数据不出内网，结果一上手发现装的时候要联网、拉模型又要联网，心态直接崩了，以为整套东西根本离不开网。其实问题出在把「联网」当成一个整体来判断了——真实情况是分环节的。有的环节只在第一次碰一下外网，之后再也不需要；有的环节每次提问都在偷偷联网；还有的环节本来可以永久断网，只是被默认配置带偏了。

这篇按搭建顺序把每个环节过一遍：装本体、拉模型、跑推理、做检索、喂文档、长期更新，逐段告诉你哪些能提前缓存、哪些必须留一条外网通道、什么情况下断网方案压根不成立。判断原则很简单：先问自己「这个动作多久发生一次」，一次性的可以忍，每天发生的就得另想办法。

先把「联网」拆成四个环节，别整段判断

把整个知识库拆成四段来看，联网需求会清楚很多。第一段是装本体和依赖，第二段是拉模型权重和嵌入模型，第三段是真正的推理与检索，第四段是文档喂料和后续更新。每一段的联网频率和性质都不一样，混在一起谈就没法做决策。

判断原则就是看动作频率：一次性动作（装机、拉模型）允许临时开一次外网，周期性动作（换模型、补文档）预留一台中转机，每次动作（提问、检索）必须保证完全离线。这样拆完，你会发现真正麻烦的只有第一、第二段。

安装环节：怎么把首次联网的需求压缩到最小

安装本体这一步的联网需求其实很小，但很多人栽在准备不足上：在目标机上边装边下依赖，网络一抖就失败，重来又是半小时。正确做法是在能联网的机器上把安装包、运行时依赖、模型权重一次性备齐，打完包再搬到目标机。

1. 在联网机准备整包把安装脚本、依赖包、模型文件放在同一个目录，记录清楚每一项的来源和用途，方便目标机核对。
2. 规划模型落盘位置Linux 下模型默认落盘位置常常在小容量系统盘上，提前用环境变量把它指向数据盘，避免搬完发现盘不够用还要重来。
3. 目标机离线导入Windows 和内网机建议走离线导入的方式把模型塞进去，具体导入流程到 /guides 里找离线导入相关内容核对。
4. 验证进程能起不急着测问答，先确认服务能正常启动、能列出已加载的模型，这一步过了再往下走。

拉模型环节：联网需求最大，但可以提前搬

模型权重体积通常远大于安装包，这是离线方案里最费事的一步，也是最容易被低估的一步。好消息是它完全可以提前搬：在外网机器上把模型拉好，再把整个模型目录拷到内网机的对应路径下，服务就能认到。路径规则和目录结构可以到 /models 里核对，别自己猜目录名。

• 对话模型、嵌入模型、重排模型三样要一起备，只备对话模型会导致检索环节直接失败；
• 外网机拉模型时注意磁盘空间，模型目录往往比你想的占地方；
• 拷贝时保持目录层级不变，改名或乱放可能让服务找不到；
• 搬完在目标机上列一次模型清单，确认每一项都能被识别；
• 换模型或换仓库来源时要重新备一次，旧目录拷过去不一定拉得起来。

这里有个容易踩的坑：嵌入模型和重排模型不在「主模型」概念里，很多人以为拉完对话模型就完事了，结果问答跑起来检索环节报错，回头才发现少备了两个。备之前先列一张模型清单，逐个打勾。

跑起来之后：哪些默认联网、哪些默认不联网

模型就位后，本地推理本身走的是本机端口，正常情况下不依赖外网，这也是本地部署最大的价值。但「默认不联网」不等于「保证不联网」，有几处例外要盯：程序启动时的版本检查、崩溃上报、插件或界面组件加载的远程资源和字体。这些不一定会导致主功能挂掉，但会在断网时冒出一堆报错，让人误判成整套不可用。

本机端口推理

走 127.0.0.1 或内网地址，不经过外网，这是默认行为

版本检查

启动时可能会去查询新版本，断网后只是提示失败，不影响推理

崩溃上报

出问题时可能尝试上报，纯内网环境建议直接关掉

前端远程资源

界面用的字体、图标有时走 CDN，断网后界面会残缺

验证方法很直接：拔掉网线或关掉出口，重跑一遍问答。如果整体还能用、只有个别功能报错，说明核心链路是离线的；如果直接不能用，说明某个关键组件还依赖外网，去排查是嵌入还是向量库出的问题。

检索与嵌入：最容易被忽略的联网点

这是最容易翻车的地方：如果嵌入模型走的是云端接口，那知识库每次提问都要联网，这跟本地部署的初衷直接冲突——你数据是没出去，但每次提问的文本都发出去了。真正的离线方案必须是本地嵌入加本地重排加本地向量库，三样都在本机跑。

什么情况下这个结论不适用？文档量很小、更新极少、查询主要是关键词命中的场景，用关键词检索替掉向量检索也能凑合跑，代价是语义匹配效果打折，问法一变就找不到。这种场景下可以接受，但别把它当成通用方案。

知识库喂料：文档从哪来，决定了要不要联网

喂料环节要不要联网，跟你知识库本身没关系，跟文档从哪来有关系。文档本来就在内网文件服务器上，这一步可以完全离线；文档在网盘、在线文档、邮件系统里，取文档这一步就得联网或者走内网代理。扫描件、图片类资料要 OCR 时，优先挑本地能跑的工具，别默认调用云端识别接口。

• 列一张数据来源清单，逐个标注是内网还是外网；
• 来源是外网的，单独走一台中转机取件，别让生产机直连；
• OCR 优先选本地工具，云端识别会把图片内容送出去；
• 文档更新频率高的，把取件流程做成脚本，减少人工联网操作。

这张数据来源清单比任何结论都实用。别人问你「你这套能断网跑吗」，你把表一摊，哪些环节要开网、开多久，一目了然，也方便后面做合规说明。

长期维护：把「必须联网」和「可以离线」定成规矩

一次性动作和周期性动作要分开管理。装机、首次拉模型属于一次性，允许临时开一次外网；换模型、补文档属于周期性，预留一台中转机专门搬运；提问、检索属于每次动作，必须保证离线。这三类混着管，早晚会有人在生产机上随手开个外网。

1. 给动作分类把团队里所有涉及外网的动作列出来，逐个归类成一次性、周期性、每次，写进文档。
2. 设中转机中转机只做搬运，不接生产数据，外网接触面越小越好，搬完的东西先落地再拷进内网。
3. 设网速与连通性基线定期用站内工具跑一次连通性测试，具体测试项到 /tools/speed-test 看当时的数字，确认外网通道正常。
4. 留离线兜底完全不允许碰外网的环境，只能靠离线介质导入，模型和文档更新频率会明显变慢，提前接受这个代价。

不适用的情况要说清楚：合规上完全不允许任何外网接触时，前面那套「临时开一次网」的做法就不成立了，只能全程离线介质搬运，更新节奏也会被拖慢。这不是技术问题，是流程代价，方案设计时就得把这段留出来。

上手前的一张判断清单

动手前把下面几条过一遍，能省掉大部分返工。这张清单不保证你的方案一定离线，但能保证你不会在踩坑之后才发现自己漏了哪一步。

• 目标机能不能临时接一次外网？能——方案简单很多；不能——提前准备离线介质和搬运流程；
• 对话模型、嵌入模型、重排模型三样是否都备齐？漏一样就会在检索环节报错；
• 文档是否全部在内网可访问？有外网来源的要单独标注出来；
• 向量库和重排是不是都跑在本地？只要有一个走云端，每次提问都在联网；
• 断网测试是否做过一遍？没做过就不算验证过。

本地部署不等于开箱离线，能不能断网跑，取决于你把每一个联网点都标出来没有。