Windows本地部署DeepSeek：Docker+Dify+Ollama完整指南

简介：面向Windows用户的一站式本地化部署指南，聚焦Docker+dify+Ollama+DeepSeek组合方案，适合具备基础IT素养、正在搭建人工智能开发环境的学习者，以及对自然语言处理与深度学习模型应用感兴趣的研发人员。文档从最低硬件要求谈起，依次说明Git与TortoiseGit安装、Docker部署与国内镜像源切换、dify代码克隆与启动验证、Ollama非系统盘存储配置和模型下载，并专门介绍如何集成大语言模型与文本嵌入模型，操作步骤均有明确指引。资源包仅含一个docx文档，整体大小923KB，目录划分清晰，按章节逐步操作，无需额外代码，可直接对照执行。目前已有3879人学习下载。全文将每一步的注意事项、版本查看方式和常用Docker命令一并整理，可帮助读者避免踩坑，快速建立起可用的本地大模型实验环境，并为后续探索机器学习前沿应用打下基础。

1. 为什么在 Windows 上把这四样拼起来：Docker、Dify、Ollama、DeepSeek 的本地化方案

把 Docker、Dify、Ollama、DeepSeek 这四个词串在一起，得到的是一套不依赖云服务器、数据不出本机的本地大模型应用底座。具体场景很常见：你想把公司内部文档做成问答知识库，又不想把资料传到公开大模型接口；或者你只是想在个人电脑上把「聊天 + 知识库 + 工作流」的完整链路跑通，而不是整天在命令行里跟模型对话。Docker 负责把 Dify 依赖的数据库、队列、向量库全部隔离成容器，Ollama 在 Windows 后台加载 DeepSeek 模型，Dify 把这两者串成可视化应用。这套方案适合能耐心看日志的开发者，你不懂容器原理也能照步骤做，但遇到问题知道去哪查日志会省下大量时间。真正劝退你的往往不是 DeepSeek 模型本身，而是 Docker Desktop 起不来的那一刻。

2. Windows 上先让 Docker Desktop 站起来：虚拟化检测、安装与引擎启动

2.1 安装前的三项体检：虚拟化开关、WSL2 内核与系统版本

先别急着装 Docker Desktop。Windows 上引擎起不来的原因，七成出在虚拟化没开。打开任务管理器 → 性能 → CPU，看右下角「虚拟化」状态：显示「已启用」这一关算过；显示「已禁用」就直接去 BIOS 开 VT-x（Intel）或 SVM（AMD），这一步卡住后面全白搭。为了确认得更细，可以用命令查系统固件的虚拟化状态：

# 在 PowerShell 或 CMD 里执行，检查 Hyper-V 固件虚拟化状态 systeminfo | findstr /i "Hyper-V"

这段输出里找「Hyper-V 要求」段落，重点看「已在固件中启用虚拟化」是不是「是」。如果「是」，说明 BIOS 层面没问题；如果整段都异常，通常就是 Windows 功能或固件设置的问题。不少 OEM 主板默认把虚拟化关掉，Intel 平台一般藏在 Advanced → CPU Configuration → Intel Virtualization Technology，AMD 平台叫 SVM Mode，各自开启后重启再回来看。

虚拟化没问题之后，还要保证 Windows 10 2004 以上或 Windows 11 的「虚拟机平台」和「适用于 Linux 的 Windows 子系统」两个功能处于打开状态。在「启用或关闭 Windows 功能」里勾上这两项，或者用管理员 PowerShell 执行下面的命令：

# 管理员身份执行，启用 WSL 与虚拟机平台两个 Windows 功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完建议重启，然后跑wsl --update把 WSL 内核更新到最新，再用wsl --status确认默认版本是 2.0。Docker Desktop 在 Windows 上有 WSL2 和 Hyper-V 两条后端路径，我绝大多数情况选 WSL2，它对 Docker 磁盘占用和启动速度都更友好，而且后续你想在 WSL 里跑别的 Linux 工具链也顺带有了。

装 Docker Desktop 之前，还有一个容易被忽略的动作：给 WSL2 设置资源上限。默认情况下 WSL2 会吞掉 50% 的物理内存，等 Dify 容器组和 Ollama 同时跑起来，Windows 会卡到鼠标都飘。在用户目录下新建一个.wslconfig文件：

# 位于 %UserProfile%\.wslconfig，控制 WSL2 全局资源上限 [wsl2] memory=6GB processors=4 swap=2GB

这里memory是 WSL2 虚拟机可用内存，processors是给它用的核数，swap是磁盘交换分区大小。我给的 6GB 是个偏保守的值：Dify 的容器组空闲状态下要占 2~3GB，Ollama 加载 7B 量化模型又要 4~6GB，16GB 内存的机器留给 Windows 本体 6~8GB 才不至于卡死。改完先执行wsl --shutdown让配置生效，再启动 Docker Desktop。

2.2 引擎启动失败的三个信号：BIOS 虚拟化、非管理员终端与内存分配

从 Docker 官网下载 Docker Desktop for Windows 安装包，双击安装，过程中勾选 Use WSL 2 instead of Hyper-V。装完先别急着点图标，把 2.1 的三项体检确认完再启动。

最常见的失败情报是：鲸鱼图标一直转圈，几分钟后弹出Docker Desktop failed to start because virtualization support is disabled in BIOS。看到这条，先把 BIOS 和 Windows 功能重新查一遍，别急着重装。网上不少教程让你「以管理员身份运行」来绕过，我试过，玄学重启之后依然打不开，根子就是虚拟化没开。有些轻薄本的 BIOS 里虚拟化开关藏得深，去 Security 或 CPU Configuration 选项卡里慢慢翻。

第二个高频报错是Error: start the windows daemon from a non-elevated terminal; shared clients。大意是 Docker 后台已经以管理员权限起来了，而你在普通终端里执行docker命令，客户端与 daemon 权限不匹配。解决方式是：完全退出 Docker Desktop，用普通用户身份重新双击启动，然后打开一个非管理员 PowerShell 执行docker version。不要一会儿管里一会儿管外切来切去，Docker CLI 会记住它第一次连接 daemon 时的上下文。

引擎正常起来后，用两个命令做最终确认：

# 查看 Docker 客户端与服务端信息，确认 Server 段已就绪 docker version # 拉取并运行 hello-world 镜像，验证整个引擎链路可用 docker run --rm hello-world

docker version只看 Client 段是不够的，必须看到 Server 段也输出了，才说明 daemon 真在跑。docker run hello-world能跑通，意味着拉镜像、创建容器、运行命令这些基础操作都正常。这里提醒一句：如果你所在网络拉镜像很慢，别反复中断重试，中断只会留下半截镜像层；先配置 Docker Desktop 的 registry mirror，再开始拉 Dify 那批容器镜像，否则后面docker compose up会等得你怀疑人生。

3. 用 Ollama 拉取 DeepSeek 模型并验证本地推理：从选型到 API 连通

3.1 先决定跑哪个尺寸：显存和内存是硬约束

Ollama 在 Windows 上就是个普通桌面应用，官网下载安装包，装完终端里跑ollama --version验证。但在拉模型之前，先想清楚你要跑哪个尺寸的 DeepSeek。DeepSeek-R1 官方开源了 671B 的完整版，也发布了蒸馏到小模型上的系列版本，Ollama 里直接用deepseek-r1:1.5b、deepseek-r1:7b、deepseek-r1:14b这样的标签区分。

Ollama 的标签规则是「模型名:参数量」，默认量化格式是 Q4_K_M，体积和质量的平衡点。拉取前看一眼磁盘剩余空间，模型文件放在%USERPROFILE%\.ollama\models，7B 量化后下载体积在 5GB 上下，1.5B 不到 2GB。执行下面三个命令完成安装验证、拉取和首次对话：

# 确认 Ollama 安装成功 ollama --version # 拉取 DeepSeek-R1 7B 蒸馏模型（默认 Q4_K_M 量化） ollama pull deepseek-r1:7b # 进入交互式对话，验证模型能正常输出 ollama run deepseek-r1:7b

pull是下载模型；run会加载模型并进入对话。第一次提问时模型要完整载入内存，等待时间较长是正常的，不是卡死。另外注意一点：R1 系列的回答里会先出现一大段thinking推理内容，这是它的设计，不是异常。CPU 机器上 7B 的思维链可能长达几百上千字，你要等它全部输出完才算结束。

3.2 一条 curl 验证 OpenAI 兼容接口：为 Dify 接入铺路

Ollama 安装后默认监听11434端口，并且自带 OpenAI 兼容接口，路径是/v1/chat/completions。Dify 接 Ollama 走的就是这个协议，所以在接入 Dify 之前，务必先用 curl 把这条链路验证通。

# 查看 Ollama 本地已加载的模型列表 curl http://localhost:11434/api/tags # 用 OpenAI 兼容接口发一次推理请求，验证 DeepSeek 能正常返回 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "user", "content": "用一句话说明你是谁"} ], "stream": false }'

第一条api/tags返回模型列表，用来确认 Ollama 服务活着。第二条的model字段必须与ollama pull时完全一致，写错了会返回model not found。stream: false表示一次性返回完整 JSON，方便你看结果；如果改成true，响应会变成一长串流式数据块，肉眼不好判断。看到 JSON 里choices下有content字段就说明通了。

这里有个关键认知要提前建立：Dify 跑在容器里，容器内的localhost指向容器自己，不是 Windows 宿主机。所以后面配置 Dify 时，Ollama 的地址要写成http://host.docker.internal:11434，而不是http://localhost:11434。host.docker.internal是 Docker Desktop 在 Windows 和 macOS 上自动注入的宿主机别名，专门解决容器访问宿主机服务的需求。如果你在 PowerShell 里执行上面的 curl，建议写成curl.exe而不是curl，因为 PowerShell 里curl是Invoke-WebRequest的别名，会把 JSON 引号搞得一团糟。

4. Dify 容器组部署与模型供应商配置：把 DeepSeek 接进可视化后台

4.1 克隆 Dify 并启动容器组：.env、端口与首次初始化

Dify 官方仓库里已经编好了完整的 Docker Compose 编排文件，部署方式就是拉仓库、改配置、启动。建议把项目放在空间充足的盘里，整个仓库加镜像体积会超过 10GB。

# 从 Dify 官方仓库克隆项目 git clone https://github.com/langgenius/dify.git # 进入 Docker 编排目录 cd dify/docker # 基于示例文件生成环境变量配置 cp .env.example .env # 后台启动整套容器组 docker compose up -d

cp .env.example .env是必须要做的一步，Dify 启动时会读取.env里的数据库密码、密钥、中间件地址等配置。启动前建议打开.env把SECRET_KEY和DB_PASSWORD改掉，默认值太容易被猜中。docker compose up -d的-d是后台运行，前台会刷日志反而看不到结果。首次执行会拉取 PostgreSQL、Redis、Weaviate、nginx、api、worker、sandbox 等镜像，耗时取决于网络，耐心等。

启动之前先确认 80 和 443 端口没被占用，Windows 上这两个端口太容易被别的软件抢走：

# 检查 80/443 端口占用情况 netstat -ano | findstr ":80" netstat -ano | findstr ":443" # 查看容器组启动状态 docker compose ps

容器全部Up之后，浏览器打开http://localhost，第一次访问会进入安装页，让你设置管理员邮箱和密码。如果 80 被占，编辑docker-compose.yaml，把 nginx 服务的端口映射改成8080:80和8443:443，再docker compose up -d，访问http://localhost:8080。注意 Dify 的 nginx 容器同时承载前端页面和 API 反向代理，改端口映射只改 nginx 这一处即可，内部容器间通信不受影响。

4.2 在 Dify 后台把 Ollama 配成模型供应商：Base URL、模型名与上下文长度

进入 Dify 后台后，点左上角设置 → 模型供应商，Dify 预置了 Ollama 供应商，不需要另外装插件。需要配置的核心参数不多，但每个都别填错：

填完点测试，如果显示「验证成功」，说明 Dify 到 Ollama 的链路已经通了。这里最容易翻车的就是 Base URL：填http://localhost:11434在容器内指向容器自己，连接必然被拒；填成https也会失败，因为 Ollama 只提供 HTTP 接口。host.docker.internal是 Docker Desktop 自动注入的，不需要你额外配置 hosts。

模型上下文长度这个参数值得单独说。很多教程让你直接抄模型的理论上下文，但在本地部署里，真正生效的是 Ollama 侧加载模型时设置的num_ctx。Ollama 默认值往往比模型理论值小，Dify 填 8192 只代表它按 8192 去组织请求，如果 Ollama 侧只有 4096，超出部分会被截断或直接报错。稳妥做法是：Dify 先填 8192 跑通，再根据实际报错去调 Ollama 侧窗口。

4.3 用容器日志做链路排查：api 与 worker 的分工

模型配置完成并不代表所有问题消失，我习惯在两类情况下立刻看日志：一是点测试不通过时，二是对话后回答为空或报错时。Dify 的容器组里有两个容器叫api和worker，它们的分工完全不同。

# 看 API 容器最近 50 行日志，同步请求都走这里 docker compose logs api --tail 50 # 看 worker 容器日志，知识库索引等异步任务都走这里 docker compose logs worker --tail 50 # 在 API 容器内部直接探测宿主机上的 Ollama，确认网络链路 docker compose exec api sh -c "curl -s http://host.docker.internal:11434/api/tags"

日志里出现connection refused，先确认 Ollama 进程还活着；出现model not found，去核对模型名大小写和冒号后的参数；出现 EOF 或空响应，大概率是上下文太大把连接拖死了。很多「页面一直转圈」的问题其实要查 worker，比如上传文档后索引不执行，api日志是干净的，你去查worker才能看到真实报错。Dify 把同步和异步任务拆到两个容器里，排查时先想清楚当前操作是哪一类。

5. 避坑：Windows 本地化部署这条链路上的五个翻车现场

5.1 Docker Desktop 报 virtualization support not detected，启动即失败

现象：点开 Docker Desktop，鲸鱼图标一直转圈，最终弹出Docker Desktop failed to start because virtualization support is disabled in BIOS，或者日志里写着virtualization support not detected。

原因：BIOS 固件里的虚拟化开关没开，或者 Windows 的「虚拟机平台」功能没有启用。这个报错基本和 Docker 自身无关，是底层能力缺失。

解决：重启进 BIOS，Intel 平台打开 VT-x，AMD 平台打开 SVM；回到 Windows 后在「启用或关闭 Windows 功能」里勾上「虚拟机平台」和「适用于 Linux 的 Windows 子系统」；然后执行wsl --update，再wsl --status确认默认版本是 2。这里有个细节：如果 Windows 开了快速启动，改完 BIOS 后关机再开可能没有真正断电，需要重启两次才会让 BIOS 设置生效，这不是玄学，是快速启动绕过 POST 检查的常见现象。

5.2 dify ssl 错误与 credentials validation：模型验证一直过不去

现象：在 Dify 后台配置完 Ollama 模型后点测试，前端弹出An error occurred during credentials validation，请求根本到不了模型。

原因：这不是账号密码问题，Ollama 本身不需要密钥。常见原因有三类：浏览器通过https://localhost打开了 Dify，而 Dify 的自签名证书不被信任；Base URL 写成了https开头，Ollama 只提供 HTTP；或者 Ollama 服务本身没起来，导致 Dify 代理请求拿到异常响应。

解决：统一用http://localhost访问 Dify，不要在地址栏手输 https；在浏览器站点设置里清掉 HSTS 记录和缓存，换无痕窗口也行；把 Base URL 写成http://host.docker.internal:11434，不写 https；最后确认 Ollama 进程在任务管理器里存在。以上排完还报错，就去翻docker compose logs api --tail 50，十有八九是模型名对不上。

5.3 上传 PDF 提示 unstructured api url is not configured，文档解析卡住

现象：知识库里上传 PDF 或 DOCX，文档状态一直停在「待解析」或「失败」，页面提示unstructured api url is not configured for doc file processing.。

原因：Dify 解析这类复杂 Office/PDF 文档走的是 Unstructured 服务，这是一条可选的中间件链路。默认.env里没有配置对应的 API 地址，ETL 阶段就直接卡住。

解决：有两条路。第一条，知识库里只放 TXT 和 Markdown 格式，绕开 Unstructured 服务，零改动；第二条，去 Dify 官方 compose 里找到 middleware 或 optional 服务定义，把 Unstructured 相关容器启用，然后在.env里配置UNSTRUCTURED_API_URL指向该服务地址，最后重启 api 和 worker：

docker compose down docker compose up -d api worker

具体服务名和端口以你拉取的版本为准，不同 Dify 版本的可选服务定义不一样。这条报错只影响复杂文档解析，TXT/MD 的知识库流程完全不受影响，如果只是验证部署可以暂时不管它。

5.4 上下文超长：DeepSeek 的思维链把窗口撑爆

现象：Dify 对话时提示上下文超长或 max tokens 超限，有时候第一轮就报错。日志里能看到类似 context length exceeded 的字样。

原因：DeepSeek-R1 蒸馏模型的设计是先把思维链写在回答前面，一段 reasoning 可能吃几百到上千 token。多轮对话后 prompt 累积得非常快，很容易顶到窗口上限。另一个隐藏问题是 Ollama 侧默认num_ctx比模型理论上下文小，Dify 那边填大了也没用。

解决：在 Ollama 侧调大上下文窗口。新版 Ollama 可以直接在 Windows 环境变量里设置OLLAMA_CONTEXT_LENGTH=32768，设置后重启 Ollama；或者写 Modelfile 指定num_ctx 32768再重新加载模型。Dify 侧的「模型上下文长度」同步调成一样的值，但不要超过物理内存能承受的范围。如果内存实在不够，换deepseek-r1:1.5b，或在 Dify 工作流里限制对话轮次、给 LLM 节点设置最大 tokens 上限。单轮知识库问答其实不需要保留太多历史，把对话轮次相关变量清掉能省下大量上下文空间。

5.5 80/443 端口被占：Dify 起不来或打开的是别人的页面

现象：docker compose up报port is already allocated，或者浏览器打开 localhost 出来的是一个完全不相干的网页。

原因：Windows 上 IIS、开发环境、其它本地服务占用了 80 和 443 端口。Dify 默认的 nginx 网关需要这两个端口。

解决：先找到占用者，再决定杀掉还是改端口：

# 找到占用 80 端口的进程 PID netstat -ano | findstr ":80" # 根据 PID 查看对应程序名称 tasklist | findstr "1234" # 确认是无关程序后强制结束 taskkill /PID 1234 /F

如果不想杀进程，直接改 Dify 的端口映射更省事。打开docker-compose.yaml，找到 nginx 服务的ports段：

services: nginx: ports: - "8080:80" - "8443:443"

改完重新docker compose up -d，访问http://localhost:8080进入安装页。注意 Dify 内部容器间通信走的是 docker 网络，只有入口 nginx 需要改映射，其他服务不用动。

6. 让 Dify 工作流可用：知识库模型分工与最小验证清单

6.1 模型分工：再拉一个文本嵌入模型给知识库用

部署完成不等于应用可用。做知识库问答时，新手最容易踩的概念坑是：DeepSeek 只管生成回答，知识库的检索环节需要另一个嵌入模型（Embedding）。Dify 知识库用「高质量」索引模式时，会把文档切片并向量化，这个向量化模型必须是嵌入模型，R1 不能干这活。

解决方案是在 Ollama 里再拉一个轻量嵌入模型：

# nomic-embed-text 是 Ollama 官方支持的轻量嵌入模型 ollama pull nomic-embed-text

然后在 Dify 的模型供应商里，给 Ollama 新增一条 Text Embedding 类型，模型名称填nomic-embed-text，Base URL 还是http://host.docker.internal:11434。之后创建数据集时选择这条嵌入模型，文档才能正常向量化。

用工作流把知识库问答串起来时，我一般建一个最简单的链路：文档检索节点 → LLM 节点。LLM 节点的 Prompt 里引用检索结果变量，比如这样写：

你是本地知识库助手。请只依据下面的资料回答，资料里没有的内容直接说不知道。 资料： {{#context#}} 问题： {{#sys.query#}}

变量名以你 Dify 工作流里实际节点的命名为准，写法是{{#节点变量名#}}。这个 Prompt 的作用是限制模型不要自由发挥，否则 DeepSeek 的思维链会把它训练时知道的东西全倒出来，脱离知识库。知识库的完整流水线是：上传 → ETL 解析 → 切片 → 向量化 → 索引 → 检索，前面 5.3 的 Unstructured 报错就发生在 ETL 解析这一步，而嵌入模型配置错误则发生在向量化这一步，排查时先分清卡在哪一环。

6.2 端到端自测清单：从 Docker 引擎到一次知识库问答

整套部署完成后，我习惯按下面的清单做一次端到端自测，防止某个环节「看起来正常」实际是坏的。

自测时有个省时间的习惯：端到端问答一旦失败，先确定断在哪一段。Dify 页面能开、模型测试能过，问题就出在知识库链路；模型测试都过不了，问题在 Ollama 或host.docker.internal网络别名；页面都打不开，回头查端口和容器状态。九成的「玄学问题」最后都落在日志里，别靠反复重启硬碰。

我第一次把上下文长度直接填成 128K，结果 Ollama 在 16GB 内存的机器上直接内存溢出，把整个 Windows 拖到卡死。后来养成的习惯是：改任何模型参数之前，先看 Docker Desktop 的资源占用曲线；改完之后，只看 api 容器日志和 Ollama 的响应耗时。这套组合的价值在于每个环节都可替换——模型不好就换模型，窗口不够就调窗口，文档解析不行就换格式。希望帮到你。

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