1. 为什么我决定不再给云端 API 打工去年年底我算了一笔账手上三个小项目一个做合同摘要一个做客服问答还有一个是内部知识库检索。三个项目加起来每个月调用云端大模型 API 的费用稳定在四百到六百块之间。钱不算多但问题不在钱上——有一次线上服务突然返回unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****排查了半天发现是某个中转服务商跑路了密钥直接失效。那天晚上我盯着屏幕第一次认真想我是不是该把核心能力搬回自己手里这就是这套「本地优先、云端兜底」私有 AI 平台的起点。核心思路很朴素日常高频、对延迟敏感的请求走本地模型复杂推理、长上下文、本地扛不住的任务自动切到云端 API。整套东西用 Dify 做编排层Ollama 做本地模型运行时DeepSeek 作为云端兜底的主力模型全部跑在 Docker 里。它适合谁如果你符合下面任意一条这套方案大概率能帮到你手上有几个小项目在调云端 API每月账单让你肉疼但又不敢完全断掉云端数据敏感合同、客户信息、内部文档不想往第三方传但偶尔又需要强模型的能力想学 Dify 和 Ollama但被dify ssl错误、ollama下载慢、dify unstructured api url is not configured for doc file processing这类报错劝退过单纯想搞一套能离线跑、断网也能用的 AI 工作台。我踩过的坑基本都在这篇里了包括 Docker 安装、Ollama 离线包、Dify 迁移、知识库流水线、上下文超长这些具体问题。下面按我实际搭建的顺序讲。2. 整体架构设计与选型逻辑2.1 三层结构编排层、推理层、兜底层先把架构说清楚不然后面每一步都会觉得莫名其妙。整套平台分三层编排层是 Dify。它负责工作流、知识库、Prompt 管理、对话历史、API 网关。你可以把它理解成一个「AI 应用的操作系统」所有请求先到它这里由它决定这个请求该走本地还是走云端。Dify 本身不跑模型它只做调度。推理层是 Ollama。它跑在本地负责加载和运行开源模型比如 Qwen、Llama、DeepSeek 的蒸馏版本。Ollama 的好处是模型管理极简一条ollama run就能拉起来而且支持 GPU 加速。它的短板是并发能力弱长上下文吃内存凶。兜底层是 DeepSeek 云端 API。当本地模型判断「这活儿我干不了」——比如上下文超过本地模型窗口、需要复杂推理、或者本地服务挂了——Dify 的工作流会把请求转发到 DeepSeek。DeepSeek 的 API 价格在同类里算便宜的作为兜底成本可控。为什么是这三件套而不是别的组合我对比过几种方案方案优势劣势我的判断纯云端 API省事、模型强贵、数据外流、服务商风险不适合长期纯本地 Ollama免费、数据不出门弱模型效果差、并发低只能做轻量任务Dify Ollama DeepSeek成本可控、数据可控、能力可扩展搭建有门槛最终选择LangChain 自研灵活工作量大、维护累不划算Dify 的价值在于它把「本地优先、云端兜底」这个逻辑做成了可视化工作流。你不需要写代码去判断「这个请求该走哪」在 Dify 里拖两个节点、加一个条件分支就行。这是它比 LangChain 自研省事的地方。2.2 「本地优先、云端兜底」的判定规则怎么定这是整套方案的核心。判定逻辑我放在 Dify 的工作流里规则大致是先看输入长度。如果用户输入加上知识库召回内容的总 token 数超过本地模型的上下文窗口比如本地跑的是 8K 窗口的模型直接走云端。这就是热词里dify工作流 上下文超长和api error: 400 this models maximum context length is 1048576 tokens要解决的问题——本地模型窗口小硬塞会报错。再看任务类型。简单分类、抽取、改写走本地复杂推理、多步规划、代码生成走云端。最后看本地健康状态。Dify 工作流里加一个 HTTP 节点探测 Ollama 的/api/tags如果本地服务没响应全部走云端。这三条规则不是拍脑袋定的。第一条是因为本地模型窗口普遍在 4K 到 32K 之间超过就崩第二条是因为小模型在简单任务上和大模型差距不大但复杂任务差距明显第三条是保命——本地服务挂了不能让整个应用瘫痪。提示判定规则不要写太复杂。我一开始搞了五六个条件分支结果调试起来痛不欲生。三条足够覆盖 90% 的场景。2.3 为什么用 Docker 而不是裸装热词里docker、docker安装、docker desktop、docker安装教程出现频率很高说明很多人卡在这一步。我用 Docker 的理由很直接Dify 官方就是 Docker Compose 部署裸装要自己配 PostgreSQL、Redis、Weaviate 一堆依赖纯属自找麻烦Ollama 也有官方镜像docker run一行起来GPU 直通配置也成熟迁移方便。热词里有dify迁移Docker 方案下迁移就是打包 volume 和.env换台机器docker compose up就完事。裸装不是不行但你要做好花一整天配环境的心理准备。Docker 方案半小时能跑起来。3. 环境准备与 Docker 落地实操3.1 Docker 安装Windows 和 Linux 的坑不一样先说 Windows。热词里dify 安装 windows、docker desktop安装教程是高频问题。Windows 上装 Docker Desktop 有几个硬性前提必须开 WSL2。Docker Desktop 在 Windows 上依赖 WSL2 后端不开的话启动会卡在「Docker Engine starting」。BIOS 里要开虚拟化。Intel 叫 VT-xAMD 叫 SVM不开的话 WSL2 起不来。内存至少给 8G。Dify 全家桶API、Worker、Web、PostgreSQL、Redis、Weaviate加起来吃 4G 起步Ollama 再跑个 7B 模型又要 5G16G 内存的机器比较舒服。Linux 上简单得多一条命令curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER装完记得重新登录让用户组生效。然后验证docker version docker compose versiondocker compose version要能输出 v2 以上Dify 的 compose 文件用的是 v2 语法。注意如果你在国内docker pull拉镜像慢是常态。配置镜像加速器能缓解具体在 Docker Desktop 的 Settings → Docker Engine 里改registry-mirrorsLinux 上改/etc/docker/daemon.json。这一步不做后面拉 Dify 镜像能等到你怀疑人生。3.2 Ollama 部署离线包和下载慢的解法热词里ollama下载慢、ollama下载太慢了、ollama离线安装包、ollama国内镜像源全是痛点。我分两种情况说。情况一能联网但慢。Ollama 本体安装包不大慢的是模型文件。一个 7B 模型动辄 4G 到 8G从官方源拉确实煎熬。解法是配置镜像源或者用ollama pull的时候挂后台慢慢拉别盯着看。情况二完全离线。这是我实际用的方案因为部署环境在内网。步骤是在有网的机器上装好 Ollamaollama pull把需要的模型拉下来模型文件默认在~/.ollama/modelsLinux/Mac或C:\Users\你的用户名\.ollama\modelsWindows把整个models目录打包拷到目标机器对应位置目标机器装好 Ollama 本体启动后ollama list就能看到模型。用 Docker 跑 Ollama 的话模型目录要挂载出来否则容器一删模型全没docker run -d \ --gpus all \ -v ollama_data:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama--gpus all是 GPU 直通前提是装了 NVIDIA Container Toolkit。没 GPU 就删掉这行纯 CPU 也能跑就是慢。提示ollama run qwen3.5:2b error: 500 internal server error: llama-server process这个报错我遇到过。八成是模型文件损坏或者内存不够。先ollama rm删掉模型重新拉还不行就看内存——2B 模型至少要 4G 可用内存。3.3 Dify 部署从 clone 到跑起来Dify 的部署流程官方文档写得清楚我补充几个实际会卡的点。git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d跑起来后访问http://localhost:3000第一次会让你设管理员账号。卡点一dify ssl错误。这个多半是访问时用了 HTTPS 但证书没配好或者反向代理配置有问题。本地开发直接用http://localhost:3000别折腾 SSL。要上 HTTPS 就正经配 Nginx 和证书别用自签证书糊弄。卡点二dify an error occurred during credentials validation。这是配置模型供应商时密钥校验失败。检查两件事密钥有没有多余空格以及网络能不能通到供应商。本地 Ollama 的话Dify 在 Docker 里Ollama 在宿主机Dify 里填的地址不能是localhost要用host.docker.internalWindows/Mac或宿主机内网 IPLinux。卡点三dify unstructured api url is not configured for doc file processing。这是知识库处理文档时报的。Dify 默认用 Unstructured 做文档解析但没配 URL。解法是在.env里配UNSTRUCTURED_API_URL或者干脆在知识库设置里换用 Dify 内置的解析器。我后来用的是内置解析器简单文档够用。4. 核心环节本地与云端的协同实现4.1 在 Dify 里接入 OllamaDify 接入 Ollama 的路径是设置 → 模型供应商 → Ollama → 添加模型。关键参数模型名称填ollama list里显示的名字比如qwen2.5:7b基础 URLhttp://host.docker.internal:11434Docker 内访问宿主机模型类型LLM上下文长度填模型实际窗口比如 8192。这个值填错会导致上下文超长报错。填完点保存Dify 会去探测 Ollama。探测失败的话先在宿主机上curl http://localhost:11434/api/tags确认 Ollama 活着再确认 Docker 网络能通到宿主机。4.2 在 Dify 里接入 DeepSeek 云端DeepSeek 的接入更简单因为它兼容 OpenAI 的接口格式。在模型供应商里选 OpenAI-API-compatible填API BaseDeepSeek 的接口地址API Key你的密钥模型名称填 DeepSeek 的模型标识。热词里deepseek api如何调用、codex接入deepseek都是这个路子。DeepSeek 的接口和 OpenAI 一致所以任何支持 OpenAI 格式的工具都能接。注意密钥别硬编码在代码里也别提交到 Git。Dify 里配置的密钥是存在数据库里的相对安全但.env文件里的密钥要注意权限。4.3 工作流里实现「本地优先、云端兜底」这是整套方案最核心的部分。在 Dify 里新建一个工作流节点顺序是开始节点接收用户输入代码节点计算输入 token 数粗略按字符数除以 1.5 估算条件分支节点判断 token 数是否超过本地模型窗口分支 A未超调用 Ollama 模型分支 B超了调用 DeepSeek 模型结束节点返回结果。代码节点里算 token 的 Python 大概是def main(text: str) - dict: # 粗略估算中文约 1 字符 1.5 token英文约 4 字符 1 token estimated_tokens len(text) * 1.5 return {tokens: estimated_tokens}条件分支里判断tokens 8000就走云端。这个 8000 是本地模型的窗口按你实际用的模型改。再加一层健康检查在工作流开头加一个 HTTP 请求节点请求http://host.docker.internal:11434/api/tags超时设 2 秒。如果失败直接走云端分支。这样本地服务挂了也不影响使用。4.4 知识库流水线的搭建热词里dify知识库流水线、weknora dify、mineru api都指向知识库。Dify 的知识库流程是上传文档 → 解析 → 分块 → 向量化 → 存储。几个实操要点分块大小默认 500 字符我一般调到 800 到 1000。太小召回碎片化太大检索不准。向量模型本地跑的话用 Ollama 拉一个 embedding 模型比如nomic-embed-text。云端的话用 DeepSeek 或智谱的 embedding 接口。检索方式混合检索向量 关键词比纯向量准尤其是专有名词多的场景。dify unstructured api url is not configured这个报错就是在这条流水线上出的。如果你不想配 Unstructured在知识库设置里把解析器换成 Dify 内置的简单 PDF 和 Word 够用。复杂排版文档才需要 Unstructured 或 MinerU。5. 常见问题与排查速查表5.1 报错速查表报错信息大概率原因解法unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****密钥失效、填错、或中转服务跑路检查密钥、换直连官方接口dify ssl错误反向代理证书问题本地用 HTTP线上正经配证书dify an error occurred during credentials validation密钥校验失败或网络不通检查密钥空格、检查 Docker 到宿主机网络dify unstructured api url is not configured for doc file processing未配 Unstructured配 URL 或换内置解析器api error: 400 this models maximum context length is 1048576 tokens输入超模型窗口缩短输入或切云端模型ollama run qwen3.5:2b error: 500 internal server error: llama-server process模型损坏或内存不足重拉模型、加内存ollama下载太慢了官方源慢配镜像源或用离线包dify工作流 上下文超长本地模型窗口小工作流里加长度判断超了走云端5.2 我踩过的三个坑坑一Docker 里访问 localhost 是容器自己。我第一次配 Ollama 地址填了localhost:11434怎么都连不上。后来才反应过来Dify 跑在容器里localhost指的是容器本身不是宿主机。改成host.docker.internal立刻通了。Linux 上这个域名默认不生效要么加--add-hosthost.docker.internal:host-gateway要么直接用宿主机内网 IP。坑二模型窗口填大了。Dify 里配 Ollama 模型时上下文长度我随手填了 32768结果本地模型实际只有 8192一超就报错。填之前一定ollama show 模型名看清楚实际窗口。坑三知识库向量模型和检索模型不一致。我一开始用 A 模型做向量化后来换了 B 模型做检索结果召回全是乱的。向量模型一旦定了就别换换了要重新向量化整个知识库。5.3 性能调优的几个经验本地模型跑得慢是常态几个提速手段用 GPU。CPU 跑 7B 模型一秒出几个字GPU 能到几十个字。有显卡一定用上。量化模型。q4_K_M量化版本比全精度小一半速度快一倍效果损失可接受。限制并发。Ollama 并发能力弱Dify 工作流里别开高并发否则请求排队。缓存高频结果。Dify 支持响应缓存重复问题直接返回缓存省算力。6. 迁移与扩展这套平台还能怎么用6.1 Dify 迁移的正确姿势热词里dify迁移是个高频需求。Docker 方案下迁移分三步备份数据卷。Dify 的数据在dify/docker/volumes下整个目录打包备份.env。所有配置都在这里包括密钥、数据库密码新机器上还原。装好 Docker把 volumes 和.env放回原位docker compose up -d。注意数据库版本要一致PostgreSQL 大版本不一致可能起不来。迁移前先docker compose down别在运行中拷数据。6.2 扩展方向这套平台搭好后能扩展的地方不少接入更多本地模型。Ollama 支持模型很多按任务类型配不同模型分类用小模型、生成用大模型加一层 API 网关。Dify 自带 API但要做鉴权、限流、计费的话前面加个网关更稳接更多云端兜底。除了 DeepSeek还能接智谱、通义等Dify 里配多个供应商工作流里按需切换做多租户。Dify 支持多工作区团队用的话按项目分工作区权限隔离。6.3 成本对比搭之前和搭之后最后说下实际成本。搭之前纯云端每月四百到六百。搭之后本地模型跑日常任务占总量约 70%成本为零电费忽略云端兜底占 30%每月一百出头一次性投入是硬件如果本来就有能跑模型的机器等于零。省下的不只是钱还有数据不出门的安心以及不再被某个服务商的密钥失效搞到半夜爬起来排查。我个人在实际操作中的体会是这套方案最大的价值不是省钱而是把控制权拿回自己手里。云端 API 该用还用但它从「唯一依赖」变成了「可替换的兜底」。哪天某个服务商出问题本地这套照样转业务不断。这种底气是纯云端方案给不了的。如果你也在被 API 账单和服务稳定性折磨建议从 Ollama 跑一个本地模型开始先感受下本地推理的延迟和效果再决定要不要上 Dify 做完整编排。一步一步来别一上来就搭全家桶容易劝退。