很多人本地跑通了 Ollama，想让 Dify 用上它，结果卡在两件事：一是 Ollama 只在 127.0.0.1 上监听，Dify 跑在容器里根本连不到；二是界面填完地址点保存没反应，报错也看不懂。这篇按顺序走一遍：组件怎么摆、地址怎么填才通、模型什么时候拉、不通了先查哪一步。
很多人本地把 Ollama 跑通了，转头想让 Dify 用上它，结果卡在两件事上：一是 Ollama 默认只在 127.0.0.1 上监听，Dify 跑在容器里根本连不到；二是界面里地址填完点保存没反应，报错也看不懂。这篇就按动手顺序走一遍，先讲清楚三块东西各管什么，再讲装、连、验、盯，最后给一套出问题时的排查顺序。
先给个整体印象：这不是装一个软件，而是把三层拼起来。拼对了就是本地一套能自己编排的 AI 应用；拼不对，你会在网络、模型、配置三者之间来回怀疑。所以本文的重点不是概念，而是每一步「怎么确认这步过了」，以及不通时先查哪一层。
先把这三块摆清楚：Dify、Ollama、模型各管什么
很多人把 Ollama 和模型当成一回事，其实要分成三块来看。Dify 是编排层，负责界面、工作流、知识库、提示词，它本身不含任何模型权重；Ollama 是推理服务，真正把权重加载进显存、对外提供一个 HTTP 接口；模型是第三块，跑在 Ollama 里。想明白这个分层，后面排查就有方向了。
| 组件 | 负责什么 | 出问题时的表现 |
|---|---|---|
| Dify | 界面、工作流、知识库、提示词 | 界面能开、但拉不到模型或保存失败 |
| Ollama | 加载权重、提供 HTTP 接口 | 本地命令行能聊、容器里连不上 |
| 模型 | 实际推理计算 | 能连上但回答中断、加载报错 |
还有个换模型的便利：换个模型只需要在 Ollama 侧换，Dify 侧基本不用动，重新选一次就行。所以别把模型名写死在脑子里，写死的是分层关系。判断自己适不适合这条路，看下面几条。
- 适合：数据必须留在自己机器上，不方便走外部接口
- 适合：想用本地算力，不想为每次调用单独付费
- 适合：要自己改工作流逻辑、挂知识库、做内部工具
- 不适合：只是偶尔问两句，用官方 App 更省事，本地部署的维护成本不划算
安装顺序与网络形态：决定后面能不能连上
顺序很重要：先装 Ollama 并确认本地能正常对话，再装 Dify。反过来的话，出问题时分不清是 Dify 配置错了还是 Ollama 没起来。这一步的验收标准很朴素——在终端里能跟模型一问一答，就说明推理这层没问题了。
接着要选网络形态。两种常见摆法：一是 Dify 用 Docker 起、Ollama 装在宿主机；二是两个都放进 Docker。宿主机加 Docker 是最常见的组合，也最容易踩坑，因为容器内的 127.0.0.1 指的是容器自己，不是你的电脑。容器要访问宿主机，得用宿主机在 Docker 网络里的别名，或者宿主机的局域网地址。
- 先装 Ollama 并本地验证装完在终端里直接对话一次，能回就说明推理服务本身是通的，这一步不通过后面都白搭。
- 再装 Dify用官方推荐的 Docker 方式起，起来后能打开界面即算过；此时还不用接模型。
- 确认两者网络位置想清楚 Ollama 在宿主机还是容器里。用 docker ps 看 Dify 各容器的网络，别默认它们是同一台机器。
- 拿宿主机地址做一次连通测试在 Dify 的容器里执行一次访问 Ollama 地址的命令，通不通直接决定你填的地址对不对。
在 Dify 里把模型接上：填什么、怎么验证
入口在设置里的模型供应商，选 Ollama 那一栏，填的是 Ollama 的服务地址加端口。填完先点保存，再看模型列表能不能拉出来。列表为空，基本就是地址或端口不对，不用往更深处猜。注意 Dify 只是读取已存在的模型，它不会替你下载，所以模型得先用 Ollama 拉下来。
还有一点常被忽略：对话和 Embedding 要分开配。聊天用对话模型，知识库检索要另外配一个嵌入模型，两者不能混着填。混填的后果是聊天能用、知识库一检索就报错，看着像知识库的问题，其实是模型类型填错了。
| 要填的项 | 填之前确认 | 填完怎么验 |
|---|---|---|
| 服务地址 | 宿主机在 Docker 网络里的别名或 IP | 保存后能拉出模型列表 |
| 对话模型 | Ollama 里已经拉好 | 发一句能收到回复 |
| 嵌入模型 | 单独拉过一个嵌入模型 | 知识库能建索引并检索 |
| 参数项 | 按你的使用场景调 | 长文本不截断、回复不中断 |
更细的字段与参数写法，别凭记忆填，到 部署测算 那页对一遍再动手。那页把常见参数的含义和适用场景列得比较细，比在界面里试错快。
验收与排查：按这个顺序找问题
排查最忌讳东试一下西试一下。建议固定一个从外到内的顺序：先确认推理服务本身，再确认网络，再看 Dify 日志，最后才怀疑模型。每一步都能把问题范围砍掉一半，比反复改配置有效得多。
- 宿主机上打接口在宿主机上用 curl 打 Ollama 的接口，通不通先确认推理服务本身没问题。不通就是 Ollama 没起或端口不对。
- 容器里打同一个地址进 Dify 的容器执行同样的请求。这一步能区分是服务问题还是网络问题，容器的结果和宿主机不一样，就是网络层的事。
- 看 Dify 日志里的错误类型连接超时多为网络问题，404 多为路径或端口填错。先看错误类型，再决定改哪儿。
- 换一个小模型试前面都通了还不回，就换一个已经拉好的小模型。能回就说明是原模型加载的问题，去查显存和模型文件。
- 跑一次最简单的对话调完先测基本对话，别一上来就压工作流，出错了不好定位是编排的问题还是模型的问题。
还有个容易被忽略的东西：延迟基线。你现在觉得快，是因为没参照。拿不准的话，用 接口测速 先量一遍本地响应时间，后面觉得变慢了、或者想加人加任务时，手上就有对照数据，不用靠感觉。
能跑之后要盯什么：别等它变慢才发现
跑通只是开始。本地部署最常见的翻车不是连不上，而是某天突然变慢或者回答到一半断掉。原因通常就那几个：显存被占满、并发超出机器能扛的量、换了模型但 Dify 里没重新选。这几个都能提前盯，不用等出事。
- 先确认显存够：加载失败、回答断在一半，多数是显存被别的进程占满
- 并发别贪多：本地一个跑得动，不等于能同时服务好几个人，多人用之前先做一次简单压测
- 换模型后回 Dify 重新选一次：旧配置还挂在原来的模型名上会报找不到
- 把用过的模型和参数记一笔，回头出问题好回退，也方便对比
- 显存和并发怎么估，别拍脑袋，按算法算一遍再买卡或加机器
显存和并发怎么估，参考 几张卡够用 里的算法，再结合你自己的卡对一遍。那页的思路是先算权重占用，再留出上下文和并发余量，比问别人「我这卡能跑吗」靠谱。
最后提醒一句适用范围：本文讲的是一台机器上自用的场景，能跑通、能排查就够了。如果你要对外提供服务、要稳定的并发和可用性，那就是另一套工程问题，本地单机的配置方式不适用。
下一步想知道本地这套大概什么水平、值不值得继续投入，去工具目录里挑几个测试工具实测一遍，比看别人的结论更靠谱。→常见问题
Dify 里填了 Ollama 地址为什么还是连不上？
先分清 Dify 是跑在 Docker 里还是直接装在宿主机上。跑在容器里时，127.0.0.1 指的是容器自身，不是你装了 Ollama 的那台机器。换成宿主机在 Docker 网络里的地址或局域网 IP，再确认 Ollama 允许外部访问、防火墙端口放开，三项都对了通常就能通。
必须两个都装 Docker 吗？
不是必须。常见做法是 Ollama 直接装在宿主机上（方便用本机显卡），Dify 用 Docker 起。这样显卡驱动和显存管理最简单，代价是容器访问宿主机要绕一下地址。如果两个都放 Docker 里，网络反而好配，但 GPU 透传给容器要额外设置，看你对 Docker 熟不熟。
接上之后能直接用知识库吗？
能，但要额外配一个嵌入模型，只有对话模型是不够的。对话模型负责生成回答，嵌入模型负责把文档和问题转成向量做检索，两者在 Dify 里是分开配的。另外文档切分粒度和检索条数都会明显影响效果，建议先用少量文档跑通链路再批量导入。
