1. 从给 API 打工说起为什么我决定自己搭一套 AI 平台去年有段时间我每个月的 API 账单都在四位数上下浮动。项目里跑的是文档摘要、知识库问答、代码辅助这几类任务调用量不算夸张但架不住单价摆在那里再加上偶尔手滑写了个死循环一晚上就能烧掉小几百。更让人难受的是有些内部资料根本不敢往云端送——不是技术问题是合规和保密的问题。那段时间我一直在想一件事能不能把大部分日常推理放在本地只在真正需要大模型能力的时候才走云端这个想法落地之后就是标题里说的这套东西Dify 做编排层Ollama 做本地推理引擎DeepSeek 做云端兜底。三者各司其职Dify 负责工作流、知识库、对话管理这些业务逻辑Ollama 负责把开源模型跑在自己的机器上DeepSeek 则作为能力上限的补充处理本地模型搞不定的复杂任务。这套架构解决的核心问题有三个。第一是成本可控日常 80% 的请求走本地只有 20% 的硬骨头才调用云端 API账单直接砍掉一大半。第二是数据可控敏感文档在本地完成向量化和推理不出内网。第三是能力可控本地模型能力不足时能无缝切换到云端不会因为本地模型答不上来就卡住整个流程。适合谁来参考如果你满足下面任意一条这篇内容应该对你有用手上有闲置的显卡或者一台配置还行的机器团队有内部文档问答、知识库检索的需求被 API 账单折磨过或者单纯想搞清楚 Dify、Ollama、DeepSeek 这三样东西到底怎么串起来。我会把选型逻辑、部署步骤、踩过的坑、以及本地优先、云端兜底这个策略具体怎么配置全部讲清楚。需要提前说明的是这套方案不是一键部署的玩具中间涉及 Docker、模型量化、路由策略这些需要动手的环节。但只要你跟着走一遍后面维护起来其实很省心。我自己这套环境跑了小半年除了偶尔更新模型基本没怎么动过。2. 三层架构的选型逻辑为什么是 Dify Ollama DeepSeek2.1 Dify 在这套体系里到底扮演什么角色很多人第一次接触 Dify会把它当成又一个聊天界面。这就把它看小了。Dify 真正的价值在于它是一个LLM 应用编排平台——你可以用可视化工作流把接收问题 → 检索知识库 → 组装提示词 → 调用模型 → 后处理 → 返回结果这一整条链路串起来而且每个环节都能替换。在这套架构里Dify 承担的是大脑皮层的角色。它不负责推理负责的是决定谁来推理、用什么上下文推理、推理完怎么处理。具体来说知识库管理文档上传、切分、向量化、检索Dify 内置了完整的 RAG 流水线。你不需要自己写 LangChain 代码配置一下就能用。工作流编排条件分支、循环、代码节点、HTTP 请求节点这些让本地优先、云端兜底的策略可以真正落地成逻辑。模型接入层Dify 支持接入 OpenAI 兼容接口的模型。Ollama 暴露的就是 OpenAI 兼容接口DeepSeek 官方 API 也是 OpenAI 兼容格式所以两者可以挂在同一个 Dify 实例下用同一个工作流调度。对话与应用管理多轮对话、变量、会话记忆这些Dify 都帮你处理了。我选 Dify 而不是自己用 FastAPI 撸一套核心原因是省时间。自己写一套 RAG 工作流引擎光是文档切分策略、向量检索调优、会话管理这些就够折腾一两个月而且 bug 一堆。Dify 把这些都做成了开箱即用的模块我只需要关注业务逻辑。2.2 Ollama 为什么比直接跑 llama.cpp 更省事本地推理引擎的选择其实不少llama.cpp、vLLM、Text Generation Inference、Ollama。我最后选 Ollama理由很实际。llama.cpp 性能确实好但你要自己编译、自己管理模型文件、自己写 HTTP 服务包装。vLLM 吞吐量高但显存要求也高而且对消费级显卡的兼容性不如 Ollama 友好。Ollama 的优势在于它把模型下载、量化版本管理、服务暴露、GPU 调度这些脏活全包了。一条ollama run qwen2.5:7b就能把模型拉下来跑起来它自动根据你的硬件选择合适量化的版本。而且 Ollama 默认在11434端口暴露 OpenAI 兼容接口Dify 直接填http://host.docker.internal:11434/v1就能接上几乎零配置。当然 Ollama 也有它的短板后面讲踩坑的时候我会细说比如并发能力弱、长上下文处理吃内存、模型切换有延迟。但对于个人和小团队场景它的性价比是最高的。2.3 DeepSeek 作为兜底层选它的理由和边界云端兜底为什么选 DeepSeek 而不是别的三个原因。第一是价格。DeepSeek 的 API 定价在同类里属于相当能打的尤其是输入侧的价格做知识库问答这种输入长、输出短的场景特别划算。第二是能力它在中文理解、代码、推理这几块的表现应付本地小模型搞不定的任务是够的。第三是接口兼容OpenAI 格式Dify 接入零成本。但要注意边界DeepSeek 是兜底不是主力。如果所有请求都走它那这套架构就失去意义了。所以关键在于路由策略——什么情况下走本地什么情况下切云端。这个我后面会用具体的工作流配置来讲。2.4 三者组合的架构全景把这三层串起来数据流是这样的层级组件职责部署位置编排层Dify工作流、知识库、对话管理、路由决策Docker 容器本地推理层Ollama跑开源模型处理日常请求宿主机或独立容器云端兜底层DeepSeek API处理复杂任务、长上下文、高难度推理云端存储层PostgreSQL Redis 向量库Dify 的元数据、缓存、向量索引Docker 容器请求进来之后Dify 先做意图判断和知识库检索然后根据预设规则决定走 Ollama 还是 DeepSeek。简单问答、文档摘要、格式转换这类走本地复杂推理、超长上下文、本地模型明确答不好的走云端。返回结果统一由 Dify 后处理用户侧感知不到背后换了模型。这套架构的精髓在于降级和兜底是自动的。本地模型超时或者返回质量不达标工作流可以自动重试到云端用户那边只是稍微慢一点不会报错。3. 部署实操从 Docker 到模型跑通3.1 Docker 环境准备与 Dify 部署Dify 官方推荐用 Docker Compose 部署这是最省事的方式。前提是你机器上装了 Docker 和 Docker Compose。Windows 用户装 Docker Desktop 就行Mac 用户同理Linux 用户直接装 docker-ce 和 docker-compose-plugin。拉代码git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env然后关键一步改.env里的配置。默认配置能跑但有几个地方建议调整# 暴露端口默认 80如果被占用改成别的 EXPOSE_NGINX_PORT8080 # 数据库密码生产环境务必改 POSTGRES_PASSWORDyour_strong_password # 向量库选择默认 weaviate也可以换 qdrant VECTOR_STOREweaviate改完直接起docker compose up -d第一次拉镜像会比较慢耐心等。起来之后访问http://localhost:8080会让你设置管理员账号。这一步做完Dify 本体就 OK 了。注意Docker Desktop 在 Windows 上默认给容器的内存有限Dify 全家桶api、worker、web、db、redis、weaviate、nginx跑起来大概要 4-6G 内存。如果你机器内存紧张建议在 Docker Desktop 设置里把内存上限调到 8G 以上否则容器会莫名其妙被 OOM kill。3.2 Ollama 安装与模型拉取的加速技巧Ollama 的安装Linux 一条命令curl -fsSL https://ollama.com/install.sh | shWindows 和 Mac 直接下安装包。装完之后验证ollama --version接下来是拉模型。这里有个大坑默认从官方源拉模型国内速度可能慢到怀疑人生。一个 7B 的模型几个 G慢的时候能拉一晚上。解决办法有两个。一是用离线安装包Ollama 的模型文件本质上是 GGUF 格式你可以从其他渠道下载好 GGUF 文件然后用 Modelfile 导入# 创建一个 Modelfile cat Modelfile EOF FROM ./qwen2.5-7b-instruct-q4_k_m.gguf PARAMETER temperature 0.7 PARAMETER num_ctx 8192 EOF # 导入 ollama create qwen2.5-local -f Modelfile二是配置镜像源。Ollama 支持通过环境变量指定模型仓库地址具体配置方式根据你使用的镜像服务而定这里不展开。核心思路就是别硬扛官方源的龟速提前准备好模型文件能省掉大量等待时间。模型选择上我的建议是场景推荐模型显存需求说明日常问答、摘要qwen2.5:7b6-8G中文好速度快代码辅助qwen2.5-coder:7b6-8G代码专用补全强轻量任务qwen2.5:3b4G配置低的机器用复杂推理deepseek-r1:14b12G本地推理天花板拉模型ollama pull qwen2.5:7b ollama pull qwen2.5-coder:7b拉完测试一下ollama run qwen2.5:7b 用一句话解释什么是RAG能正常返回就说明本地推理通了。3.3 让 Dify 连上 Ollama那个经典的连接问题这是最容易卡住的一步。Dify 跑在 Docker 容器里Ollama 跑在宿主机上容器默认是访问不到宿主机的localhost的。解决方案是在 Dify 的模型配置里把 Ollama 的地址填成http://host.docker.internal:11434host.docker.internal是 Docker 提供的一个特殊域名指向宿主机。Linux 上如果这个域名不生效可以在docker-compose.yml里给 api 和 worker 服务加一行extra_hosts: - host.docker.internal:host-gateway然后在 Dify 后台设置 → 模型供应商 → Ollama填上地址模型名称填qwen2.5:7b保存。如果连接成功会显示模型列表。注意Ollama 默认只监听127.0.0.1:11434容器访问不到。需要设置环境变量OLLAMA_HOST0.0.0.0:11434让它监听所有网卡。Linux 上改 systemd 服务文件Windows 上在系统环境变量里加。3.4 DeepSeek API 接入与密钥管理DeepSeek 的接入就简单多了。去官网申请 API Key然后在 Dify 的模型供应商里选 OpenAI 兼容填Base URL:https://api.deepseek.com/v1API Key: 你的 key模型名:deepseek-chat或deepseek-reasoner保存即可。这里有个常见的报错unexpected status 401 unauthorized: incorrect api key provided。这个错误 90% 的情况是 key 填错了或者 key 前后有空格。还有一种情况是你复制的时候把sk-前缀漏了。检查一遍基本能解决。密钥管理上千万别把 key 硬编码在工作流的代码节点里。Dify 支持环境变量把 key 放在环境变量里工作流里引用变量名。这样迁移和分享工作流的时候不会泄露。4. 本地优先、云端兜底的路由策略怎么落地4.1 判断该走本地还是云端的几个维度这是整套架构的灵魂。路由策略设计得好成本和体验都能兼顾设计得烂要么本地模型被滥用导致体验差要么云端调用过多导致账单爆炸。我用的判断维度有四个第一任务类型。文档摘要、格式转换、简单问答、关键词提取这类模式化任务本地模型完全够用。复杂推理、多步计算、代码调试、长文档深度分析这些交给云端。第二输入长度。本地模型的上下文窗口有限qwen2.5:7b 默认 8K超过这个长度要么截断要么报错。所以输入超过一定阈值我设的是 6000 token就直接走云端。第三本地模型置信度。这个稍微复杂一点。我让本地模型在回答时附带一个自评如果它明确表示不确定或者回答明显敷衍就触发云端重试。第四用户显式指定。有些场景用户就是想要最好的结果那就直接走云端不用绕。4.2 用 Dify 工作流实现条件路由在 Dify 里新建一个工作流结构大概是这样开始节点 ↓ 知识库检索节点可选 ↓ 条件分支节点判断输入长度、任务类型 ↓ ├─ 分支A本地模型Ollama │ ↓ │ 质量检查节点 │ ↓ │ ├─ 合格 → 输出 │ └─ 不合格 → 转分支B │ └─ 分支B云端模型DeepSeek ↓ 输出条件分支的配置用 Dify 的表达式{{#start.query#}} 的长度 6000 或者 {{#start.task_type#}} complex满足就走云端否则走本地。质量检查节点可以用一个代码节点实现判断本地模型的输出是否包含我不确定无法回答这类关键词或者输出长度是否异常短。命中就标记为不合格。4.3 兜底触发条件与降级处理兜底不只是本地答不好就切云端还要考虑本地服务本身挂掉的情况。我遇到过几次 Ollama 进程被系统 OOM kill 的情况这时候如果工作流还傻傻地等本地模型用户就会一直卡着。所以我在工作流里加了超时控制。Dify 的模型调用节点可以设置超时时间我设的是 30 秒。超过 30 秒没返回直接走云端分支。降级处理的逻辑触发条件处理方式本地模型超时30s切云端本地模型返回质量不合格切云端输入超长6000 token直接走云端本地服务不可用切云端并记录告警云端也不可用返回友好提示建议稍后重试这套逻辑跑下来用户侧基本感知不到背后的切换只是偶尔响应慢一点。4.4 实测数据本地和云端的成本与延迟对比我拿实际跑的数据做了个对比任务类型是500 字文档摘要跑 100 次取平均指标Ollama (qwen2.5:7b)DeepSeek API平均延迟3.2 秒2.1 秒单次成本约 0.002 元电费约 0.015 元质量评分主观7.5/109/10并发能力弱1-2 并发强延迟上云端反而更快因为本地显卡不是顶级卡。但成本上本地优势明显100 次摘要本地花 2 毛云端花 1 块 5。量大了差距就出来了。所以我的策略是质量要求不高的批量任务走本地质量要求高的走云端。比如批量给文档打标签本地跑给客户生成正式报告走云端。5. 踩坑实录那些让我熬夜的报错5.1 Dify 安装时的 SSL 错误与网络问题第一次装 Dify 的时候docker compose up卡在拉镜像那一步报 SSL 错误。这个问题的根源是 Docker 拉镜像走的是默认源网络不稳定。解决办法是配置镜像加速。在 Docker Desktop 的设置里或者 Linux 的/etc/docker/daemon.json里加{ registry-mirrors: [ https://your-mirror.example.com ] }改完重启 Docker 服务。具体用哪个镜像源根据你所在网络环境选择可用的。还有一个坑是 Dify 的 web 容器启动后访问白屏。这个通常是 nginx 配置或者前端资源加载问题检查docker compose logs nginx和docker compose logs web能看到具体报错。多数情况是端口冲突或者.env里CONSOLE_API_URL配置不对。5.2 Ollama 模型加载失败与显存不足ollama run qwen3.5:2b报500 internal server error: llama-server process这个错误我遇到过好几次。原因通常是显存不够。模型加载需要显存如果显卡被其他进程占用或者模型量化版本选大了就会加载失败。解决方法是换更小的量化版本比如从 q4 换到 q4_k_m 或者 q3。模型文件损坏。下载中断会导致文件不完整删掉重新拉。Ollama 版本和模型不兼容。升级 Ollama 到最新版。查看显存占用nvidia-smi如果显存快满了先停掉其他占显存的进程。5.3 401 报错与 API Key 的那些坑unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****这个报错我见过太多次了。排查顺序检查 key 是否完整有没有多余空格检查 key 是否过期或者额度用完检查 Base URL 是否写对DeepSeek 是https://api.deepseek.com/v1别写成别的检查模型名是否正确deepseek-chat和deepseek-reasoner是两个不同的模型还有一种情况是 Dify 的凭证校验报an error occurred during credentials validation这个通常是网络问题Dify 容器访问不到 DeepSeek 的 API。检查容器的网络配置确认能出网。5.4 上下文超长与知识库处理报错api error: 400 this models maximum context length is 1048576 tokens这个报错看着吓人其实意思是你的输入超过了模型上限。虽然 100 万 token 听起来很多但如果你把整个知识库塞进去还是会超。解决办法是控制检索返回的文档数量。Dify 的知识库检索节点可以设置 Top K 和 Score 阈值别一次返回太多。我一般设 Top K 3Score 阈值 0.7只返回最相关的几段。另一个报错dify unstructured api url is not configured for doc file processing这个是因为你上传了 Dify 默认解析器处理不了的文档格式比如某些 PDF 或者扫描件需要配置 Unstructured API。如果你不需要处理复杂格式把文档转成 txt 或 markdown 再上传就行。5.5 工作流上下文超长的处理经验Dify 工作流跑多轮对话的时候上下文会累积。跑久了就会遇到上下文超长的问题。我的处理方式是会话记忆限制轮数。Dify 的会话变量可以设置最大保留轮数我设的是 10 轮超过就丢弃最早的。知识库检索结果做摘要。如果检索回来的文档很长先用本地模型做一次摘要再把摘要塞进上下文。长文档分段处理。不要一次性把整个文档塞进去切成段分别处理再汇总。6. 让这套平台真正好用的几个进阶配置6.1 知识库流水线的切分策略调优Dify 的知识库默认切分是固定长度但不同文档类型适合不同的切分方式。我的经验技术文档按标题层级切分每个小节一段保留上下文。FAQ 类按问答对切分一问一答作为一个 chunk。长篇文章按段落切分每段 300-500 字重叠 50 字。切分粒度直接影响检索质量。切太碎检索到的片段缺乏上下文切太大检索精度下降。我一般先用默认配置跑一遍看看检索效果再针对性调整。6.2 模型切换的平滑过渡本地模型和云端模型的输出风格不一样切换的时候用户能感觉到。我的做法是在工作流最后加一个风格统一节点用固定的提示词把输出格式规范化。这样不管背后是哪个模型用户看到的格式是一致的。另外切换的时候可以在响应里加一个不显眼的标记方便自己排查问题但用户侧不展示。6.3 监控与告警知道什么时候该扩容跑了一段时间之后你需要知道本地模型的负载情况。我用的方案是Ollama 的日志里能看到每次请求的耗时和 token 数Dify 的日志里能看到工作流的执行情况用一个简单的脚本定时检查 Ollama 服务是否存活如果发现本地模型经常超时说明该升级硬件或者调整路由策略了。如果云端调用比例持续上升说明本地模型能力跟不上需求该考虑换更大的模型。6.4 数据备份与迁移注意事项Dify 的数据都在 Docker volume 里迁移的时候别只备份代码要把 volume 一起备份。关键数据包括PostgreSQL 数据工作流、知识库元数据向量库数据文档向量上传的文件备份命令docker compose down docker run --rm -v dify_postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_backup.tar.gz /data docker compose up -d迁移到新机器的时候把 volume 恢复回去改一下.env里的地址配置基本就能无缝切换。7. 我个人在实际操作中的几点体会这套平台我断断续续维护了小半年最大的感受是本地优先不是目的成本和质量的最优平衡才是。一开始我有点执念什么都想走本地结果用户体验很差本地模型答得慢还答不好。后来调整了策略把本地定位成处理 80% 简单任务云端处理20% 复杂任务整体体验才上来。另一个体会是别追求一步到位。我一开始想搞得很复杂又是多模型路由又是自动评估结果配置了一堆自己都记不住。后来简化成长度 任务类型两个判断维度反而稳定好用。工具是为人服务的别被工具绑架。最后分享一个小技巧给本地模型设置合理的超时时间。我一开始设的 60 秒结果用户等得花儿都谢了。后来改成 30 秒超时直接切云端用户感知好很多。本地模型快的时候几秒就返回慢的时候 30 秒也够呛能出好结果不如早点切。这套东西后续还能扩展比如接入更多本地模型做 A/B 测试或者把知识库做成多租户隔离。但那是后面的事了先把基础跑稳再说。 
长河君 · 2026/10/3 11:14:49 · 阅读 1.2k Dify+Ollama+DeepSeek：本地优先、云端兜底的AI平台实战
1. 从给 API 打工说起为什么我决定自己搭一套 AI 平台去年有段时间我每个月的 API 账单都在四位数上下浮动。项目里跑的是文档摘要、知识库问答、代码辅助这几类任务调用量不算夸张但架不住单价摆在那里再加上偶尔手滑写了个死循环一晚上就能烧掉小几百。更让人难受的是有些内部资料根本不敢往云端送——不是技术问题是合规和保密的问题。那段时间我一直在想一件事能不能把大部分日常推理放在本地只在真正需要大模型能力的时候才走云端这个想法落地之后就是标题里说的这套东西Dify 做编排层Ollama 做本地推理引擎DeepSeek 做云端兜底。三者各司其职Dify 负责工作流、知识库、对话管理这些业务逻辑Ollama 负责把开源模型跑在自己的机器上DeepSeek 则作为能力上限的补充处理本地模型搞不定的复杂任务。这套架构解决的核心问题有三个。第一是成本可控日常 80% 的请求走本地只有 20% 的硬骨头才调用云端 API账单直接砍掉一大半。第二是数据可控敏感文档在本地完成向量化和推理不出内网。第三是能力可控本地模型能力不足时能无缝切换到云端不会因为本地模型答不上来就卡住整个流程。适合谁来参考如果你满足下面任意一条这篇内容应该对你有用手上有闲置的显卡或者一台配置还行的机器团队有内部文档问答、知识库检索的需求被 API 账单折磨过或者单纯想搞清楚 Dify、Ollama、DeepSeek 这三样东西到底怎么串起来。我会把选型逻辑、部署步骤、踩过的坑、以及本地优先、云端兜底这个策略具体怎么配置全部讲清楚。需要提前说明的是这套方案不是一键部署的玩具中间涉及 Docker、模型量化、路由策略这些需要动手的环节。但只要你跟着走一遍后面维护起来其实很省心。我自己这套环境跑了小半年除了偶尔更新模型基本没怎么动过。2. 三层架构的选型逻辑为什么是 Dify Ollama DeepSeek2.1 Dify 在这套体系里到底扮演什么角色很多人第一次接触 Dify会把它当成又一个聊天界面。这就把它看小了。Dify 真正的价值在于它是一个LLM 应用编排平台——你可以用可视化工作流把接收问题 → 检索知识库 → 组装提示词 → 调用模型 → 后处理 → 返回结果这一整条链路串起来而且每个环节都能替换。在这套架构里Dify 承担的是大脑皮层的角色。它不负责推理负责的是决定谁来推理、用什么上下文推理、推理完怎么处理。具体来说知识库管理文档上传、切分、向量化、检索Dify 内置了完整的 RAG 流水线。你不需要自己写 LangChain 代码配置一下就能用。工作流编排条件分支、循环、代码节点、HTTP 请求节点这些让本地优先、云端兜底的策略可以真正落地成逻辑。模型接入层Dify 支持接入 OpenAI 兼容接口的模型。Ollama 暴露的就是 OpenAI 兼容接口DeepSeek 官方 API 也是 OpenAI 兼容格式所以两者可以挂在同一个 Dify 实例下用同一个工作流调度。对话与应用管理多轮对话、变量、会话记忆这些Dify 都帮你处理了。我选 Dify 而不是自己用 FastAPI 撸一套核心原因是省时间。自己写一套 RAG 工作流引擎光是文档切分策略、向量检索调优、会话管理这些就够折腾一两个月而且 bug 一堆。Dify 把这些都做成了开箱即用的模块我只需要关注业务逻辑。2.2 Ollama 为什么比直接跑 llama.cpp 更省事本地推理引擎的选择其实不少llama.cpp、vLLM、Text Generation Inference、Ollama。我最后选 Ollama理由很实际。llama.cpp 性能确实好但你要自己编译、自己管理模型文件、自己写 HTTP 服务包装。vLLM 吞吐量高但显存要求也高而且对消费级显卡的兼容性不如 Ollama 友好。Ollama 的优势在于它把模型下载、量化版本管理、服务暴露、GPU 调度这些脏活全包了。一条ollama run qwen2.5:7b就能把模型拉下来跑起来它自动根据你的硬件选择合适量化的版本。而且 Ollama 默认在11434端口暴露 OpenAI 兼容接口Dify 直接填http://host.docker.internal:11434/v1就能接上几乎零配置。当然 Ollama 也有它的短板后面讲踩坑的时候我会细说比如并发能力弱、长上下文处理吃内存、模型切换有延迟。但对于个人和小团队场景它的性价比是最高的。2.3 DeepSeek 作为兜底层选它的理由和边界云端兜底为什么选 DeepSeek 而不是别的三个原因。第一是价格。DeepSeek 的 API 定价在同类里属于相当能打的尤其是输入侧的价格做知识库问答这种输入长、输出短的场景特别划算。第二是能力它在中文理解、代码、推理这几块的表现应付本地小模型搞不定的任务是够的。第三是接口兼容OpenAI 格式Dify 接入零成本。但要注意边界DeepSeek 是兜底不是主力。如果所有请求都走它那这套架构就失去意义了。所以关键在于路由策略——什么情况下走本地什么情况下切云端。这个我后面会用具体的工作流配置来讲。2.4 三者组合的架构全景把这三层串起来数据流是这样的层级组件职责部署位置编排层Dify工作流、知识库、对话管理、路由决策Docker 容器本地推理层Ollama跑开源模型处理日常请求宿主机或独立容器云端兜底层DeepSeek API处理复杂任务、长上下文、高难度推理云端存储层PostgreSQL Redis 向量库Dify 的元数据、缓存、向量索引Docker 容器请求进来之后Dify 先做意图判断和知识库检索然后根据预设规则决定走 Ollama 还是 DeepSeek。简单问答、文档摘要、格式转换这类走本地复杂推理、超长上下文、本地模型明确答不好的走云端。返回结果统一由 Dify 后处理用户侧感知不到背后换了模型。这套架构的精髓在于降级和兜底是自动的。本地模型超时或者返回质量不达标工作流可以自动重试到云端用户那边只是稍微慢一点不会报错。3. 部署实操从 Docker 到模型跑通3.1 Docker 环境准备与 Dify 部署Dify 官方推荐用 Docker Compose 部署这是最省事的方式。前提是你机器上装了 Docker 和 Docker Compose。Windows 用户装 Docker Desktop 就行Mac 用户同理Linux 用户直接装 docker-ce 和 docker-compose-plugin。拉代码git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env然后关键一步改.env里的配置。默认配置能跑但有几个地方建议调整# 暴露端口默认 80如果被占用改成别的 EXPOSE_NGINX_PORT8080 # 数据库密码生产环境务必改 POSTGRES_PASSWORDyour_strong_password # 向量库选择默认 weaviate也可以换 qdrant VECTOR_STOREweaviate改完直接起docker compose up -d第一次拉镜像会比较慢耐心等。起来之后访问http://localhost:8080会让你设置管理员账号。这一步做完Dify 本体就 OK 了。注意Docker Desktop 在 Windows 上默认给容器的内存有限Dify 全家桶api、worker、web、db、redis、weaviate、nginx跑起来大概要 4-6G 内存。如果你机器内存紧张建议在 Docker Desktop 设置里把内存上限调到 8G 以上否则容器会莫名其妙被 OOM kill。3.2 Ollama 安装与模型拉取的加速技巧Ollama 的安装Linux 一条命令curl -fsSL https://ollama.com/install.sh | shWindows 和 Mac 直接下安装包。装完之后验证ollama --version接下来是拉模型。这里有个大坑默认从官方源拉模型国内速度可能慢到怀疑人生。一个 7B 的模型几个 G慢的时候能拉一晚上。解决办法有两个。一是用离线安装包Ollama 的模型文件本质上是 GGUF 格式你可以从其他渠道下载好 GGUF 文件然后用 Modelfile 导入# 创建一个 Modelfile cat Modelfile EOF FROM ./qwen2.5-7b-instruct-q4_k_m.gguf PARAMETER temperature 0.7 PARAMETER num_ctx 8192 EOF # 导入 ollama create qwen2.5-local -f Modelfile二是配置镜像源。Ollama 支持通过环境变量指定模型仓库地址具体配置方式根据你使用的镜像服务而定这里不展开。核心思路就是别硬扛官方源的龟速提前准备好模型文件能省掉大量等待时间。模型选择上我的建议是场景推荐模型显存需求说明日常问答、摘要qwen2.5:7b6-8G中文好速度快代码辅助qwen2.5-coder:7b6-8G代码专用补全强轻量任务qwen2.5:3b4G配置低的机器用复杂推理deepseek-r1:14b12G本地推理天花板拉模型ollama pull qwen2.5:7b ollama pull qwen2.5-coder:7b拉完测试一下ollama run qwen2.5:7b 用一句话解释什么是RAG能正常返回就说明本地推理通了。3.3 让 Dify 连上 Ollama那个经典的连接问题这是最容易卡住的一步。Dify 跑在 Docker 容器里Ollama 跑在宿主机上容器默认是访问不到宿主机的localhost的。解决方案是在 Dify 的模型配置里把 Ollama 的地址填成http://host.docker.internal:11434host.docker.internal是 Docker 提供的一个特殊域名指向宿主机。Linux 上如果这个域名不生效可以在docker-compose.yml里给 api 和 worker 服务加一行extra_hosts: - host.docker.internal:host-gateway然后在 Dify 后台设置 → 模型供应商 → Ollama填上地址模型名称填qwen2.5:7b保存。如果连接成功会显示模型列表。注意Ollama 默认只监听127.0.0.1:11434容器访问不到。需要设置环境变量OLLAMA_HOST0.0.0.0:11434让它监听所有网卡。Linux 上改 systemd 服务文件Windows 上在系统环境变量里加。3.4 DeepSeek API 接入与密钥管理DeepSeek 的接入就简单多了。去官网申请 API Key然后在 Dify 的模型供应商里选 OpenAI 兼容填Base URL:https://api.deepseek.com/v1API Key: 你的 key模型名:deepseek-chat或deepseek-reasoner保存即可。这里有个常见的报错unexpected status 401 unauthorized: incorrect api key provided。这个错误 90% 的情况是 key 填错了或者 key 前后有空格。还有一种情况是你复制的时候把sk-前缀漏了。检查一遍基本能解决。密钥管理上千万别把 key 硬编码在工作流的代码节点里。Dify 支持环境变量把 key 放在环境变量里工作流里引用变量名。这样迁移和分享工作流的时候不会泄露。4. 本地优先、云端兜底的路由策略怎么落地4.1 判断该走本地还是云端的几个维度这是整套架构的灵魂。路由策略设计得好成本和体验都能兼顾设计得烂要么本地模型被滥用导致体验差要么云端调用过多导致账单爆炸。我用的判断维度有四个第一任务类型。文档摘要、格式转换、简单问答、关键词提取这类模式化任务本地模型完全够用。复杂推理、多步计算、代码调试、长文档深度分析这些交给云端。第二输入长度。本地模型的上下文窗口有限qwen2.5:7b 默认 8K超过这个长度要么截断要么报错。所以输入超过一定阈值我设的是 6000 token就直接走云端。第三本地模型置信度。这个稍微复杂一点。我让本地模型在回答时附带一个自评如果它明确表示不确定或者回答明显敷衍就触发云端重试。第四用户显式指定。有些场景用户就是想要最好的结果那就直接走云端不用绕。4.2 用 Dify 工作流实现条件路由在 Dify 里新建一个工作流结构大概是这样开始节点 ↓ 知识库检索节点可选 ↓ 条件分支节点判断输入长度、任务类型 ↓ ├─ 分支A本地模型Ollama │ ↓ │ 质量检查节点 │ ↓ │ ├─ 合格 → 输出 │ └─ 不合格 → 转分支B │ └─ 分支B云端模型DeepSeek ↓ 输出条件分支的配置用 Dify 的表达式{{#start.query#}} 的长度 6000 或者 {{#start.task_type#}} complex满足就走云端否则走本地。质量检查节点可以用一个代码节点实现判断本地模型的输出是否包含我不确定无法回答这类关键词或者输出长度是否异常短。命中就标记为不合格。4.3 兜底触发条件与降级处理兜底不只是本地答不好就切云端还要考虑本地服务本身挂掉的情况。我遇到过几次 Ollama 进程被系统 OOM kill 的情况这时候如果工作流还傻傻地等本地模型用户就会一直卡着。所以我在工作流里加了超时控制。Dify 的模型调用节点可以设置超时时间我设的是 30 秒。超过 30 秒没返回直接走云端分支。降级处理的逻辑触发条件处理方式本地模型超时30s切云端本地模型返回质量不合格切云端输入超长6000 token直接走云端本地服务不可用切云端并记录告警云端也不可用返回友好提示建议稍后重试这套逻辑跑下来用户侧基本感知不到背后的切换只是偶尔响应慢一点。4.4 实测数据本地和云端的成本与延迟对比我拿实际跑的数据做了个对比任务类型是500 字文档摘要跑 100 次取平均指标Ollama (qwen2.5:7b)DeepSeek API平均延迟3.2 秒2.1 秒单次成本约 0.002 元电费约 0.015 元质量评分主观7.5/109/10并发能力弱1-2 并发强延迟上云端反而更快因为本地显卡不是顶级卡。但成本上本地优势明显100 次摘要本地花 2 毛云端花 1 块 5。量大了差距就出来了。所以我的策略是质量要求不高的批量任务走本地质量要求高的走云端。比如批量给文档打标签本地跑给客户生成正式报告走云端。5. 踩坑实录那些让我熬夜的报错5.1 Dify 安装时的 SSL 错误与网络问题第一次装 Dify 的时候docker compose up卡在拉镜像那一步报 SSL 错误。这个问题的根源是 Docker 拉镜像走的是默认源网络不稳定。解决办法是配置镜像加速。在 Docker Desktop 的设置里或者 Linux 的/etc/docker/daemon.json里加{ registry-mirrors: [ https://your-mirror.example.com ] }改完重启 Docker 服务。具体用哪个镜像源根据你所在网络环境选择可用的。还有一个坑是 Dify 的 web 容器启动后访问白屏。这个通常是 nginx 配置或者前端资源加载问题检查docker compose logs nginx和docker compose logs web能看到具体报错。多数情况是端口冲突或者.env里CONSOLE_API_URL配置不对。5.2 Ollama 模型加载失败与显存不足ollama run qwen3.5:2b报500 internal server error: llama-server process这个错误我遇到过好几次。原因通常是显存不够。模型加载需要显存如果显卡被其他进程占用或者模型量化版本选大了就会加载失败。解决方法是换更小的量化版本比如从 q4 换到 q4_k_m 或者 q3。模型文件损坏。下载中断会导致文件不完整删掉重新拉。Ollama 版本和模型不兼容。升级 Ollama 到最新版。查看显存占用nvidia-smi如果显存快满了先停掉其他占显存的进程。5.3 401 报错与 API Key 的那些坑unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****这个报错我见过太多次了。排查顺序检查 key 是否完整有没有多余空格检查 key 是否过期或者额度用完检查 Base URL 是否写对DeepSeek 是https://api.deepseek.com/v1别写成别的检查模型名是否正确deepseek-chat和deepseek-reasoner是两个不同的模型还有一种情况是 Dify 的凭证校验报an error occurred during credentials validation这个通常是网络问题Dify 容器访问不到 DeepSeek 的 API。检查容器的网络配置确认能出网。5.4 上下文超长与知识库处理报错api error: 400 this models maximum context length is 1048576 tokens这个报错看着吓人其实意思是你的输入超过了模型上限。虽然 100 万 token 听起来很多但如果你把整个知识库塞进去还是会超。解决办法是控制检索返回的文档数量。Dify 的知识库检索节点可以设置 Top K 和 Score 阈值别一次返回太多。我一般设 Top K 3Score 阈值 0.7只返回最相关的几段。另一个报错dify unstructured api url is not configured for doc file processing这个是因为你上传了 Dify 默认解析器处理不了的文档格式比如某些 PDF 或者扫描件需要配置 Unstructured API。如果你不需要处理复杂格式把文档转成 txt 或 markdown 再上传就行。5.5 工作流上下文超长的处理经验Dify 工作流跑多轮对话的时候上下文会累积。跑久了就会遇到上下文超长的问题。我的处理方式是会话记忆限制轮数。Dify 的会话变量可以设置最大保留轮数我设的是 10 轮超过就丢弃最早的。知识库检索结果做摘要。如果检索回来的文档很长先用本地模型做一次摘要再把摘要塞进上下文。长文档分段处理。不要一次性把整个文档塞进去切成段分别处理再汇总。6. 让这套平台真正好用的几个进阶配置6.1 知识库流水线的切分策略调优Dify 的知识库默认切分是固定长度但不同文档类型适合不同的切分方式。我的经验技术文档按标题层级切分每个小节一段保留上下文。FAQ 类按问答对切分一问一答作为一个 chunk。长篇文章按段落切分每段 300-500 字重叠 50 字。切分粒度直接影响检索质量。切太碎检索到的片段缺乏上下文切太大检索精度下降。我一般先用默认配置跑一遍看看检索效果再针对性调整。6.2 模型切换的平滑过渡本地模型和云端模型的输出风格不一样切换的时候用户能感觉到。我的做法是在工作流最后加一个风格统一节点用固定的提示词把输出格式规范化。这样不管背后是哪个模型用户看到的格式是一致的。另外切换的时候可以在响应里加一个不显眼的标记方便自己排查问题但用户侧不展示。6.3 监控与告警知道什么时候该扩容跑了一段时间之后你需要知道本地模型的负载情况。我用的方案是Ollama 的日志里能看到每次请求的耗时和 token 数Dify 的日志里能看到工作流的执行情况用一个简单的脚本定时检查 Ollama 服务是否存活如果发现本地模型经常超时说明该升级硬件或者调整路由策略了。如果云端调用比例持续上升说明本地模型能力跟不上需求该考虑换更大的模型。6.4 数据备份与迁移注意事项Dify 的数据都在 Docker volume 里迁移的时候别只备份代码要把 volume 一起备份。关键数据包括PostgreSQL 数据工作流、知识库元数据向量库数据文档向量上传的文件备份命令docker compose down docker run --rm -v dify_postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_backup.tar.gz /data docker compose up -d迁移到新机器的时候把 volume 恢复回去改一下.env里的地址配置基本就能无缝切换。7. 我个人在实际操作中的几点体会这套平台我断断续续维护了小半年最大的感受是本地优先不是目的成本和质量的最优平衡才是。一开始我有点执念什么都想走本地结果用户体验很差本地模型答得慢还答不好。后来调整了策略把本地定位成处理 80% 简单任务云端处理20% 复杂任务整体体验才上来。另一个体会是别追求一步到位。我一开始想搞得很复杂又是多模型路由又是自动评估结果配置了一堆自己都记不住。后来简化成长度 任务类型两个判断维度反而稳定好用。工具是为人服务的别被工具绑架。最后分享一个小技巧给本地模型设置合理的超时时间。我一开始设的 60 秒结果用户等得花儿都谢了。后来改成 30 秒超时直接切云端用户感知好很多。本地模型快的时候几秒就返回慢的时候 30 秒也够呛能出好结果不如早点切。这套东西后续还能扩展比如接入更多本地模型做 A/B 测试或者把知识库做成多租户隔离。但那是后面的事了先把基础跑稳再说。