ollama+dify本地化部署

想在自己机器或内网跑一套带知识库和编排的 AI 应用，通常会把 Ollama 当模型服务、Dify 当应用层。真动手时卡人的不是安装命令，而是两边的连接口径、模型名与地址怎么填、跑起来之后慢和不通该怎么查。这篇按部署顺序给一份可照着走的清单。

想在自己机器或内网跑一套带知识库、带流程编排的 AI 应用，常见做法是让 Ollama 负责把模型跑起来，Dify 负责对话流程、知识库和工作流。两个东西装起来都不算难，真正卡人的是两边怎么接、地址和模型名填什么、跑起来之后慢和不通该从哪查起。

这篇按部署顺序给一份能照着走的清单：先分清两边各管什么，再把模型接进 Dify，接着是排查顺序，最后说清楚什么场景下这套组合不该用。全程不聊具体硬件参数和版本号，需要实时数字就去站内对应页面核对。

先把两边的分工分清楚

Ollama 的职责只有一件：把模型加载起来，在本地暴露一个能调用的接口。Dify 管的是应用层那摊事，对话流程、知识库检索、工作流编排都在它这边。很多人一上来就把两边一起装、一起配，出问题后完全分不清是模型没起来还是应用配错了。

• 判断顺序固定死：先确认 Ollama 单独调用能出字，再去接 Dify；反过来查会一直在两个系统之间打转
• 部署形态取舍：同一台机器全塞一起最省心，但模型吃内存会挤压 Dify 的数据库和后台进程，分开两台更稳
• 什么情况下不适用：只想要一个纯聊天窗口、不做编排和知识库，那就不必上 Dify，单装 Ollama 配个前端更省事
• 接 Dify 之前先把 Ollama 的监听地址改成本机之外也能访问，否则容器里的 Dify 根本摸不到它

把模型接进 Dify 的关键几步

Dify 的模型供应商列表里选 Ollama，填的是 Ollama 服务地址，不是 Dify 自己的地址。这一点在容器化部署时最容易踩坑：配置里写 localhost 指的是容器自身，不是宿主机，要换成宿主机地址或同一个网络里的服务名。

1. 填对服务地址按部署方式区分：Dify 跑在容器里就写宿主机 IP 或服务名，Dify 跑在宿主机上才可以用本机回环地址。填完先别急着建应用，做一次连通性测试看能不能列出模型。
2. 原样填模型名模型名按 Ollama 里已经拉取的名字原样抄，大小写、分隔符、标签后缀不一致都会直接连不上。拿不准就去 Ollama 侧列一遍已有模型再复制。
3. 对话模型和嵌入模型分开配知识库还需要一个嵌入模型，两类不要混填同一个。嵌入模型挑中文语义检索表现更稳的那类，具体对照去 /embeddings 页面看。
4. 建应用前先测通连通性测试通过之后再建应用和工作流，别等到流程跑到一半才发现模型根本没接上。

跑起来之后按这个顺序排查

跑起来之后的症状基本就三类：慢、不通、答非所问。三类对应的排查位置完全不同，顺序错了就是在瞎改配置。建议固定成下面这个顺序，一层一层往下走。

• 先量延迟基线：本地模型直接调用的响应速度量一次，再去 Dify 里测同一句话，差值就是应用层的开销
• 再看连接类报错：按「服务在不在、端口通不通、模型名对不对、路径有没有多写后缀」逐层排，别一上来改配置
• 再看显存与内存：模型加载后显存被占满、系统开始换页，表现就是越用越慢，这时降量化档位比加并发更有效
• 最后看知识库链路：检索答非所问往往不是对话模型的问题，先怀疑切分粒度和嵌入模型是否匹配中文内容

排查时给自己留一个最小的可复现请求，不要拿复杂工作流当测试用例。工作流里变量多、分支多，任何一处出错都会被误判成模型问题。延迟测出来之后可以去 /tools/speed-test 对比一下同类环境的大致区间，判断是环境问题还是配置问题。

什么时候这套组合不该用

这套组合适合的是个人或小团队在内网搭一套能自己控制的应用。一旦使用场景变了，硬撑着用同一套架构反而更费事。下面几种情况值得提前想清楚，别等上线了再返工。

还有一类容易被忽略的情况：只想要一个聊天入口，不需要知识库和编排。这时候上 Dify 是给自己加负担，维护一套用不上的编排系统本身就是成本。判断标准很简单，问自己未来一个月会不会用到知识库或工作流，答案是不会就先别上。

先把 Ollama 调通，再接 Dify；先量延迟基线，再改配置。