简介：这份PDF资料面向希望零基础搭建本地AI知识库的开发者与AI爱好者，围绕DeepSeek大模型与Dify开源平台，给出从系统环境变量配置、Ollama安装、模型拉取到Docker与Dify部署的完整落地路径，帮助读者在个人电脑上跑通一套可对话、可检索的私有知识库，无需深厚技术背景即可上手。资源包共1个PDF文件，约1.47MB，以图文步骤形式串联各环节，涵盖环境变量设置、deepseek-r1与bge-m3模型拉取、Docker镜像配置、Dify源码部署及知识库创建与助手对话等关键节点，便于对照操作与排错。目前已有2345人学习，适合想低成本实践大模型本地化、构建个人或团队知识库的读者参考。
1. 从一次“模型下完却找不到”的翻车说起：DeepSeek+Dify 本地知识库部署
Windows 11 上装 DeepSeek+Dify 本地知识库，最容易翻车的不是 Docker，也不是 Dify 本身，而是 Ollama 把模型下到了 C 盘，系统盘一夜之间红了，重装时又找不到模型文件在哪。这套组合——Ollama 跑 deepseek-r1 加 bge-m3，Docker Desktop 起容器，Dify 做知识库应用——是当前大模型本地部署里门槛相对低、复现率很高的一条路线，适合想把资料喂给模型、又不想把文档传到外面的开发者。装不好会怎样？模型拉取中断、Docker 镜像拉不动、Dify 页面打不开、知识库建完检索不到内容，四个环节任何一个卡住，整套环境就白搭。这篇按我实际装过一遍的顺序，把版本选择、环境变量、模型拉取、容器配置和验证方法一次讲清。
2. 装前把环境列清：Windows 11、Ollama 与 Docker 的版本取舍
2.1 系统与硬件的最低线
这套方案的原生环境是 Windows 11，Windows 10 22H2 也能跑，但 WSL2 的体验差一截，Docker Desktop 在旧版本上偶发启动卡死，我一般建议直接上 Win11。硬件上分两块看：跑 deepseek-r1 的 8B 量化版本，内存至少 16GB，留出 8GB 以上给模型；跑 14B 或 32B，内存要 32GB 起步，否则加载阶段就开始吃交换分区，响应慢到没法用。磁盘方面，Ollama 模型目录、Docker 镜像目录、Dify 源码目录三处都要预留空间，deepseek-r1:8b 大约 5GB，bge-m3 约 1.2GB，Docker 镜像全套下来 10GB 上下，加上系统本身，建议单独准备一个 60GB 以上的数据盘。
显卡不是硬性要求，纯 CPU 也能跑 8B，只是首字延迟明显；有 NVIDIA 显卡的话，Ollama 会自动调用，Docker 侧不需要额外配 CUDA，这点比早年自己编译推理框架省心得多。
2.2 版本选择：别追最新，追能对上的
Ollama 从官网下载 Windows 安装包即可，版本上我倾向用当前稳定版，不刻意锁旧版，因为它对模型的兼容是向前覆盖的。Docker Desktop 要注意一点：必须确认 WSL2 后端已启用，安装时勾选 “Use WSL 2 instead of Hyper-V”，否则后面docker compose起容器会报引擎未运行。Dify 走 GitHub 主分支压缩包，解压后直接用，不需要 Node 环境，所有依赖都在容器里。
| 组件 | 用途 | 版本策略 | 占用参考 |
|---|---|---|---|
| Ollama | 拉取并运行 deepseek-r1、bge-m3 | 官网稳定版 | 模型约 6GB |
| Docker Desktop | 承载 Dify 全部容器 | 当前稳定版，WSL2 后端 | 镜像约 10GB |
| Dify | 知识库应用平台 | GitHub 主分支压缩包 | 源码数百 MB |
2.3 先设环境变量，再装 Ollama
这一步顺序不能反。先右击“此电脑”→“属性”→“高级系统设置”→“环境变量”，在系统变量里新建OLLAMA_MODELS，值指向数据盘上的空文件夹，比如E:\Ai\Ollama3。设完重启系统，让变量对安装程序生效。为什么强调先设？Ollama 安装后会以服务形式常驻，模型默认落在用户目录，等发现 C 盘爆了再改，得停服务、迁文件、改路径，多绕一圈。
# 设置完成后在 cmd 里验证变量是否生效 echo %OLLAMA_MODELS% # 期望输出：E:\Ai\Ollama3这条命令只是确认变量写进去了，不涉及模型操作。如果输出是%OLLAMA_MODELS%原样，说明变量没建在系统级或者没重启，回到环境变量窗口检查变量名拼写，注意是下划线不是横杠。
3. 拉模型与起容器：Ollama 拉取 deepseek-r1 和 bge-m3 的实操
3.1 安装 Ollama 并拉取对话模型
双击OllamaSetup.exe，点 Install，装完托盘会出现 Ollama 图标。打开命令行，执行拉取命令。模型规格按机器来，16GB 内存选 8B，32GB 可以试 14B，命令里的标签要对应：
# 拉取并进入交互式对话，首次执行会先下载模型 ollama run deepseek-r1:8b # 出现 >>> 提示符后输入一句话测试，比如“你好” # 测试完按 Ctrl+C 退出对话，再按 Ctrl+D 退出模型run的语义是“没有就拉、有就直接跑”，所以第一次执行会看到下载进度条。测试时随便问一句，能正常回复就说明推理链路通了。退出用 Ctrl+C 中断当前生成，Ctrl+D 退出交互，两个键别搞混，只按 Ctrl+C 有时会停在半截。
3.2 拉取向量模型 bge-m3
知识库的检索靠向量化，对话模型不干这个活，必须单独拉 embedding 模型：
# 拉取 bge-m3 向量模型，供 Dify 知识库做文本嵌入 ollama pull bge-m3 # 拉完后列出本地全部模型，核对名称和大小 ollama listpull只下载不运行，适合后台准备。ollama list的输出里要能看到deepseek-r1:8b和bge-m3两行，名称后面跟的是模型 ID 和体积。Dify 里填模型名称时必须和这里显示的一字不差，包括标签，写成deepseek-r1不带标签大概率匹配不上。
3.3 Docker Desktop 安装与镜像加速配置
从 Docker 官网下载 Windows AMD64 安装包，双击安装，过程中保持默认勾选 WSL2 后端。装完启动 Docker Desktop，进 Settings → Resources → Advanced，先把 Disk image location 改到数据盘，比如D:\Docker\DockerDesktopWSL，避免镜像把系统盘撑满。再进 Docker Engine，把配置改成下面这样：
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": ["https://hub.rat.dev"] }defaultKeepStorage控制构建缓存保留上限，20GB 对这套环境够用；registry-mirrors是镜像拉取地址，国内网络下拉官方源经常超时，配一个可用镜像源能显著减少docker compose up卡住的时间。改完点 Apply & restart，等引擎重启完成，托盘图标变绿再继续。这里有个细节：镜像源不是永久有效，某天拉取又变慢，先怀疑镜像源失效，换一个再试，不要急着怀疑 Dify 配置。
3.4 解压 Dify 并改 .env
下载 Dify 主分支压缩包，解压到数据盘并命名为dify。进入dify\docker目录，把.env.example复制一份改名为.env，用记事本打开拉到末尾，追加两行：
# 允许 Dify 接入自定义模型供应商 CUSTOM_MODEL_ENABLED=true # 容器内访问宿主机 Ollama 服务的地址，端口固定 11434 OLLAMA_API_BASE_URL=host.docker.internal:11434host.docker.internal是 Docker 提供的宿主机别名，容器里访问它等于访问本机，比写127.0.0.1可靠，因为容器内的回环地址指向容器自己。端口 11434 是 Ollama 默认监听端口，没改过就照抄。保存后在docker文件夹空白处右键“在终端中打开”，执行：
# 后台拉起 Dify 全部依赖容器，首次执行会拉取镜像 docker compose up -d # 查看容器状态，确认没有反复重启的 docker compose ps-d是后台运行，不加会占住终端。首次执行时间长是正常的，镜像总量摆在那。docker compose ps里每个服务的 State 应该是 running，如果某个容器不断 restart，先看它的日志：docker compose logs 服务名，多数是端口冲突或镜像没拉全。
4. 避坑与排查：Dify 起不来、模型连不上的四类现场
4.1 现象：浏览器打开 127.0.0.1 一直转圈
原因通常是容器还没起全，或者 80 端口被别的服务占了。解决：先docker compose ps看 nginx 和 api 两个服务是否 running，没起来就看日志；端口冲突的话改.env里的EXPOSE_NGINX_PORT，换成 8080 之类，再docker compose up -d重建。我遇到过本机装了别的 Web 服务占 80，排查了半小时才发现，血泪经验是装之前先netstat -ano | findstr :80看一眼。
4.2 现象：Dify 添加 Ollama 模型时提示连接失败
原因分两种：一是.env里地址写成了127.0.0.1:11434，容器内访问不到宿主机；二是 Ollama 服务没在跑。解决：确认.env用的是host.docker.internal:11434，改完必须docker compose up -d让容器重建才生效，只改文件不重建等于没改。再在宿主机浏览器访问http://127.0.0.1:11434，能看到 Ollama 的返回就说明服务正常。
4.3 现象：知识库建完，提问却答不出内容
原因多半是索引方式或检索设置不匹配。创建知识库时选“高质量”索引，就必须配好 Text Embedding 模型，也就是 bge-m3；如果 embedding 模型没在 Dify 里添加成功，索引会失败但页面不一定报错。解决：回设置里检查 Ollama 下是否同时有 LLM 和 Text Embedding 两类模型，缺一个就补一个，然后删掉知识库重建，别在原库上反复重试。
4.4 现象：模型拉取到一半中断，重试又从零开始
原因是网络抖动导致分片下载失败，Ollama 对未完成的分片会重新拉。解决：换时间段重试，或者先ollama rm 模型名清掉半成品再拉，避免残留文件干扰。另外确认OLLAMA_MODELS指向的盘剩余空间足够，空间不足时下载会在最后阶段失败，报错信息不明显，容易被当成网络问题。
5. 装完怎么验证：从模型对话到知识库检索走一遍闭环
验证不要只看页面能不能打开，要按数据流走一遍。第一步，命令行确认两个模型都在：ollama list输出包含deepseek-r1:8b和bge-m3。第二步，宿主机访问http://127.0.0.1:11434，有响应说明 Ollama 服务对外可用。第三步，浏览器打开http://127.0.0.1/install，设置管理员账号进入主界面，进设置 → 模型供应商 → Ollama，分别添加 LLM 和 Text Embedding，模型名称照抄ollama list的输出，基础 URL 填http://host.docker.internal:11434，保存时如果报错，回到 4.2 节对照排查。
第四步，建一个聊天助手应用，再建一个知识库：数据源选导入文本，分段用通用，索引选高质量，检索选向量检索，保存并处理，等状态变成可用。第五步，回到应用里把知识库挂到上下文，问一个只有你上传的文档里才有的问题，答案能引用到文档内容，整条链路才算通。
| 验证点 | 操作 | 通过标准 |
|---|---|---|
| 模型就位 | ollama list | 两个模型名称完整显示 |
| 服务可达 | 浏览器访问 11434 | 返回 Ollama 运行提示 |
| 模型接入 | Dify 添加 LLM 与 Embedding | 保存无报错 |
| 检索闭环 | 上传文档后提问 | 回答引用文档内容 |
这套环境我装过几次，最深的教训是：每次重装都先把OLLAMA_MODELS和 Docker 镜像目录改到数据盘，再动安装包，顺序错一步就要多花一小时迁文件。从那以后我每次装完都强制走一遍上面这张验证表，五项全过才认为环境可用，不靠“页面能打开”这种玄学判断。希望帮到你。
本文还有配套的精品资源，点击获取
