如何将本地大模型与dify关联起来

本地模型跑通了，一问 Dify 里却选不到、连不上、报超时，多数人卡在这一步。这篇按顺序走一遍：先确认本地服务对外是什么形态，再在 Dify 里配对模型供应商，填地址和密钥，最后用一条测试对话验证通不通。不涉及选哪个模型、也不比较租卡和自建，只解决怎么把两边接上。

本地模型在命令行里跑得挺欢，一进 Dify 就选不到、连不上、报超时，这几乎是每个人都会踩的坑。问题通常不在模型本身，而在中间那段「怎么让 Dify 摸到你的服务」没配对。

这篇只解决接上这一件事，按顺序走：先确认本地服务对外是什么形态，再在 Dify 里选对供应商类型、填地址和密钥，最后用一条最短的测试对话验证。不涉及选哪个模型，也不比较租卡和自建，那些去站内模型资料库看当时的数字。

先确认本地模型服务能不能被 Dify 摸到

接之前先分清你的本地服务是哪种形态：一种自带 OpenAI 兼容接口，另一种只有框架自己的原生接口。前者 Dify 对接很省事，后者要走对应的供应商条目。两种都行，但填法完全不同，搞错了再怎么试都连不上。

1. 宿主机上先自己调通用 curl 或类似方式把模型列表接口打一遍，确认返回正常。这一步是排除服务本身的问题，服务没起后面全是白忙。
2. 确认 Dify 从哪发起请求Dify 跑在容器里时，它眼里的 localhost 是容器自己，不是你的宿主机。这是最常见的失败原因。
3. 把地址换成能互通的形态要么填宿主机在容器网络里的内网 IP，要么让两个服务挂在同一个 docker 网络里，用服务名互访。
4. 顺手确认端口和防火墙端口有没有对外开放、防火墙有没有放行，属于接之前就该排除的项，留到最后查会浪费大量时间。

在 Dify 里选对模型供应商类型

Dify 的模型供应商列表里，本地服务基本落进两类。选对类型比填对地址还靠前，因为填错类型的话，地址栏填什么都白搭。

• 地址要不要带版本路径后缀，带不带差一个字就连不上，两边各试一次能快速确认
• 密钥栏本地服务往往没有真校验，但 Dify 里通常不能留空，填一个符合格式的占位值即可
• 原生接口类供应商填的是服务地址，模型列表会被自动拉出来，不用手写模型名
• 如果列表拉不出来，先怀疑地址末尾多或少了斜杠、后缀，而不是模型没加载

填完先点保存，别急着去建应用。Dify 有些版本会在保存时去探一次模型列表，列表拉不出来会当场报错，这一步能提前暴露地址问题。

接通之后怎么验证，以及顺手要调的参数

接通了不代表能用。先用一条最短的测试对话验证整条链路，别一上来就挂知识库或工作流，出问题时分不清是哪一层坏的。

1. 跑一条最短对话在模型供应商页面或新建一个空白应用里发一句话，只看它能不能正常返回。
2. 指定系统模型用途进系统模型设置，把对话、嵌入这类用途各自指到对应模型。嵌入模型和对话模型不能混着填，混了检索会乱。
3. 按实际窗口调上下文长度填大了会截断或直接报错，填小了长文档场景会掉内容，按本地模型真实支持的窗口来。
4. 调超时和流式输出本地推理比云端慢，超时时间要留够；流式输出打开，交互体感会好很多。

连不上时的排查顺序

报错不可怕，怕的是东摸一下西摸一下。按固定顺序走，每一步只回答一个是或否的问题，能最快定位。

其中第一步最关键，容器日志里的报错通常会直接写清是哪一类问题。很多人跳过它直接改配置，反而绕远。想先量出本机推理的延迟基线，可以去 /tools/speed-test 测一遍，心里有个底再回去调超时。