企业官网建设流程全解析

简介：这份文档面向具备基础IT素养、希望搭建本地AI开发环境的学习者与从业者，尤其适合自然语言处理与深度学习方向的技术人员。内容围绕Windows平台下Docker、Dify、Ollama与DeepSeek的组合部署展开，从硬件要求、Git与Docker安装、国内镜像源切换，到Dify克隆启动与访问验证、Ollama模型路径配置与下载检验，再到LLM与文本嵌入模型的集成，并附常用Docker命令参考，形成一套可落地的本地化部署指引。资源包为1个docx文档，约923KB，结构按说明、适用环境、准备工作、各组件部署与附件分章编排，便于按需查阅。目前已有3881人学习下载，适合想快速构建本地大模型开发环境、减少环境配置踩坑的读者参考。

1. 为什么要在 Windows 上折腾 Docker + Dify + Ollama + DeepSeek 这套组合

很多做 AI 应用落地的朋友，第一反应是租云 GPU、开容器服务，但真到客户现场或者自己内网环境里，网络策略、数据合规、成本控制三座大山一压，本地化部署就成了绕不开的选项。这套组合的核心思路是：用 Ollama 在 Windows 上跑 DeepSeek 模型推理，用 Docker 跑 Dify 的应用编排层，两者通过本机网络打通，最终得到一个完全离线、数据不出本机、可自由接入知识库和 Agent 流程的 AI 应用平台。它适合三类人：一是需要在无外网环境做 POC 的交付工程师，二是想低成本学习 AI 应用编排的后端开发者，三是手里只有一台带独显的 Windows 工作站、想榨干硬件价值的技术负责人。整条链路里最容易翻车的不是模型本身，而是 Windows 下 Docker 的网络模式与 Ollama 的监听地址配置——这两个点没对齐，后面全是玄学报错。

2. 环境准备与组件选型：哪些版本能少踩坑

2.1 Windows 侧基础依赖的安装顺序

在 Windows 上跑这套组合，底层依赖的顺序不能乱。我一般按这个顺序来：先装 WSL2，再装 Docker Desktop，然后装 Ollama for Windows，最后拉 Dify 的镜像。WSL2 是 Docker Desktop 在 Windows 上稳定运行的前提，跳过它直接用 Hyper-V 后端，容器访问宿主机 Ollama 时会出现间歇性连接拒绝，这个坑我踩过不止一次。

安装 WSL2 的命令很简单，用管理员权限打开 PowerShell：

wsl --install wsl --set-default-version 2

执行完重启一次，再确认版本：

wsl --list --verbose

输出里 VERSION 列必须是 2。如果是 1，用wsl --set-version <发行版名> 2转过来。这一步的逻辑是：WSL2 提供的是一个轻量级虚拟机，Docker Desktop 会默认把容器跑在这个虚拟机里，而 Ollama 是直接装在 Windows 宿主上的，两者之间要通过宿主 IP 通信，所以网络模式的选择直接决定了后面能不能通。

Docker Desktop 安装时注意两个选项：一是不要勾选“Use WSL 2 instead of Hyper-V”之外的任何实验特性，二是安装完成后在 Settings 里把 Resources 的内存调到至少 8GB，因为 Dify 的 api 和 worker 两个容器加起来吃内存比较凶。Ollama 的 Windows 安装包直接下一步到底，装完后它会在后台注册一个服务，默认监听127.0.0.1:11434。

2.2 DeepSeek 模型在 Ollama 里的拉取与量化选择

Ollama 装好后，拉模型就是一行命令的事，但选哪个量化版本直接决定你后面跑得顺不顺。DeepSeek 系列在 Ollama 库里有多个尺寸，常见的是 7B 和 14B 的量化版。如果你的显卡显存是 8GB，老老实实拉 7B 的 q4 量化版；12GB 以上可以上 14B 的 q4；再大就没必要在 Windows 单机上折腾了，推理速度会掉到不可用。

ollama pull deepseek-r1:7b ollama list

拉完后先别急着接 Dify，单独测一下模型能不能正常出结果：

ollama run deepseek-r1:7b "用一句话说明什么是容器编排"

这里的关键参数是num_ctx，默认可能是 2048 或 4096，如果你后面要在 Dify 里挂知识库，上下文长度不够会直接截断检索结果。可以在 Modelfile 里改，也可以启动时用环境变量覆盖。我一般会在 Ollama 的启动参数里加OLLAMA_HOST=0.0.0.0:11434，让它在宿主机所有网卡上监听，这样 Docker 容器才能通过宿主 IP 访问到，否则默认只监听 127.0.0.1，容器里怎么调都是 connection refused。

2.3 Dify 镜像版本与 Docker Compose 文件调整

Dify 官方提供 docker-compose 部署方式，但直接拿默认文件在 Windows 上跑，大概率会在端口映射和卷挂载上出问题。我一般会做三处修改：第一，把 api 和 worker 的depends_on里对 db 和 redis 的健康检查超时调大，Windows 下磁盘 IO 慢，默认 30 秒经常不够；第二，把 nginx 的 80 端口映射改成 8080 或其他非保留端口，避免和 Windows 上已有的 IIS 或其它服务冲突；第三，在 api 容器的环境变量里显式指定 Ollama 的地址，不要用 localhost，要用宿主机的局域网 IP。

services: api: environment: - OLLAMA_API_BASE_URL=http://192.168.1.100:11434 - CODE_EXECUTION_ENDPOINT=http://192.168.1.100:11434

上面这个 IP 要换成你自己机器的实际局域网地址，用ipconfig查。逻辑说明：Docker 容器里的 localhost 指向容器自身，不是宿主机，所以必须用宿主机的真实 IP。参数上，OLLAMA_API_BASE_URL是 Dify 调用模型推理的入口，CODE_EXECUTION_ENDPOINT是代码执行沙箱的回调地址，两个都要改，漏一个就会出现“模型列表能拉到但对话报错”的怪现象。

3. 把 Dify 跑起来并接上 Ollama 的完整操作链

3.1 Docker Compose 启动与容器健康检查

Dify 的 docker-compose 文件拉下来后，先别急着up，用config命令验证一下语法：

docker compose config

确认没有变量未定义或缩进错误后，再启动：

docker compose up -d

启动完成后，用docker compose ps看容器状态，重点看 api、worker、db、redis、nginx 这几个是不是都处于 running 或 healthy。如果 api 一直重启，用docker compose logs api --tail 100看日志，最常见的报错是数据库连接超时，这时候把 db 的healthcheck里的start_period从 30s 改成 60s，再docker compose up -d一次。

这里有个细节：Windows 下 Docker Desktop 的磁盘挂载性能比 Linux 差很多，如果 Dify 的卷映射到了 Windows 文件系统上的目录，启动会非常慢。我一般会把数据卷放在 WSL2 的 ext4 文件系统里，或者直接用 Docker 的命名卷，不映射到宿主机目录。这样做的代价是数据不好直接备份，但换来的是启动速度和运行稳定性。

3.2 在 Dify 控制台配置 Ollama 模型供应商

容器全部 healthy 后，浏览器打开http://localhost:8080，第一次进会要求设置管理员账号。登录后进“设置”->“模型供应商”，找到 Ollama，点添加模型。这里要填两个关键字段：Base URL 和模型名称。Base URL 填http://<宿主机IP>:11434，模型名称填你在 Ollama 里list出来的那个名字，比如deepseek-r1:7b。

填完后点“测试连接”，如果报错，按这个顺序排查：先在 Windows 宿主机浏览器里访问http://<宿主机IP>:11434/api/tags，看能不能返回 JSON；如果不能，说明 Ollama 没监听在 0.0.0.0，回去改启动参数；如果能，但 Dify 里还是连不上，进 api 容器里用curl测同一个地址：

docker compose exec api curl http://192.168.1.100:11434/api/tags

如果容器里 curl 不通而宿主机浏览器能通，那就是 Windows 防火墙拦了 Docker 的虚拟网卡，去防火墙入站规则里放行 11434 端口，或者临时关掉防火墙验证。

3.3 用 Dify 编排一个最小可用对话应用

模型供应商配好后，创建一个“聊天助手”应用，在编排界面里把模型选成刚才添加的 Ollama DeepSeek。提示词可以先写一句简单的系统指令，比如“你是一个只回答技术问题的助手，不确定的内容直接说不知道”。然后点右上角“发布”，用预览窗口发一条消息测试。

如果模型能正常回复，说明整条链路已经通了。这时候可以进一步在“知识库”里上传一份 PDF 或 Markdown 文档，测试 RAG 流程。注意 Dify 的默认嵌入模型也是走 Ollama 的，如果你没拉嵌入模型，知识库会报错。常见做法是再拉一个nomic-embed-text：

ollama pull nomic-embed-text

然后在 Dify 的模型设置里把嵌入模型指向它。参数上，嵌入模型的num_ctx也要调大，否则长文档分块后会截断，检索召回率会明显下降。

4. 避坑与常见问题：那些让你怀疑人生的报错

4.1 容器里 curl 不通宿主 Ollama 的排查路径

现象：Dify 的 api 容器日志里反复出现Connection refused或Max retries exceeded，但宿主机浏览器访问 Ollama 地址正常。

原因：Ollama 默认只监听127.0.0.1，Docker 容器通过宿主 IP 访问时被拒绝；或者 Windows 防火墙没有放行 Docker 的虚拟网卡网段。

解决：在 Windows 系统环境变量里加OLLAMA_HOST=0.0.0.0:11434，重启 Ollama 服务；然后在防火墙高级设置里新建入站规则，允许 11434 端口的 TCP 连接，作用域选“任何”或至少包含 Docker 的网段。

4.2 Dify 启动时 db 容器健康检查一直不通过

现象：docker compose up -d后，api 容器不断重启，日志显示等待数据库就绪超时。

原因：Windows 下 Docker 的卷 IO 性能低，PostgreSQL 初始化时间比 Linux 长，默认的start_period和retries不够。

解决：编辑 docker-compose.yaml，把 db 服务的healthcheck改成start_period: 60s、retries: 10，然后docker compose down再up -d。如果还是不行，检查 Windows 的杀毒软件是否在扫描 Docker 的数据卷目录，把该目录加入排除列表。

4.3 模型回复速度极慢或直接超时

现象：在 Dify 里发一条消息，等了几分钟才出结果，或者直接报超时错误。

原因：DeepSeek 7B 模型在 CPU 上跑推理，或者显存不够导致部分层回落到 CPU；也可能是 Dify 的 api 容器内存不足，被 OOM Killer 杀掉了。

解决：确认 Ollama 是否在用 GPU，用ollama ps看模型的处理器占用；如果显示 100% CPU，说明 CUDA 或 ROCm 驱动没配好。另外把 Docker Desktop 的内存限制调到 12GB 以上，给 api 和 worker 留足空间。如果硬件确实不够，换更小的量化版模型，比如 q4_0 或 q3_K_S。

4.4 知识库上传文档后检索不到内容

现象：在 Dify 里建了知识库，上传了 PDF，但对话时模型说“没有找到相关信息”。

原因：嵌入模型没配置或配置错误；文档分块大小和重叠长度设置不合理；Ollama 的嵌入模型上下文长度不够。

解决：先在模型供应商里确认嵌入模型已添加且测试通过；然后把知识库的分块大小从默认的 500 改成 300，重叠从 50 改成 80，重新索引；最后检查嵌入模型的num_ctx，用ollama show nomic-embed-text看默认值，必要时在 Modelfile 里调大。

4.5 Windows 重启后 Docker 容器全部消失

现象：电脑重启后，docker compose ps显示没有任何容器，但镜像还在。

原因：Docker Desktop 的“Start Docker Desktop when you log in”没勾选，或者 WSL2 的默认发行版被切换了。

解决：在 Docker Desktop 设置里勾选开机自启；确认wsl --list --verbose里默认发行版还是当初装 Docker 时用的那个。如果 WSL 发行版被换过，Docker 的上下文会丢失，需要重新docker context use default。

5. 进阶技巧：让这套组合在 Windows 上跑得更稳的几个习惯

第一个习惯是把 Ollama 的模型存储目录从默认的 C 盘用户目录移到数据盘。Windows 下 C 盘空间被模型文件吃满是很常见的事，一个 7B 的 q4 模型大约 4GB，14B 的接近 9GB，多拉几个版本 C 盘就红了。改法是在系统环境变量里加OLLAMA_MODELS=D:\ollama-models，然后把原来目录里的文件移过去，重启 Ollama 服务。这个操作没有后悔药，移之前先确认目标盘有足够空间。

第二个习惯是给 Dify 的 docker-compose 加一个.env文件，把所有跟宿主机 IP、端口、密码相关的变量抽出来。这样换一台机器部署时，只改.env就行，不用去动 yaml 文件。我一般会定义这几个变量：

HOST_IP=192.168.1.100 DIFY_PORT=8080 OLLAMA_PORT=11434 POSTGRES_PASSWORD=your_password_here

然后在 compose 文件里用${HOST_IP}这种形式引用。注意.env文件不要提交到任何版本控制系统里，密码和 IP 信息泄露出去虽然不至于出大事，但会带来不必要的麻烦。

第三个习惯是定期用docker system df看磁盘占用，Dify 的日志和 Ollama 的临时文件会慢慢堆积。清理时用docker system prune -a要小心，它会删掉所有没在运行的镜像和卷，如果 Dify 的数据库卷被误删，知识库和对话记录就全没了。我一般只清 dangling 镜像和停止的容器，卷不动。

第四个习惯是给 Ollama 的推理请求加超时和重试。Dify 默认的模型请求超时是 60 秒，DeepSeek 7B 在 GPU 上跑一般够用，但如果上下文很长或者并发请求多，偶尔会超时。可以在 Dify 的模型配置里把超时调到 120 秒，同时在 Ollama 侧用OLLAMA_NUM_PARALLEL=2控制并发数，避免多个请求同时挤爆显存。这个参数在 8GB 显存的机器上尤其重要，设成 1 最稳，设成 2 以上大概率会触发 OOM。

最后一个习惯是每次改完配置后，不要直接docker compose restart，而是down再up -d。Windows 下 Docker 的 restart 有时不会重新读取环境变量，导致你改了.env但容器里还是旧值，然后花半小时排查一个根本不存在的 bug。这个血泪经验值一条：改配置，先 down，再 up。

希望帮到你。

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