简介这份资源是面向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 --verbosewsl --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把内存调到至少 8GBCPU 给 4 核以上。Ollama 加载 7B 模型时光模型权重就要占 4-5GB 内存Dify 的 API 服务和数据库还要再分 2GB 左右。如果机器只有 16GB 内存建议把 Dify 的 PostgreSQL 和 Redis 用轻量配置跑。# 安装完成后验证 Docker 和 Compose 版本 docker --version docker compose version # 拉一个测试镜像确认网络和存储正常 docker run --rm hello-worlddocker compose version输出应为 v2.xDify 的编排文件用的是 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 个 token14B 需要 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是 PostgreSQLredis做缓存和消息队列。直接docker compose up -d就能全部拉起但有几个环境变量必须提前改。# 克隆 Dify 仓库如果已有可跳过 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 编辑 .env重点改这几项 # EXPOSE_NGINX_PORT80 # 前端访问端口 # DB_PASSWORDdify1234 # 数据库密码改成自己的 # REDIS_PASSWORDdify1234 # Redis 密码 # OLLAMA_API_BASE_URLhttp://host.docker.internal:11434OLLAMA_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 apidocker 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点添加模型。配置项填写值说明模型类型LLM对话类模型选这个模型名称deepseek-r1:7b必须和ollama list输出一致Base URLhttp://host.docker.internal:11434容器内访问宿主机的固定写法模型上下文长度40967B 模型建议值14B 可设 8192最大 token 数2048单次回复上限按需调整填完后点「保存」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选 Ollamaname是模型名system是系统提示词。调试通过后点「发布」就能通过 API 或嵌入页面访问了。5. 避坑排查五个让我重装三次的典型问题5.1 容器间网络不通Dify 报连接超时现象Dify 添加 Ollama 模型时提示Connection refused或Timeout但宿主机 curl 能正常访问localhost:11434。原因Dify 容器内的localhost指向容器自身不是宿主机。必须用host.docker.internal这个特殊域名且 Ollama 容器要暴露端口到宿主机。解决确认.env里OLLAMA_API_BASE_URLhttp://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 分配的内存可能只有 4GB7B 模型加载需要 5GB 以上。解决在 Windows 用户目录下创建.wslconfig文件限制 WSL2 的资源上限。改完后wsl --shutdown重启 WSL。# 文件位置C:\Users\你的用户名\.wslconfig [wsl2] memory12GB processors6 swap8GBmemory根据物理内存调整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 LANGC.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: fBearer {API_KEY}, Content-Type: application/json }, json{ inputs: {}, query: query, response_mode: blocking, # blocking 一次性返回streaming 流式 user: local-test }, timeout60 ) 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 数 } }, timeout120 ) 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% 的问题。从那以后我每次部署新环境都强制走一遍这个检查清单省了很多来回折腾的时间。希望帮到你。本文还有配套的精品资源点击获取