1. 为什么我决定不再给云端 API 打工1.1 一个让我彻底破防的账单夜晚去年冬天的一个凌晨我盯着后台的 API 调用账单发呆。那个月我做了三个小工具一个帮团队整理会议纪要一个给客户做文档问答还有一个自己用的代码片段检索。三个项目加起来一个月烧掉了将近四百块。钱不算多但问题在于——我根本不知道这些钱花在哪了。每次调试、每次重试、每次上下文塞太长都在悄悄扣费。更别提有两次因为密钥泄露被人刷了几百次调用等我发现的时候已经来不及了。那一刻我意识到我其实是在给 API 打工。我的产品逻辑、我的数据、我的成本全都攥在别人手里。于是我开始琢磨一件事能不能搭一套「本地优先、云端兜底」的私有 AI 平台平时用本地模型跑遇到本地扛不住的任务再切云端既保住数据隐私又控制成本还不至于因为本地算力不够而卡死。这套方案我前后折腾了大概两个月中间踩了无数坑最终稳定跑起来的组合是Dify Ollama DeepSeek全部用Docker编排。下面我把整套思路、选型理由、实操步骤和踩坑记录完整写出来你照着抄作业基本能少走八成弯路。1.2 这套平台到底解决了什么问题先说清楚它是什么。Dify 是一个开源的 LLM 应用开发平台你可以把它理解成一个「AI 应用的操作系统」——工作流编排、知识库、Agent、API 发布它都管。Ollama 是本地大模型的运行时一条命令就能把模型拉下来跑起来省去了自己配 CUDA、编译推理引擎的麻烦。DeepSeek 则是云端兜底的那一环当本地模型搞不定长上下文或者复杂推理时把请求转给它。它解决的问题很具体第一数据不出内网。日常的文档问答、内部知识检索全部走本地模型敏感内容不经过任何第三方。第二成本可控。本地推理只吃电费云端只在必要时调用账单从每月几百降到几十。第三不牺牲体验。本地模型能力有限但配合云端兜底用户感知不到差别。适合谁来参考我觉得三类人最合适一是像我这样自己折腾小工具的个人开发者二是中小团队里负责内部效率工具的同学三是对数据隐私有要求、但又不想完全放弃大模型能力的场景。如果你只是想跑个 demo那没必要搞这么复杂直接用云端 API 就行。但如果你打算长期做点东西这套架构值得投入。1.3 整体架构长什么样在动手之前先把架构在脑子里过一遍不然后面配置会乱。整套系统分三层接入层Dify 作为统一入口对外暴露 Web 界面和 API。所有请求先到 Dify由它决定走本地还是云端。推理层Ollama 跑本地模型DeepSeek 作为云端备选。Dify 通过模型供应商配置同时接入两者。基础设施层Docker 负责编排所有服务包括 Dify 的 API、Worker、Web、数据库、向量库以及 Ollama 容器。关键设计点是「路由策略」。Dify 本身支持配置多个模型供应商你可以在工作流里用条件判断决定走哪个。比如 token 数小于某个阈值走本地超过就走云端或者按任务类型分简单问答走本地复杂推理走云端。这个策略是整套方案的核心后面会详细讲。2. 选型背后的取舍为什么是这三个2.1 Dify 凭什么当这个「中枢」市面上做 LLM 应用编排的工具不少LangChain、Flowise、FastGPT 都有人用。我最后选 Dify主要看中三点。第一是开箱即用的完整度。Dify 自带知识库、工作流、Agent、API 发布、日志监控你不用自己拼装。我之前用 LangChain 搭过类似的东西光是知识库的文档解析、分块、向量化就得写一大堆代码Dify 直接给你做好了。第二是模型供应商的抽象做得好。它把不同厂商的模型统一成一套接口切换模型只需要改配置不用动业务代码。这对「本地优先、云端兜底」这种需要频繁切换的场景太重要了。第三是社区活跃。遇到问题搜一下基本都有答案这对个人开发者来说是救命稻草。当然它也有缺点。Dify 的默认部署比较重一套下来六七个容器对机器有一定要求。而且它的工作流在某些复杂逻辑上不如直接写代码灵活。但综合来看对于我这种想快速搭起来、又不想维护太多自研代码的人Dify 是最优解。2.2 Ollama 的定位本地推理的「傻瓜相机」Ollama 最大的价值就是把本地大模型的门槛拉到了地板上。以前跑本地模型你得装 CUDA、配 PyTorch、下载权重、写推理脚本一套下来半天没了。Ollama 一条ollama run就搞定模型自动下载、自动量化、自动管理显存。我实测下来Ollama 在消费级显卡上的表现足够日常使用。比如 7B 到 14B 级别的模型一张 12G 显存的卡就能跑得挺顺。它支持模型的热加载和卸载不会一直占着显存。而且它的 API 兼容 OpenAI 格式Dify 接入几乎零成本。但要注意Ollama 不是万能的。它的并发能力有限默认配置下同时处理多个请求会排队。而且它对长上下文的支持取决于模型本身不是 Ollama 能解决的。所以它适合做「日常主力」不适合做「高并发生产」。这也是为什么需要云端兜底。2.3 DeepSeek 作为兜底便宜、够用、接口友好兜底模型的选择我纠结了很久。OpenAI 太贵国内几家大厂的模型接口各有各的坑。最后选 DeepSeek理由很实在价格便宜到离谱能力又足够强。它的 API 价格大概是主流模型的几十分之一长上下文支持也好处理那些本地模型搞不定的任务绰绰有余。接口方面DeepSeek 完全兼容 OpenAI 的调用格式Dify 里直接选 OpenAI 供应商、改一下 base_url 和 key 就能用。这点很省事。我实测下来把复杂推理任务转给 DeepSeek响应速度和结果质量都让人满意。需要提醒的是兜底不代表可以无脑用。云端调用依然有成本和隐私问题所以路由策略要设计好不能什么都往云端丢。我的原则是本地能做的绝不外发本地做不好的才兜底。2.4 Docker 编排让一切可复现用 Docker 的理由很简单可复现、可迁移、可回滚。这套系统涉及多个服务手动装的话环境依赖能把你逼疯。Docker Compose 一份配置文件换台机器docker compose up就能跑起来。而且 Dify 官方就提供了 docker-compose 模板Ollama 也有官方镜像组合起来很自然。我建议所有服务都跑在同一个 Docker 网络里这样容器之间用服务名互相访问不用管 IP。数据卷一定要挂出来不然容器一删数据全没这个坑我踩过。3. 从零开始环境准备与 Docker 部署实操3.1 硬件与系统的最低要求先说硬件这决定了你能跑多大的模型。我的测试机配置是CPU 是 8 核内存 32G显卡是一张 12G 显存的卡硬盘 512G SSD。这套配置跑 7B 到 14B 的量化模型没问题再大就吃力了。如果你没有独立显卡纯 CPU 也能跑但速度会慢很多。7B 模型在纯 CPU 上大概每秒几个 token日常问答勉强能用但体验一般。我的建议是如果只是尝鲜纯 CPU 够了如果要长期用至少搞一张 8G 以上显存的卡。系统方面Linux 最省心Windows 和 macOS 也能跑但坑多一些。Windows 上 Docker Desktop 需要开启 WSL2显卡直通要额外配置。macOS 的 Apple Silicon 芯片跑 Ollama 其实挺香统一内存架构对大模型友好但 Docker 里的 GPU 加速支持不如 Linux。3.2 Docker 与 Docker Compose 安装Linux 上装 Docker 我用的是官方脚本一条命令搞定curl -fsSL https://get.docker.com | sh sudo systemctl enable docker sudo systemctl start docker装完之后把当前用户加进 docker 组免得每次都要 sudosudo usermod -aG docker $USER newgrp dockerDocker Compose 现在一般是插件形式装 Docker 的时候会一起带上。验证一下docker compose versionWindows 用户直接去官网下 Docker Desktop安装时勾选 WSL2 后端。装完在设置里把「Use WSL 2 based engine」打开。macOS 用户下 Docker Desktop for Mac 就行Apple Silicon 选 ARM 版本。注意Windows 上如果遇到 Docker Desktop 启动失败八成是 WSL2 没装好或者虚拟化没开。去 BIOS 里确认 VT-x 或 AMD-V 是开启状态然后在 PowerShell 里跑wsl --install装好 WSL2。3.3 拉取 Dify 并配置环境变量Dify 官方仓库里有 docker 目录直接 clone 下来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 # 密钥用于加密敏感信息生成一个随机的 SECRET_KEYyour_random_secret_keySECRET_KEY可以用openssl rand -base64 42生成。这个值一旦设定就不要改改了会导致已加密的数据解不开。配置好之后启动docker compose up -d第一次启动会拉镜像Dify 的镜像加起来有好几个 G网速慢的话耐心等。启动完成后访问http://localhost:8080能看到登录页就成功了。首次访问会让你设置管理员账号。3.4 Ollama 的部署与模型拉取Ollama 我建议单独跑一个容器和 Dify 在同一个 Docker 网络里。在 Dify 的 docker 目录下新建一个docker-compose.ollama.ymlservices: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - 11434:11434 volumes: - ./ollama_data:/root/.ollama networks: - ssrf_proxy_network - default deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] networks: ssrf_proxy_network: external: true注意ssrf_proxy_network是 Dify 默认创建的网络用docker network ls能看到实际名字可能是docker_ssrf_proxy_network这种带前缀的按实际情况改。启动 Ollamadocker compose -f docker-compose.ollama.yml up -d然后进容器拉模型docker exec -it ollama ollama pull qwen2.5:7b模型选择上我推荐几个实测好用的qwen2.5:7b中文能力强日常问答够用llama3.1:8b英文和通用推理不错如果显存够qwen2.5:14b效果明显更好。拉模型的时候如果下载慢可以配置镜像源具体方法后面踩坑部分讲。3.5 在 Dify 里接入本地与云端模型Ollama 跑起来之后回到 Dify 后台配置模型供应商。进入「设置」-「模型供应商」找到 Ollama点添加模型模型名称填qwen2.5:7b和你拉下来的名字一致基础 URL填http://ollama:11434用容器名因为同网络模型类型选 LLM保存后测试一下能通就说明本地模型接好了。接着配 DeepSeek 兜底。在模型供应商里找 OpenAI因为 DeepSeek 兼容 OpenAI 格式添加模型名称deepseek-chatAPI Key你的 DeepSeek 密钥基础 URLhttps://api.deepseek.com/v1保存测试。两个都通了之后你就有了一套「本地 云端」的双模型环境。4. 核心机制路由策略与工作流设计4.1 本地优先、云端兜底的路由逻辑这是整套方案最核心的部分。路由策略决定了什么时候用本地、什么时候用云端。我的设计原则是三条第一按 token 长度分流。本地模型上下文窗口有限比如 7B 模型通常 8K 到 32K。如果输入超过这个长度直接走云端。在 Dify 工作流里可以用代码节点计算 token 数然后条件分支。第二按任务类型分流。简单问答、文档检索、格式转换这类任务本地完全够用。复杂推理、长文写作、代码生成这类对能力要求高的走云端。第三按可用性兜底。如果本地模型调用失败或者超时自动重试云端。这个可以用 Dify 的错误处理机制实现。具体实现上我在工作流里加了一个「路由节点」用条件判断def main(input_text: str, task_type: str) - dict: # 粗略估算 token 数中文按 1.5 字符/token estimated_tokens len(input_text) / 1.5 # 本地模型上下文上限留点余量 local_limit 6000 if task_type in [reasoning, long_form, code]: return {route: cloud} elif estimated_tokens local_limit: return {route: cloud} else: return {route: local}这个逻辑不复杂但效果很明显。我统计过日常使用中大概 70% 的请求走本地30% 走云端成本降了一大截。4.2 知识库的本地化处理Dify 的知识库功能是它的一大亮点但默认的文档解析走的是云端服务。如果你对数据隐私有要求得把这块也本地化。Dify 支持配置本地的 unstructured API 来做文档解析。你需要单独部署一个 unstructured 服务然后在 Dify 的环境变量里配置UNSTRUCTURED_API_URLhttp://unstructured:8000这样文档解析就在本地完成了不会外发。向量化也一样Dify 支持用本地的 embedding 模型比如通过 Ollama 跑nomic-embed-textdocker exec -it ollama ollama pull nomic-embed-text然后在 Dify 的模型供应商里把 embedding 模型指向 Ollama。这样从文档解析到向量存储整条链路都在本地。提示知识库的分块策略很影响检索效果。我的经验是技术文档按 500 到 800 字符分块重叠 100 字符对话记录按轮次分块。分块太大检索不准太小上下文不完整。4.3 工作流中的上下文管理上下文超长是本地模型最常见的报错。Dify 工作流里如果直接把整个知识库检索结果塞进 prompt很容易超过本地模型的窗口限制。我的做法是加一个「上下文压缩」节点。检索回来的文档先做一次重排序只保留最相关的 top 3 到 top 5然后再拼进 prompt。Dify 自带重排序模型配置也可以用本地的 bge-reranker。另外对话历史也要控制。多轮对话时只保留最近几轮更早的做摘要。这个在 Dify 的对话型应用里可以配置「记忆窗口」大小。实测下来经过这两步处理本地模型的上下文溢出问题基本消失了。5. 踩坑实录那些让我熬夜的问题5.1 SSL 错误与网络问题的排查Dify 部署过程中最常见的报错之一就是 SSL 相关。典型表现是容器启动后访问页面报证书错误或者调用外部 API 时报 SSL 验证失败。原因通常是容器内的 CA 证书过期或者缺失。解决办法是进容器更新证书docker exec -it docker-api-1 bash apt-get update apt-get install -y ca-certificates update-ca-certificates如果是调用外部 API 报 SSL 错误检查一下是不是走了代理但代理配置不对。Dify 的 ssrf_proxy 容器负责出站请求它的配置在.env里的SSRF_PROXY_HTTP_URL和SSRF_PROXY_HTTPS_URL。如果不需要代理把这两个留空。还有一个坑是 Docker 的 DNS 问题。容器内解析不了域名导致拉模型或者调 API 失败。可以在 docker-compose 里给服务加 DNS 配置dns: - 8.8.8.8 - 114.114.114.1145.2 401 与 400 报错的定位思路unexpected status 401 unauthorized: incorrect api key provided这个报错我见过太多次了。401 就是密钥问题排查顺序是先确认密钥有没有复制错前后空格、换行都算再确认密钥有没有过期最后确认调用的 base_url 和密钥是不是匹配的。比如你拿 DeepSeek 的密钥去调 OpenAI 的地址肯定 401。400 报错里最常见的是上下文超长this models maximum context length is 1048576 tokens。这个报错说明你塞给模型的输入超过了它的窗口限制。解决办法就是前面说的上下文压缩或者换更大窗口的模型。注意不同模型的窗口大小不一样配置的时候要对应好。还有一种 400 是参数格式问题比如 temperature 设成了字符串、max_tokens 设成了负数。Dify 的模型配置里这些参数都有校验但如果你在代码节点里手动构造请求就得自己保证格式正确。5.3 Ollama 下载慢与离线安装ollama pull下载慢是国内用户的普遍痛点。几个应对方案第一用国内镜像源。设置环境变量export OLLAMA_HOST0.0.0.0然后在拉模型时指定镜像具体镜像地址会变建议搜一下当前可用的。第二离线安装。在有网的机器上把模型拉下来模型文件在~/.ollama/models目录整个打包拷到目标机器对应目录。注意目录结构要保持一致。第三用ollama create从本地 GGUF 文件导入。如果你已经下载了 GGUF 格式的模型文件写一个 ModelfileFROM ./qwen2.5-7b.Q4_K_M.gguf然后ollama create mymodel -f Modelfile就能导入。5.4 容器启动失败的常见原因Docker 容器起不来先看日志docker compose logs -f api几个高频原因端口被占用改.env里的端口、数据卷权限不对chown一下、内存不够Dify 全套跑起来至少 8G 内存、镜像拉取不完整docker compose pull重新拉。还有一个隐蔽的坑是.env文件里的变量有特殊字符没转义导致解析失败。密码里如果有$、#这些要用引号包起来。6. 常见问题速查与优化建议6.1 问题速查表报错/现象可能原因解决办法SSL 证书错误容器 CA 证书缺失进容器更新 ca-certificates401 unauthorized密钥错误或过期检查密钥、base_url 匹配400 context length输入超过模型窗口压缩上下文或换大窗口模型Ollama 下载慢网络问题用镜像源或离线导入容器启动失败端口/权限/内存查日志逐项排查本地模型响应慢显存不足或模型太大换小模型或量化版本知识库检索不准分块策略不当调整分块大小和重叠工作流超时本地推理排队增加并发或走云端兜底6.2 性能优化的几个实操技巧第一模型量化。Ollama 默认拉的模型很多是 Q4 量化如果你显存够可以换 Q5 或 Q8效果更好。但要注意显存占用会上升。第二显存管理。Ollama 默认会在模型闲置一段时间后卸载可以通过OLLAMA_KEEP_ALIVE环境变量控制。设成-1是永不卸载适合频繁调用的场景设成0是用完就卸适合显存紧张。第三并发控制。Ollama 的OLLAMA_NUM_PARALLEL控制并发数默认是 1。如果你的卡显存够可以调到 2 或 4提升吞吐。但别调太高会 OOM。第四缓存。Dify 支持对相同请求做缓存在.env里开启CACHE_ENABLEDtrue。对于重复性高的问答场景能省不少算力。6.3 数据备份与迁移Dify 的数据分几块PostgreSQL 存应用配置和日志向量库存知识库向量文件存储存上传的文档。备份的时候三块都要覆盖。PostgreSQL 备份docker exec -t docker-db-1 pg_dump -U postgres dify backup.sql向量库如果是 weaviate数据在数据卷里直接打包卷目录。文件存储在docker/volumes/app/storage目录。迁移的时候把这三块恢复到新机器然后改一下.env里的配置docker compose up -d就能跑起来。注意SECRET_KEY必须和原来一致否则加密数据解不开。7. 我实际用下来的几点体会这套平台我跑了小半年最大的感受是「掌控感」回来了。以前用云端 API模型什么时候变、价格什么时候涨、服务什么时候挂我完全被动。现在本地模型是基本盘云端只是补充主动权在自己手里。成本上我算过一笔账本地推理的电费一个月大概十几块云端调用因为只走 30% 的请求一个月二三十块。加起来五十块左右比之前纯云端省了八成多。而且数据隐私这块彻底放心了内部文档问答全部本地闭环。当然也有不满意的地方。本地模型的能力天花板确实存在遇到特别复杂的任务还是得靠云端。而且维护这套系统需要一定的技术底子不是装完就一劳永逸得时不时看看日志、调调参数。最后分享一个小技巧如果你也想搭这套建议先用最小配置跑通别一上来就追求完美。先让 Dify 和 Ollama 跑起来接一个本地模型能问答了再慢慢加知识库、加路由、加云端兜底。一步步来每步都验证比一次性配一大堆然后到处报错要高效得多。我当初就是贪心想一次配全结果卡在 SSL 错误上折腾了一整晚后来拆开来一步步弄反而顺了。