很多人第一次接触 Dify，都会从一个问题开始：它到底能不能同时接本地模型和在线模型？我自己的答案是能，而且这是 Dify 最吸引我的一点。去年我在做一个小型团队的知识库问答系统时，就是让它白天走在线模型处理复杂问题，晚上或离线时切到本地模型做基础检索问答，成本直接降了一个量级。今天这篇就围绕“Dify 调用本地和在线模型服务”这件事，把我踩过的坑、验证过的方法、以及几个关键参数的选择逻辑都摊开来讲。
这篇内容适合谁？想用 Dify 搭 AI 应用但还没搞定模型接入的人，已经接了一个模型但想在本地和在线之间灵活切换的人，以及想搞清楚“为什么这么配”而不是只会抄代码的人。我会尽量少讲废话，直接上实操。
1. 为什么要在 Dify 里同时接本地和在线模型
1.1 本地模型解决的核心痛点
先聊本地模型。很多人一听“本地部署大语言模型”就头大，觉得又是显卡又是显存又是环境配置，其实现在工具链已经很成熟了，Ollama、llama.cpp、vLLM、LocalAI 这些项目把门槛拉低了很多。我自己最常用的是 Ollama，因为它的安装和模型管理实在太省心了。本地模型最大的价值就三个：数据不出内网、调用没网络延迟、长期使用边际成本几乎为零。
数据不出内网这一点，在政企项目和医疗、金融这类场景里尤其重要。线上 API 虽然方便，但数据要经过第三方服务器，光这一点就够合规部门谈很久。我接过一个客户，内部知识库里有大量未公开的研发文档，他们明确要求所有内容只能在内网流转，那在这种条件下，本地模型就是唯一选择。另外，如果你只是做内部工具的 MVP 验证，每天几千次调用，每次都要走线上 API，一个月下来账单也很可观。本地模型虽然效果不一定追得上最顶级的在线模型，但做分类、抽取、摘要这类任务完全够用。
还有一个很实际的原因：离线容灾。我在线下分享的时候经常举一个例子——某次线上模型服务故障，所有走 API 的同事全部抓瞎，但我这边的 Dify 应用走的是本地模型，完全没受影响。当时团队其他人都傻眼了，问我为什么没断。正是因为我在 Dify 里配了两个供应商，本地模型作为 fallback，在线模型挂了系统自动切回来。所以本地模型不是要和在线模型二选一，而是互为兜底。
1.2 在线模型不可替代的能力优势
再来看在线模型。尽管本地模型这几年进步飞快，但要说综合能力，顶级在线模型在复杂逻辑推理、长文本理解、多轮对话一致性、多模态识别这些方面仍然有明显优势。我们实际测过同一个企业知识库问答任务，DeepSeek-R1 蒸馏版在某些环节的表现已经接近 GPT-4o mini，但遇到需要结合多篇文档进行深度推理的题目时，在线大模型的准确率和答案结构明显更好。
在线模型的另一个优势是省心。你不用管 GPU、不用管显存、不用管量化精度、不用管推理框架的版本兼容。注册账号、拿到 API Key、填进 Dify 就能用。而且在线服务通常会有多个地区和实例，并发上限很高。比如你接了一个在线模型供应商，Dify 里配置好之后，短时间内来了一百个用户同时问问题，只要你的套餐允许，基本都能撑住。本地模型如果部署的是小参数模型，并发稍微高一点就直接排队。
在线模型还有一个不可忽视的点：持续迭代。今天你用 GPT-4o，下周供应商可能就发布了新版本，效果评估、多语言支持、安全对齐都在改进。模型供应商自己维护和升级，你的应用只需要在 Dify 里把模型版本切换一下，甚至都不用改代码。相比之下，本地模型想升级还得重新下载权重、重新跑压测，工作量完全不是一个量级。
1.3 混合接入的本质是“场景化分流”
我见过不少团队在选型时非要争出个唯一答案，什么“本地就是不行”“在线太贵不稳定”，其实真没必要。Dify 的最大价值之一就是模糊了“供应商”这个概念的边界，它把所有模型抽象成一个个可配置的 provider，你可以同时挂上本地的 Ollama、在线的 OpenAI 兼容接口、其他国产大模型服务，然后在不同应用或不同工作流里灵活选择和切换。
打个比方。你的团队就像一家餐厅，本地模型是后厨自己备的常备食材，便宜、方便、随时拿；在线模型是高档食材，需要的时候下单采购，贵但品质顶。正常情况下每天用常备食材就能出餐，遇到大客户、重要宴席，再临时买高档食材。混合接入的本质就是给不同场景分配不同的“食材供应链”，控制成本，守住体验。
具体来说，我一般这么分：
- 内部效率工具（知识问答、摘要、标签提取）：默认走本地模型；
- 客户面向的智能客服、复杂报告生成：走在线模型；
- 某一类模型不稳定或限流时：Dify 工作流里做条件判断自动切换。
这样的配置让我在“体验、成本、稳定性”三者之间找到了一个比较舒服的平衡点。接下来的部分就一个一个拆开讲怎么落地。
2. 环境准备：先把 Dify 跑起来
2.1 部署方式该怎么选
Dify 的部署方式有这么几种：Docker Compose（最推荐）、Helm（Kubernetes 环境）、1Panel 应用商店、源码运行。我第一次接触 Dify 是在一台 4C8G 的云服务器上，当时直接用 Docker Compose 一把装好，整个流程大约二十分钟。如果你只是为了学习或在公司内网做验证，Docker Compose 是最合适的选择；如果你已经在用 Kubernetes，Dify 官方也有对应的 Helm Chart，升级和扩缩容都方便。
我建议新手不要一开始就想着从源码编译，或者自己魔改前端，先老老实实用 Docker 方式把核心流程跑通，理解模型、应用、知识库、工作流之间的关系，再考虑深度定制。很多人卡在“部署”这一关太久，最后连模型都还没接上就放弃了，很可惜。Dify 的架构其实不复杂，由 API 服务、Worker、Web 前端、数据库（PostgreSQL）、缓存（Redis）、向量数据库（Weaviate 或 Qdrant）等几个核心组件构成，Docker Compose 会把它们一起编排起来。
2.2 用 Docker Compose 部署的关键步骤
以 Dify 1.17.1 版本为例，官方代码仓库的 docker 目录下已经准备好了完整的编排文件。部署步骤如下：
- 克隆或下载 Dify 源码包，进入
docker目录； - 复制环境变量模板：
cp .env.example .env，这一步很重要，别跳过，.env里包含了所有核心组件的初始化配置； - 按需修改
.env里的端口号、密钥、存储路径等（如果只是本地测试，大多数默认值可以直接用）； - 执行
docker compose up -d启动全部服务； - 等待容器状态变为 healthy 后，访问
http://服务器IP:端口（默认是 80 或 8080），完成初始化安装。
当时我在 Windows 上部署时，在dify-main的 docker 文件夹路径下，右键打开终端输入cp .env.example .env，然后在.env里把EXPOSE_NGINX_PORT改成了8088，避免和本机已有的服务冲突。这个细节看起来小，但如果你机器上已经跑了其他 Web 服务，不改端口会非常被动。
另外.env里的SECRET_KEY是系统用来加密敏感信息的，生产环境一定要改成足够长的随机字符串，不要用默认值。还有向量数据库的存储路径，建议挂载到独立的数据盘，后续知识库数据量起来之后，迁移和备份都方便。
2.3 部署完后的初始化配置要点
服务起来之后，第一件事是注册管理员账号。Dify 会根据你的首个账号初始化工作区，后续所有成员、应用、模型都会被纳入这个工作区管理。如果你有多租户需求，Dify 社区版从某个版本开始也支持多租户模式，可以在用户管理里创建更多空间，但普通使用场景一个工作区就够。
初始化之后，我习惯先到“设置 → 模型供应商”页面里把模型配好，再去创建应用。Dify 的模型供应商页面是一个模型集中管理入口，你所有接进来的模型都会在这里统一显示。它支持的供应商非常多，包括 OpenAI、Azure OpenAI、Anthropic、Google Gemini、AWS Bedrock，以及国产的通义千问、智谱、月之暗面、DeepSeek，还有本地类的 Ollama、Xinference、LocalAI、Hugging Face 等。这也就是为什么我说 Dify 是“模型路由器”，接入不是问题，怎么组织调度才是关键。
部署完之后，强烈建议先用 Dify 自带的“模型测试”对话框，把自己要用的模型都调一遍，看看返回速度和回答质量。这一步花五分钟，省得后面应用建完才发现模型没配好，排错排半天。
3. 接入本地模型：以 Ollama 部署 DeepSeek 为例
3.1 部署 Ollama 和下载模型
本地模型方案里，我体验下来最顺手的是 Ollama。它支持 macOS、Linux、Windows，安装包直接去官网下载，装完就有一个命令行工具。以 DeepSeek 系列模型为例，想下载一个 7B 量级的量化版本，命令非常简单：
ollama pull deepseek-r1:7b它会自动从模型仓库拉取权重并做好格式转换，整个过程你不用关心 GGUF、量化参数之类的细节。如果你的机器显存不大，可以先试试更小的模型，比如qwen2.5:3b或llama3.2:3b，跑顺了再上更大的模型。
我要提醒一句：别盲目追求大参数。我之前在一台只有 8GB 显存的机器上硬跑 32B 模型，结果推理速度慢到没法用，一个简单问题要等三四十秒。后来换成 7B 量化版，速度明显提升，回答质量在内部问答场景里也能接受。选本地模型本质上是在“效果”和“机器配置”之间做平衡，没有最好的模型，只有最合适的。
模型下载完成后，Ollama 默认会在11434端口提供 OpenAI 兼容的 API，不过访问路径和标准 OpenAI 不完全一样。Dify 已经内置了 Ollama 供应商，它会自动拼接正确的接口路径，所以我们只需要在 Dify 里填好 Ollama 的服务地址即可。
3.2 在 Dify 里配置 Ollama 供应商
进入 Dify 的“设置 → 模型供应商”，找到 Ollama，点“添加模型”。需要填写的信息有几项：
- 模型名称：要和
ollama list里显示的模型名完全一致，例如deepseek-r1:7b； - 基础 URL：填 Ollama 服务的地址，比如
http://localhost:11434，如果 Dify 是 Docker 启动而 Ollama 在宿主机上，这里不能填 localhost，要填宿主机 IP 或host.docker.internal，这是新手容易翻车的地方； - 模型类型：选择对话模型或嵌入模型，按实际用途填；
- 上下文长度：根据模型支持的窗口来填，7B 模型一般填 4096 或 8192，填太大会爆显存，填太小又浪费能力。
配完之后，点测试按钮，如果能正常返回就说明通了。如果测试失败，优先检查基础 URL 是否可达——在 Dify 容器里跑curl http://宿主IP:11434，看能不能通。这个排查方法几乎能解决百分之八十的本地模型接入问题。
3.3 本地模型的关键参数配置
Dify 里配置模型时，有几个参数要特别上心：
- Temperature（温度）：控制回答的随机性。做知识问答和抽取类任务，我建议调到 0.2 以下，让输出尽量稳定可控；做头脑风暴或文案生成，可以调到 0.7~0.9。
- Max Tokens（最大输出长度）：决定了单次回复的最长 token 数。本地模型在长文本生成时容易因为达到上限而截断，我一般设置 1024 起步，复杂任务设到 2048。
- 上下文长度：这个参数直接决定你一次能塞进多少资料。Dify 在做知识库检索时，会把检索到的分段拼接进 prompt，如果上下文窗口太小，文档信息会被截断，严重影响回答质量。我之前用 4k 窗口跑知识问答，长文档经常答非所问，后来换成 8k 窗口，问题立刻缓解。
还有一个容易忽略的点：并发数。本地模型服务默认的并发处理能力很弱，如果你把 Dify 应用暴露给多人同时用，建议在 Ollama 的启动参数里设置OLLAMA_NUM_PARALLEL，或者直接控制 Dify 应用的并发限制。我在内部工具里一般限到 4 并发，再多就会出现排队。
3.4 本地模型的实际表现和限制
用了几个月下来，我的体感是：本地模型做“格式化输出、信息抽取、短文本分类、关键词生成”这类任务，效果已经相当能打。比如我让 Dify 工作流自动从客户反馈里抽取“问题类型、紧急程度、涉及模块”三个字段，用 7B 模型跑了 200 条数据，准确率大概在 90% 左右，完全够用。但如果你让它做“基于几十页文档综合回答一个需要推理的问题”，本地模型会明显吃力，回答容易遗漏细节，甚至出现幻觉。
另外本地模型在多语言场景上的表现也需要测试。我有个阿拉伯语的小项目，本地模型生成的阿语质量明显不如在线模型，换成在线模型之后才达标。所以“本地全覆盖”并不现实，混合调用才是正确姿态。
4. 接入在线模型：API Key 配置与模型调优
4.1 在线模型接入前的准备
在线模型接入前，你要先确定两件事：用哪家供应商、预算多少。各大云厂商和大模型公司基本都提供了 OpenAI 兼容的接口，Dify 里也内置了大部分主流供应商。我自己常用的有 OpenAI 系的 GPT 模型、DeepSeek API、通义千问 API。它们的注册流程都很快，拿到 API Key 之后就能在 Dify 里配置。
在线模型的 API Key 一定要妥善保管，特别是公司环境里，不要直接写在前端代码或公开仓库里。Dify 的供应商配置里填好之后，密钥会加密存储，但如果你用 API 的方式二次开发，记得把密钥放在服务端环境变量里。
4.2 OpenAI 兼容接口的配置方法
Dify 支持“OpenAI-API-compatible”这种自定义供应商方式，这意味即使某个模型不在 Dify 的官方供应商列表里，只要它提供 OpenAI 兼容的 HTTP 接口，你都可以手动接进来。配置入口在“模型供应商 → OpenAI-API-compatible”，需要填 API Key、Base URL 和模型 ID。
举个例子。假设你用的是某个国内模型服务，它的 Base URL 是https://api.example.com/v1，模型 ID 是example-chat，那在 Dify 里就是这么填。我之前接过一个第三方模型服务时，官方供应商列表里没有，但是服务商提供了 OpenAI 兼容接口，我用自定义方式五分钟就接上了，非常灵活。
需要注意：Base URL 一定不要漏掉/v1，很多模型服务的路由是挂在/v1下面的，漏了会导致 404。模型 ID 也不能填错，不同厂商的命名规则不一样，去控制台复制是最稳妥的做法。
4.3 在线模型的重要设置
在线模型的配置要关注三个层面：模型版本、上下文参数、超时和重试策略。
模型版本方面，Dify 支持同一个供应商下配置多个模型，你可以把 GPT-4o、GPT-4o mini、DeepSeek-V3 等全部挂上去。这样在应用里就能根据任务类型选择，比如简单任务走 mini 模型省钱，复杂任务走大模型保质量。我实际跑过成本对比，同样一段客服问答，GPT-4o 和 GPT-4o mini 的价格差距能到十倍以上，但回答质量差距在某些任务上很小。上线前多测几个版本，把“便宜且够用”的模型找出来，长期能省不少钱。
上下文参数方面，在线模型通常有较大的上下文窗口，但不要把它当成无限大的垃圾桶。Dify 的知识库检索默认会控制插入 prompt 的分段数量，如果文本量太大，既浪费 token 又可能干扰模型注意力。我一般把“检索分段数”设为 3~5 个，每段 500~800 字，足够回答大多数问题。
超时和重试方面，在线模型偶尔会有抖动。Dify 有默认的请求超时时间，生产环境建议在应用的高级设置里调高一点，尤其是在工作流里串联多个模型调用的时候，超时时间太短容易中途中段。我一般设 120 秒，双保险再加一层重试逻辑，如果第一次返回失败，自动重试一次。
4.4 在线模型调用中的成本控制
成本控制是长期使用在线模型最核心的话题。有几个土办法实测有效：第一，在 Dify 里为应用设置“访客用量限制”，比如单日请求数、单次请求最大 token 数，防止有人误操作刷爆额度；第二，利用工作流把输入压缩后再传给大模型，比如先让一个便宜的模型做摘要或关键词提取，再喂给贵模型；第三，定期检查日志，看哪些应用调用量异常高，及时调整策略。
我踩过一次坑：某天日志里发现一个内部工具有几千次调用，仔细一查，是有人把自动化脚本绑到了这个 API 上，循环调用了一整天。如果当时没有在 Dify 里设置每日配额，那天的费用会非常夸张。所以“成本控制”不是事后看账单，而是提前在平台层面把闸门关好。
5. 混合调用的实战经验：工作流里的一个生产案例
5.1 场景设计：低成本兜底 + 高质量精修
理论讲再多，不如看一个真实跑通的场景。我用 Dify 做了一个内部“合同关键信息提取”应用，流程是这样：用户上传合同 PDF，系统先做 OCR 和文本提取，然后把内容丢给模型，要求输出合同编号、甲方乙方、金额、时间等结构化字段。
这个场景如果全部走在线大模型，单次成本其实不算高，但团队每天要处理上千份合同，积少成多费用就很可观。于是我设计了两级模型调度：先用本地 DeepSeek 7B 做第一轮提取，成功率大约在 85% 左右；剩下 15% 提取失败或置信度低的，再交给在线大模型做精修。整体算下来，在线模型调用量只有原来的 15%，成本降了大半，准确率还比纯本地模型高了不少。
5.2 实现方式：模型切换节点与条件判断
在 Dify 工作流里，实现这种混合调度非常方便。我大致是这样搭建的：
- 开始节点：接收文件或文本输入；
- 预处理节点：用代码节点把文本按规则分段，去掉多余空白；
- 本地模型节点：选择 Ollama 供应商的 DeepSeek 模型，prompt 里写明抽取字段和输出格式（JSON）；
- 判断节点：检查本地模型的输出——如果 JSON 能正常解析，且关键字段不为空，则直接走结果节点；如果解析失败或字段缺失，则进入在线模型节点；
- 在线模型节点：选择 GPT-4o mini 或 DeepSeek API，同样的 prompt 再抽一次；
- 结果节点：汇总输出最终 JSON。
需要注意，Dify 工作流里判断节点支持多种条件。我在判断 JSON 是否有效时，会在本地模型节点的前置代码节点里先把模型输出解析成字典，同时返回一个valid字段，判断节点只判断这个布尔值，逻辑清爽很多，不容易被模型输出的语气词干扰。
5.3 调度效果和成本对比
实际跑了两个月，统计下来是这样：
- 本地模型负责了 80% 以上请求，平均响应时间 4~6 秒；
- 在线模型精修的平均响应时间 8~15 秒；
- 整体提取准确率从纯本地模型的 85% 提升到 96% 左右；
- 月度模型 API 费用比全部走在线模型减少约 70%。
有人可能会问，工作流里加判断节点、加两个模型，响应时间会不会变长？其实不会，因为大多数请求走完本地模型就直接返回了，只有少数“不确定”的请求才走在线模型，只有当判断节点检测到异常才触发精修。相比“每次请求都同时调用两个模型”，这种“失败/低置信度才升级”的模式更经济。
这个思路也可以扩展到别的场景。比如写文章时，先用小模型生成初稿，再用大模型润色；或者在知识库里，先让嵌入模型做粗召回，再让大模型做重排精读。Dify 工作流的条件分支和模型管理结合起来，可玩性非常高。
6. 常见问题与排查技巧实录
6.1 连接失败：“模型测试不通过”怎么办
这是最多人遇到的问题。Dify 里添加模型后点“测试”，结果直接红字报错。我的排查顺序是这样：
- 检查地址：本地模型看 Base URL 是不是
http://宿主机IP:端口，别用localhost；在线模型看 Base URL 是否包含/v1； - 检查模型 ID：本地模型要和
ollama list完全一致，在线模型要看服务商控制台里的准确名称； - 检查密钥：在线模型 401 基本都是 API Key 错了或过期了；
- 看容器日志：执行
docker compose logs api，看 Dify 后端到底报什么错，这一步能定位 90% 的问题。
有次我在 Docker 环境里接 Ollama，怎么都连不上，最后发现 Ollama 只绑定了 127.0.0.1，Dify 容器自然无法访问。解决方式很简单，启动 Ollama 时设置OLLAMA_HOST=0.0.0.0，让它监听所有网卡，再配好防火墙规则。这个问题特别经典，我见过好几个人卡在这里。
6.2 响应慢、超时的问题
本地模型响应慢，先看显存和 CPU 占用。如果显存不够，系统会把部分层卸载到内存，速度直接掉一个量级。用ollama ps查看当前加载的模型和显存占用，如果模型被反复加载卸载，考虑设置OLLAMA_KEEP_ALIVE让模型常驻。在线模型响应慢，先看是不是请求内容太长，或者供应商那段时间负载高。可以试试把知识库分段数调小，或者换一个晚高峰不那么拥堵的模型实例。
另外 Dify 的日志里会记录每次模型调用的耗时，用来判断瓶颈很直观。如果发现主要是“等待上游”时间长，那就是模型服务的问题；如果“上游返回后”处理时间长，可能是工作流里的代码节点或知识库检索拖了后腿。
6.3 回答质量不对、输出格式不稳定
很多人在 Dify 里写 prompt 时，让模型输出 JSON，但模型经常多输出几句废话，导致解析失败。这里我推荐几个改善技巧：
- 在 prompt 里明确写“仅输出 JSON，不要任何解释”，并给一个示例；
- 使用 Dify 的“代码节点”做健壮性解析，用正则把第一个
{到最后一个}之间的内容提取出来，再尝试JSON.parse，失败就抛错误触发重试； - 在模型参数里把 temperature 调低，逻辑任务调到 0~0.2，能让输出稳定非常多。
6.4 上下文长度超出限制
知识库问答最常见的报错是“context length exceeded”。这个问题的本质是，检索到的分片加上系统 prompt、历史对话、用户问题，拼在一起超过了模型的窗口上限。排查思路也很直接：先看模型配置里的上下文长度是否设置正确，再检查知识库检索的分段数量是不是太多，最后看看多轮对话历史是不是越积越长。Dify 支持在应用设置里配置“对话轮次”，限制保留最近几轮历史，超出就截断，能有效降低上下文压力。
我一般把知识库分段数量控制在 3~5 个，分段长度控制在 500~800 个 token 之间，对话历史保留 4~6 轮。这样即使接的是 4k 窗口的小模型，也不容易爆。
最后再分享一个我个人的使用习惯：在 Dify 里每个应用都写好清晰的“系统提示词”，并且在关键节点开启日志追踪。出了问题能快速定位是哪一次调用、哪个模型、哪段输入导致的，而不是到处猜。这个习惯帮我省下了无数排查时间，强烈建议你也试试。
