你在本地用 Ollama 跑着 DeepSeek，想把它接进 Dify 当应用后端，结果卡在「配了但拉不到模型」或者「保存就报错」。这篇按顺序讲清三件事：Ollama 那一侧要暴露成什么形态、Dify 里该填哪个地址和模型名、报错时按什么顺序排查。不涉及参数选购和榜单结论，只讲把链路打通的动作。
你在本地用 Ollama 跑着 DeepSeek，想把它接进 Dify 当应用后端，结果卡在「配了但拉不到模型」或者「保存就报错」。别急着重装，这类问题九成出在链路的某一段没打通，而不是软件坏了。
这篇按顺序讲清三件事：Ollama 那一侧要暴露成什么形态、Dify 里该填哪个地址和模型名、报错时按什么顺序排查。不涉及参数选购和榜单结论，只讲把链路打通的动作。选型和横向对比可以到 /rankings 和 /tools/speed-test 看当时的数字。
第一步：先确认 Ollama 那一侧是不是「可被访问」的
动手配 Dify 之前，先在终端把模型跑通一次。模型本身都没起来，Dify 那边怎么填都是失败。这一步只要出现正常的对话输出，就说明模型侧没问题，可以往下走。
- 拉模型并直接对话用 ollama 命令行先把目标模型拉下来，再发一句最简单的话测试。能正常返回，才算模型侧就绪。
- 确认监听地址默认情况下 Ollama 只监听本机回环地址，外部进程访问不到。需要改环境变量把监听范围放开，改成能被其他地址访问的形式，改完必须重启服务才生效。
- 重启后验证接口用命令行或浏览器直接请求一次模型列表接口，返回内容里能看到刚才那个模型名，就说明暴露成功了。
- 区分访问来源先在本机 curl 一次，如果本机通但 Dify 不通，问题基本不在 Ollama 而在网络。这一步能帮你提前把排查范围切一半。
第二步：Dify 里填什么——地址、模型名、要不要 key
进 Dify 的模型供应商页面，找到 Ollama 这一类，然后把地址和模型名填对。这一步最常见的坑是地址写多了路径、模型名少了一个字符，两者都会让保存或拉取失败。
| 要填的项 | 怎么填 | 常见错误 |
|---|---|---|
| 接口地址 | 只填根地址，不要带任何模型相关的路径后缀 | 多写了后缀，导致保存或连接失败 |
| 模型名称 | 跟 Ollama 里的名字逐字一致，冒号后的标签也算 | 大小写错、漏掉冒号后半段 |
| 密钥字段 | Ollama 一般不需要真密钥，但字段不能空 | 留空导致校验不通过 |
| 容器场景地址 | 写宿主机内网地址或容器网络里能解析的名字 | 写 localhost，容器里指向的是自己 |
地址这一项在 Dify 容器部署时特别容易错。Dify 跑在容器里，localhost 指的是容器自身，不是你的宿主机。所以要么用宿主机在局域网里的地址，要么用容器网络里能互相解析的服务名。
- 保存前再核对一遍模型名，包括冒号和标签部分
- 密钥字段即使不用也填一个非空值
- 保存成功后回到模型列表，手动点一次连通性测试或发一条最短消息
- 看到真的出字，才算这一步完成，不要只看「保存成功」的提示
第三步：连不上时的排查顺序，别乱试
连不上时最忌东改一处西改一处。按层排查，每层只回答一个问题，很快就能定位到是哪一段断了。下面这个顺序命中率最高，照做就行。
- 第一层：从宿主机直接请求 Ollama 接口，能不能拿到模型列表
- 第二层：进 Dify 容器内部，用同样的方式请求一次，看是不是网络不通
- 第三层：在 Dify 界面拉模型列表，看能不能显示出来
- 第四层：发一条最短测试消息，看是否真的返回内容
四类常见原因按概率排：地址写错、监听没放开、模型名不匹配、容器网络不通。前三个都在前面两步覆盖过，第四个要看你用的是什么部署方式。如果一直转圈或超时，先确认是不是模型正在加载进显存，首次调用本来就慢，别当成配置错误去改。
长上下文或参数较大的模型，在普通机器上跑起来，超时阈值和并发数都要往下压，否则表现就是「配置对了但请求总失败」。想长期用，把「能跑通」和「跑得稳」分开验收：先用一条请求确认链路通，再发几条并发看会不会崩。显存和吞吐的估算可以到 /tools/speed-test 跑一遍当时的数字。
这套配法适合谁、什么情况下别这么干
本地 Ollama 接 Dify 最适合个人或小团队做原型、验证流程，主要动机是数据不出内网、调用不依赖外部服务。一家 5 人小团队拿它跑内部工具的原型验证，是合理的用法。
| 场景 | 适不适合 | 原因 |
|---|---|---|
| 个人本地做原型 | 适合 | 链路简单，数据不出机器 |
| 小团队内网验证流程 | 适合 | 够用且可控，成本低 |
| 对外提供正式服务 | 不适合 | 缺少账号隔离、限流和审计 |
| 高并发多人共用 | 不适合 | 单机推理框架扛不住，应换专门方案 |
不适合的情况要说清楚：Ollama 默认面向单机单人场景，没有账号隔离、限流和审计，直接暴露到公网风险很大。追求高并发或多人共用，应该换专门的推理服务框架，Dify 只当上层编排。机器配置撑不住更大模型时，先用小参数模型把链路跑通，再按需要换模型，不要把「配通」和「换大模型」两件事混在一起调。
另外，如果你评估的是「要不要继续用第三方接口」，那属于另一条路线，跟本地自建的取舍不同，可以对照 /sites 和 /price-watch 看当时的可信度和价格数字再决定。
下一步链路打通之后，建议顺手在站内工具页跑一次推理速度测试，把当前机器能扛的并发和响应时间记下来，后面换模型或加并发时有对照基准。→常见问题
Dify 里填 Ollama 地址，为什么写 localhost 连不上？
因为 Dify 通常跑在容器里，容器内的 localhost 是它自己，不是你的宿主机。要么换成宿主机的内网 IP，要么走两个容器之间的网络别名，并且确认 Ollama 已经放开监听，能接受来自该地址的请求。改完重启服务再测一次。
模型列表拉不到，一定是配置错了吗？
不一定。先确认 Ollama 服务本身在跑、模型名拼写和标签完全一致；再确认地址指向的不是别的进程。如果模型体积大、正在加载，首次请求会明显变慢甚至看起来像失败，等它加载完再试一次，把「没配好」和「还没加载完」分开判断。
本地跑通了，能直接给团队多人用吗？
短期小范围可以，但别当生产服务。本地推理服务一般没有账号隔离、限流和审计，多人同时用容易互相拖慢甚至崩掉。要多人共用，先算清显存和并发上限，再考虑换成面向服务的推理框架，具体数字到站内的部署测算和算力页面按你的机器核对。
