简介：这份资源是面向Windows平台的本地化AI开发环境搭建指南，采用Docker、Dify、Ollama与DeepSeek组合方案，适合具备基础IT素养、专注自然语言处理或深度学习的学习者与从业者。内容围绕最低硬件要求（CPU≥2核、内存≥4GiB、磁盘≥20G）、Git与TortoiseGit及Docker安装、国内镜像源切换、Dify克隆与启动验证、Ollama模型路径配置与下载、文本嵌入模型集成等环节展开，并附Docker常用命令参考。资源包为1个docx文档，约923KB，目录从说明、适用环境、准备工作到Dify部署、Ollama部署、集成部署及附件共九章，结构清晰，便于按步骤查阅。已有3881人学习，可帮助读者快速搭建可运行的大模型实验环境，掌握容器化部署与模型集成思路，减少环境配置中的试错成本。

1. 为什么我劝你先别急着拉镜像：这套组合到底解决了什么

如果你手头只有一台 Windows 机器，却想跑一个能对话、能调工具、能接知识库的本地大模型应用，大概率会刷到 Docker + Dify + Ollama + DeepSeek 这套组合。我最初看到它时的反应是：四个东西叠在一起，是不是过度设计了？直到我把一套内部问答系统从零搭起来，才发现这个组合的每一层都有明确的职责边界——Docker 负责环境隔离，Ollama 负责模型推理，DeepSeek 提供权重，Dify 负责编排和前端交互。拆开看每个都不复杂，合在一起才是完整的本地化方案。

这套方案适合三类人：一是数据不能出内网的团队，二是想低成本验证 AI 应用原型的开发者，三是需要离线演示的技术人员。它不追求极致性能，追求的是「可控」——模型在本地、数据在本地、编排逻辑也在本地。下面我按实际搭建顺序，把每一步的参数、坑和验证方法讲清楚。

2. 环境准备：Docker Desktop 与 WSL2 的版本对齐

2.1 为什么 Windows 上必须走 WSL2 后端

Docker Desktop 在 Windows 上有两种后端：Hyper-V 和 WSL2。跑 Ollama 和 Dify 这类需要频繁文件挂载、网络转发的场景，WSL2 是唯一不折腾的选择。Hyper-V 模式下容器访问宿主机文件系统要经过一层网络映射，模型文件动辄几个 GB，加载速度会明显变慢。WSL2 则直接共享内核，挂载卷的性能接近原生。

安装前先确认 Windows 版本：Win10 需要 21H2 及以上，Win11 全版本支持。在「启用或关闭 Windows 功能」里勾选「适用于 Linux 的 Windows 子系统」和「虚拟机平台」，然后重启。这一步不做，后面 Docker Desktop 启动时会直接报 WSL2 内核未安装。

# 以管理员身份打开 PowerShell，安装 WSL2 并设为默认 wsl --install wsl --set-default-version 2 # 验证 WSL 版本，输出应为 2 wsl --list --verbose

wsl --install会自动装好 Ubuntu 发行版和内核更新包。--set-default-version 2确保后续新建的发行版都用 WSL2。--list --verbose用来确认 VERSION 列是 2，如果是 1，用wsl --set-version <发行版名> 2单独转换。

2.2 Docker Desktop 安装与资源分配

从官网下载 Docker Desktop 安装包，安装时勾选「Use WSL 2 instead of Hyper-V」。装完后进入 Settings → Resources，把内存调到至少 8GB，CPU 给 4 核以上。Ollama 加载 7B 模型时，光模型权重就要占 4-5GB 内存，Dify 的 API 服务和数据库还要再分 2GB 左右。如果机器只有 16GB 内存，建议把 Dify 的 PostgreSQL 和 Redis 用轻量配置跑。

# 安装完成后验证 Docker 和 Compose 版本 docker --version docker compose version # 拉一个测试镜像确认网络和存储正常 docker run --rm hello-world

docker compose version输出应为 v2.x，Dify 的编排文件用的是 Compose V2 语法，V1 的docker-compose命令会有兼容问题。hello-world能跑通说明镜像拉取、容器创建、存储驱动都没问题，这是后续所有操作的基础。

提示：如果hello-world卡在拉取阶段，先检查 Docker Desktop 的代理设置。公司网络环境下经常需要配置 HTTP 代理才能访问镜像仓库，这个在 Settings → Resources → Proxies 里填。

3. Ollama 部署与 DeepSeek 模型拉取：从拉取到推理的完整链路

3.1 Ollama 的容器化运行与端口映射

Ollama 官方提供了 Docker 镜像，但直接docker run有个坑：模型文件默认存在容器内部，容器一删模型就没了。正确做法是把模型目录挂载到宿主机，这样升级镜像或重建容器时不用重新下载几十 GB 的权重。

# 创建宿主机模型存储目录 mkdir -p D:/ollama/models # 启动 Ollama 容器，映射 11434 端口，挂载模型目录 docker run -d \ --name ollama \ -p 11434:11434 \ -v D:/ollama/models:/root/.ollama \ --restart unless-stopped \ ollama/ollama:latest

-p 11434:11434把容器内的 API 端口暴露到宿主机，Dify 后面要通过这个端口调用推理服务。-v D:/ollama/models:/root/.ollama是关键，Ollama 在容器内把模型存在/root/.ollama，挂载后实际落在 Windows 的 D 盘。--restart unless-stopped保证开机自启，但手动停止后不会自动拉起，适合调试阶段。

3.2 DeepSeek 模型选型与拉取参数

DeepSeek 在 Ollama 上有多个尺寸，常见的是deepseek-r1:7b、deepseek-r1:14b和deepseek-coder系列。7B 版本在 16GB 内存的机器上能跑，但推理速度大概每秒 5-10 个 token；14B 需要 32GB 内存才比较流畅。如果只是做功能验证，7B 足够；如果要接知识库做问答，建议至少 14B，否则回答质量下降明显。

# 进入容器执行拉取，避免 Windows 终端编码问题 docker exec -it ollama ollama pull deepseek-r1:7b # 查看已下载的模型列表 docker exec -it ollama ollama list # 测试推理，输入一段提示词看输出 docker exec -it ollama ollama run deepseek-r1:7b "用一句话解释什么是容器"

ollama pull会从官方仓库下载模型权重，7B 版本大约 4.7GB，下载时间取决于网络。ollama list显示模型名称、大小和修改时间，用来确认下载完整。ollama run进入交互模式，输入问题后模型会流式输出，第一次加载会有几秒延迟，之后响应会快一些。

注意：如果拉取过程中断，重新执行ollama pull会断点续传，不用删掉已下载的部分。但如果是磁盘空间不足导致的失败，需要先清理D:/ollama/models下的临时文件。

3.3 验证 Ollama API 是否可用

Dify 调用 Ollama 走的是 HTTP API，所以在接入之前先用 curl 确认接口通。这一步能排除掉大部分「Dify 连不上模型」的问题。

# 查看模型列表接口 curl http://localhost:11434/api/tags # 发送推理请求，stream 设为 false 方便看完整响应 curl http://localhost:11434/api/generate -d "{\"model\":\"deepseek-r1:7b\",\"prompt\":\"你好\",\"stream\":false}"

/api/tags返回 JSON 格式的模型清单，如果能正常输出说明 Ollama 服务在运行。/api/generate是推理接口，stream:false让响应一次性返回，方便调试。如果返回connection refused，检查容器是否在运行：docker ps | grep ollama。

4. Dify 编排层部署：数据库、Redis 与 API 服务的联动

4.1 用 Compose 拉起 Dify 全家桶

Dify 的部署文件在官方仓库的docker目录下，核心是docker-compose.yaml。它包含五个服务：api负责后端逻辑，web是前端界面，worker处理异步任务，db是 PostgreSQL，redis做缓存和消息队列。直接docker compose up -d就能全部拉起，但有几个环境变量必须提前改。

# 克隆 Dify 仓库（如果已有可跳过） git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 编辑 .env，重点改这几项 # EXPOSE_NGINX_PORT=80 # 前端访问端口 # DB_PASSWORD=dify1234 # 数据库密码，改成自己的 # REDIS_PASSWORD=dify1234 # Redis 密码 # OLLAMA_API_BASE_URL=http://host.docker.internal:11434

OLLAMA_API_BASE_URL是最关键的配置。Dify 的容器内部访问宿主机的 Ollama，不能用localhost，因为容器里的localhost指向容器自身。host.docker.internal是 Docker Desktop 提供的特殊域名，解析到宿主机 IP。如果这个变量不设，Dify 添加模型时会一直报连接超时。

# 启动所有服务 docker compose up -d # 查看服务状态，确认所有容器都是 running docker compose ps # 查看 api 服务日志，排查启动错误 docker compose logs -f api

docker compose up -d会按依赖顺序启动，PostgreSQL 和 Redis 先起来，然后才是 api 和 worker。docker compose ps的 STATUS 列显示Up才算正常，如果某个服务是Exit，用logs看具体报错。常见问题是数据库密码不一致导致 api 连不上 db，改.env后要docker compose down再up才能生效。

4.2 在 Dify 中添加 Ollama 模型供应商

服务全部起来后，浏览器访问http://localhost（或你改的端口），首次进入要设置管理员账号。登录后在右上角头像 → 设置 → 模型供应商里找到 Ollama，点添加模型。

填完后点「保存」，Dify 会发一个测试请求到 Ollama。如果提示连接失败，先回到上一步确认OLLAMA_API_BASE_URL是否写对，再检查 Ollama 容器是否在运行。测试通过后，在「系统模型设置」里把默认对话模型选成刚添加的 DeepSeek，这样新建应用时就不用每次手动选了。

4.3 创建一个最小可用的对话应用

在 Dify 首页点「创建应用」→「聊天助手」，填个名字比如「本地问答测试」。进入编排界面后，在「提示词」区域写一段系统指令，比如「你是一个本地部署的助手，回答要简洁」。右侧调试窗口直接输入问题，如果能收到 DeepSeek 的回复，说明整条链路已经通了。

# 这是 Dify 应用编排的简化结构，实际在界面上操作即可 app: name: 本地问答测试 mode: chat model: provider: ollama name: deepseek-r1:7b prompt: system: "你是一个本地部署的助手，回答要简洁"

这个结构对应界面上填的内容，provider选 Ollama，name是模型名，system是系统提示词。调试通过后点「发布」，就能通过 API 或嵌入页面访问了。

5. 避坑排查：五个让我重装三次的典型问题

5.1 容器间网络不通，Dify 报连接超时

现象：Dify 添加 Ollama 模型时提示Connection refused或Timeout，但宿主机 curl 能正常访问localhost:11434。

原因：Dify 容器内的localhost指向容器自身，不是宿主机。必须用host.docker.internal这个特殊域名，且 Ollama 容器要暴露端口到宿主机。

解决：确认.env里OLLAMA_API_BASE_URL=http://host.docker.internal:11434，然后docker compose down && docker compose up -d重建容器。如果还不行，在 Dify 的 api 容器里执行curl http://host.docker.internal:11434/api/tags手动测试连通性。

5.2 模型加载失败，Ollama 日志报内存不足

现象：ollama run时卡在loading model然后退出，日志显示out of memory。

原因：Docker Desktop 默认给 WSL2 分配的内存可能只有 4GB，7B 模型加载需要 5GB 以上。

解决：在 Windows 用户目录下创建.wslconfig文件，限制 WSL2 的资源上限。改完后wsl --shutdown重启 WSL。

# 文件位置：C:\Users\你的用户名\.wslconfig [wsl2] memory=12GB processors=6 swap=8GB

memory根据物理内存调整，16GB 机器给 12GB 比较稳妥。swap设 8GB 作为溢出缓冲，但不要依赖 swap，速度会慢很多。

5.3 Dify 数据库密码不一致导致启动失败

现象：docker compose ps显示 db 是Up，但 api 反复重启，日志报password authentication failed。

原因：.env里的DB_PASSWORD和 PostgreSQL 容器初始化时用的密码不一致。PostgreSQL 只在数据卷为空时读取环境变量创建用户，如果之前用旧密码初始化过，改.env不会生效。

解决：删掉数据卷重新初始化，或者进入 db 容器手动改密码。最彻底的方式是docker compose down -v删掉所有卷，再up -d重建。注意这会清空所有数据，只适合调试阶段。

5.4 端口冲突导致 Nginx 启动失败

现象：docker compose up报port is already allocated，通常是 80 或 443 被占用。

原因：Windows 上 IIS、Skype 或其他服务可能占了 80 端口。

解决：改.env里的EXPOSE_NGINX_PORT为其他端口，比如 8080，然后重建。用netstat -ano | findstr :80查看占用进程，确认不是关键服务后可以停掉。

5.5 模型回复乱码或截断

现象：Dify 调试窗口里 DeepSeek 的回复出现乱码，或者只输出一半就停了。

原因：通常是上下文长度设置超过模型实际支持的值，或者 token 上限太小导致截断。

解决：在 Dify 模型配置里把上下文长度改成 4096，最大 token 改成 2048。如果还是乱码，检查 Ollama 容器的日志有没有编码报错，必要时在docker run时加-e LANG=C.UTF-8环境变量。

6. 进阶技巧：用 API 把本地模型接进现有系统

6.1 Dify 应用 API 的调用方式

Dify 发布应用后，在「访问 API」页面能拿到一个 API Key。用这个 Key 可以像调用 OpenAI 一样调用本地部署的 DeepSeek，区别只是 base URL 指向你自己的 Dify 实例。

import requests API_KEY = "app-xxxxxxxxxxxx" # 从 Dify 访问 API 页面获取 BASE_URL = "http://localhost/v1" def chat(query: str) -> str: """调用 Dify 聊天接口，返回模型回复""" resp = requests.post( f"{BASE_URL}/chat-messages", headers={ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" }, json={ "inputs": {}, "query": query, "response_mode": "blocking", # blocking 一次性返回，streaming 流式 "user": "local-test" }, timeout=60 ) resp.raise_for_status() return resp.json()["answer"] if __name__ == "__main__": print(chat("用一句话说明什么是 Docker"))

response_mode选blocking时接口会等模型生成完再返回，适合脚本调用；选streaming则返回 SSE 流，适合做打字机效果。user字段用于区分会话来源，同一个 user 的多次请求会共享上下文。timeout设 60 秒是因为本地模型首次加载可能较慢，设太短会误报超时。

6.2 用 Ollama 原生 API 做轻量集成

如果不需要 Dify 的编排能力，只想直接调模型，可以绕过 Dify 直接用 Ollama 的 API。这种方式延迟更低，适合做命令行工具或简单脚本。

import requests import json def ollama_chat(prompt: str, model: str = "deepseek-r1:7b") -> str: """直接调用 Ollama 推理接口""" resp = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": { "temperature": 0.7, # 控制随机性，0 最确定，1 最发散 "num_predict": 512 # 最大生成 token 数 } }, timeout=120 ) resp.raise_for_status() return resp.json()["response"] # 测试 print(ollama_chat("解释一下什么是容器编排"))

temperature设 0.7 是通用场景的平衡值，做代码生成可以降到 0.2，做创意写作可以升到 0.9。num_predict限制单次生成的最大 token 数，设太小会导致回答被截断，设太大则可能浪费显存。这两个参数在 Dify 里也有对应配置，但直接调 Ollama 时更灵活。

6.3 验证部署是否真正可用

搭完之后别只看界面能回复就完事，跑一个完整的验证流程：重启电脑 → 等 Docker Desktop 自动启动 → 确认 Ollama 和 Dify 容器都自动拉起 → 在 Dify 里发一条消息 → 收到回复。这个流程走通，才算真正可用的本地化部署。

我自己的习惯是每次改完配置后，先docker compose ps看状态，再docker exec ollama ollama list确认模型在，最后用 curl 打一次 API。这三步走完，基本能排除 90% 的问题。从那以后我每次部署新环境都强制走一遍这个检查清单，省了很多来回折腾的时间。希望帮到你。

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