30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度1. 先搞清楚 Dify 接入大模型到底要解决什么问题如果你正在找一种方法能快速把 OpenAI、Claude、智谱、通义千问甚至是本地部署的 Llama、Qwen 这些大模型集成到你自己的应用、工作流或者知识库系统里那么 Dify 的“模型接入”功能就是你最该优先看的部分。它不是一个简单的 API 转发器而是一个生产级的模型编排与代理工作流平台。核心价值在于它让你能在一个统一的界面里管理不同厂商、不同协议的模型并基于这些模型构建复杂的 AI 应用而不用为每个模型单独写一堆胶水代码。很多人第一次接触 Dify容易被它“可视化工作流”、“RAG 知识库”这些高级功能吸引但往往卡在第一步模型怎么接进去是填个 API Key 就行还是需要自己部署服务支持哪些模型计费怎么算这些问题不搞清楚后面的所有功能都是空中楼阁。根据我的实测经验Dify 在模型接入上最实用的三点是协议兼容性极广它不仅支持 OpenAI 兼容的 API这是基础还原生支持 Anthropic Claude、智谱、百度文心、阿里通义、讯飞星火等国内主流厂商的官方接口格式。这意味着你不需要自己处理各家不同的 SDK 和调用方式。本地模型无缝集成通过支持 Ollama、vLLM、LocalAI 等本地推理框架你可以把在自己机器上跑的私有模型比如 Llama 3、Qwen 2.5当成一个“云端服务”来用享受和商用 API 一样的编排能力。统一的管理与切换所有接入的模型都在一个地方管理。你可以为同一个应用设置多个备选模型一个挂了或者太贵可以自动或手动切换到另一个这对保证服务稳定性至关重要。所以这一课的关键不是“接入”这个动作而是理解接入后能带来什么工程化优势统一的密钥管理、可视化的模型测试、便捷的切换和成本控制。下面我们就从环境准备开始一步步拆解。2. 接入前的环境准备与核心概念梳理在开始填 API Key 之前先确保你的 Dify 环境是正常运行的。根据热词来看很多朋友卡在dify internal server error或dify llm 提供者的密钥未设置这类问题上这通常和环境、配置有关不一定是模型本身的问题。2.1 确认你的 Dify 运行状态Dify 支持多种部署方式Docker Compose、Kubernetes、直接源码运行甚至有一键脚本。无论哪种方式接入模型前请先通过以下命令确认核心服务API 服务器和前端是否健康# 如果你使用 Docker Compose 部署检查容器状态 docker-compose ps # 应该看到类似下面的输出状态均为 Up # Name Command State Ports # -------------------------------------------------------------------------------- # dify-api /bin/bash /app/entrypoint ... Up 80/tcp, 5001/tcp # dify-web /docker-entrypoint.sh ngin ... Up 0.0.0.0:80-80/tcp # dify-redis docker-entrypoint.sh redis ... Up 6379/tcp # dify-weaviate /bin/sh -c /bin/entrypoint ... Up 8080/tcp然后在浏览器访问你的 Dify 地址通常是http://你的服务器IP或域名能正常看到登录/注册页面并且能成功登录进入控制台。如果这一步就报错先别急着搞模型去查日志docker-compose logs -f解决基础服务问题。2.2 理解 Dify 中的“模型供应商”和“模型”这是两个容易混淆但必须分清的概念模型供应商指的是提供模型服务的平台或协议比如 “OpenAI”、“Anthropic”、“智谱AI”、“Ollama”。你需要为每个供应商配置一次性的连接信息如 API 基础地址、密钥等。模型指的是供应商提供的具体模型比如 “gpt-4o”、“claude-3-5-sonnet”、“glm-4”。你需要在供应商配置的基础上再选择或创建具体的模型并为其设置单价、上下文长度等参数。一个供应商下可以有多个模型。例如在 “OpenAI” 供应商下你可以配置 “gpt-4o”、“gpt-4-turbo” 等多个模型。这种设计让你能灵活地管理同一平台的不同型号。2.3 准备你的模型访问凭证根据你要接入的模型类型提前准备好以下信息模型类型需要准备的信息示例/说明云端商用 API1. 对应平台的 API Key2. 可选API Base URL如需代理或自定义端点OpenAI:sk-xxx智谱:你的API Key通义:你的API Key本地模型 (Ollama)1. Ollama 服务的地址通常为http://主机IP:114342. 已拉取到本地的模型名称地址:http://192.168.1.100:11434模型:llama3.2:3b本地模型 (vLLM)1. vLLM 服务的 OpenAI 兼容 API 地址地址:http://主机IP:8000/v1其他 OpenAI 兼容 API1. API Base URL2. API Key如果需要例如一些开源项目或第三方服务提供的兼容接口注意对于本地模型确保 Dify 服务所在的网络能够访问到你的模型服务地址。如果 Dify 用 Docker 部署而 Ollama 跑在宿主机需要使用host.docker.internalMac/Windows或宿主机真实 IPLinux进行连接。环境就绪概念清晰凭证在手我们就可以进入控制台开始实际操作了。3. 一步步配置从云端 API 到本地模型登录 Dify 控制台点击左侧导航栏的“模型供应商”这里是所有操作的起点。我建议按以下顺序操作从最简单的云端 API 开始再尝试本地模型。3.1 接入云端商用 API以 OpenAI 为例这是最常见、最稳定的方式。假设你已经有了 OpenAI 的 API Key。添加供应商在“模型供应商”页面点击“添加供应商”在列表中选择“OpenAI”。填写配置供应商名称自定义如 “My-OpenAI”。API Key填入你的sk-xxx。API Base URL绝大多数情况留空即可。只有当你使用了第三方代理服务注意此处不讨论任何违规网络访问行为或自建了 OpenAI 兼容网关时才需要填写。默认会使用官方地址https://api.openai.com/v1。代理根据你的网络环境配置。如果你的服务器无法直接访问 OpenAI可能需要在此处配置合规的网络代理。请务必遵守当地法律法规仅使用合规的企业级网络解决方案。测试连接填写后点击“测试连接”。Dify 会尝试用这个 Key 调用一个简单接口。看到“连接成功”的提示说明密钥和网络都正常。添加具体模型连接成功后页面会自动跳转或刷新下方会出现“添加模型”的选项。点击后你可以从预置的模型列表中选择比如gpt-4o、gpt-4-turbo-preview。选择后需要配置模型名称在 Dify 中显示的名字可以自定义。模型类型根据模型能力选择“聊天”或“补全”。现代模型如 GPT-4 都选“聊天”。单价非常重要这里填写的是每 1000 个 tokens 的价格单位美元。你需要在 OpenAI 官网定价页面查询准确价格并填入Dify 会根据用量计算成本。例如gpt-4o输入 $5.00输出 $15.00单位是每百万 tokens需换算成每千 tokens输入 0.005输出 0.015。上下文长度填写模型支持的最大 tokens 数如128000。完成这些步骤这个模型就可以在你的应用和工作流中使用了。其他云端供应商Anthropic、智谱、通义等流程几乎一模一样只是在第一步选择对应的供应商然后填入该平台提供的 API Key 和 Base URL如果有。3.2 接入本地模型以 Ollama 为例这是很多开发者关注的点想在本地或内网使用开源模型。Ollama 是目前最方便的本地模型运行器。确保 Ollama 服务已启动在你的模型服务器上确保 Ollama 正在运行并且已经拉取了需要的模型例如ollama pull llama3.2:3b。可以通过curl http://localhost:11434/api/tags测试。在 Dify 中添加供应商在“模型供应商”页面选择“Ollama”。填写配置供应商名称如 “My-Ollama-Local”。API Base URL填写 Ollama 服务的地址。这是关键。如果 Ollama 和 Dify 在同一台机器且都用 Docker 运行可能需要使用 Docker 网络 IP 或服务名。如果 Ollama 在宿主机Dify 在 Docker在 Linux 下通常填http://host.docker.internal:11434Mac/Windows Docker Desktop 也支持。在纯 Linux 宿主机部署时可能需要填宿主机的真实内网 IP如http://192.168.1.100:11434。测试连接点击测试。成功后会显示“连接成功”并列出 Ollama 中已下载的模型列表。添加模型从列表中选择你想要的模型比如llama3.2:3b。然后配置模型名称自定义。模型类型选“聊天”。单价本地模型不计费这里可以填0。上下文长度根据模型实际情况填写例如8192。配置完成后这个本地模型就会出现在你的模型列表中可以和云端 API 一样被工作流和知识库调用。3.3 处理常见接入错误在配置过程中你可能会遇到以下问题这是我的排查顺序“连接失败”或“内部服务器错误”第一步检查网络连通性。在 Dify 服务器上用curl命令尝试直接访问你填写的 API Base URL。例如curl http://192.168.1.100:11434/api/tags。如果连不上是网络或服务问题。第二步检查 API Key 是否正确是否有余额或调用权限。第三步查看 Dify 后台日志。通过docker-compose logs dify-api查看具体错误信息通常会比前台的报错更详细。模型列表加载不出来Ollama 常见通常是 Base URL 不对或者 Ollama 服务未启动。确保 Ollama 的 API 端口默认 11434可访问。dify llm 提供者的密钥未设置这个错误通常发生在你创建了应用或工作流但忘记给应用配置默认的模型。你需要进入具体应用的“模型设置”页面为其选择一个已配置好的模型。也可能意味着你配置的模型供应商本身没有添加任何可用的模型实例。回去检查“模型供应商”页面确认对应供应商下是否有“已启用”的模型。4. 模型配置的进阶用法与生产实践模型接入成功只是第一步。要让它在生产环境中稳定、经济地运行还需要关注以下几个进阶配置点。4.1 为同一供应商配置多个模型与负载均衡一个应用不应该只绑定一个模型。你可以在同一个供应商下添加多个不同型号或配置的模型。例如在“OpenAI”供应商下你可以同时添加gpt-4o用于需要高智力的复杂任务。gpt-3.5-turbo用于简单的对话和低成本任务。gpt-4-turbo-preview用于需要超长上下文的任务。在应用的“模型设置”中你可以设置一个默认模型并配置备选模型。当默认模型因额度不足、速率限制或故障无法响应时Dify 会自动按顺序尝试备选模型。这是提高应用鲁棒性的关键。4.2 精细化的成本与限额控制在模型配置页面除了单价还有几个重要参数每秒请求数限制限制对该模型的并发请求频率防止意外刷爆 API 额度。每秒 Token 数限制限制 Token 的消耗速度是更精细的成本控制手段。输入/输出单价分开设置对于按输入/输出分别计费的模型如 GPT-4务必准确填写这样成本统计才准确。建议在新模型上线初期先设置一个较严格的限额跑一段时间观察用量和成本再逐步调整。4.3 利用模型模式适配不同场景Dify 的模型配置中有“模式”选项这经常被忽略但很有用聊天模式用于多轮对话模型会维护对话历史上下文。补全模式用于单轮文本生成比如写文章、翻译、总结不维护历史。选错模式可能导致上下文处理异常。绝大多数基于 Transformer 的现代模型GPT、Claude、GLM、Qwen都应选择“聊天模式”。4.4 本地模型的生产化考量如果你打算在生产环境使用本地模型如通过 Ollama需要额外关注性能与资源本地模型的推理速度远慢于云端 API且消耗 CPU/GPU 和内存。你需要监控服务器资源确保不会因为模型推理导致 Dify 或其他服务卡死。高可用单机 Ollama 是单点。生产环境可以考虑部署多个 vLLM 实例并用负载均衡器暴露一个统一的 API 地址给 Dify。版本管理本地模型的版本更新需要手动维护。在 Dify 中更新模型配置时要注意版本变更可能带来的输出不一致问题。一个稳妥的做法是核心、高并发的生产应用使用稳定的云端 API对数据隐私要求高、流量较低的内部工具使用本地模型。5. 在工作流和知识库中调用配置好的模型模型配置好后最终要落地到具体功能中。Dify 的两大核心——工作流和知识库——调用模型的方式略有不同。5.1 在工作流中使用模型创建工作流时你会用到“LLM”节点。点击该节点进行配置选择供应商和模型这里会下拉列出所有你已配置并启用的模型。直接选择即可。配置提示词在“上下文”或“系统提示词”区域编写你的指令。这里是发挥创造力的地方。参数调优可以调整温度、Top P、最大生成长度等影响模型的创造性和稳定性。关键点工作流中的模型调用是同步的。如果模型响应慢整个工作流会阻塞等待。对于本地模型要特别注意设置合理的超时时间。5.2 在知识库中使用模型知识库的模型配置在两个地方索引模型用于将上传的文档切块并生成向量嵌入。这通常需要一个嵌入模型。Dify 内置了 OpenAI 的text-embedding-3-small等也支持配置其他嵌入模型。如果你的文档是中文为主可以考虑配置兼容 OpenAI 接口的本地嵌入模型如BAAI/bge-large-zh-v1.5效果和成本可能更优。推理模型当用户提问时用于理解问题、检索上下文并生成最终答案的模型。这里就选择你之前配置好的聊天模型如 GPT-4、GLM-4 或本地 Llama。建议知识库对模型的上下文长度要求较高因为需要将检索到的文档片段和问题一起送入模型。优先选择上下文窗口大的模型如 128K 或以上。5.3 测试与监控模型接入并应用后一定要进行测试和监控在控制台测试每个配置好的模型在供应商详情页都有“测试”按钮。用一些标准问题如“你好请介绍一下你自己”测试确保能返回正常响应。查看使用日志在“日志与审计” - “工作流运行日志”中可以看到每次模型调用的详细输入输出、耗时和 Token 消耗。这是排查问题、优化成本的主要依据。关注 Token 消耗在“费用”页面Dify 会根据你设置的单价统计各模型的花费。对于本地模型虽然费用为0但这里的 Token 统计也能帮你了解负载情况。6. 总结从接入到上线的关键检查清单把大模型接入 Dify 只是构建 AI 应用的第一步但这一步走稳了后面会顺畅很多。最后我把自己在项目落地时的检查清单分享给你每次配置完模型都可以对照一遍连通性在 Dify 控制台“模型供应商”页面对每个供应商都点击“测试连接”确保全部通过。模型启用确认在供应商下你计划使用的模型状态是“已启用”而不是“未启用”。应用绑定进入你创建的每个应用工作流或助手在“模型设置”里确认已正确选择了默认模型和备选模型。成本配置对于计费模型反复核对输入/输出单价和上下文长度避免因配置错误导致成本估算偏差巨大。限额设置为生产环境的模型设置合理的 QPS 和 TPM 限制作为安全阀。本地网络如果用了本地模型Ollama/vLLM在 Dify 容器内用curl测试模型服务的连通性和延迟。备份方案关键应用务必配置至少一个备选模型并测试切换功能是否正常。文档记录在团队内部记录每个模型的用途、配置参数和负责人避免后续维护混乱。记住Dify 的模型接入层设计得很好它把复杂的 API 差异和协议封装了起来让你能更专注于提示词工程和工作流设计。花点时间把模型这一层配置扎实后续无论是做智能客服、内容生成还是数据分析你都会有一个稳定可靠的“大脑”供应池。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度