ollama+DeepSeek+Docker+Dify：本地知识库部署实战-平芜编程栈

简介：这份资源面向希望本地搭建个人知识库的开发者与AI爱好者，围绕ollama、deepseek、docker与Dify四件套的协同部署展开，帮助读者理解搜索引擎框架、深度学习模型、容器化运行与知识库问答之间的配合关系，适合具备基础命令行操作能力、想动手实践本地大模型应用的中级学习者。压缩包内为1个doc文档，约5.19MB，以图文步骤形式记录从安装ollama、配置环境变量、下载deepseek-r1模型，到用docker-desktop启动Dify项目、创建知识库并接入ollama接口的完整流程，并附有分词配置、模型供应商设置与问答测试等关键环节的界面示意。已有3396人学习该资源，可作为搭建本地知识库时的对照参考，帮助读者理清各工具的安装顺序与接口衔接方式，减少环境配置与模型接入中的摸索成本。

1. 本地知识库这套组合拳：ollama 拉模型、Docker 跑 Dify、DeepSeek 接进工作流

很多人第一次听到「本地部署个人知识库」，脑子里浮现的是买显卡、装驱动、配 CUDA 的一整套硬仗。实际拆下来，这套 ollama + DeepSeek + Docker + Dify 的方案，门槛比想象中低不少：一台普通 Windows 机器，8GB 内存起步，跟着命令走，一两个小时能跑通一个能问答、能引用自己文档的聊天界面。它解决的核心问题很具体——你有一堆 PDF、笔记、内部文档，想让模型基于这些内容回答，而不是靠它自己瞎编。适合谁？想把资料变成可检索问答库的开发者、做课程设计的学生、需要给团队搭个内部知识助手但不想上云的人。这篇就按我实际拆包的顺序，从装 ollama 到 Dify 里接上知识库，把参数、命令和翻车点一次讲透。

2. 装 ollama 与拉 DeepSeek：环境变量和模型规格怎么定

ollama 在这套链路里扮演的是「本地模型运行时」的角色，它负责把 DeepSeek 这类模型下载到本地、加载进内存、对外暴露一个 HTTP 接口。Dify 本身不跑模型，它只是个应用层编排工具，真正干活的是 ollama 后面挂的那个模型。所以第一步必须先把 ollama 跑通，再谈知识库。

2.1 Windows 下安装与版本校验

去 ollama 官网下载 Windows 安装包，双击走完 Install 流程即可。装完别急着拉模型，先验证命令是否进了 PATH。按Win + R输入cmd打开命令行，执行：

ollama --version

正常会回一行版本号，比如ollama version is 0.x.x。如果提示「不是内部或外部命令」，说明安装时 PATH 没写进去，重装一次或者手动把 ollama 的安装目录加进系统环境变量。这一步看着废话，但我见过太多人卡在这里以为是安装失败，其实是终端没刷新环境变量，关掉 cmd 重开一次往往就好了。

2.2 环境变量：把模型挪出 C 盘

默认情况下 ollama 会把模型存在用户目录下，DeepSeek 的模型文件动辄几个 GB，C 盘紧张的人必须提前改。打开「编辑系统环境变量」→「环境变量」→ 新建系统变量，参数这样填：

变量名	变量值示例	说明
`OLLAMA_MODELS`	`D:\ollama\models`	模型存放目录，按自己硬盘改
`OLLAMA_HOST`	`0.0.0.0:11434`	监听地址，Dify 容器要访问时用得上
`OLLAMA_KEEP_ALIVE`	`24h`	模型驻留内存时长，避免频繁冷加载

OLLAMA_MODELS指向的目录要提前建好，路径里别带中文和空格，这是血泪经验——带空格的路径在某些版本的加载逻辑里会出玄学问题。OLLAMA_HOST设成0.0.0.0是为了让 Docker 容器内的 Dify 能通过宿主机地址访问到 ollama，只监听127.0.0.1的话容器里是够不着的。改完环境变量必须重启终端，甚至重启一次 ollama 服务，否则不生效。

2.3 拉取 DeepSeek 模型：1.5B 起步，别一上来就冲大杯

进 ollama 官网的 Models 页面，搜deepseek-r1，能看到从 1.5B 到 671B 的一串规格。选哪个不是看心情，是看内存。粗略的对应关系：1.5B 约需 2GB 内存，7B/8B 约需 8GB，14B 约需 16GB，32B 往上基本要有独立显卡才谈得上流畅。课程设计、个人笔记问答这种场景，1.5B 完全够用，先跑通链路比追求效果重要。

# 拉取并直接进入交互式对话，首次会自动下载模型 ollama run deepseek-r1:1.5b

回车后开始下载，1.5B 大概几百 MB 到 1GB 出头，几分钟能完；如果你手滑选了 32B，下载两三个小时是常态，中途断网还得重来。下载完成后会直接进入>>>提示符，随便问一句「你是谁」验证模型能出话。这个命令行窗口不要关，关掉 ollama 服务就停了，Dify 那边就接不上。后面如果关了，重新执行ollama run deepseek-r1:1.5b即可，模型已在本地，秒起。

提示：模型下载慢和网络环境有关，跟 ollama 本身没关系。可以先拉 1.5B 把整条链路验证通，再回头换大模型，别在下载环节耗掉半天耐心。

3. Docker 起 Dify：compose 文件、端口与容器网络

Dify 是这套方案里唯一需要「跑起来一个 Web 服务」的组件，官方推荐用 Docker Compose 部署，因为它依赖 PostgreSQL、Redis、向量数据库等一堆服务，手动装能把人逼疯。Docker Desktop 在 Windows 上把这堆东西打包成容器，一条命令拉起。

3.1 准备源码与 Docker Desktop

先把 Dify 源码拿到本地，有 git 就直接克隆，没有就下压缩包解压：

git clone https://github.com/langgenius/dify.git cd dify/docker

目录里会有一个.env.example，先复制成.env，这是 compose 读取的配置文件：

# Windows cmd 下用 copy，PowerShell 用 Copy-Item copy .env.example .env

然后装 Docker Desktop，官网下 Windows 版，安装时勾选 WSL2 后端（Win10/11 都支持），装完点 Close and restart，等托盘图标变绿说明引擎起来了。这里有个前置条件：WSL2 得先启用，否则 Docker Desktop 起不来，报错通常是「WSL kernel version too low」，按提示跑一次wsl --update即可。

3.2 docker-compose up 的参数与首次启动

在dify/docker目录下打开命令行（在资源管理器地址栏输入cmd回车最快），执行：

# -d 表示后台运行，首次会拉取镜像，耗时取决于网络 docker-compose up -d

首次执行会拉 postgres、redis、weaviate、api、web 等一堆镜像，几个 GB 的量，网络一般的话十几分钟到半小时。拉完后docker ps能看到一串容器在跑。这里最容易翻车的是端口冲突：Dify 默认 web 走 80 端口，如果你本机 IIS 或别的服务占了 80，容器起不来。改.env里的EXPOSE_NGINX_PORT，比如改成8080，然后docker-compose up -d重新拉起，访问地址就变成http://127.0.0.1:8080。

容器/服务	默认端口	作用
nginx（web）	80	前端入口，浏览器访问这个
api	5001	后端接口，容器内部通信
postgres	5432	元数据存储
redis	6379	缓存与队列
weaviate	8080	向量库，知识库检索靠它

启动完成后浏览器打开http://127.0.0.1/signin，第一次会让你设管理员账号，设完登录进主界面。如果页面打不开但容器都在跑，先docker-compose logs nginx看日志，八成是端口映射或镜像没拉全。

3.3 容器访问宿主机 ollama 的地址写法

这是整篇最容易卡住的一步。Dify 跑在容器里，容器里的127.0.0.1指的是容器自己，不是你的 Windows 宿主机，所以填http://127.0.0.1:11434必然连不上。正确写法是 Docker Desktop 提供的宿主机别名：

http://host.docker.internal:11434

前提是 ollama 的OLLAMA_HOST设成了0.0.0.0:11434，只监听回环地址的话这个别名也够不着。填完点保存，如果报连接失败，先在宿主机浏览器开http://127.0.0.1:11434看 ollama 是否在响应，再docker exec -it <dify-api容器名> curl http://host.docker.internal:11434从容器里测一次，两头都通才说明配置对。

4. Dify 里建知识库与工作流：分词、召回和模型接入

Dify 跑起来只是有了个空壳，真正让它变成「个人知识库」的是两件事：把文档灌进去做成向量索引，再把 DeepSeek 模型接进聊天应用并挂上这个知识库。

4.1 创建知识库与分段策略

主界面点「知识库」→「创建知识库」，上传你的 PDF、Markdown、TXT。上传后进入分段设置，Dify 默认给的是通用分段，参数大致是：

参数	默认值	调整建议
分段标识符	`\n\n`	结构化文档可改`\n`或按标题
最大分段长度	500 tokens	笔记类可降到 300，长文档可升到 800
分段重叠	50 tokens	保持 10% 左右，避免切断语义

分段长度不是越大越好。设太大，检索时召回一大段无关内容，模型容易被带偏；设太小，一句话被切碎，上下文丢失。我一般先用默认值跑一遍，看解析出来的分段预览，如果发现一个完整段落被拦腰截断，就调大重叠或换标识符。保存后等索引完成，状态变「可用」才算好，解析时间跟文档量和机器配置有关，几十页 PDF 几分钟正常。

4.2 接入 ollama 模型供应商

回到「设置」→「模型供应商」，往下找到 Ollama，点「添加模型」。这里要填两样：模型名称和基础 URL。模型名称必须和ollama list里显示的一模一样，比如deepseek-r1:1.5b，少个 tag 就认不到。基础 URL 填上一节说的http://host.docker.internal:11434。

# 在宿主机确认模型名和运行状态 ollama list # 输出示例：deepseek-r1:1.5b xxxxxxxx 1.1 GB

添加成功后，供应商列表顶部会出现这个模型。如果添加时提示「模型不存在」，先确认 ollama 命令行窗口还开着、ollama list能列出模型，再检查 URL 末尾有没有多写斜杠。模型参数（temperature、top_p）可以在模型配置里调，知识库问答场景建议 temperature 压到 0.3 以下，减少自由发挥。

4.3 工作流里挂知识库做上下文增强

点「工作流」→「创建空白应用」→ 选「聊天机器人」，起个名字创建。进入编排界面后，在「上下文」旁边点添加，选中刚建的知识库。这样每次提问，Dify 会先拿问题去向量库检索相关分段，拼进 prompt 再交给 DeepSeek。

测试时问一个只有你文档里才有的细节，比如「XX 项目的验收标准第三条是什么」，看回答下方有没有引用来源。有引用且内容对得上，说明检索链路通了；如果模型答得泛泛而谈、没有引用，多半是知识库没挂上或者分段没索引完。这一步是整个方案的价值所在——模型不再靠记忆瞎编，而是基于你喂进去的资料作答。

5. 避坑排查：五个真实翻车现场

5.1 容器里连不上 ollama，报 connection refused

现象：Dify 添加 Ollama 模型时一直失败，日志里是connection refused。原因：ollama 只监听了127.0.0.1，容器通过host.docker.internal访问不到。解决：把OLLAMA_HOST改成0.0.0.0:11434，重启 ollama 服务，再从容器内curl验证一次。

5.2 知识库上传后一直「索引中」

现象：文档传上去半天状态不变，聊天时检索不到内容。原因：向量库容器没起全，或者 embedding 模型没配。Dify 建知识库需要 embedding 模型，默认可能走外部 API，本地部署得在模型供应商里配一个本地 embedding，比如 ollama 拉的nomic-embed-text。解决：先docker ps确认 weaviate 在跑，再在知识库设置里把 embedding 模型指到本地那个。

5.3 80 端口被占，Dify 页面打不开

现象：docker-compose up -d成功，但浏览器访问127.0.0.1是别的页面或 404。原因：本机已有服务占用 80。解决：改.env的EXPOSE_NGINX_PORT=8080，重新 up，访问带端口号。改完记得docker-compose down再 up，光 restart 有时不重新读端口映射。

5.4 模型下载到一半断了，重跑又从零开始

现象：拉 7B 以上模型时断网，重新ollama run进度归零。原因：ollama 的下载分片机制对断点续传支持有限，大文件容易前功尽弃。解决：先拉小模型验证链路，大模型挑网络稳定的时段拉；已经下了一半的，去OLLAMA_MODELS目录看残留文件，必要时清掉重来，别在残缺文件上反复重试。

5.5 回答不引用知识库，模型自由发挥

现象：明明挂了知识库，回答却像没看过文档。原因：分段太长导致检索命中率低，或者 temperature 太高。解决：把最大分段长度降到 300～500，重叠保持 10%，temperature 压到 0.3 以下；再在检索设置里把「召回数量」从默认调到 3～5，让更多相关分段进上下文。

6. 进阶：用 API 把知识库接进自己的程序

Dify 的网页界面适合验证，但真正落地往往要把这套问答能力嵌进自己的工具里。Dify 每个应用都暴露了 API，在应用「访问 API」页面能拿到密钥和接口地址，用 Python 调一下就能把「本地知识库 + DeepSeek」变成你脚本里的一个函数。

import requests API_KEY = "app-xxxxxxxx" # Dify 应用 API 密钥 BASE_URL = "http://127.0.0.1/v1/chat-messages" def ask_kb(question: str, user_id: str = "local-user"): headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } payload = { "inputs": {}, "query": question, "response_mode": "blocking", # 阻塞式，等完整回答 "user": user_id, "conversation_id": "", # 空表示新会话 } resp = requests.post(BASE_URL, headers=headers, json=payload, timeout=120) resp.raise_for_status() return resp.json()["answer"] if __name__ == "__main__": print(ask_kb("根据知识库，验收标准第三条是什么？"))

这段代码的关键在三个参数：response_mode用blocking适合脚本一次性拿结果，要流式输出就改streaming并逐行读 SSE；conversation_id传空开新会话，传上次返回的 id 就能多轮对话；timeout给足，1.5B 模型在普通机器上答长问题十几秒很正常，超时设太短会误判失败。API 地址里的端口要跟你.env里配的 nginx 端口一致，改过 8080 的话这里也得跟着改。

验证方法很简单：先用网页界面问同一个问题，确认回答和引用正常，再用脚本问一遍，两边答案一致说明 API 链路没问题。如果脚本报 401，检查密钥有没有复制全；报 404，检查 BASE_URL 路径是不是/v1/chat-messages，少一段都通不了。

从那以后我每次搭这类本地知识库，都强制自己先用 1.5B 小模型把「ollama 起服务 → Docker 起 Dify → 容器连宿主机 → 知识库索引 → API 调通」这五步走一遍，全绿了再换大模型、灌正式文档。因为链路问题和小模型大模型无关，先跑通再谈效果，能省掉大量「到底是模型不行还是配置不对」的自我怀疑。希望帮到你。

本文还有配套的精品资源，点击获取