dify ollama 連携 ローカル

本地 Ollama 已经能跑通对话，接到 Dify 上却要么连不上、要么工作流里模型调不动，是很多人卡住的地方。这篇不讲「本地部署好不好」，只给一套接线与验证顺序：先在 Dify 里加什么、再在模型设置里填什么、最后怎么用一次最小工作流确认链路通了；同时说清哪些场景下本地模型并不合适，以及出现超时、报错、输出空时要按什么顺序排查。

本地 Ollama 已经能跑通对话，接到 Dify 上却连不上，或者模型节点一跑就报错、输出空。这种卡壳跟「本地部署好不好」没关系，纯粹是接线顺序和地址概念没理顺。这篇只给一套可照做的验证链：先确认 Ollama 端活着，再在 Dify 里加供应商、填地址，最后用一次最小工作流确认整条链路通。跑通之后遇到超时、报错、输出跑偏，也按同一个顺序往回查。

动手之前先有个预期：本地模型在 Dify 里的作用边界，跟云端 API 不一样。窗口大小、并发余量、指令遵循能力都由你那张卡决定，不是配置里随便填个数就变出来的。所以下面每一步都带验证动作，跑不通就停在原地解决，别急着往复杂编排上堆。

动手前先确认哪几件事

这三件事不确认清楚，后面所有报错都会指向错误的方向。最典型的坑是：Ollama 明明在跑，Dify 报连接被拒，其实只是因为 Dify 跑在容器里，容器内的 localhost 指向的是容器自己，不是你的宿主机。地址概念没分清，怎么改模型名都没用。

• 确认 Ollama 服务真在跑：命令行能列出已拉取的模型清单，本机浏览器能直接调通它的接口，再去动 Dify；这一步不通，后面全是白折腾。
• 分清两个地址：Dify 若在容器里，填服务地址时容器内的 localhost 不是宿主机，要换成宿主机内网地址或容器网络别名；这是连不上最常见的单一原因。
• 确认模型能力边界：Dify 工作流里的对话、意图分类、参数提取，对指令遵循和输出格式的要求各不相同，同一个本地小模型不一定都扛得住；选型前到 /models 看模型资料，再自己判断。

在 Dify 里把本地模型接上：按这个顺序做

顺序不能乱：先加供应商、再填地址和模型名、然后立刻用最小工作流验证，最后才调参数。很多人反过来，先把上下文长度、超时、并发全填上，结果链路本来就没通，改参数纯粹是浪费时间。

1. 添加供应商在 Dify 的模型供应商里加 Ollama 类目，填服务地址；地址按上一步确认的宿主机内网或容器网络别名来写，别直接抄 localhost。
2. 填模型名模型名要和命令行里列出来的一致，大小写、标签后缀都别省。填错名字的报错往往长得像「模型不存在」，容易被误判成服务没起来。
3. 最小工作流验证建一个只有开始和结束节点、中间挂一次模型调用的小工作流，用固定短问题跑一次。能出结果，才说明模型、地址、鉴权这一层全通了。
4. 再调参数上下文长度、超时、并发按你那张卡的实际余量设，别照搬云端模型的值。显存、量化档和并发的对应关系，到 /compute/sizing 自己算一遍，别凭单次测试的体感估。

接到工作流里之后，几个容易踩的点

链路通了只是开始。把本地模型放进真实工作流后，问题通常从「能不能调通」变成「输出稳不稳」。本地小模型对提示词的容错更低，格式要求越松越容易跑偏，这些都得在编排层处理，别指望换配置解决。

• 输出不稳定时，先在提示词里把输出格式写死，再考虑换模型；格式约束是成本最低的稳定手段。
• 涉及知识库检索的场景，嵌入模型和对话模型要分开配，别用同一个本地模型硬扛，嵌入模型怎么挑可查 /embeddings。
• 长文本任务留意上下文上限，本地窗口常比云端小，超了是截断不是报错，表现就是答非所问。
• 多轮工作流保持会话 ID 一致，否则每次都被当新对话，看起来像模型失忆。

什么情况下别硬走本地

本地不是所有场景都合适，硬上只会把调提示词的时间拉长。判断标准就三条：并发、质量要求、时间成本。三项里有两项踩线，就该考虑换云，本地只留作验证思路的环境。

需要说明的是，「不适合」不等于「不能用」。如果任务输出格式固定、调用量不大、又不想让数据出本机，本地反而是合适的选择，只是要把并发上限和上下文窗口按真实卡去算，别拿云端模型的参数习惯去套。