简介一份面向Windows用户的Dockerdifyollamadeepseek组合方案本地化部署指南专为具备基础IT素养、希望搭建大语言模型与自然语言处理实验环境的开发者或专业人士编写。文档从最低硬件要求CPU≥2核、内存≥4GB、磁盘≥20GB讲起涵盖Git、TortoiseGit和Docker的安装、国内镜像源切换随后分步演示dify从克隆代码到启动访问的完整流程并详细说明Ollama的非C盘存储配置与模型下载验证以及集成部署时文本嵌入模型的选择要点最后附上常用Docker命令供排查参考。资源包共1个docx文件大小约923KB内容组织清晰便于按章节逐步操作。目前已有3879人学习适合需要快速搭建AI开发环境并深入探索机器学习、深度学习前沿应用的读者作为实践参考。1. Docker Dify Ollama DeepSeek 的 Windows 本地化部署为什么说底座才是最大门槛先把标题里的组合说清楚Docker 负责运行 DifyDify 负责搭建 AI 应用Ollama资源标题里写成 ollma实际是 Ollama负责在本地拉起模型DeepSeek 在这里是模型权重整套跑在 Windows 上。我拆这套方案时最大的感受是真正卡人的不是 AI 推理而是 Windows 上的 Docker 底座。你没把 WSL2、虚拟化、端口映射捋顺Dify 起来也接不上模型。我会按“环境准备 → 平台部署 → 模型接入 → 排错 → 落地”的顺序把每一步的参数和坑一次性讲完。适合不想把数据交给云端、想在笔记本里私有化跑一套 LLM 应用链路的开发者和运维人员。2. 装对 Docker Desktop 和 Ollama虚拟化、WSL2、模型拉取一次讲清2.1 装 Docker Desktop 前先确认 Windows 虚拟化状态很多新手上来就装 Docker Desktop然后双击图标弹出Virtualization support not detected第一反应是重新安装其实问题在底层。Windows 跑 Docker Desktop 依赖 Hyper-V 或 WSL2这两者都需要 CPU 虚拟化在 BIOS 层面打开。我一般先用系统信息命令确认一下虚拟化是否已经启用。PowerShell 里执行# 查看系统 Hyper-V 相关状态 systeminfo | findstr /i Hyper-V能看到类似Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。这样的文本说明虚拟化已经可用。如果显示“未检测到虚拟机监控程序”或者“Hyper-V 要求: 已列出虚拟机监控程序”但后面跟的是“不支持”就要进 BIOS 打开 Intel VT-x 或 AMD SVM。提示Windows 家庭版没有完整 Hyper-V 管理工具但可以启用 WSL2 后端Docker Desktop 照样能跑。只要 CPU 虚拟化开启并且 Windows 更新到 21H2 以上问题不大。确认虚拟化之后打开“启用或关闭 Windows 功能”勾选“适用于 Linux 的 Windows 子系统”和“Windows 虚拟机监控程序平台”。这一步做完必须重启。重启后跑wsl --status能看到 WSL 版本和默认发行版信息就说明 WSL2 子系统就绪了。这里有个容易忽略的点Docker Desktop 安装包建议右键“以管理员身份运行”安装目录别放系统盘也行但低配机器我会装在 C 盘以避免跨盘符的 Docker 数据目录引路问题。安装完成后打开 Docker Desktop在 Settings - General 中勾选Use the WSL 2 based engine这样 Docker 容器实际跑在 WSL2 里而不是老旧的 Hyper-V 虚拟机模式。2.2 安装 Ollama 并拉取 DeepSeek 权重Ollama 的 Windows 安装就是官网下载 exe 然后一路下一步装好之后系统托盘会出现一只小羊驼图标。这里有个血泪经验Ollama 默认安装后服务只监听127.0.0.1这个后面接 Dify 时一定会翻车所以要提前设置环境变量OLLAMA_HOST0.0.0.0:11434。设置环境变量的方式是Windows 搜索“环境变量”在系统变量里新建OLLAMA_HOST值填0.0.0.0:11434然后重启 Ollama。如果不想改全局也可以在 PowerShell 里临时指定# 当前终端临时指定监听地址 $env:OLLAMA_HOST0.0.0.0:11434 ollama serve用ollama serve手动起服务时这个环境变量只对当前终端有效。我建议直接改系统环境变量然后右键托盘图标退出 Ollama再重新启动这样 Windows 服务用的才是新配置。后面连接 Dify 时如果遇到connection refused大概率就是这一步没做。模型拉取命令# 拉取 DeepSeek-R1 的 7B 量化版本 ollama pull deepseek-r1:7b这条命令会从 Ollama 的模型仓库拉取 DeepSeek-R1 的 7B 参数量化版本。我第一次拉的时候没看大小结果发现下载体积不是小数好在断点续传还算稳定。拉完用ollama list确认# 列出本地已安装模型 ollama list输出里会列出deepseek-r1:7b以及它的 ID 和大小。如果内存只有 8G我建议用更小的量化版# 拉取更小的 1.5B 版本用于联通性验证 ollama pull deepseek-r1:1.5b1.5b参数量的版本在 CPU 上也能跑回答质量比 7B 差一些但作为联通性验证足够了。参数说明deepseek-r1是模型系列名冒号后面是标签常见标签有1.5b、7b、8b、14b数字越小占用资源越低。拉取失败时先看磁盘剩余空间再看网络是否稳定Ollama 官方仓库不在国内但这里我们不展开网络优化手段。2.3 验证 Ollama 的 API 是否通畅模型落盘后不要急着去连 Dify先用 curl 探一下接口# 查看 Ollama 本地 API 状态和模型列表 curl http://localhost:11434/api/tags正常会返回一个 JSON里面的models数组包含所有已安装模型的信息。这一步相当于确认“模型服务已经起来了而且接口协议是标准 OpenAI 风格兼容的”。如果你返回的是连接拒绝说明 Ollama 服务没跑起来或者端口被占用如果用localhost通但后面 Dify 容器内不通那就是监听地址的问题回看 2.2 节的OLLAMA_HOST设置。注意Dify 连接 Ollama 实际是走 OpenAI 兼容接口因此需要确认 Ollama 版本支持这一协议。新版本默认都支持老版本建议升级到新版否则会出现能拉模型但 Dify 校验过不了的情况。现在底座已经齐了Docker 和 WSL2 状态正常Ollama 能提供模型推理服务。接下来进入 Dify 平台部署。3. 用 Docker Compose 拉起 Dify 平台.env 配置与容器验证3.1 准备 Dify 的部署文件Dify 是一个开源 LLM 应用开发平台官方仓库里直接带了一套 docker 编排目录。Windows 上不需要自己手写 Dockerfile只需要拿到源码包里的docker目录然后执行docker compose up就行。常见做法是去 Dify 的 GitHub Releases 页面下载对应版本的源码包解压后进入dify-main/docker目录。我习惯只保留docker目录其他源码不看。打开这个目录你会看到docker-compose.yaml、.env.example、volumes目录等材料。这里先解释一下这套编排文件里到底有几个角色。api是 Dify 的后端服务worker是异步任务执行器web是前端页面db是 PostgreSQLredis做缓存队列sandbox跑用户代码插件ssrf_proxy负责过滤外部请求。这 7 个容器必须协同工作所以最好用 compose 一次性拉起不要手动一个个docker run。进入目录后第一步是把环境变量模板复制一份# 从示例文件生成 Dify 的环境变量文件 cp .env.example .env然后打开.env文件最需要改的是这几个SECRET_KEYDify 用它做会话加密必须改成一个随机长字符串。可以用 PowerShell 生成-join ((48..57)(65..90)(97..122) | Get-Random -Count 32 | % {[char]$_})。POSTGRES_PASSWORD数据库密码默认是difyai测试环境可以不改但端口暴露到局域网就必须改。EXPOSE_NGINX_PORTDify 对外访问的端口默认80。如果 Windows 上 80 端口被占用改成8080或8000。还有几个不常改但值得了解的参数POSTGRES_PORT默认 5432如果你本机已经装了 PostgreSQL需要改成其他端口比如 5433REDIS_PORT同理。这些端口改完后compose 内部服务之间使用容器网络互访不受宿主机端口影响但宿主机访问数据库和 Redis 时要用新端口。3.2 修改 compose 文件让 Dify 容器能访问宿主机 Ollama这里是最关键的一步。Dify 的容器跑在 WSL2 里容器里的localhost指向容器自己不是 Windows 宿主机。要让 Dify 访问宿主机上 Ollama 的 11434 端口需要在docker-compose.yaml中给api和worker两个服务加上extra_hostsapi: extra_hosts: # 让容器内能通过 host.docker.internal 访问宿主机 - host.docker.internal:host-gateway worker: extra_hosts: - host.docker.internal:host-gateway加完后Dify 内部访问http://host.docker.internal:11434就能打到你 Windows 宿主机上的 Ollama。如果你在 Docker Desktop 的较新版本里跑 Linux 容器host-gateway是个自动映射宿主机地址的关键字不用再去查 WSL2 的 IP。注意host.docker.internal在 Docker Desktop 的 WSL2 模式下默认不一定可用所以显式声明extra_hosts是最稳的做法。这也是为什么很多教程只讲在 Dify 里填localhost:11434导致失败的原因。改完 compose 文件后执行启动命令# 后台拉起 Dify 全部容器服务 docker compose up -d-d表示后台运行。第一次启动会拉取镜像时间取决于网络和镜像体积可能要等一阵。中途如果卡在某个镜像拉取上不要连续 CtrlC先看是哪个服务的镜像失败了。常见情况是sandbox镜像比较大耐心等待即可。3.3 检查容器状态与日志启动完成后用docker compose ps查看所有服务状态。理想情况下STATUS列应该是UpHEALTHY字段如果显示healthy就说明健康检查通过了。我遇到最多的情况是api容器起不来所以单独看它的日志# 持续跟踪 api 容器日志 docker compose logs -f api日志尾部如果出现Listening at: http://0.0.0.0:5000说明 API 服务已经就绪。如果出现Connection refused或FATAL通常是 PostgreSQL 还没就绪等待几十秒后再次查看即可。Dify 的 api 容器在启动阶段会等待数据库和 Redis所以第一次启动时日志里出现retrying是正常的别急着重启。如果api反复重启检查.env里SECRET_KEY是否为空以及POSTGRES_PASSWORD是否和docker-compose.yaml里的默认值一致。很多时候是手工改乱了导致api连不上数据库。容器日志里如果出现password authentication failed for user dify那基本就是密码不匹配回看.env中POSTGRES_PASSWORD的值。3.4 初始化 Dify 管理员账号然后是web容器它是纯静态资源服务默认映射到宿主机 80 端口。如果你前面把EXPOSE_NGINX_PORT改成了8080访问地址就是http://localhost:8080。浏览器打开后应该看到一个安装引导页。安装引导页会要求设置管理员邮箱和密码这一步填好后 Dify 会自动建库建表等待约一分钟。初始化完成后进入登录页用刚才的账号登录你会看到 Dify 的主界面。此时平台已经可用但还没有任何模型下面进入模型接入环节。4. 把 DeepSeek 接进 Dify模型供应商参数与连接测试4.1 在 Dify 控制台找到 Ollama 供应商登录 Dify 后点击右上角头像进入“设置”左侧菜单找到“模型供应商”。在供应商列表里找到 “Ollama”点击“安装”或“添加模型”。这里会有一个表单需要填模型类型、模型名称、Base URL 和上下文长度等参数。我建议先不要直接填 Dify 界面而是先在 PowerShell 里用 curl 确认 Ollama 的 OpenAI 兼容接口是通的# 查看 Ollama 的 OpenAI 兼容模型列表 curl http://localhost:11434/v1/models如果返回 JSON 列表说明 Ollama 已经开启了 OpenAI 兼容 API。Dify 添加模型时模型类型选“对话模型”LLM模型名称填你在ollama list里看到的标签比如deepseek-r1:7b。Base URL 填http://host.docker.internal:11434不是http://localhost:11434。上下文长度按照模型实际情况填deepseek-r1:7b建议填 4096 或 8192。这里有个容易搞混的点ollama pull时指定的模型标签是唯一的Dify 表单里也必须一模一样。如果ollama list输出的是deepseek-r1:7b就不要填deepseek-r1也不要填deepseek-r1:latest。Dify 校验时是通过 API 获取模型列表后逐一比对差一个字符都会失败。4.2 关键参数逐个说明参数推荐值说明模型类型对话模型 (LLM)如果用于嵌入或排序要单独添加DeepSeek 目前不常用作 embedding模型名称deepseek-r1:7b必须和ollama list输出完全一致Base URLhttp://host.docker.internal:11434容器内访问宿主机的唯一正确入口上下文长度4096超出会报 context length exceeded温度0.7对话任务常用R1 推理任务建议 0.2 以下Prompt 提示词可留空之后在应用编排里单独写上下文长度这个参数值得单独说。Ollama 模型的上下文窗口由模型本身和OLLAMA_CONTEXT_LENGTH环境变量共同决定Dify 侧填的值只是在请求里声明的max_tokens上限。如果你把 Dify 的上下文长度填得比模型实际支持的大请求时 Ollama 可能会报context length exceeded。反之填得太小长文档知识库在召回后放不下回答会不完整。对于deepseek-r1:7b4096 是最稳的选择需要更长时再调整。4.3 用聊天助手验证一次完整推理模型添加成功后回到 Dify 首页点击“创建应用”选“聊天助手”。在应用编排页的右上角模型下拉框里选择刚才添加的 Ollama / deepseek-r1:7b。然后在左下角的调试对话区输入一句测试问题比如“用一句中文解释 Docker 的 Overlay2 存储驱动”。这里有个值得注意的细节Dify 的聊天助手会把提示词、变量和历史消息拼装后发送给模型。第一次测试如果响应比较慢需要先确认是模型推理慢还是接口连接有延迟。打开 Docker Desktop 的容器日志界面选中api容器查看请求日志里有没有Ollama相关的响应时间记录。如果你看到 5 秒以上的生成耗时在 CPU 推理场景下是正常的不要误判成故障。如果日志中出现 HTTP 500先别急着改 Dify 配置。直接绕过 Dify 用 curl 向 Ollama 发一次同样的问题# 直接用 OpenAI 兼容接口测试 Ollama 推理 curl http://localhost:11434/v1/chat/completions -H Content-Type: application/json -d {\model\:\deepseek-r1:7b\,\messages\:[{\role\:\user\,\content\:\你好\}]}能正常返回内容说明模型服务本身没问题问题出在 Dify 和 Ollama 之间的参数传递上。常见原因是 Dify 发送的temperature或max_tokens数值超出 Ollama 允许范围可以把 Dify 里的温度调到 0.7最大令牌数调到 500 再试。测试成功之后应用就可以用了。但真正要落地到业务里还需要配置“提示词编排”或者“知识库”。在测试阶段先确保模型能正常回复然后回到模型供应商页面确认状态显示“可用”。这样链路算打通了。5. Windows 本地化部署避坑Docker、Dify、Ollama 组合的五个高频故障5.1 Docker Desktop 启动报错Virtualization support not detected现象双击 Docker Desktop 图标提示Virtualization support not detected或Docker Desktop failed to start because virtualization support is not detected即使重装也一样。原因BIOS 中的 CPU 虚拟化没有被打开或者 Windows 的 Hyper-V / WSL2 功能没有启用。Docker Desktop 依赖这两个底层能力缺一个都会直接报错。解决重启机器进入 BIOS找到Intel Virtualization Technology或SVM Mode设为 Enabled保存重启后在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机监控程序平台”再次重启。然后在管理员 PowerShell 里执行wsl --set-default-version 2确保 WSL 默认版本是 2再启动 Docker Desktop。我组里有两台机器都是这种报错一台是 BIOS 没开一台是装完没重启处理完再没复发。5.2 Dify 容器内访问 Ollama 报 Connection refused现象在 Dify 里添加 Ollama 模型填写http://localhost:11434点击保存后报connection refused或Failed to establish connection。原因Dify 的api容器跑在 WSL2 的独立网络命名空间里容器内的localhost指向容器自己而不是 Windows 宿主机。Ollama 服务默认也只监听127.0.0.1双重因素叠加后必然连不上。解决先在.env或系统环境变量中设置OLLAMA_HOST0.0.0.0:11434并重启 Ollama然后在docker-compose.yaml的api服务和worker服务中都加上extra_hosts: - host.docker.internal:host-gateway最后 Dify 表单中的 Base URL 填http://host.docker.internal:11434。改完需要docker compose up -d重建容器。注意光改.env不够Ollama 服务重启后才生效。5.3 Dify 提示 An error occurred during credentials validation现象模型供应商表单填写完成后Dify 弹出An error occurred during credentials validation保存不了模型。原因这个问题很少是 Dify 代码出 bug绝大多数是模型名称与 Ollama 返回的模型 ID 不一致。比如你ollama pull时写了deepseek-r1:7b但 Dify 里多填了个空格或者把标签写成了deepseek-r1都会导致校验失败。另外部分 Ollama 老版本没有开启 OpenAI 兼容接口也会报同样的错。解决在 PowerShell 执行curl http://host.docker.internal:11434/v1/models把返回 JSON 里的model字段原样复制到 Dify。如果接口返回 404说明 Ollama 版本太老升级到支持 OpenAI 兼容 API 的版本。还有一种玄学情况是 Base URL 结尾多写了/v1Dify 的 Ollama 集成已经自带路径所以一律只填到端口号。5.4 DeepSeek 响应很长或直接 timeout现象应用已经能回复但输入问题后要等十几甚至几十秒才出第一个字Dify 侧出现timeout或者模型回答到一半就断了。原因DeepSeek-R1 是推理模型默认会生成很长的思维链内容即便 7B 量化版在 CPU 上也要不少时间。Docker Desktop 默认分配的资源可能只有 2 核 4G连 WSL2 系统本身都不够分推理速度自然没法看。解决打开 Docker Desktop 的 Settings - Resources把 CPU 提高到 4 核以上内存至少 8G点击 Apply 后重启 Docker。另外在 Ollama 启动时可以通过环境变量OLLAMA_NUM_PARALLEL1强制串行推理避免多个请求挤占资源。如果仍然慢换deepseek-r1:1.5b或deepseek-coder:1.3b这类小模型。5.5 Windows 端口启动时报 bind 失败现象docker compose up -d之后日志里提示bind: An attempt was made to access a socket in a way forbidden by its access permissionsDify 的web或nginx容器无法绑定端口。原因Windows 上 Hyper-V / WSL2 会保留一部分动态端口或者有别的进程占用了 80 端口。常见元凶是 IIS、SQL Server 报表服务甚至商店应用也会占用 80。Dify 的EXPOSE_NGINX_PORT如果设成 80就很容易撞上。解决先用netstat -ano | findstr :80查看是谁占用了端口如果找到 PID再在任务管理器里定位进程。不想杀进程的话直接改.env里的EXPOSE_NGINX_PORT8080然后重启容器。注意修改后访问地址也变成http://localhost:8080。如果确定是 Windows 保留端口可以在管理员 PowerShell 里执行netsh interface ipv4 show excludedportrange protocoltcp查看保留段把EXPOSE_NGINX_PORT改到保留段之外。还有一点容易忘改端口后要docker compose down再up -d单纯restart可能不加载新配置。6. 收尾技巧用 Dify 搭一个能检索本地文档的知识库问答当模型接入验证通过就可以从“聊天助手”升级成“知识库问答”了。Dify 的“知识库”模块在左侧菜单单独存在本质上是把本地文档做切片、向量化然后在问答时做语义检索再交给 LLM 生成回答。你可以把部署手册、接口文档、运维记录全部丢进去然后让 DeepSeek 基于这些文档回答而不是让它凭参数面自由发挥。创建知识库时点击“知识库” - “创建知识库”上传一个 PDF 或 Markdown 文件。这里有个关键参数分段设置。默认分段长度为 500 个字符重叠度为 50对中文文档来说可以适当调大一点比如 800 个字符、重叠 100尽量避免把一个完整概念切到两个片段。索引方式选“高质量”虽然会消耗一些 Ollama 资源但准确率比“经济”好很多实测在本地文档上差别明显。文档上传后Dify 会开始预处理调用嵌入模型为每个分段生成向量。这里要注意Ollama 提供的 DeepSeek 是对话模型不能做嵌入你需要单独在 Ollama 里拉一个嵌入模型比如nomic-embed-text# 拉取本地嵌入模型用于知识库向量化 ollama pull nomic-embed-text然后在 Dify 的模型供应商设置里找到 Ollama 供应商再添加一个“Embedding 模型”模型名称填nomic-embed-textBase URL 跟对话模型相同。这样知识库的向量化才有着落。如果你跳过这一步知识库会一直卡在“索引中”。知识库创建完回到聊天助手的应用编排里点击“添加上下文”选择刚才创建的知识库设置检索模式为“向量检索”或“混合检索”。混合检索更适合文档中常出现专业词汇的场景它会把关键词命中结果也带进来。最后修改一下 Prompt 提示词先把知识库作为背景资料再让 DeepSeek 判断是否需要回答避免模型直接凭“背诵”回答错误。全部配置完成后重新打开应用输入一个只有文档里才有的问题看它能否给出准确答案。建议在调试对话里同时打开“引用”面板检查召回片段是否真的和问题相关。如果召回内容偏离可以把分段长度调小、重叠度调大或者换用混合检索。从那以后我每次在 Windows 上搭 Dify 新环境都会强制把自己的检查清单走一遍虚拟化先看、OLLAMA_HOST 先改、extra_hosts 先加、模型名先 curl 确认。这套组合看似简单但底层链路的每一环都可能在你身后咬一口。希望这份拆解帮到你让你在下一次部署时少走一段冤枉路。本文还有配套的精品资源点击获取
Windows本地部署Dify+Ollama+DeepSeek：Docker底座配置与避坑指南
简介一份面向Windows用户的Dockerdifyollamadeepseek组合方案本地化部署指南专为具备基础IT素养、希望搭建大语言模型与自然语言处理实验环境的开发者或专业人士编写。文档从最低硬件要求CPU≥2核、内存≥4GB、磁盘≥20GB讲起涵盖Git、TortoiseGit和Docker的安装、国内镜像源切换随后分步演示dify从克隆代码到启动访问的完整流程并详细说明Ollama的非C盘存储配置与模型下载验证以及集成部署时文本嵌入模型的选择要点最后附上常用Docker命令供排查参考。资源包共1个docx文件大小约923KB内容组织清晰便于按章节逐步操作。目前已有3879人学习适合需要快速搭建AI开发环境并深入探索机器学习、深度学习前沿应用的读者作为实践参考。1. Docker Dify Ollama DeepSeek 的 Windows 本地化部署为什么说底座才是最大门槛先把标题里的组合说清楚Docker 负责运行 DifyDify 负责搭建 AI 应用Ollama资源标题里写成 ollma实际是 Ollama负责在本地拉起模型DeepSeek 在这里是模型权重整套跑在 Windows 上。我拆这套方案时最大的感受是真正卡人的不是 AI 推理而是 Windows 上的 Docker 底座。你没把 WSL2、虚拟化、端口映射捋顺Dify 起来也接不上模型。我会按“环境准备 → 平台部署 → 模型接入 → 排错 → 落地”的顺序把每一步的参数和坑一次性讲完。适合不想把数据交给云端、想在笔记本里私有化跑一套 LLM 应用链路的开发者和运维人员。2. 装对 Docker Desktop 和 Ollama虚拟化、WSL2、模型拉取一次讲清2.1 装 Docker Desktop 前先确认 Windows 虚拟化状态很多新手上来就装 Docker Desktop然后双击图标弹出Virtualization support not detected第一反应是重新安装其实问题在底层。Windows 跑 Docker Desktop 依赖 Hyper-V 或 WSL2这两者都需要 CPU 虚拟化在 BIOS 层面打开。我一般先用系统信息命令确认一下虚拟化是否已经启用。PowerShell 里执行# 查看系统 Hyper-V 相关状态 systeminfo | findstr /i Hyper-V能看到类似Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。这样的文本说明虚拟化已经可用。如果显示“未检测到虚拟机监控程序”或者“Hyper-V 要求: 已列出虚拟机监控程序”但后面跟的是“不支持”就要进 BIOS 打开 Intel VT-x 或 AMD SVM。提示Windows 家庭版没有完整 Hyper-V 管理工具但可以启用 WSL2 后端Docker Desktop 照样能跑。只要 CPU 虚拟化开启并且 Windows 更新到 21H2 以上问题不大。确认虚拟化之后打开“启用或关闭 Windows 功能”勾选“适用于 Linux 的 Windows 子系统”和“Windows 虚拟机监控程序平台”。这一步做完必须重启。重启后跑wsl --status能看到 WSL 版本和默认发行版信息就说明 WSL2 子系统就绪了。这里有个容易忽略的点Docker Desktop 安装包建议右键“以管理员身份运行”安装目录别放系统盘也行但低配机器我会装在 C 盘以避免跨盘符的 Docker 数据目录引路问题。安装完成后打开 Docker Desktop在 Settings - General 中勾选Use the WSL 2 based engine这样 Docker 容器实际跑在 WSL2 里而不是老旧的 Hyper-V 虚拟机模式。2.2 安装 Ollama 并拉取 DeepSeek 权重Ollama 的 Windows 安装就是官网下载 exe 然后一路下一步装好之后系统托盘会出现一只小羊驼图标。这里有个血泪经验Ollama 默认安装后服务只监听127.0.0.1这个后面接 Dify 时一定会翻车所以要提前设置环境变量OLLAMA_HOST0.0.0.0:11434。设置环境变量的方式是Windows 搜索“环境变量”在系统变量里新建OLLAMA_HOST值填0.0.0.0:11434然后重启 Ollama。如果不想改全局也可以在 PowerShell 里临时指定# 当前终端临时指定监听地址 $env:OLLAMA_HOST0.0.0.0:11434 ollama serve用ollama serve手动起服务时这个环境变量只对当前终端有效。我建议直接改系统环境变量然后右键托盘图标退出 Ollama再重新启动这样 Windows 服务用的才是新配置。后面连接 Dify 时如果遇到connection refused大概率就是这一步没做。模型拉取命令# 拉取 DeepSeek-R1 的 7B 量化版本 ollama pull deepseek-r1:7b这条命令会从 Ollama 的模型仓库拉取 DeepSeek-R1 的 7B 参数量化版本。我第一次拉的时候没看大小结果发现下载体积不是小数好在断点续传还算稳定。拉完用ollama list确认# 列出本地已安装模型 ollama list输出里会列出deepseek-r1:7b以及它的 ID 和大小。如果内存只有 8G我建议用更小的量化版# 拉取更小的 1.5B 版本用于联通性验证 ollama pull deepseek-r1:1.5b1.5b参数量的版本在 CPU 上也能跑回答质量比 7B 差一些但作为联通性验证足够了。参数说明deepseek-r1是模型系列名冒号后面是标签常见标签有1.5b、7b、8b、14b数字越小占用资源越低。拉取失败时先看磁盘剩余空间再看网络是否稳定Ollama 官方仓库不在国内但这里我们不展开网络优化手段。2.3 验证 Ollama 的 API 是否通畅模型落盘后不要急着去连 Dify先用 curl 探一下接口# 查看 Ollama 本地 API 状态和模型列表 curl http://localhost:11434/api/tags正常会返回一个 JSON里面的models数组包含所有已安装模型的信息。这一步相当于确认“模型服务已经起来了而且接口协议是标准 OpenAI 风格兼容的”。如果你返回的是连接拒绝说明 Ollama 服务没跑起来或者端口被占用如果用localhost通但后面 Dify 容器内不通那就是监听地址的问题回看 2.2 节的OLLAMA_HOST设置。注意Dify 连接 Ollama 实际是走 OpenAI 兼容接口因此需要确认 Ollama 版本支持这一协议。新版本默认都支持老版本建议升级到新版否则会出现能拉模型但 Dify 校验过不了的情况。现在底座已经齐了Docker 和 WSL2 状态正常Ollama 能提供模型推理服务。接下来进入 Dify 平台部署。3. 用 Docker Compose 拉起 Dify 平台.env 配置与容器验证3.1 准备 Dify 的部署文件Dify 是一个开源 LLM 应用开发平台官方仓库里直接带了一套 docker 编排目录。Windows 上不需要自己手写 Dockerfile只需要拿到源码包里的docker目录然后执行docker compose up就行。常见做法是去 Dify 的 GitHub Releases 页面下载对应版本的源码包解压后进入dify-main/docker目录。我习惯只保留docker目录其他源码不看。打开这个目录你会看到docker-compose.yaml、.env.example、volumes目录等材料。这里先解释一下这套编排文件里到底有几个角色。api是 Dify 的后端服务worker是异步任务执行器web是前端页面db是 PostgreSQLredis做缓存队列sandbox跑用户代码插件ssrf_proxy负责过滤外部请求。这 7 个容器必须协同工作所以最好用 compose 一次性拉起不要手动一个个docker run。进入目录后第一步是把环境变量模板复制一份# 从示例文件生成 Dify 的环境变量文件 cp .env.example .env然后打开.env文件最需要改的是这几个SECRET_KEYDify 用它做会话加密必须改成一个随机长字符串。可以用 PowerShell 生成-join ((48..57)(65..90)(97..122) | Get-Random -Count 32 | % {[char]$_})。POSTGRES_PASSWORD数据库密码默认是difyai测试环境可以不改但端口暴露到局域网就必须改。EXPOSE_NGINX_PORTDify 对外访问的端口默认80。如果 Windows 上 80 端口被占用改成8080或8000。还有几个不常改但值得了解的参数POSTGRES_PORT默认 5432如果你本机已经装了 PostgreSQL需要改成其他端口比如 5433REDIS_PORT同理。这些端口改完后compose 内部服务之间使用容器网络互访不受宿主机端口影响但宿主机访问数据库和 Redis 时要用新端口。3.2 修改 compose 文件让 Dify 容器能访问宿主机 Ollama这里是最关键的一步。Dify 的容器跑在 WSL2 里容器里的localhost指向容器自己不是 Windows 宿主机。要让 Dify 访问宿主机上 Ollama 的 11434 端口需要在docker-compose.yaml中给api和worker两个服务加上extra_hostsapi: extra_hosts: # 让容器内能通过 host.docker.internal 访问宿主机 - host.docker.internal:host-gateway worker: extra_hosts: - host.docker.internal:host-gateway加完后Dify 内部访问http://host.docker.internal:11434就能打到你 Windows 宿主机上的 Ollama。如果你在 Docker Desktop 的较新版本里跑 Linux 容器host-gateway是个自动映射宿主机地址的关键字不用再去查 WSL2 的 IP。注意host.docker.internal在 Docker Desktop 的 WSL2 模式下默认不一定可用所以显式声明extra_hosts是最稳的做法。这也是为什么很多教程只讲在 Dify 里填localhost:11434导致失败的原因。改完 compose 文件后执行启动命令# 后台拉起 Dify 全部容器服务 docker compose up -d-d表示后台运行。第一次启动会拉取镜像时间取决于网络和镜像体积可能要等一阵。中途如果卡在某个镜像拉取上不要连续 CtrlC先看是哪个服务的镜像失败了。常见情况是sandbox镜像比较大耐心等待即可。3.3 检查容器状态与日志启动完成后用docker compose ps查看所有服务状态。理想情况下STATUS列应该是UpHEALTHY字段如果显示healthy就说明健康检查通过了。我遇到最多的情况是api容器起不来所以单独看它的日志# 持续跟踪 api 容器日志 docker compose logs -f api日志尾部如果出现Listening at: http://0.0.0.0:5000说明 API 服务已经就绪。如果出现Connection refused或FATAL通常是 PostgreSQL 还没就绪等待几十秒后再次查看即可。Dify 的 api 容器在启动阶段会等待数据库和 Redis所以第一次启动时日志里出现retrying是正常的别急着重启。如果api反复重启检查.env里SECRET_KEY是否为空以及POSTGRES_PASSWORD是否和docker-compose.yaml里的默认值一致。很多时候是手工改乱了导致api连不上数据库。容器日志里如果出现password authentication failed for user dify那基本就是密码不匹配回看.env中POSTGRES_PASSWORD的值。3.4 初始化 Dify 管理员账号然后是web容器它是纯静态资源服务默认映射到宿主机 80 端口。如果你前面把EXPOSE_NGINX_PORT改成了8080访问地址就是http://localhost:8080。浏览器打开后应该看到一个安装引导页。安装引导页会要求设置管理员邮箱和密码这一步填好后 Dify 会自动建库建表等待约一分钟。初始化完成后进入登录页用刚才的账号登录你会看到 Dify 的主界面。此时平台已经可用但还没有任何模型下面进入模型接入环节。4. 把 DeepSeek 接进 Dify模型供应商参数与连接测试4.1 在 Dify 控制台找到 Ollama 供应商登录 Dify 后点击右上角头像进入“设置”左侧菜单找到“模型供应商”。在供应商列表里找到 “Ollama”点击“安装”或“添加模型”。这里会有一个表单需要填模型类型、模型名称、Base URL 和上下文长度等参数。我建议先不要直接填 Dify 界面而是先在 PowerShell 里用 curl 确认 Ollama 的 OpenAI 兼容接口是通的# 查看 Ollama 的 OpenAI 兼容模型列表 curl http://localhost:11434/v1/models如果返回 JSON 列表说明 Ollama 已经开启了 OpenAI 兼容 API。Dify 添加模型时模型类型选“对话模型”LLM模型名称填你在ollama list里看到的标签比如deepseek-r1:7b。Base URL 填http://host.docker.internal:11434不是http://localhost:11434。上下文长度按照模型实际情况填deepseek-r1:7b建议填 4096 或 8192。这里有个容易搞混的点ollama pull时指定的模型标签是唯一的Dify 表单里也必须一模一样。如果ollama list输出的是deepseek-r1:7b就不要填deepseek-r1也不要填deepseek-r1:latest。Dify 校验时是通过 API 获取模型列表后逐一比对差一个字符都会失败。4.2 关键参数逐个说明参数推荐值说明模型类型对话模型 (LLM)如果用于嵌入或排序要单独添加DeepSeek 目前不常用作 embedding模型名称deepseek-r1:7b必须和ollama list输出完全一致Base URLhttp://host.docker.internal:11434容器内访问宿主机的唯一正确入口上下文长度4096超出会报 context length exceeded温度0.7对话任务常用R1 推理任务建议 0.2 以下Prompt 提示词可留空之后在应用编排里单独写上下文长度这个参数值得单独说。Ollama 模型的上下文窗口由模型本身和OLLAMA_CONTEXT_LENGTH环境变量共同决定Dify 侧填的值只是在请求里声明的max_tokens上限。如果你把 Dify 的上下文长度填得比模型实际支持的大请求时 Ollama 可能会报context length exceeded。反之填得太小长文档知识库在召回后放不下回答会不完整。对于deepseek-r1:7b4096 是最稳的选择需要更长时再调整。4.3 用聊天助手验证一次完整推理模型添加成功后回到 Dify 首页点击“创建应用”选“聊天助手”。在应用编排页的右上角模型下拉框里选择刚才添加的 Ollama / deepseek-r1:7b。然后在左下角的调试对话区输入一句测试问题比如“用一句中文解释 Docker 的 Overlay2 存储驱动”。这里有个值得注意的细节Dify 的聊天助手会把提示词、变量和历史消息拼装后发送给模型。第一次测试如果响应比较慢需要先确认是模型推理慢还是接口连接有延迟。打开 Docker Desktop 的容器日志界面选中api容器查看请求日志里有没有Ollama相关的响应时间记录。如果你看到 5 秒以上的生成耗时在 CPU 推理场景下是正常的不要误判成故障。如果日志中出现 HTTP 500先别急着改 Dify 配置。直接绕过 Dify 用 curl 向 Ollama 发一次同样的问题# 直接用 OpenAI 兼容接口测试 Ollama 推理 curl http://localhost:11434/v1/chat/completions -H Content-Type: application/json -d {\model\:\deepseek-r1:7b\,\messages\:[{\role\:\user\,\content\:\你好\}]}能正常返回内容说明模型服务本身没问题问题出在 Dify 和 Ollama 之间的参数传递上。常见原因是 Dify 发送的temperature或max_tokens数值超出 Ollama 允许范围可以把 Dify 里的温度调到 0.7最大令牌数调到 500 再试。测试成功之后应用就可以用了。但真正要落地到业务里还需要配置“提示词编排”或者“知识库”。在测试阶段先确保模型能正常回复然后回到模型供应商页面确认状态显示“可用”。这样链路算打通了。5. Windows 本地化部署避坑Docker、Dify、Ollama 组合的五个高频故障5.1 Docker Desktop 启动报错Virtualization support not detected现象双击 Docker Desktop 图标提示Virtualization support not detected或Docker Desktop failed to start because virtualization support is not detected即使重装也一样。原因BIOS 中的 CPU 虚拟化没有被打开或者 Windows 的 Hyper-V / WSL2 功能没有启用。Docker Desktop 依赖这两个底层能力缺一个都会直接报错。解决重启机器进入 BIOS找到Intel Virtualization Technology或SVM Mode设为 Enabled保存重启后在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机监控程序平台”再次重启。然后在管理员 PowerShell 里执行wsl --set-default-version 2确保 WSL 默认版本是 2再启动 Docker Desktop。我组里有两台机器都是这种报错一台是 BIOS 没开一台是装完没重启处理完再没复发。5.2 Dify 容器内访问 Ollama 报 Connection refused现象在 Dify 里添加 Ollama 模型填写http://localhost:11434点击保存后报connection refused或Failed to establish connection。原因Dify 的api容器跑在 WSL2 的独立网络命名空间里容器内的localhost指向容器自己而不是 Windows 宿主机。Ollama 服务默认也只监听127.0.0.1双重因素叠加后必然连不上。解决先在.env或系统环境变量中设置OLLAMA_HOST0.0.0.0:11434并重启 Ollama然后在docker-compose.yaml的api服务和worker服务中都加上extra_hosts: - host.docker.internal:host-gateway最后 Dify 表单中的 Base URL 填http://host.docker.internal:11434。改完需要docker compose up -d重建容器。注意光改.env不够Ollama 服务重启后才生效。5.3 Dify 提示 An error occurred during credentials validation现象模型供应商表单填写完成后Dify 弹出An error occurred during credentials validation保存不了模型。原因这个问题很少是 Dify 代码出 bug绝大多数是模型名称与 Ollama 返回的模型 ID 不一致。比如你ollama pull时写了deepseek-r1:7b但 Dify 里多填了个空格或者把标签写成了deepseek-r1都会导致校验失败。另外部分 Ollama 老版本没有开启 OpenAI 兼容接口也会报同样的错。解决在 PowerShell 执行curl http://host.docker.internal:11434/v1/models把返回 JSON 里的model字段原样复制到 Dify。如果接口返回 404说明 Ollama 版本太老升级到支持 OpenAI 兼容 API 的版本。还有一种玄学情况是 Base URL 结尾多写了/v1Dify 的 Ollama 集成已经自带路径所以一律只填到端口号。5.4 DeepSeek 响应很长或直接 timeout现象应用已经能回复但输入问题后要等十几甚至几十秒才出第一个字Dify 侧出现timeout或者模型回答到一半就断了。原因DeepSeek-R1 是推理模型默认会生成很长的思维链内容即便 7B 量化版在 CPU 上也要不少时间。Docker Desktop 默认分配的资源可能只有 2 核 4G连 WSL2 系统本身都不够分推理速度自然没法看。解决打开 Docker Desktop 的 Settings - Resources把 CPU 提高到 4 核以上内存至少 8G点击 Apply 后重启 Docker。另外在 Ollama 启动时可以通过环境变量OLLAMA_NUM_PARALLEL1强制串行推理避免多个请求挤占资源。如果仍然慢换deepseek-r1:1.5b或deepseek-coder:1.3b这类小模型。5.5 Windows 端口启动时报 bind 失败现象docker compose up -d之后日志里提示bind: An attempt was made to access a socket in a way forbidden by its access permissionsDify 的web或nginx容器无法绑定端口。原因Windows 上 Hyper-V / WSL2 会保留一部分动态端口或者有别的进程占用了 80 端口。常见元凶是 IIS、SQL Server 报表服务甚至商店应用也会占用 80。Dify 的EXPOSE_NGINX_PORT如果设成 80就很容易撞上。解决先用netstat -ano | findstr :80查看是谁占用了端口如果找到 PID再在任务管理器里定位进程。不想杀进程的话直接改.env里的EXPOSE_NGINX_PORT8080然后重启容器。注意修改后访问地址也变成http://localhost:8080。如果确定是 Windows 保留端口可以在管理员 PowerShell 里执行netsh interface ipv4 show excludedportrange protocoltcp查看保留段把EXPOSE_NGINX_PORT改到保留段之外。还有一点容易忘改端口后要docker compose down再up -d单纯restart可能不加载新配置。6. 收尾技巧用 Dify 搭一个能检索本地文档的知识库问答当模型接入验证通过就可以从“聊天助手”升级成“知识库问答”了。Dify 的“知识库”模块在左侧菜单单独存在本质上是把本地文档做切片、向量化然后在问答时做语义检索再交给 LLM 生成回答。你可以把部署手册、接口文档、运维记录全部丢进去然后让 DeepSeek 基于这些文档回答而不是让它凭参数面自由发挥。创建知识库时点击“知识库” - “创建知识库”上传一个 PDF 或 Markdown 文件。这里有个关键参数分段设置。默认分段长度为 500 个字符重叠度为 50对中文文档来说可以适当调大一点比如 800 个字符、重叠 100尽量避免把一个完整概念切到两个片段。索引方式选“高质量”虽然会消耗一些 Ollama 资源但准确率比“经济”好很多实测在本地文档上差别明显。文档上传后Dify 会开始预处理调用嵌入模型为每个分段生成向量。这里要注意Ollama 提供的 DeepSeek 是对话模型不能做嵌入你需要单独在 Ollama 里拉一个嵌入模型比如nomic-embed-text# 拉取本地嵌入模型用于知识库向量化 ollama pull nomic-embed-text然后在 Dify 的模型供应商设置里找到 Ollama 供应商再添加一个“Embedding 模型”模型名称填nomic-embed-textBase URL 跟对话模型相同。这样知识库的向量化才有着落。如果你跳过这一步知识库会一直卡在“索引中”。知识库创建完回到聊天助手的应用编排里点击“添加上下文”选择刚才创建的知识库设置检索模式为“向量检索”或“混合检索”。混合检索更适合文档中常出现专业词汇的场景它会把关键词命中结果也带进来。最后修改一下 Prompt 提示词先把知识库作为背景资料再让 DeepSeek 判断是否需要回答避免模型直接凭“背诵”回答错误。全部配置完成后重新打开应用输入一个只有文档里才有的问题看它能否给出准确答案。建议在调试对话里同时打开“引用”面板检查召回片段是否真的和问题相关。如果召回内容偏离可以把分段长度调小、重叠度调大或者换用混合检索。从那以后我每次在 Windows 上搭 Dify 新环境都会强制把自己的检查清单走一遍虚拟化先看、OLLAMA_HOST 先改、extra_hosts 先加、模型名先 curl 确认。这套组合看似简单但底层链路的每一环都可能在你身后咬一口。希望这份拆解帮到你让你在下一次部署时少走一段冤枉路。本文还有配套的精品资源点击获取
