★ FEATURED ARTICLE 简介面向有意搭建个人知识库的技术爱好者这份部署教程系统整合了 Ollama、DeepSeek、Docker 与 Dify 四个工具从安装到联调的全过程。资源仅包含 1 个 doc 文档压缩包约 5.19MB教程以 Windows 10 WSL 环境为实例覆盖 Ollama 官网下载与环境变量配置、DeepSeek-R1 模型命令行拉取、Docker Desktop 部署 Dify 项目、浏览器端创建知识库、接入 Ollama 端口并完成问答测试等关键步骤每一步均配有操作示意图和必敲命令可直接跟随执行。当前已有 3389 人学习下载适合具备基础命令行操作经验、希望将本地大模型与个人文档检索相结合的读者。教程还补充了模型存放路径设置、解析耗时差异、Ollama 后台保持运行等易错点能帮助使用者减少盲目尝试整体是一份可直接跟做的实操笔记能让读者从零完成私有知识库的搭建获得一套完整可复用的本地部署方法。1. Ollama DeepSeek Dify 自建知识库这套组合到底解决了什么很多人第一次听到「本地知识库」这个词以为把文档丢进一个文件夹、再装一个聊天框就是全部。真正跑过一遍才知道最卡脖子的不是模型而是「外部文档如何进入模型」这条链路。Ollama 负责把 DeepSeek 模型在本地跑起来Docker 把 Dify 这套包含数据库、向量检索、模型网关的复杂系统编排落地三者一组合你丢进去的 PDF、Word、Markdown 会被切块、向量化、存入数据库每次提问时被检索出来作为上下文喂给模型。这套方案适合不想把私有数据传到云端、又希望尽快出效果的个人开发者和中小团队整条链路完全跑在自己的机器上。下面我把从零搭建的每一步、每个参数和每道坑都讲清楚。2. 先把底座立住Ollama 运行 DeepSeek 的选型、安装与参数2.1 为什么选 Ollama 托管 DeepSeek而不是直接跑 Python 推理脚本不选裸跑 Python 推理主要是三个原因。第一是显存管理Ollama 支持按需加载模型空闲时自动释放显存多个模型切换不用手动清理这对 6G 到 8G 显存的个人电脑很关键。第二是 API 兼容它默认暴露 OpenAI 风格的/v1/chat/completions接口Dify 这类平台只需要填一个 base_url 就能接入不需要自己写推理适配层。第三是模型文件管理Ollama 用分层文件管理不同量化版本想换 GGUF 的 q4 或 q8 只需拉对应 tag磁盘占用一目了然。Ollama 当然不是没有短板。显存不足时它会回退到 CPU 推理速度断崖式下降体验很难受并发请求的处理能力也有限多人同时提问会出现排队。但作为本地知识库的底座单人单机场景完全够用。Dify 官方目前也把 Ollama 列为最常用的本地模型方案社区里丰富的教程和排错经验本身就是一种保障。2.2 Ollama 安装与拉取 DeepSeek 模型的最小命令安装 Ollama 在 Linux 上最快的方式是官方脚本Windows 和 macOS 也都有对应安装包。这里以 Ubuntu 22.04 为例# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 验证安装并查看版本 ollama --version # 拉取 DeepSeek 的 7B 量化模型q4_K_M 是默认量化档 ollama pull deepseek-r1:7b # 确认模型已就绪 ollama list逻辑说明curl 安装脚本会顺手配置 systemd 服务让 Ollama 常驻后台运行这样 Dify 随时可以调用。ollama pull根据标签从模型仓库下载分层文件deepseek-r1:7b 这个 tag 默认对应约 4.7GB 的 q4_K_M 量化文件。ollama list可以看到本地已有模型的名称、标签和体积。参数说明显存只有 6G 的话建议就拉 7b 的 q4_K_M显存 12G 以上可以尝试 14b 版本。我的习惯是先用 7b 把整条链路跑通确认 Dify、知识库、检索都正常工作之后再根据回答质量决定是否换更大的模型。一上来就跑大模型出问题你分不清是模型的问题还是链路的毛病。# 启动一个带上下文长度限制的模型会话--num-ctx 覆盖默认 2048 ollama run deepseek-r1:7b --num-ctx 8192--num-ctx控制上下文窗口默认 2048 对知识库场景太小检索到的文档片段加上对话历史很容易就撑爆建议至少 4096。每次手动传参容易忘更可靠的做法是写一个 Modelfile 把参数固化进模型FROM deepseek-r1:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.5# 生成带自定义参数的新模型 ollama create deepseek-r1-ctx8k -f Modelfile逻辑说明Modelfile 的格式与 Dockerfile 类似FROM指定基础模型PARAMETER行写入运行参数。ollama create会生成一个新模型名之后 Dify 里配置模型时直接填deepseek-r1-ctx8k不用每次手动指定参数。2.3 量化级别、上下文长度和显存的关系三个必调参数第一个必调参数是量化级别。q4_K_M 是体积和质量的平衡点q8_0 更接近原版精度但体积几乎翻倍7B 模型大概要多占 3G 磁盘和显存。我一般先用 q4_K_M 验证效果如果确实感觉回答质量被精度拖累优先换更大的模型参数量而不是盲目上高精度量化——量化精度带来的收益远小于模型规模带来的收益。第二个必调参数是上下文长度。知识库场景里检索结果动辄几千 token 输入加上对话历史2048 的默认窗口什么都干不了。但调大 num_ctx 不只是改一个数字7B 模型在 8192 上下文下大约额外多占 2G 显存显存不够会被挤出到 CPU速度直接崩。想验证就开个系统监控工具一边提问一边看显存和内存曲线。第三个必调参数是温度 temperature。知识库问答时温度太高模型会把检索到的内容改得面目全非调到 0.3 到 0.5模型更愿意贴着原文说话。在 Dify 的模型设置里可以按应用覆盖也可以在 Ollama 层固化我倾向后者因为这样不会因为换应用忘记重新配置。提示先跑默认参数把链路打通再回头调这三个参数。一次只改一个用同一个问题反复试不然你不知道是哪个改动影响了回答质量。3. 用 Docker Compose 编排 Dify依赖关系、配置修改与启动验证3.1 Dify 不是单个容器而是一组服务的协作Dify 采用微服务架构独立部署时至少包含这些组件API 服务后端接口、Web 前端、Worker处理文档切块和向量化的异步任务、PostgreSQL存应用配置和对话记录、Redis缓存和队列、向量数据库Weaviate 或 Qdrant存文档向量以及 Nginx反向代理。打开官方仓库的 docker-compose.yaml你会发现十几个 service 整整齐齐排在那里。第一次看到这套架构的人容易犯一个错以为 Dify 是一体化容器结果打开 compose 文件直接懵了。你不需要理解每个服务的内部实现但必须清楚数据流向文档上传后由 Worker 异步切块和向量化向量写进向量数据库用户提问时API 服务从向量库检索相关片段拼进上下文再调用 Ollama 的 DeepSeek 生成回答。这条链路刻在脑子里后面排查问题就能按图索骥。Dify 官方仓库同时提供了 docker 目录里面有 .env.example 和 docker-compose.yaml这是目前最可靠的部署入口。不建议自己从头写 compose官方模板把环境变量、容器间网络、数据卷挂载都对齐了自己拼装容易在版本兼容上花掉大量不必要的排查时间。3.2 修改 .env 与 docker-compose.yaml最小可运行配置拿到官方 docker 目录后第一步是拷贝环境变量模板并修改关键配置# 进入 Dify 的 docker 目录 cd dify/docker # 复制环境变量模板 cp .env.example .env # 生成一个随机的 SECRET_KEY openssl rand -base64 42.env 里必须改的字段是SECRET_KEY它用来加密会话和用户数据。如果沿用默认值你的知识库应用在局域网里几乎是裸奔状态。把openssl rand -base64 42生成的字符串填进去注意别带换行符。另一个要确认的是向量数据库类型。新版 Dify 默认使用 Weaviate也可以换成 Qdrant二者在 .env 里通过VECTOR_STORE字段切换。首次部署建议就用默认值不要同时配置两个避免数据写入的路径混乱。端口冲突是个人机器上最常见的问题。下面这段 docker-compose.yaml 片段演示如何修改 Web 服务对外端口services: nginx: image: nginx:latest ports: - 8080:80 # 宿主机 8080 映射到容器 80避免占用系统 80 端口 volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf逻辑说明compose 里 ports 的格式是「宿主机端口:容器端口」。容器内部 80 端口是 Dify 前端服务固定监听的不必改要调整的是宿主机一侧。改成 8080 后访问地址从 http://localhost 变成 http://localhost:8080。如果 8080 也被占用继续换 18000 之类的端口。首次启动前我习惯先在宿主机上检查端口占用# 检查 80、5432、6379 等常用端口是否被占用 ss -tlnp | grep -E :(80|5432|6379|8000)\s # 启动所有服务先拉镜像再后台运行 docker compose up -d # 查看各服务运行状态 docker compose ps逻辑说明ss命令先排除本地端口冲突docker compose up -d会拉取镜像并以后台模式启动全部容器docker compose ps显示每个服务的运行状态正常都应该是 Up。3.3 首次启动后的验证与日志排查启动后浏览器访问 http://localhost:8080应该能看到 Dify 的初始化设置页面。首次访问会让你设置管理员邮箱和密码这是本地实例的管理员账号务必用强密码。初始化完成后进入控制台首页看到仪表盘数据说明整体服务已经起来了。如果页面打不开优先看 Nginx 和 API 两个容器的日志# 查看 Nginx 容器日志 docker compose logs nginx --tail 100 # 查看 API 容器日志 docker compose logs api --tail 200最常见的情况是 API 容器在等待数据库初始化PostgreSQL 首次启动需要几十秒甚至更久日志里反复报连接数据库失败时不要慌等两分钟刷新页面。如果长时间仍然报错手动连接 PostgreSQL 验证一下docker compose exec postgres psql -U postgres -c select 1;逻辑说明这条命令直接进入 postgres 容器执行select 1能返回结果说明数据库本身没问题问题在 API 容器与数据库之间的网络或配置。正常情况下 Dify 会创建独立的数据库实例名字在 .env 里的POSTGRES_DB字段指定默认是 dify。提示不要在同一台机器上同时启动两个 docker compose 项目它们的网络和数据卷会互相干扰这是很多人改了配置却不起作用的隐藏原因。4. 打通 Dify 与 Ollama模型注册、知识库创建与最小链路验证4.1 在 Dify 中把 Ollama 注册为模型供应商进入 Dify 控制台点右上角头像进入「设置」在「模型供应商」页面找到 Ollama 并点击添加。这里涉及三个关键配置模型名称必须与本地ollama list显示的完全一致Base URL 填 Ollama 的访问地址模型类型选择「对话」而不是「文本生成」。如果 Dify 跑在 Docker 容器里而 Ollama 在宿主机上这里有一个最容易踩的坑容器里的localhost指向容器自己不是宿主机。Dify 的 API 容器访问 Ollama 时需要把 Base URL 写成宿主机的局域网 IP 或者 Docker 网关地址而不是http://localhost:11434。在 Linux 上用ip addr就能查到局域网 IP。{ model_name: deepseek-r1:7b, base_url: http://192.168.1.100:11434, api_key: ollama, model_type: chat }逻辑说明Dify 接入 OpenAI 兼容接口时api_key字段是必填项Ollama 本身不做鉴权任意字符串都能通过校验。base_url一定不要带/v1后缀Dify 会在内部自动拼接/v1/chat/completions填错会报 404。参数说明如果你改了 Ollama 的默认端口base_url 也要同步改。默认情况下 Ollama 只监听本机 11434 端口Dify 容器要跨主机访问的话还需要在 Ollama 的 systemd 服务配置文件里加上OLLAMA_HOST0.0.0.0否则外部容器根本连不上。改完记得systemctl restart ollama。4.2 创建知识库并正确设置分段和索引方式知识库的创建入口在 Dify 控制台的「知识库」页面支持上传 PDF、Markdown、Word、TXT 等格式也可以连接 Notion 这类外部数据源。个人知识库场景下直接上传文件即可。上传之后最关键的步骤是设置分段规则。Dify 默认按固定 token 数切块比如 500 token 一块。这个默认值对中文文档不太友好中文的 token 密度和标点习惯跟英文不同固定 500 的切法经常把一句话从中间砍断。实际操作中我建议选择「自定义」分段按换行符作为分隔符每块控制在 250 到 500 token 之间。分段设置完成后 Dify 会用配置好的 embedding 模型把每块转成向量存入向量数据库。这里有一个先决条件embedding 模型必须先配好。Dify 支持多种 embedding 接入本地环境通常选 Ollama 提供的嵌入式模型比如nomic-embed-text或者直接用 Dify 支持的本地向量模型。没配 embedding 模型文档传上去会一直卡在「待索引」状态没有任何报错提示排查起来很费劲。注意知识库的检索质量上限在分段的语义完整性上。一份代码文件如果按固定 token 硬切函数定义和函数体被拆进不同块后续检索到的片段大概率语义残缺模型回答自然跟着错。4.3 搭建一个最小聊天助手验证「文档 → 检索 → 生成」链路在 Dify 控制台点击「创建应用」选择「聊天助手」类型然后按顺序完成三件事第一在模型选择里把对话模型切成刚注册的 Ollama DeepSeek第二在「上下文」区关联刚建好的知识库第三打开调试对话面板问一句「这个知识库里有哪些内容」。如果调试时接口直接报错先不要怀疑 Dify在宿主机上用 curl 测一下 Ollama 本身# 直接在宿主机测试 Ollama 是否正常响应 curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d {model: deepseek-r1:7b, messages: [{role: user, content: 你好}]}逻辑说明这条 curl 如果正常返回模型回复说明 Ollama 和模型本身没问题问题出在 Dify 的模型配置或知识库链路。如果没有返回先排查 Ollama 是否启动、模型是否拉取完整。链路验证通过后上传一份只有你自己知道内容的文档注意不要用网上到处都能搜到的公开资料。比如上传一份项目排期表然后问表里某个具体日期。如果回答里没有这个日期别急着怪模型——大概率是知识库检索环节没把内容喂给模型回到调试面板看「引用与归属」里有没有列出文档片段。没有引用片段就说明检索链路是断的问题不在生成模型。5. 避坑指南本地知识库部署中最常见的 5 个翻车现场5.1 现象Ollama 拉取模型一直卡在 waiting 或直接超时原因模型仓库的下载服务器有时不稳定加上模型文件动辄几个 GB拉取过程中容易卡死。解决先确认磁盘空间是否充足df -h看一下根分区剩余空间至少留出模型体积两倍以上的余量。如果空间足够把OLLAMA_MODELS环境变量指向有足够空间的磁盘目录然后重新执行ollama pull。拉取中断后下次执行会基于已下载的分层文件断点续传不用清空重来。如果网络条件确实差换个时段再拉是实测最有效的笨办法凌晨成功率明显更高。5.2 现象docker compose up -d 之后几个容器反复重启或直接 Exited原因两个主要来源。一是宿主机端口被占用尤其是 5432PostgreSQL和 6379Redis本地装过数据库服务就会撞上二是数据卷权限问题容器内的进程以非 root 用户运行而宿主机挂载目录的属主不对。解决端口冲突用ss -tlnp找出占用进程停掉旧服务或者修改 compose 文件里的端口映射。数据卷权限问题先看日志确认docker compose logs postgres --tail 50如果日志里出现 permission denied 相关报错给数据目录纠正属主sudo chown -R 1000:1000 ./data逻辑说明容器内进程的默认用户 UID 是 1000宿主机挂载目录如果属于 root容器写不进去。chown 到 1000 是最直接的解法。改完重新docker compose up -d即可。注意这个命令是在 Dify 的 docker 目录下执行的别在别的目录敲路径不对没有效果。5.3 现象模型明明连上了但回答完全不用知识库里的内容原因这是整条链路里最隐蔽的问题。表面上问答能跑通但应用的编排里没有正确关联知识库或者「引用与归属」功能没开启导致你根本看不到知识库是否参与了回答。解决第一步确认知识库状态是「可用」不是「待索引」。第二步在应用编排页面确认知识库节点真的连接到了 LLM 节点的 context 输入。第三步在调试界面开启「引用与归属」看回答底部是否列出了引用的文档片段。如果没有任何引用记录说明知识库节点没生效重新拖拽连接后保存再试。5.4 现象回答到一半明显变慢甚至直接报显存不足原因本地知识库的上下文很长。一个 500 token 的检索片段拼入上下文加上对话历史模型的上下文长度很容易超过 8000。7B 模型在 8G 显存上很难舒服地处理长上下文超出后回退 CPU速度肉眼可见地掉。解决把知识库片段调小从 500 降到 250同时限制每次检索返回的片段数量。Dify 的检索设置里默认返回 3 个片段改成 2 个先试试。显存占用明显下降的同时回答质量可能不降反升——因为喂给模型的噪声更少。另外在应用设置里把「对话历史轮数」限制在 4 到 6 轮能有效控制输入长度。这一步的收益比换显卡来得快得多。5.5 现象知识库检索出来的片段明显不对题回答读起来逻辑混乱原因纯靠向量相似度的召回在中文场景下对专业术语和同义词特别不友好。比如你问「什么是 RoPE 位置编码」文档里写的是「旋转位置编码」向量相似度很可能排不到前面模型拿到的是无关片段。解决三个方向一起下手。第一把检索模式从「向量检索」改成「混合检索」让关键词全文检索和向量检索并行Dify 会把两路结果合并去重。第二调大召回数量让模型看到更多候选片段同时在提示词里明确写「只基于以上资料回答不要自行补充」。第三条件允许的话加一个 rerank 重排序节点相关内容在 6.1 节具体说。6. 进阶技巧让知识库答疑从「能答」到「答得准」6.1 接入 Rerank 模型提升效果比换大模型更明显很多人第一反应是换更大的模型来提升知识库回答质量实测下来对本地知识库场景Rerank 的性价比远高于升级大模型。逻辑很简单知识库回答的上限由「能不能检索到对的片段」决定而不是由生成模型的参数量决定。检索到无关内容14B 模型也只能一本正经地编。本地部署时可以在 Ollama 上跑一个轻量 rerank 模型然后在 Dify 的检索流程里加入重排序环节。配置时把召回数量从 3 提到 10先让向量检索阶段多捞候选再用 Rerank 从 10 个候选中挑出最相关的 3 个喂给大模型。调试面板里会很直观地看到引用片段的变化——这算是所有调优动作里见效最快的。6.2 分段策略的细节从按字数硬切到按语义边界切我做第一个知识库时直接用了固定 token 切块结果代码片段和表格被拦腰斩断检索出来的内容语义残缺。后来改成按 Markdown 标题层级切分一级标题作为块的起点二级标题的内容独立成块。Dify 的自定义分段规则支持把##、###、换行等符号作为分隔符实际效果比固定 token 好得多。另一个低成本技巧是给文档开头写一段简短描述说明这份文档的主题和范围Dify 切块时这段描述会随每个片段一起参与向量化检索命中率会明显上升。这是最便宜的优化方式——改文档而不是改系统成本几乎为零。6.3 显存规划、文档数量和这套方案的边界总有读者来问 8G 显存能不能跑这套方案。我的实际体验是能跑但上限很清晰DeepSeek 7B 加 8192 上下文再叠加 embedding 和 rerank 模型常驻8G 会非常紧。我的部署习惯是 embedding 和 rerank 跑在 CPU 上GPU 显存只留给大模型。这些轻量模型用 CPU 推理延迟也不高却能把显存完全释放给生成模型整体体验反而更好。文档规模上不建议一开始就把几十 GB 的资料全部塞进知识库。先放两三份高质量文档调通链路再逐步扩展。文档数量上来之后检索召回准确率一定会下降这是真实存在的边界不是改配置能完全弥补的。这时候更合理的做法是按主题拆分成多个知识库在应用里按场景切换而不是试图让一个知识库解决所有问题。这套方案我跑了大半年几乎踩遍了我上面写到的每道坑。回头看最有价值的经验不是记住了哪个参数而是把整条数据流链路刻在脑子里文档进来怎么切块、怎么向量化、怎么存储提问时怎么检索、怎么拼上下文、怎么生成。链路理清楚了Dify 和 Ollama 的再配置就只是填几个地址和密钥而已。希望这篇笔记能帮你少走几段弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
