Windows 本地部署 Dify + Ollama + DeepSeek 知识库实战指南

简介面向具备基础IT素养、希望快速搭建AI开发环境的学习者与专业人士这份Windows本地化部署教程围绕Docker、Dify、Ollama与DeepSeek组合方案展开。内容覆盖从硬件门槛CPU≥2核、内存≥4GiB、磁盘20G以上、Git与TortoiseGit安装、Docker部署及国内镜像加速到Dify代码克隆与启动验证、Ollama非C盘路径配置与模型下载、集成文本嵌入模型等关键步骤并附常用Docker命令供日常排障。资源为1个docx格式文档压缩包约923KB虽仅单个文件但目录结构完整按说明、准备、部署到附件顺序组织可逐段对照操作。目前已有3879人学习使用。按文档执行能有效节省环境配置时间避开存储路径、镜像拉取等常见坑点适合作为本地化部署LLM工作台的入门参考。1. Windows 上跑 Difyollama 的这条路值得从 Docker 开始一个本地知识库管理员想做的事大概是这样内网一台 Windows 机器装好 Dify 当工作台把私有文档扔进知识库让 deepseek 模型在本地回答问题整个过程不经过任何外部 API。这个组合里有个输入法留下的坑——标题里的 ollma 实际是 ollama很多人第一次docker run时就把镜像名拼错拉取直接 404。整套方案的核心是把 Docker 作为唯一依赖层Dify 跑容器ollama 负责加载 deepseek 权重Windows 只提供 WSL2 后端和 GPU 驱动。适合谁适合有 16G 以上内存、想彻底掌控模型和数据的开发者也适合不想在云上为每次问答付费的企业内部试用。反直觉的一点是所有组件都在本机Dify 却默认连不上 ollama因为这俩跑在不同的网络命名空间里。2. 选 Docker Desktop 还是原生进程WSL2 后端与资源预留2.1 Docker Desktop 的 Windows 后端WSL2 和 Hyper-V 怎么选Windows 上跑 Docker 容器本质上是借一个 Linux 内核。Docker Desktop 安装时让你在 WSL2 和 Hyper-V 后端之间做选择我建议直接选 WSL2。WSL2 的启动速度快内存回收比 Hyper-V 激进而且它允许你在 WSL 发行版里直接访问/mnt/d这类 Windows 挂载盘对调试 compose 里的 volume 路径非常方便。Hyper-V 后端适合那些已经被虚拟化软件占用了 CPU 虚拟化指令的老机器但它的隔离层更重Dify 全家桶在 Compose 里要起十几个容器时Hyper-V 后端的镜像层读写明显更慢这是实际体感不是玄学。WSL2 模式下Docker 的上下文其实跑在一个轻量虚拟机里Windows 上看到的所有端口映射都是 Docker Desktop 通过localhost转发到 WSL2 里的。这就带来一个关键差异你在 Windows 浏览器里打开localhost:3000没问题但容器内部访问localhost访问的是容器自己不是 Windows 宿主机也不是 WSL2 宿主。后面配置 ollama 和 Dify 的连接时这个差异会让不少人翻车。安装 Docker Desktop 之前先确认三件事。第一BIOS 里 Intel VT-x 或 AMD-V 要开着否则 Docker Desktop 直接报 Virtualization support is not detected。第二Windows 功能里启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”然后重启。第三最好把 Docker 的镜像存储位置从 C 盘改到其他盘这个在 Docker Desktop 的 Settings → Resources → Disk image location 里设置因为后面拉 deepseek 的模型文件是几个 GB 的体量C 盘容易爆。2.2 组合方案对 Windows 宿主的最低要求与资源预留跑这套组合内存是第一瓶颈。Dify 的 docker compose 里含 API 服务、Worker、PostgreSQL、Redis、Weaviate、Sandbox、Nginx 等十来个容器光是空载就能吃 3-4G 内存。ollama 加载 7B 参数的 deepseek 模型量化后大约需要 6-8G如果加载 16B 或更大的模型内存占满后 Windows 会开始疯狂换页。我一般建议这么预留内存默认 32G最低 16GCPU 推理极慢且 Docker Desktop 默认给 WSL2 的内存上限是 4G要手动调大。Docker Desktop 的 Resources 里把 Memory 至少拉到 8GSwap 开到 2G。如果你的 Windows 机器带 NVIDIA 显卡这一步提前确认装好最新驱动和 CUDA 运行库Docker Desktop 会在 WSL2 里自动启用 GPU 加速不需要在容器里再装 CUDA 工具链官方镜像已经内置了。提示Docker Desktop 的 WSL2 内存上限不是越大越好。给 WSL2 太多内存Windows 宿主本身的缓存会被压缩模型加载时反而慢。我用 32G 机器时WSL2 分配 12G剩下留给 Windows 和浏览器。这套组合的磁盘占用也要算清楚Docker 镜像层加起来接近 10G模型文件按需下载embedding 模型再加 1-2G知识库的向量库数据另算。所以磁盘至少要留 40G 可用空间。我见过有人把 Dify 装在机械盘上docker compose 启动花了二十分钟后面索引文档时 CPU 打满体验非常差。固态盘是这个方案的默认前提。3. 用 docker compose 把 Dify 拉起来最小改动与必改变量3.1 拉取 Dify 官方 compose 项目并整理目录Dify 官方在 GitHub 上维护了一套 docker compose 编排Windows 上不需要自己手写容器配置直接拉仓库里的 docker 目录即可。注意这套代码里默认绑定的端口是 80、3000、5000、5432 等如果你本机已经装了 MySQL、PostgreSQL 或者常用的 80/5000 端口被占用改动环境变量和端口映射是不可避免的。git clone https://github.com/langgenius/dify.git cd dify/docker # Windows 上用记事本或 VS Code 打开 .env 文件确认默认配置 cp .env.example .env # 按需修改关键变量保存后再启动 docker compose up -d上面这段是把 Dify 实例拉起来的完整链路。clone之后进入dify/docker目录这里才是真正执行docker compose的地方。cp .env.example .env不是可选项Dify 的 compose 文件里大量引用了.env中的变量不拷贝.env.example的话启动时那些${SECRET_KEY}会变成空字符串Nginx 容器会直接退出。docker compose up -d是后台启动第一次会拉几十个镜像时间取决于网络状况和 Docker 镜像源的配置。等镜像拉取完你还需要再等大约两分钟因为 PostgreSQL 和 Redis 要初始化数据。判断是否就绪用下面这段docker compose ps docker logs -f docker-web-1docker compose ps看容器状态重点看docker-web-1和docker-api-1是否处于 Up 状态。docker logs -f docker-web-1会输出 Dify 前端的日志看到类似ready或服务监听 3000 端口的信息就说明前端已经起来了。如果容器反复重启第一步不是改文件而是docker compose logs api看 API 侧的报错大多数时候是数据库还没起来时 API 先连库导致的崩溃等 PostgreSQL 就绪后自动恢复。3.2 环境变量与端口映射安装前必须改的三个值.env文件里最值得动的是三个地方。第一个是SECRET_KEY保持默认值也能跑但凡是暴露到局域网的环境都建议生成一个随机串第二个是POSTGRES_PASSWORD默认密码在公网环境等于裸奔第三个是绑定端口如果你的 80 或 5000 端口被 IIS 或本地开发服务占住把EXPOSE_NGINX_PORT改成别的端口即可比如8080和5443。还有一个变量是SQL_PORT这个控制 PostgreSQL 对宿主机暴露的端口。只是自己用的话我建议把数据库容器从宿主端口摘掉只保留 Docker 内部网络访问。做法是在docker-compose.yaml里把ports: - 5432:5432那行注释掉或者改成一个访达随机端口。Windows 上默认会有人扫5432这个端口暴露出去是个安全隐患。这三处改动分别解决三个问题安全证书相关的不报错、数据库不被外部工具连接、前端端口不冲突。改动完.env后不用 remove 全部容器只需要docker compose up -d再跑一遍compose 自己会重建配置有变动的容器。3.3 启动、等迁移完成、验证 web 容器启动后我一般不到浏览器里点先在命令行验证三层。# 检查所有容器是否健康 docker compose ps # 从宿主机验证 Nginx 端口是否监听 curl -I http://localhost:8080 # 实时看 API 是否在正常响应 docker logs --tail50 docker-api-1curl -I只看响应头状态码是200或302都正常说明 Nginx 那一层通了。这时候打开浏览器访问http://localhost:8080如果 Nginx 端口改成 80 就是http://localhost。Dify 首次打开会让你设置管理员账号这一步会写入 PostgreSQL所以如果数据库迁移没完成页面会卡在初始化界面转圈。等迁移完成的判断方法docker logs docker-api-1里出现Database migration complete之类的关键字或者docker compose ps里docker-db-1的状态从starting变成healthy。Dify 的容器编排里数据库定义了健康检查healthy状态是后续所有服务正常工作的前提。注意如果访问页面直接报 SSL 错误是 Dify 默认带了 HTTPS 端口映射浏览器抢先把请求转到了https://。单独访问http://localhost:8080可以绕开这个报错这个属于配置陷阱不是服务坏了。4. 让 ollama 与 deepseek 被 Dify 认账模型接入的完整链路4.1 ollama 原生安装 vs 容器安装Windows 上的选择ollama 接入这套方案有两条路线一条是把 ollama 直接装进 Windows 宿主机另一条是把 ollama 做成容器加入 compose。我在 Windows 上强烈推荐第一条在 Windows 原生安装 ollamaDify 容器通过 Docker 的宿主机网关地址访问它。原因有两个一是 ollama 在 Windows 原生模式下的 GPU 加速比容器模式少一层显卡透传很多老些的显卡驱动在 WSL2 里转 CUDA 会拉垮二是模型文件放在 Windows 自己的目录下管理起来直观改模型或者备份都方便。容器跑 ollama 也不是不行但你需要额外给容器挂载 GPU 参数并且模型文件会写在 Docker 数据卷里将来迁移时反而多一道工序。所以后文的命令我都假设 ollama 装在 Windows 宿主机上监听默认的 11434 端口。Dify 容器到 Windows 宿主机的网络路径用host.docker.internal这是 Docker Desktop 在 Windows/macOS 上内置的网关别名容器里访问host.docker.internal:11434就等于访问 Windows 的 11434 端口。4.2 用 ollama 拉取并运行 deepseek 模型Windows 上安装 ollama 之后命令行里直接拉模型。deepseek 官方在 ollama 仓库里维护了多个档位的模型按显存和响应速度取舍。ollama pull deepseek-r1:7b ollama list ollama run deepseek-r1:7bollama run之后随便输入一句话如果出现正常回复说明模型加载成功。这一步不要跳过因为 Dify 里配模型报错时你至少能确认是 ollama 侧的问题还是 Dify 侧的问题。ollama list会显示已经下载到本地的模型命令名里的deepseek-r1:7b是模型名加 tag没有显存的情况下 CPU 推理也能跑但回答速度会像蜗牛。ollama 模型下载默认会放在用户名目录下的.ollama/models里。如果你想让模型文件放到 D 盘提前设置环境变量OLLAMA_MODELS再重启 ollama然后再 pull否则下到一半改路径会导致模型文件不完整。这是个特别隐蔽的坑模型管理器显示了文件但加载报错十有八九是半途换了目录。模型下载完以后ollama 服务默认是开机自启的不需要手动ollama serve。如果你在 Windows 服务列表里看不到 ollama 进程可以用管理员身份跑一次ollama serve它会常驻前台跑保持这个窗口开着即可也算一种兜底方案。4.3 在 Dify 里配置自定义模型供应商参数表与测试Dify 对 ollama 的支持是走 Ollama 模型供应商配置入口在设置里的“模型供应商”页面选“Ollama”后填参数。注意这里填的不是 deepseek 的 API Key因为你走的是本地模型不需要任何密钥。我通常只在填写各项参数时不额外造几张表这里给张参数速查表更直观。配置项推荐值说明Model Namedeepseek-r1:7b必须和ollama list里的名字完全一致Base URLhttp://host.docker.internal:11434容器里访问 Windows 宿主机的固定写法Temperature0.7太高会语无伦次本地模型建议 0.5-0.8Top P0.9蒸馏模型默认即可不需要动Max Tokens4096长文档总结时建议拉高到 8192填完以后点测试Dify 会发一个请求到 ollama如果连接正常会回一条模型响应。很多人在这里报an error occurred during credentials validation看得人一头雾水。这个报错的原因通常是 Base URL 写错了尤其不能写成localhost:11434因为 Dify 的 API 容器里 localhost 指向的是容器自己它没跑 ollama。改成http://host.docker.internal:11434基本立竿见影。测试通过后还要在“系统模型设置”里把这个模型设置为 default model。这一步漏掉的后果是你在应用里创建对话时模型下拉框是空的。Dify 只认“系统默认”和“应用显式指定”两种模型来源光在供应商列表里配好不设为默认是不生效的。4.4 知识库与 embedding 模型让私有文档可检索如果只是对话上面的配置够用了但很多人搭这套组合是为了私有知识库。知识库的完整链路需要一个 embedding 模型和一个 rerank 模型embedding 把文档切成向量存进 Weaviate回答时再拿问题向量去比相似度。Dify 的知识库导文档时默认走 OpenAI 接口你不配的话会报错所以要在模型供应商里加一个 Ollama 的 embedding 模型。ollama pull bge-m3embedding 模型推荐bge-m3这是 ollama 里兼容性较好的中文向量模型。Dify 里选“Ollama”供应商Model Type 选 “Text Embedding”Model Name 填bge-m3其它参数沿用 4.3 的表。接下来到知识库的设置页面把“Embedding Model”切到bge-m3再新建知识库并导入文档。这里有个很常见的报错unstructured api url is not configured for doc file processing。原因是 Dify 默认用 unstructured 服务来解析 doc、pdf 这类非纯文本文件而.env里没配UNSTRUCTURED_API_URL。最简单的绕法是暂时只用 txt、markdown 文件做知识库等需要复杂文档解析时再补配服务。如果你必须立刻用 doc 文件就在.env里增加一行UNSTRUCTURED_API_URLhttp://host.docker.internal:8000前提是你另外把 unstructured 服务跑起来。对大多数内部知识库场景先用文本文件把链路打通是性价比最高的路径。5. 本地化部署避坑清单5 个把新手卡住一夜的问题5.1 现象Docker Desktop 启动失败弹窗 Virtualization support is not detected原因Windows 宿主机没有开启 CPU 虚拟化或者 Hyper-V/WSL2 功能缺了某项。这个报错通常出现在老机器或品牌机 BIOS 里默认关闭虚拟化的情况跟 Docker Desktop 本身没关系。解决重启进 BIOS找到 “Intel Virtualization Technology” 或 “SVM Mode”改成 Enabled。然后在 Windows 的“启用或关闭 Windows 功能”里勾上“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。改完让系统重启再打开 Docker Desktop。如果还是报同样的错可以打开 PowerShell 执行systeminfo查看最后几行的“Hyper-V 要求”是否显示“已检测到虚拟机监控程序”没有的话说明 Hyper-V 组件没生效。5.2 现象Docker 守护进程起不来提示 start the windows daemon from a non-elevated terminal原因这不是配置问题是 Windows 的权限设计。Docker Desktop 的守护进程不想在高权限终端里启动因为提权会改变它和 WSL2 的交互方式。很多教程让人“用管理员身份运行”解决一切这个习惯在这里反而帮倒忙。解决把 Docker Desktop 进程全部退出然后用普通权限的 PowerShell 或 CMD 跑docker version验证。如果你当前终端是管理员重新开一个不加“以管理员身份运行”的窗口即可。Windows 上我更习惯直接在系统托盘里点 Docker Desktop 图标让进程自己决定启动方式。5.3 现象Dify 里配置 ollama 模型测试时报 an error occurred during credentials validation原因这个报错信息的字面意思和实际原因经常不一致。绝大多数情况下是 Base URL 里的主机名写成了localhost。Dify 的 API 容器在它自己的网络里localhost指向容器自身所以连接被拒Dify 把这个失败归纳成“凭据验证失败”容易误导人往 API Key 上找问题。解决把 Base URL 改成http://host.docker.internal:11434。如果改了还是报错就在 ollama 所在机器上先curl http://localhost:11434确认服务活着再看 Windows 防火墙有没有拦截 Docker 虚拟网卡的入站连接。我遇到过一次是公司安全软件把 WSL2 的虚拟网卡挡了把 Docker Desktop 加入信任列表就通了。5.4 现象模型拉取命令报错提示 manifest for deepseek-r1 的某个 tag 不存在原因这里有个特殊的历史包袱——很多人按标题把ollama拼成ollma命令变成ollma pull deepseek-r1:7bWindows 会直接提示命令找不到。另一个常见原因是模型 tag 写错比如把7b写成7Bollama 的 tag 是区分大小写的。解决命令不存在就去重新安装 ollama重新确认安装时勾选了“添加到 PATH”。tag 不存在就先在模型仓库页面确认最新 tag再回到命令行输入ollama list看本地已有的模型名。关键词拼写这种东西无法通过报错定位只能每次敲命令前对一眼这个坑我踩过不止三次。5.5 现象Web 界面端口打不开Windows 报端口已被占用原因Dify 默认的端口是 3000前端和 80nginxWindows 上 IIS 的 World Wide Web Publishing Service 和 Jenkins 这类进程常驻占着这些端口。用netstat -ano | findstr :3000查到 PID 后任务管理器里又杀不掉是因为查看进程的用户权限不够。解决管理员身份的 CMD 里先netstat -ano | findstr :5000拿到 PID再tasklist | findstr 那个PID看是哪个程序确认不需要后taskkill /F /PID 那个PID结束它。如果不确定那个进程是不是系统服务最稳的是改 Dify 的.env里的端口映射避开 3000/5000/80改成 8080/3001 这些不常用的高位端口。端口问题的排查思路优先“绕开”而不是“杀掉”。6. 自启、保活与模型参数调优把这套组合当生产环境养Windows 上这套组合跑通以后下一个问题是如何让它长期稳定地跑而不是重启一次系统就要手动敲一遍命令。Docker Desktop 在设置里勾上“Start Docker Desktop when you sign in”它会在登录后自动启动 WSL2 和全部容器这个不用写脚本。ollama 在 Windows 原生安装时默认设置了开机自启两种组件加起来不需要额外的任务计划。真正需要留意的是系统休眠Windows 睡眠唤醒后WSL2 有可能出现网络过一会儿才恢复的情况表现为容器都活着但域名解析超时。这类玄学问题的临时解法是wsl --shutdown后再启动 Docker Desktop但更优雅的做法是把 Windows 的电源计划调成“从不休眠”代价是电费上涨。模型参数这一层很多人以为 Dify 界面上的 Temperature 已经定死了其实 ollama 在运行时也有一套自己的采样参数。如果直接在 Dify 里调的参数不生效可以在 ollama 的模型配置层面覆盖。做法是在~/.ollama里给模型建一个 Modelfile写入PARAMETER temperature 0.5然后ollama create deepseek-r1:local -f Modelfile这样 Dify 调用原模型名时走的就是覆盖后的参数。不过我更推荐只在 Dify 里调因为 Dify 的请求会显式携带参数ollama 收到请求时以请求参数为准。验证整条链路是否正常最直接的办法是在 Dify 里新建一个空白应用把模型选成 deepseek输入“用一句话介绍你自己”。如果响应正常再打开“编排”页签检查上下文里是否带上了知识库的检索结果。这个测试路径可以快速区分是模型问题还是知识库问题。最后说一个我自己的习惯每次改动.env或 Modelfile 前先docker compose cp备份或者直接复制一份原文件这条规则救过我太多次。默认配置跑通后所有调整都小步走——改一个变量、启动、验证、再改下一个。这套组合值得投入的方向是把一个完整的内网推理服务托在 Windows 主机上它能挡住外部流量、不消耗 API 费用同时让你彻底理解容器编排和模型服务之间的关系。希望帮到你。本文还有配套的精品资源点击获取