1. Dify 模型供应商扩展后Llama2 与 ChatGLM 到底怎么接Dify 从 V0.3.13 开始把模型供应商的名单拉长了一大截Llama2、ChatGLM、百川 Baichuan、通义千问-7B 这些托管在 Hugging Face 和 Replicate 上的开源模型都能通过填 API Token 加模型名称的方式接进来。这件事对开发者的实际意义是你不再需要为了试一个开源模型去单独写一套推理服务Dify 把「模型供应商配置」和「应用编排」拆开了换模型就像在设置页里换个条目。这篇内容面向的是需要在本地或云端快速调用 Llama2、ChatGLM 等热门开源模型的开发者。我会把 Dify 里模型供应商的接入配置、API Key 与 Base URL 的填写示例、对话调用与流式输出的验证动作完整走一遍让你从配置到可用形成闭环。如果你之前卡在「填了 Key 但模型列表刷不出来」或者「对话报 401」第 5 节的排错对照可以直接拿去用。需要先明确一个前提Dify 本身是应用编排层它不负责跑模型权重。Llama2 这类开源模型要么托管在 Replicate、Hugging Face 上要么你自己用兼容 OpenAI 协议的服务暴露出来。Dify 的「模型供应商」做的就是把这几种来源统一成一套调用接口。所以配置的核心永远是三件套Base URL、API Key、Model ID。这三样填对剩下的就是验证。我试过在同一个 Dify 工作区里同时挂 Replicate 的 Llama2 和 Hugging Face 的 ChatGLM2切换时只需要在应用编排页的模型选择器里点一下不用改任何代码。下面按顺序拆开讲。2. TaoToken 前置把兼容 OpenAI 的入口准备好在讲 Dify 的具体配置之前先解决一个很多人会忽略的问题如果你要接的开源模型不是托管在 Replicate 或 Hugging Face而是自己部署或通过第三方兼容 OpenAI 协议的服务暴露那你就需要一个稳定的 Base URL 和 Key。TaoToken 在这里的角色就是提供这样一个兼容 OpenAI 协议的入口官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。为什么要在 Dify 接入开源模型时提这个因为 Dify 的「OpenAI 自定义 API 域名」能力允许你填任意兼容 OpenAI 的服务器地址。也就是说只要你的模型服务遵循 OpenAI 的/v1/chat/completions格式就能通过这个入口接进 Dify。Llama2、ChatGLM 的很多部署方案比如 vLLM、FastChat、Ollama 的 OpenAI 兼容层都符合这个格式。你需要准备的东西很简单一个 API Key以及确认 Base URL 填https://taotoken.net/api。注意这里不要带 UTM 参数API 调用地址就是干净的https://taotoken.net/api。Key 的获取在控制台的 API Keys 页面地址是 https://taotoken.net/console/api-keys 登录后新建一个即可。拿到 Key 之后先别急着进 Dify。建议用 curl 在命令行验证一次确认这个入口本身是通的再去 Dify 里配置。这样能把「入口问题」和「Dify 配置问题」分开排错时省一半时间。验证命令在第 4 节会给。如果你更习惯在对话界面里先试模型效果可以走模型对话入口 https://taotoken.net/models 先确认模型能正常返回再回到 Dify 做编排。这个顺序对新手最友好先证明模型可用再证明 Dify 能调通。对于长期要做编码或 Agent 场景的Coding Plan 页面 https://taotoken.net/coding-plan 里有更细的额度说明这里不展开你按自己用量选就行。接入文档在 https://taotoken.net/doc 配置项有疑问时对照文档比猜要快。3. 可复制配置Dify 模型供应商的 JSON 与填写示例这一节是全文最需要你动手的部分。Dify 的模型供应商配置分两类一类是内置供应商Replicate、Hugging Face、OpenAI 自定义一类是通过「OpenAI-API-compatible」这种通用条目接入。下面分别给可复制的片段。先说 Replicate 接 Llama2。进入 Dify 设置 → 模型供应商 → 找到 Replicate点配置填入你的 Replicate API Token。然后在模型列表里添加模型Model Name 填meta/llama-2-70b-chatModel Type 选 LLM。这里的 Model Name 必须和 Replicate 上的模型标识完全一致大小写和斜杠都不能错。再说 Hugging Face 接 ChatGLM2。同样在模型供应商里找 Hugging Face填入 HF Token模型名称填THUDM/chatglm2-6b。注意 Hugging Face 的推理端点需要模型已经部署为 Inference Endpoint否则调用会返回 404这一点在第 5 节会展开。如果你走的是 OpenAI 兼容入口比如 TaoToken 或自建的 vLLM 服务配置方式不一样。Dify 里选「OpenAI-API-compatible」然后填三个字段{ model_name: llama-2-70b-chat, base_url: https://taotoken.net/api, api_key: sk-你的Key, model_type: llm, context_size: 4096, max_tokens_to_sample: 2048 }这段 JSON 对应的是 Dify 模型配置表单里的字段你按界面逐项填即可。context_size对 Llama2 填 4096因为 Llama2 的上下文窗口就是 4096 词元。ChatGLM2-6B 的上下文是 8192填的时候别照抄 Llama2 的值。如果你用 TOML 管理本地配置比如自建服务可以这样写[model_providers.taotoken] base_url https://taotoken.net/api api_key sk-你的Key model chatglm2-6b context_window 8192 max_output_tokens 2048这里的三件套对应关系要记牢Base URL 是https://taotoken.net/apiKey 是控制台生成的sk-开头字符串Model ID 是你要调的具体模型名。任何一处填错Dify 的模型测试都会失败。配置完成后Dify 的模型选择器里会出现你刚加的条目。建议先在「系统模型设置」里把它设为默认对话模型再去创建应用这样应用创建时就直接可用少一步切换。4. 验证请求对话调用与流式输出的成功结果配置填完不代表能用必须做一次真实请求验证。分两步先用 curl 验证入口再在 Dify 里验证对话和流式输出。第一步命令行验证。把下面的命令里的 Key 换成你自己的curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的Key \ -d { model: llama-2-70b-chat, messages: [{role: user, content: 用一句话解释什么是开源大模型}], stream: false }如果返回里有choices数组且message.content有正常文本说明入口和 Key 都没问题。如果返回 401看第 5 节。第二步Dify 内验证。进入你创建的应用在编排页的模型选择器里选中刚配置的 Llama2 或 ChatGLM然后在右侧调试窗口输入一句话比如「你好介绍一下你自己」。正常情况你会看到模型逐字返回。如果 Dify 界面里出现「reading choices」相关报错说明返回结构不符合预期通常是 Base URL 少了/v1或多了斜杠。流式输出的验证要单独做。在 Dify 应用编排里把「流式输出」开关打开再发一次请求。观察两点一是文字是否逐字出现而不是一次性刷出二是浏览器 Network 面板里是否看到text/event-stream类型的响应。如果开关开了但还是一次性返回多半是模型服务端不支持流式或者 Dify 的供应商配置里没勾选 stream 能力。一个实测有效的判断方法在 Dify 调试窗口发一个需要较长回答的问题比如「写一段 200 字的产品介绍」。流式正常的话你能明显看到文字一段段冒出来非流式则要等几秒后整段出现。这个体感差异比看日志更直接。验证通过后建议把这次成功的配置截图或记录下 Model ID 和 Base URL后面换环境时直接复用不用重新试错。5. 本篇常见错排查401、local proxy failed 与 reading choices这一节按真实报错来对照你遇到哪个查哪个。401 Unauthorized。最常见的原因是 Key 填错或带了多余空格。Dify 的 Key 输入框有时会把你复制时带的换行也存进去粘贴后手动删一下末尾。另一个原因是 Base URL 和 Key 不匹配比如 Key 是 A 平台的Base URL 填了 B 平台的。确认两者来自同一处。如果 Key 确认无误仍 401去控制台看这个 Key 是否被禁用或额度耗尽。local proxy failed。这个报错通常出现在 Dify 部署在容器里、而模型服务在宿主机或另一网络环境时。Dify 的容器访问不到你填的 Base URL。排查方法进 Dify 容器执行curl测一下目标地址通不通。如果是本地服务把 Base URL 里的localhost换成宿主机的内网 IP或者用 Docker 的host.docker.internal。云端部署则检查安全组和防火墙是否放行了出站。reading choices 相关报错。完整报错常是Error reading choices或invalid response format。这说明请求发出去了但返回的 JSON 结构里没有 Dify 期望的choices字段。原因通常是 Base URL 路径不对。OpenAI 兼容接口的完整路径是/v1/chat/completions你在 Dify 里填 Base URL 时一般填到/api或/v1这一层Dify 会自己拼后面的部分。如果你填成了完整的/v1/chat/completions就会拼出重复路径返回 404 或非标准结构。正确填法是https://taotoken.net/api让 Dify 去补/v1/chat/completions。OAuth 或 token 过期类报错。Hugging Face 和 Replicate 的 Token 都有有效期或权限范围。HF Token 需要勾选read权限Replicate Token 需要确认账户有可用额度。如果报错里出现OAuth字样去对应平台重新生成 Token别用旧的。模型列表为空。配置保存了但模型选择器里看不到。检查 Model Type 是否选对LLM 和 Embedding 是分开的。另外 Dify 有些版本需要手动点「添加模型」才会出现在列表里不是保存供应商就自动出现。Codex auth.json 相关。如果你在用 Codex 类工具并涉及auth.json注意里面的 Base URL、Key、Model ID 三件套要和 Dify 里填的一致。auth.json里通常长这样{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: chatglm2-6b }三处不一致是排错时最容易漏的点。改完auth.json记得重启对应服务很多工具是启动时读一次配置。6. 从配置到可用的闭环以及后续怎么选模型把上面的流程走完你手里应该有一个能在 Dify 里正常对话、且流式输出可用的开源模型条目。这个闭环的关键不是某一步配置而是「先验证入口、再配置 Dify、最后验证流式」这个顺序。顺序对了出问题时你能立刻定位是哪一层。关于模型选择Llama2 适合长文本和英文为主的场景4096 的上下文在处理长文档时比早期模型宽裕不少。ChatGLM2-6B 的优势是中英双语和消费级显卡可跑部署门槛低适合本地快速验证。百川和通义千问-7B 在中文知识类任务上各有侧重具体哪个更合适最省事的办法是在 Dify 里建同一个应用用你的业务数据分别跑一遍看输出质量再定。Dify 的模型选择器让这种对比成本变得很低切换模型不用改代码也不用重新部署。你可以把同一段 Prompt 在几个模型上各跑一次记录返回质量和响应速度再决定长期用哪个。后续如果 Dify 支持了新的供应商接入方式基本还是这套三件套逻辑。把 Base URL、Key、Model ID 填对先 curl 验证再进 Dify 配置最后验证流式。这套方法不挑模型换哪个开源模型都能套用。