windows 本地部署 dify 加 ollama

你在 Windows 上想让 Dify 用上本地跑的 Ollama 模型，结果一半时间卡在装不上、一半时间卡在「模型列表空的、连不上」。这篇不讲原理，只给一份能照着走的顺序：先确认 Ollama 在不在跑、服务监听在哪个地址、再让 Dify 去指它，最后用对话或知识库验证一条链路。属于「模型与算力」分区的部署速查。

你在 Windows 上想把 Dify 和本地跑的 Ollama 接起来，往往不是卡在「装不上」，就是卡在「模型列表空的、连不上」。这篇不讲原理，只给一份能照着走的顺序：先确认 Ollama 在不在跑、服务监听在哪个地址，再让 Dify 去指它，最后用一次对话或一条知识库链路验证通没通。

整个流程属于「模型与算力」分区的部署速查，核心就三件事：前置条件别漏、启动顺序别乱、地址写法别照抄教程默认值。下面按动手顺序拆开讲，每一步都给你判断标准和验证动作。

动手前先把三个前提确认掉

别急着点安装包。先把机器能不能跑动、Ollama 本身通不通、Dify 用哪种方式部署这三件事确认掉，不然后面每一步都可能白折腾。尤其是量化档位和显存对不上的情况，装完也跑不起来。

• 确认机器本身能不能跑动你要用的模型：显存、内存和量化档位对不上，后面全是白折腾，先到 /models/deploy 按当时的参数算一遍；
• 确认 Ollama 已装好并能正常拉起一个模型，能跑通对话再谈接 Dify，先跑通再叠加组件，出问题也好定位；
• 确认 Dify 的部署形态：容器方式还是本机直接装，两者的网络寻址规则完全不同，直接决定后面地址怎么写。

启动顺序：谁先谁后，地址按什么写

顺序错了或者地址写错，最常见的表现就是 Dify 那边一直转圈、模型列表拉不出来。先把 Ollama 当成一个常驻服务起好，再动 Dify，最后开控制台，中间任何一步没稳都别往下叠。

1. 起 Ollama让它处于常驻服务状态，确认宿主机自己能访问到它的端口，先用命令行或浏览器试一下再说下一步。
2. 起 Dify按你选的部署形态把 Dify 相关服务拉起来，等它自己初始化完成，别在启动过程中就去点配置。
3. 打开控制台进 Dify 界面后先别急着加模型，先确认服务本身是活的、能正常登录进设置页。

地址别照抄教程里的默认值。容器里的「本机」不是宿主机的本机，这是最常见的一处连不上。判断连通性看两件事：Ollama 端口在宿主机能不能访问、Dify 容器内部能不能解析到那个地址，一条不通就换个写法，比如换成宿主机的实际地址或专门的容器互通地址。

在 Dify 里把模型接进来

这一步只做一件事：让 Dify 知道 Ollama 在哪、有哪些模型。填完先做连通测试或拉一次模型列表，列表出不来就别往下走，先回去查上一节的地址问题，别在应用里反复点。

• 模型供应商那一栏选 Ollama，填服务地址和模型名，模型名要和 Ollama 里实际拉下来的名字完全一致，大小写和标签都别错；
• 填完先做一次连通测试或拉模型列表，拉不出来就停下，回去核对地址和 Ollama 服务状态；
• 系统模型和应用模型要分别配：对话用哪个、嵌入用哪个，知识库场景少配了嵌入模型是另一处常见现场。

服务地址

Dify 去访问 Ollama 的那个入口，按部署形态决定写法。

模型名

Ollama 里实际拉下来的名字，必须一一对应。

系统模型

给整个平台兜底用的模型配置。

嵌入模型

知识库检索要用，单独配，别只配对话模型。

验证与排查：一条链路通没通

验证要从最简单的场景开始。先用单轮对话确认模型能被调用，通了再上知识库或工作流，别一上来就压复杂场景，那样出问题根本分不清是模型没通还是应用配错。

1. 单轮对话验证在 Dify 里新建一个最简应用发一句话，能正常返回就说明模型这一层通了。
2. 按顺序排查连不上时依次查：Ollama 服务在不在、端口通不通、容器内能不能访问到这个地址、模型名对不对，别跳步。
3. 量一下速度基线速度慢、首字卡先别怀疑 Dify，多半是模型本身没跑顺，到 /tools/speed-test 量一下基线再判断瓶颈在哪。

哪些情况这套做法不适用

本地 Dify 套 Ollama 适合自用、折腾、验证想法，但不适合所有场景。下面这几种情况，硬套这套组合大概率会难受，最好先想清楚需求再决定要不要换方案。

• 多人共用、要稳定对外提供服务时，这套组合不是首选，得先看并发和吞吐要求再定；
• 机器配置刚好压线时，只能跑小参数量或高量化档位，别指望同时挂知识库和大模型；
• 公司有内网代理、安全软件或统一管控时，容器的网络行为会变，要先和运维对齐再做。