ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Windows本地AI链路实战:Docker+Dify+Ollama+DeepSeek整合指南

Windows本地AI链路实战:Docker+Dify+Ollama+DeepSeek整合指南 简介这份文档面向具备基础 IT 素养、希望搭建本地 AI 开发环境的学习者与从业者尤其是自然语言处理、深度学习方向的技术人员。内容围绕 Windows 平台下 Docker、Dify、Ollama 与 DeepSeek 的组合部署展开先明确 CPU≥2 核、内存≥4GiB、磁盘≥20G 的最低要求再依次覆盖 Git 与 TortoiseGit 安装、Docker 安装及国内镜像源切换、Dify 代码克隆与启动验证、Ollama 下载与模型路径配置、文本嵌入模型集成等环节并附常用 Docker 命令作为速查参考。资源包为 1 个 docx 文档约 923KB目录按说明、适用环境、准备工作、各组件部署、集成配置与附件分节结构清晰便于按步骤对照操作。目前已有 3880 人学习适合想快速跑通本地大模型应用栈、减少环境配置踩坑的读者参考。1. Windows 上把 Docker、Dify、Ollama、DeepSeek 串成一条本地链路这套组合到底解决什么问题很多人在 Windows 上想跑一套属于自己的 AI 应用第一步就卡住了Dify 要 Docker模型要 Ollama推理要 DeepSeek三个东西各自都能装但拼在一起就各种报错。这套组合方案的核心价值是把「应用编排层 模型运行时 推理模型」三层压在一台 Windows 机器上不依赖外部 API数据不出本机。Dify 负责工作流和知识库Ollama 负责把 DeepSeek 模型跑起来Docker 负责把 Dify 的依赖环境封住。适合谁适合手上有 16GB 以上内存、想搭私有知识库或本地工作流的开发者也适合想先跑通再决定要不要上服务器的团队。这一章先把三层关系讲清楚后面再动手。2. 三层架构怎么分工Dify、Ollama、DeepSeek 各自管什么2.1 Dify 是编排层不是模型层Dify 的定位经常被误解。它不是模型也不直接跑推理它做的是把「用户输入 → 提示词组装 → 模型调用 → 结果处理」这条链路可视化。你在 Dify 里拖一个工作流本质上是在定义一串 HTTP 请求和上下文拼接逻辑。它自带知识库流水线能把文档切片、向量化、存进向量库然后在对话时做检索增强。这些能力都跑在 Docker 容器里所以 Windows 上必须先有 Docker Desktop。Dify 调用模型的方式是走 OpenAI 兼容接口。Ollama 恰好提供了/v1/chat/completions这个兼容端点所以两者能对接。关键点在于Dify 容器内部访问 Ollama 时不能用localhost因为容器里的 localhost 指向容器自己。这是后面配置时最容易翻车的地方。2.2 Ollama 是模型运行时负责把 DeepSeek 拉起来Ollama 在 Windows 上有原生安装包装完就是一个后台服务默认监听11434端口。它的作用是管理模型文件、加载模型到内存、对外暴露推理接口。DeepSeek 在 Ollama 上有多个尺寸的蒸馏版本常见的是deepseek-r1:7b、deepseek-r1:14b、deepseek-r1:32b。选哪个取决于你的显存和内存。这里有个血泪经验Ollama 默认把模型存在 C 盘用户目录下一个 14B 的模型动辄 9GB 以上C 盘很快爆。安装前先改环境变量OLLAMA_MODELS指向其他盘能省掉后面迁移的麻烦。2.3 DeepSeek 模型选型参数规模和量化等级怎么定模型标签参数量文件大小约最低内存适用场景deepseek-r1:7b7B4.7GB16GB轻量问答、测试链路deepseek-r1:14b14B9GB32GB知识库问答、工作流deepseek-r1:32b32B20GB64GB复杂推理、代码生成量化等级默认是 Q4_K_M平衡了精度和体积。如果你机器内存紧张可以找 Q3 或 Q2 的量化版本但推理质量会下降。我一般建议先用 7b 把整条链路跑通确认 Dify 能正常调用之后再换大模型。这样排错时变量少不会一上来就怀疑是模型加载失败还是网络配置错了。3. Windows 上装 Docker Desktop绕开虚拟化和 WSL2 的坑3.1 安装前的系统检查Docker Desktop 在 Windows 上依赖 WSL2 或 Hyper-V。安装前先确认三件事CPU 虚拟化在 BIOS 里开了、Windows 功能里勾了「虚拟机平台」和「适用于 Linux 的 Windows 子系统」、WSL2 内核已更新。缺一个都会导致 Docker Desktop 启动时报Virtualization support not detected。用管理员 PowerShell 跑这两条命令开启功能# 开启 WSL 和虚拟机平台功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启后设置 WSL2 为默认版本 wsl --set-default-version 2逻辑说明第一条命令启用 WSL 子系统支持第二条启用虚拟机平台这是 Docker Desktop 跑 Linux 容器的基础。/norestart表示不自动重启你需要手动重启一次。重启后wsl --set-default-version 2确保新装的发行版走 WSL2 而不是老的 WSL1。参数说明/all表示对所有用户生效/norestart避免命令执行中途重启导致后续命令丢失。如果你已经装过 WSL只需要确认版本是 2 即可。3.2 Docker Desktop 安装与镜像加速安装包从官网下载后直接双击安装时勾选「Use WSL 2 instead of Hyper-V」。装完启动如果卡在 starting 不动大概率是 WSL2 内核没更新去微软官网下wsl_update_x64.msi装一下。启动成功后第一件事是配镜像加速否则拉 Dify 镜像会慢到怀疑人生。在 Docker Desktop 设置里找到 Docker Engine修改 JSON{ registry-mirrors: [ https://docker.1ms.run, https://docker.xuanyuan.me ], dns: [8.8.8.8, 114.114.114.114] }逻辑说明registry-mirrors指定镜像拉取的加速源Docker 会按顺序尝试。dns配置容器内的 DNS避免容器里解析不了域名导致 Dify 调 Ollama 时超时。参数说明镜像源地址会变动如果某个源失效就换一个。改完点 Apply RestartDocker 会重启守护进程。验证方式是docker info看 Registry Mirrors 是否生效。提示Docker Desktop 必须从非管理员终端启动否则会报error: start the windows daemon from a non-elevated terminal。如果你习惯用管理员 PowerShell记得 Docker Desktop 本身用普通权限启动。4. Ollama 部署 DeepSeek模型下载、存储迁移和接口验证4.1 安装 Ollama 并改模型存储路径Ollama 的 Windows 安装包直接装装完托盘会出现一个羊驼图标。在拉模型之前先改存储路径。打开系统环境变量新建OLLAMA_MODELS值设成D:\ollama-models这类非系统盘路径。改完重启 Ollama 服务。验证环境变量是否生效# 查看 Ollama 当前使用的模型目录 ollama list # 如果 list 为空但你知道之前拉过模型说明路径变了 # 检查环境变量 echo $env:OLLAMA_MODELS逻辑说明ollama list列出当前模型目录下的模型。如果路径改对了但模型没迁移这里会是空的。你需要手动把原来 C 盘.ollama\models下的文件剪切到新路径。参数说明OLLAMA_MODELS只影响模型文件存储不影响 Ollama 程序本身。如果你用ollama pull下载慢可以在 Ollama 设置里配代理但注意这里不展开网络层面的配置。4.2 拉取 DeepSeek 模型并验证推理# 拉取 7B 版本先跑通链路 ollama pull deepseek-r1:7b # 拉完后直接命令行测试 ollama run deepseek-r1:7b 用一句话解释什么是 Docker逻辑说明ollama pull从模型库下载指定标签的模型下载过程会显示进度。ollama run加载模型并进入交互模式后面跟的字符串是直接提问。如果模型正常加载你会看到推理输出。参数说明deepseek-r1:7b里的7b是参数量标签冒号后面还可以跟量化等级比如deepseek-r1:7b-q4_K_M。不写量化等级时用默认值。第一次 run 会加载模型到内存7B 大约占 5GB 内存14B 大约占 10GB。验证 Ollama 的 API 是否可用# 检查 11434 端口是否监听 curl http://localhost:11434/api/tags # 测试 OpenAI 兼容接口 curl http://localhost:11434/v1/chat/completions -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}] }逻辑说明第一个请求列出本地所有模型确认 Ollama 服务在跑。第二个请求走 OpenAI 兼容格式这是 Dify 后面要调用的端点。如果第二个请求返回正常 JSON说明 Ollama 侧准备好了。参数说明/api/tags是 Ollama 原生接口/v1/chat/completions是兼容接口。Dify 配置模型时填的 Base URL 就是http://host.docker.internal:11434/v1注意不是 localhost。5. Dify 在 Docker 里跑起来从 clone 到接入 Ollama5.1 获取 Dify 源码并启动容器Dify 官方推荐用 Docker Compose 部署。先 clone 仓库然后进 docker 目录复制环境变量文件# 克隆 Dify 仓库 git clone https://github.com/langgenius/dify.git # 进入 docker 部署目录 cd dify/docker # 复制环境变量模板 cp .env.example .env # 启动所有容器 docker compose up -d逻辑说明docker compose up -d会按docker-compose.yaml里的定义拉起 api、worker、web、db、redis、weaviate 等容器。-d表示后台运行。第一次执行会拉取大量镜像耗时取决于网速。参数说明.env文件里可以改端口、数据库密码、向量库类型。默认 web 端口是 80如果 80 被占用改EXPOSE_NGINX_PORT就行。启动后用docker compose ps看容器状态所有服务 healthy 才算成功。5.2 在 Dify 里配置 Ollama 作为模型供应商浏览器打开http://localhost第一次会要求设置管理员账号。登录后进「设置 → 模型供应商 → Ollama」填两个关键参数参数值说明Base URLhttp://host.docker.internal:11434容器访问宿主机 Ollama模型名称deepseek-r1:7b与 ollama list 一致模型类型LLM对话模型逻辑说明host.docker.internal是 Docker Desktop 提供的特殊域名指向宿主机。Dify 的 api 容器通过这个域名访问 Windows 上跑的 Ollama。如果你填localhost请求会打到容器内部必然失败。参数说明Base URL 不要带/v1Dify 会根据模型类型自动拼路径。模型名称必须和ollama list里显示的完全一致大小写敏感。填完点保存Dify 会发一个测试请求成功的话会显示绿色对勾。5.3 建一个最小工作流验证整条链路在 Dify 里新建一个「聊天助手」应用模型选刚才配的deepseek-r1:7b提示词随便写一句「你是一个助手」。然后在对话框里输入问题如果能看到流式输出说明 Docker → Dify → Ollama → DeepSeek 整条链路通了。这一步的意义在于把变量降到最少。不要一上来就加知识库、加工作流分支先用最简单的对话确认模型调用没问题。链路通了之后再逐步加检索、加工具调用出问题时才能定位是哪一层的事。6. 避坑与排查Dify 接 Ollama 最常见的 5 个翻车现场6.1 Dify 报 credentials validation 失败现象在 Dify 里保存 Ollama 供应商时提示an error occurred during credentials validation。原因Dify 的 api 容器访问不到宿主机的 11434 端口。常见情况是 Ollama 只监听了127.0.0.1而容器走的是虚拟网卡不在同一个 loopback 里。解决设置环境变量OLLAMA_HOST0.0.0.0:11434重启 Ollama。然后在 Dify 容器里用docker exec -it docker-api-1 curl http://host.docker.internal:11434/api/tags验证连通性。如果这条命令能返回模型列表Dify 侧就能保存成功。6.2 模型加载后推理极慢或卡死现象Ollama 命令行测试正常但 Dify 里发消息后长时间无响应。原因模型太大内存不够Ollama 在反复换页。或者 Dify 的 worker 容器资源受限。解决先看任务管理器Ollama 进程内存是否接近上限。如果是换小模型或加内存。另外检查 Docker Desktop 的资源限制默认 WSL2 可能只给了一半内存在.wslconfig里调大# 在用户目录创建 .wslconfig [wsl2] memory16GB processors8改完wsl --shutdown重启 WSL。6.3 Dify 知识库流水线卡在索引阶段现象上传文档后知识库一直显示「索引中」不报错也不完成。原因向量化模型没配。Dify 的知识库需要 embedding 模型默认可能指向 OpenAI但你没配 key。解决在模型供应商里配一个本地 embedding 模型比如 Ollama 的nomic-embed-text。然后进知识库设置把 embedding 模型改成这个。注意 embedding 模型和 LLM 是分开配的不要只配了对话模型就以为知识库能跑。6.4 Docker 容器启动后端口冲突现象docker compose up -d后 web 容器不断重启日志显示端口被占用。原因Windows 上 80 或 443 被 IIS、其他服务占了。解决改.env里的EXPOSE_NGINX_PORT为 8080 或其他空闲端口然后docker compose down docker compose up -d。改完访问http://localhost:8080。6.5 Ollama 下载模型中断后无法续传现象ollama pull下到一半断了重新 pull 又从零开始。原因Ollama 的下载缓存机制在某些网络环境下不保留分片。解决如果反复失败可以用离线方式在能正常下载的机器上ollama pull完把OLLAMA_MODELS目录下的对应模型文件夹整个拷过来放到目标机器的模型目录里。Ollama 启动时会扫描目录识别到模型文件就能直接用。7. 进阶技巧用 Dify 工作流把 DeepSeek 的推理过程接进知识库问答链路跑通之后真正有价值的是把 DeepSeek 的推理能力和 Dify 的知识库结合起来。DeepSeek-R1 系列的特点是输出里带thinking标签里面是推理过程。默认情况下 Dify 会把整段输出直接展示给用户包括思考过程。如果你只想要最终答案需要在工作流里加一个处理节点。具体做法在 Dify 工作流里LLM 节点后面接一个「代码执行」节点用 Python 把 之后的内容截出来。代码大概长这样def main(text: str) - dict: # DeepSeek-R1 输出格式 thinking...最终答案 if in text: answer text.split()[-1].strip() else: answer text.strip() return {answer: answer}逻辑说明split()[-1]取最后一个闭合标签之后的内容这样即使推理过程里嵌套了标签也不会截错。返回的 dict 里answer字段供下游节点引用。参数说明代码节点的输入变量名要和工作流里上游 LLM 节点的输出变量对应。Dify 的代码节点默认用 Python 3不需要额外装依赖。另一个技巧是控制上下文长度。Dify 工作流里如果挂了知识库检索检索结果会拼进提示词。DeepSeek 的上下文窗口有限7B 版本大约 64K token但实际用的时候建议把检索条数控制在 3 到 5 条每条切片不超过 500 字。否则提示词太长推理会变慢甚至截断。我一般会在检索节点后面加一个「限制条数」的配置而不是全靠模型自己处理。验证方法在工作流里开调试模式看每个节点的输入输出。重点看 LLM 节点的 prompt 实际拼出来多长以及代码节点截取后的结果是否符合预期。如果发现答案被截断先检查是不是 标签没匹配到有些量化版本可能输出格式略有差异。这套组合我前后搭过三次每次卡住的地方都不一样但归根结底就两类问题网络连通性和资源不够。先把最小链路跑通再往上加功能比一上来就全量部署要省时间。希望帮到你。本文还有配套的精品资源点击获取
返回列表